From seandarcy2 at gmail.com Wed Nov 1 02:06:26 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 31 Oct 2006 21:06:26 -0500 Subject: no repository available for repo extras-devel?? Message-ID: yum update for extras-devel: [extras-development] name=Fedora Extras - Development Tree mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=extras-devel&arch=$basearch and indeed: http://mirrors.fedoraproject.org/mirrorlist?repo=extras-devel&arch=x86_64 gives: # no repository available for repo extras-devel yet http://mirrors.fedoraproject.org/ shows: http://mirrors.fedoraproject.org/extras-devel-US-x86_64.txt which contains a number of mirrors. ?? sean From jpmahowald at gmail.com Wed Nov 1 05:50:26 2006 From: jpmahowald at gmail.com (John Mahowald) Date: Wed, 1 Nov 2006 23:50:26 +1800 Subject: Join the Devel Team In-Reply-To: <1162333688.5425.2.camel@localhost.localdomain> References: <1162333688.5425.2.camel@localhost.localdomain> Message-ID: <3ea997540610312150k359c2911wcb9bbce6cef94c6e@mail.gmail.com> On 11/1/06, Jovan Spasojevic wrote: > Hi, > > i would be like to involved in the devel team too. i don't know if i had > join the devel-group. > what's the stepps? > > There are a variety of tasks that need help here: http://fedoraproject.org/wiki/HelpWanted John From buildsys at redhat.com Wed Nov 1 11:11:39 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 1 Nov 2006 06:11:39 -0500 Subject: rawhide report: 20061101 changes Message-ID: <200611011111.kA1BBduj014640@hs20-bc2-6.build.redhat.com> Updated Packages: curl-7.16.0-2.fc7 ----------------- * Tue Oct 31 2006 Jindrich Novy - 7.16.0-2 - fix BuildRoot - add Requires: pkgconfig for curl-devel - move LDFLAGS and LIBS to Libs.private in libcurl.pc.in (#213278) dhcpv6-0.10-33.fc7 ------------------ * Tue Oct 31 2006 David Cantrell - 0.10-33 - spec file cleanup (remove NODEBUGINFO, useless code, etc) - Patch rollup since a lot of the later patches overwrote previous patches - Put typedef for dhcp_state_e before it's used in libdhcp_control.h (#212612) - Include rather than the old BSD queue.h in the source eclipse-1:3.2.1-10.fc7 ---------------------- * Tue Oct 31 2006 Ben Konrath 3.2.1-10 - Add 3.2.1 splash screen. - Sort the java source files before building (#209249). - Remove Fedora ifdefs. - Resolves: #209249. * Tue Oct 31 2006 Ben Konrath 3.2.1-9 - Re-enable building of the icu4j plugins. fetchmail-6.3.5-1 ----------------- * Wed Nov 01 2006 Miloslav Trmac - 6.3.5-1 - Update to fetchmail-6.3.5 - Fix some rpmlint warnings gamin-0.1.8-1.fc7 ----------------- * Tue Oct 31 2006 Daniel Veillard - 0.1.8-1 - made new upstream release, that should include all the existing patches gd-2.0.33-9.4.fc7 ----------------- * Tue Oct 31 2006 Adam Tkac 2.0.33-9.4 - patched some additionals overflows in gd (#175414) gnupg-1.4.5-5 ------------- * Tue Oct 31 2006 Nalin Dahyabhai - 1.4.5-5 - rebuild against current libcurl jwhois-3.2.3-8.fc7 ------------------ * Tue Oct 31 2006 Miloslav Trmac - 3.2.3-8 - Actually use the new upstream config in non-rawhide branches * Tue Oct 31 2006 Miloslav Trmac - 3.2.3-7 - Backport IDN support Resolves: #205033 - Update to upstream config as of Oct 31 2006 logwatch-7.3.1-5.fc7 -------------------- * Wed Nov 01 2006 Ivana Varekova 7.3.1-5 - fix named patch (#213267) - add openvpn patch mc-1:4.6.1a-33.fc7 ------------------ * Tue Oct 31 2006 Jindrich Novy 4.6.1a-33 - display also conflicts in addition to provides/obsoletes/requires while browsing RPM vfs mutt-5:1.4.2.2-4.fc7 -------------------- * Tue Oct 31 2006 Miroslav Lichvar 5:1.4.2.2-4 - fix POP authentication with latest cyrus-sasl (#212816) nfs-utils-1:1.0.10-2.fc7 ------------------------ * Tue Oct 31 2006 Steve Dickson 1.0.10-2 - Fixed -o remount (bz 210346) - fix memory leak in rpc.idmapd (bz 212547) - fix use after free bug in dirscancb (bz 212547) - Made no_subtree_check a default export option (bz 212218) * Wed Oct 25 2006 Steve Dickson 1.0.10-1 - Upgraded to 1.0.10 rpm-4.4.2-35.fc7 ---------------- * Tue Oct 31 2006 Paul Nasrat - 4.4.2-35 - Flush query buffer patch from jbj (#212833) * Tue Oct 31 2006 Paul Nasrat - 4.4.2-34 - Debuginfo extraction with O0 * Wed Oct 25 2006 Paul Nasrat - 4.4.2-33 - Fix for ordering (#202540, #202542, #202543, #202544) selinux-policy-2.4.2-4 ---------------------- * Tue Oct 31 2006 Dan Walsh 2.4.2-4 - Add perms for swat Broken deps for s390 ---------------------------------------------------------- php - 5.1.6-3.s390 requires libcurl.so.3 php-cli - 5.1.6-3.s390 requires libcurl.so.3 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 vorbis-tools - 1:1.1.1-3.fc7.s390 requires libcurl.so.3 Broken deps for i386 ---------------------------------------------------------- openoffice.org-core - 1:2.0.4-5.6.i386 requires libcurl.so.3 php - 5.1.6-3.i386 requires libcurl.so.3 php-cli - 5.1.6-3.i386 requires libcurl.so.3 vorbis-tools - 1:1.1.1-3.fc7.i386 requires libcurl.so.3 Broken deps for ppc64 ---------------------------------------------------------- php - 5.1.6-3.ppc64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.ppc64 requires libcurl.so.3()(64bit) vorbis-tools - 1:1.1.1-3.fc7.ppc64 requires libcurl.so.3()(64bit) Broken deps for x86_64 ---------------------------------------------------------- openoffice.org-core - 1:2.0.4-5.6.x86_64 requires libcurl.so.3()(64bit) php - 5.1.6-3.x86_64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.x86_64 requires libcurl.so.3()(64bit) vorbis-tools - 1:1.1.1-3.fc7.x86_64 requires libcurl.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- openoffice.org-core - 1:2.0.4-5.6.ppc requires libcurl.so.3 php - 5.1.6-3.ppc requires libcurl.so.3 php-cli - 5.1.6-3.ppc requires libcurl.so.3 vorbis-tools - 1:1.1.1-3.fc7.ppc requires libcurl.so.3 Broken deps for ia64 ---------------------------------------------------------- php - 5.1.6-3.ia64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.ia64 requires libcurl.so.3()(64bit) vorbis-tools - 1:1.1.1-3.fc7.ia64 requires libcurl.so.3()(64bit) Broken deps for s390x ---------------------------------------------------------- php - 5.1.6-3.s390x requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.s390x requires libcurl.so.3()(64bit) vorbis-tools - 1:1.1.1-3.fc7.s390x requires libcurl.so.3()(64bit) From atkac at redhat.com Wed Nov 1 12:51:50 2006 From: atkac at redhat.com (Adam Tkac) Date: Wed, 01 Nov 2006 13:51:50 +0100 Subject: vncserver in future dists Message-ID: <1162385510.2894.28.camel@numenor> Hi all, I'm going to port x11vnc (http://www.karlrunge.com/x11vnc/) project as default vncserver in future dists. Current vncserver has self xorg-server and this is argument for x11vnc. When main xorg-x11-server package is patched, patches must be ported to vnc now. vncserver might be only "layer" on xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think about it?? Is this bad idea?? From k.georgiou at imperial.ac.uk Wed Nov 1 13:12:46 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Wed, 1 Nov 2006 13:12:46 +0000 Subject: vncserver in future dists In-Reply-To: <1162385510.2894.28.camel@numenor> References: <1162385510.2894.28.camel@numenor> Message-ID: <20061101131246.GA16008@imperial.ac.uk> On Wed, Nov 01, 2006 at 01:51:50PM +0100, Adam Tkac wrote: > Hi all, > > I'm going to port x11vnc > (http://www.karlrunge.com/x11vnc/) project as default vncserver in > future dists. Current vncserver has self xorg-server and this is > argument for x11vnc. When main xorg-x11-server package is patched, > patches must be ported to vnc now. vncserver might be only "layer" on > xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think > about it?? Is this bad idea?? >From what I can tell x11vnc requires a running X server which makes it useless for headless servers. None of my users uses vnc in this setup (or will want to). I thought that KDE (and Gnome I suspect) offer this already anyway. Kostas Georgiou From pertusus at free.fr Wed Nov 1 13:25:13 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 1 Nov 2006 14:25:13 +0100 Subject: vncserver in future dists In-Reply-To: <1162385510.2894.28.camel@numenor> References: <1162385510.2894.28.camel@numenor> Message-ID: <20061101132513.GD2294@free.fr> On Wed, Nov 01, 2006 at 01:51:50PM +0100, Adam Tkac wrote: > Hi all, > > I'm going to port x11vnc > (http://www.karlrunge.com/x11vnc/) project as default vncserver in > future dists. Current vncserver has self xorg-server and this is > argument for x11vnc. When main xorg-x11-server package is patched, > patches must be ported to vnc now. vncserver might be only "layer" on > xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think > about it?? Is this bad idea?? I think that it is a good idea, however it seems to be a rather different software that the current vnc-server. And to have the client you have to build the vnc-server since they come from the same source. So it is not a replacement for the vnc server package, but rather a usefull complementary package (if I'm not wrong it replaces more or less x0vncserver from the vncserver package). Now you may use x11vnc for the distro specific bits, like in anaconda (but I don't know enough to comment that), or the /etc/rc.d/init.d/vncserver. Anyway you could allready submit x11vnc to extras, there are packages in rpmforge, you may want to coordinate with them. -- Pat From fedora at leemhuis.info Wed Nov 1 13:27:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 01 Nov 2006 14:27:43 +0100 Subject: vncserver in future dists In-Reply-To: <1162385510.2894.28.camel@numenor> References: <1162385510.2894.28.camel@numenor> Message-ID: <4548A0CF.4020208@leemhuis.info> Adam Tkac schrieb: > I'm going to port x11vnc > (http://www.karlrunge.com/x11vnc/) project as default vncserver in > future dists. Current vncserver has self xorg-server and this is > argument for x11vnc. When main xorg-x11-server package is patched, > patches must be ported to vnc now. vncserver might be only "layer" on > xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think > about it?? Is this bad idea?? Does it require special support in the X drivers? It might be a bit problematic to use with proprietary drivers if the answer to that question is "yes" (*1) Cu thl (*1) -- I remember I once used the stuff documented at http://www.realvnc.com/products/free/4.1/x0.html for testing purposes on Fedora and noticed that it did not work together with the proprietary fglrx drivers from ati. :-/ Proprietary drivers really suck... From ajackson at redhat.com Wed Nov 1 15:25:45 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 01 Nov 2006 10:25:45 -0500 Subject: vncserver in future dists In-Reply-To: <20061101131246.GA16008@imperial.ac.uk> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> Message-ID: <4548BC79.5090002@redhat.com> Kostas Georgiou wrote: > On Wed, Nov 01, 2006 at 01:51:50PM +0100, Adam Tkac wrote: > >> Hi all, >> >> I'm going to port x11vnc >> (http://www.karlrunge.com/x11vnc/) project as default vncserver in >> future dists. Current vncserver has self xorg-server and this is >> argument for x11vnc. When main xorg-x11-server package is patched, >> patches must be ported to vnc now. vncserver might be only "layer" on >> xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think >> about it?? Is this bad idea?? > >>From what I can tell x11vnc requires a running X server which makes it > useless for headless servers. None of my users uses vnc in this setup > (or will want to). I thought that KDE (and Gnome I suspect) offer this > already anyway. The Xorg server is perfectly capable of running headless, just configure it to use the dummy driver. - ajax From twaugh at redhat.com Wed Nov 1 15:47:55 2006 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 01 Nov 2006 15:47:55 +0000 Subject: vncserver in future dists In-Reply-To: <4548BC79.5090002@redhat.com> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> Message-ID: <1162396075.4385.19.camel@cyberelk.elk> On Wed, 2006-11-01 at 10:25 -0500, Adam Jackson wrote: > The Xorg server is perfectly capable of running headless, just configure > it to use the dummy driver. I think the point is that VNC users are used to having a single 'Xvnc' binary they can run, which is a bit like Xvfb but you can connect a VNC viewer to it. As far as I can tell, this isn't trivial with x11vnc (but maybe I'm reading the FAQ incorrectly). Tim. */ -------------- 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 ajackson at redhat.com Wed Nov 1 15:55:54 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 01 Nov 2006 10:55:54 -0500 Subject: vncserver in future dists In-Reply-To: <1162396075.4385.19.camel@cyberelk.elk> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> <1162396075.4385.19.camel@cyberelk.elk> Message-ID: <4548C38A.5070407@redhat.com> Tim Waugh wrote: > On Wed, 2006-11-01 at 10:25 -0500, Adam Jackson wrote: >> The Xorg server is perfectly capable of running headless, just configure >> it to use the dummy driver. > > I think the point is that VNC users are used to having a single 'Xvnc' > binary they can run, which is a bit like Xvfb but you can connect a VNC > viewer to it. > > As far as I can tell, this isn't trivial with x11vnc (but maybe I'm > reading the FAQ incorrectly). Nothing a small shell script couldn't fix though. Something like: # cat > /usr/bin/Xvnc < References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> <1162396075.4385.19.camel@cyberelk.elk> Message-ID: <1162397197.8232.8.camel@numenor> On Wed, 2006-11-01 at 15:47 +0000, Tim Waugh wrote: > On Wed, 2006-11-01 at 10:25 -0500, Adam Jackson wrote: > > The Xorg server is perfectly capable of running headless, just configure > > it to use the dummy driver. > > I think the point is that VNC users are used to having a single 'Xvnc' > binary they can run, which is a bit like Xvfb but you can connect a VNC > viewer to it. > > As far as I can tell, this isn't trivial with x11vnc (but maybe I'm > reading the FAQ incorrectly). > > Tim. > */ Yes, I've checked that x11vnc isn't good choice. I want discuss idea that Xvnc won't be big single binary package like now. They're many ways how it could be done and I want find the best way (performance and maintaining aspects). I think, vncserver isn't xserver but only "moderator" between vncviewer and xserver (virtual or psychical) From wtogami at redhat.com Wed Nov 1 16:09:52 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 01 Nov 2006 11:09:52 -0500 Subject: vncserver in future dists In-Reply-To: <4548BC79.5090002@redhat.com> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> Message-ID: <4548C6D0.3080600@redhat.com> A common use case of Xvnc for LTSP-like deployments is launching dozens of Xvnc sessions on the same host. Wouldn't this be a bit messy given the proposed x11vnc change? Warren Togami wtogami at redhat.com From stuart at terminus.co.uk Wed Nov 1 16:10:51 2006 From: stuart at terminus.co.uk (Stuart Children) Date: Wed, 01 Nov 2006 16:10:51 +0000 Subject: vncserver in future dists In-Reply-To: <4548C38A.5070407@redhat.com> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> <1162396075.4385.19.camel@cyberelk.elk> <4548C38A.5070407@redhat.com> Message-ID: <4548C70B.8040907@terminus.co.uk> Adam Jackson wrote: > Tim Waugh wrote: >> On Wed, 2006-11-01 at 10:25 -0500, Adam Jackson wrote: >>> The Xorg server is perfectly capable of running headless, just >>> configure it to use the dummy driver. >> >> I think the point is that VNC users are used to having a single 'Xvnc' >> binary they can run, which is a bit like Xvfb but you can connect a VNC >> viewer to it. >> >> As far as I can tell, this isn't trivial with x11vnc (but maybe I'm >> reading the FAQ incorrectly). > > Nothing a small shell script couldn't fix though. Something like: If this is done and the scripts included, then the proposal sounds good to me. I use x11vnc at home, but with an existing server (mythtv frontend, output is connected to my TV, but this setup allows me access and control from my desktop if necessary). I've had no major problem with it. Only small issue that I've yet to look into properly, is that if you resize the X server's display resolution, then x11vnc exits. Whether picking up this change and coping with it (even if it's not passed down to any connected client) is possible... I've not investigated. If you're interested, I'd want to do this because I have an optimum resolution for my TV, but if I connect from my desktop I'd like to increase the resolution). Cheers -- Stuart Children http://terminus.co.uk/ From ajackson at redhat.com Wed Nov 1 16:13:05 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 01 Nov 2006 11:13:05 -0500 Subject: vncserver in future dists In-Reply-To: <4548C70B.8040907@terminus.co.uk> References: <1162385510.2894.28.camel@numenor> <20061101131246.GA16008@imperial.ac.uk> <4548BC79.5090002@redhat.com> <1162396075.4385.19.camel@cyberelk.elk> <4548C38A.5070407@redhat.com> <4548C70B.8040907@terminus.co.uk> Message-ID: <4548C791.8000101@redhat.com> Stuart Children wrote: > Only small issue that I've yet to look into properly, is that if you > resize the X server's display resolution, then x11vnc exits. Whether > picking up this change and coping with it (even if it's not passed down > to any connected client) is possible... I've not investigated. If you're > interested, I'd want to do this because I have an optimum resolution for > my TV, but if I connect from my desktop I'd like to increase the > resolution). We can definitely catch when that happens, you just listen for a ConfigureNotify on the root window. If x11vnc is exiting it's either because the VNC protocol can't deal with it, or it's just a bug. - ajax From dcantrell at redhat.com Wed Nov 1 16:19:08 2006 From: dcantrell at redhat.com (David Cantrell) Date: Wed, 01 Nov 2006 11:19:08 -0500 Subject: NetworkManager not working in rawhide Message-ID: <4548C8FC.5000708@redhat.com> Some people may have noticed that NetworkManager is not working correctly in rawhide post-FC6. The problem is caused by dhcdbd not starting before NetworkManager, so NM gets confused and starts running around crazylike. The dhcdbd-2.2-1.fc7 package fixes the daemon start order. It will appear in tomorrow's rawhide. Just wanted to let everyone know. -- David Cantrell Red Hat / Westford, MA From dcbw at redhat.com Wed Nov 1 16:31:20 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 01 Nov 2006 11:31:20 -0500 Subject: NetworkManager not working in rawhide In-Reply-To: <4548C8FC.5000708@redhat.com> References: <4548C8FC.5000708@redhat.com> Message-ID: <1162398680.12312.2.camel@localhost.localdomain> On Wed, 2006-11-01 at 11:19 -0500, David Cantrell wrote: > Some people may have noticed that NetworkManager is not working > correctly in rawhide post-FC6. The problem is caused by dhcdbd not > starting before NetworkManager, so NM gets confused and starts running > around crazylike. > > The dhcdbd-2.2-1.fc7 package fixes the daemon start order. It will > appear in tomorrow's rawhide. Just wanted to let everyone know. Hopefully in the FC7 timeframe DavidZ's system bus activation patch will be merged to dbus, and a release including it will be in FC7, and then the root cause of this problem will vanish :) But thanks for figuring this out and for the fix. NM should be more resilient to dhcdbd not being around too. For the record, this dhcdbd problem also exposed a bug in the DBus service activation code that caused a segfault in the core dbus daemon, which was patched last week. Dan > -- > David Cantrell > Red Hat / Westford, MA > From david at fubar.dk Wed Nov 1 17:45:12 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 01 Nov 2006 12:45:12 -0500 Subject: vncserver in future dists In-Reply-To: <1162385510.2894.28.camel@numenor> References: <1162385510.2894.28.camel@numenor> Message-ID: <1162403112.5191.2.camel@dhcp83-66.boston.redhat.com> Hi, Have you tested x11vnc with vino? Note that vino is in the default desktop install. David From david at fubar.dk Wed Nov 1 17:50:07 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 01 Nov 2006 12:50:07 -0500 Subject: NetworkManager not working in rawhide In-Reply-To: <1162398680.12312.2.camel@localhost.localdomain> References: <4548C8FC.5000708@redhat.com> <1162398680.12312.2.camel@localhost.localdomain> Message-ID: <1162403407.5191.5.camel@dhcp83-66.boston.redhat.com> On Wed, 2006-11-01 at 11:31 -0500, Dan Williams wrote: > Hopefully in the FC7 timeframe DavidZ's system bus activation patch will > be merged to dbus, and a release including it will be in FC7, and then > the root cause of this problem will vanish :) Right. That's indeed part of the plan. I'm just waiting for D-Bus 1.0 to come out and the we'll do a D-Bus 1.1 unstable release that includes this patch. David From gianluca.cecchi at gmail.com Wed Nov 1 19:21:42 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 1 Nov 2006 20:21:42 +0100 Subject: package updater optimization proposal Message-ID: <561c252c0611011121jb68207cscf5f5a0bd31a88a7@mail.gmail.com> Hello, I'm using package updater with my brand new fc6. I found in the past in fc5 that using yum from command line, I could do a Ctrl+C when hitting a slow mirror and then I got a faster one, eventually with more than one Ctrl+C. it was a useful workaround.. Only drawback was that the Ctrl+C was not trapped and so after the downloading phase completed, the program exited and I had to rerun "yum update" to go to the transaction phase. In fc6 it seems Ctrl+C is trapped, so it seems better in this way. In graphical package updater instead, you have no way to say to it for example "hey, I got a slooooow mirror; can you change it, please? Also randomly, I don't want to choose a specific one..." Is it reasonable to have pup propose to change mirror through a button or something else? Or by deign is intended that the mirror you get, the mirror you deserve? I admit that in this way you could saturate some mirrors, but during these days using pup is a pain... I always get very slow mirrors. I'm based in Italy and I'm using adsl with Tele2, that I think uses servers based in sweden to go through broad internet... Gianluca From chris at tylers.info Wed Nov 1 19:45:55 2006 From: chris at tylers.info (Chris Tyler) Date: Wed, 01 Nov 2006 14:45:55 -0500 Subject: vncserver in future dists In-Reply-To: <20061101160532.4DB517394B@hormel.redhat.com> References: <20061101160532.4DB517394B@hormel.redhat.com> Message-ID: <1162410355.28769.4.camel@concord2.proximity.on.ca> Adam Tkac wrote: > Hi all, > > I'm going to port x11vnc > (http://www.karlrunge.com/x11vnc/) project as default vncserver in > future dists. Current vncserver has self xorg-server and this is > argument for x11vnc. When main xorg-x11-server package is patched, > patches must be ported to vnc now. vncserver might be only "layer" on > xorg-x11-server and have dependency for it. Maintaining of vnc could be really easy.. What do you think > about it?? Is this bad idea?? FC6 includes four VNC servers: - the VNC module for the Xorg server (in package vnc-server) - Xvnc (vnc-server) - krfb (kdenetwork) - vino-server (vino) krfb and vino-server are basically KDE/Gnome implementations of the same thing; Xvnc is headless; and the VNC module is a (potentially) higher-performance version of krfb/vinoserver that is running whenever the X server is running (i.e., you can login to a session with it). x11vnc is similar to krfb/vino-server in that it's an X client and does not contain the X server. Others have pointed out that it can be used with an X server driving a dummy framebuffer to act like Xvnc, but that seems kludgey. One important feature of Xvnc that x11vnc seems to be missing is the "-inetd" mode, where the RFB protocol is handled on stdin/stdout and the X display number is automatically determined (first unused port in the range 6000-6099). This feature is important not only for on-demand vnc server instances but also for exotic applications such as X clients embedded into web pages (e.g., embedding one specific X app into a rectangle on a web page, used for product demos and so forth). One x11vnc FAQ entry mentions using x11vnc with xinetd, but it's talking about connecting to a running X server on demand, not starting a new X instance; you can bridge the gap with some scripting, but again it seems inelegant. -- Chris Tyler From jaroslav at aster.pl Wed Nov 1 19:55:20 2006 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Wed, 1 Nov 2006 20:55:20 +0100 Subject: package updater optimization proposal In-Reply-To: <561c252c0611011121jb68207cscf5f5a0bd31a88a7@mail.gmail.com> References: <561c252c0611011121jb68207cscf5f5a0bd31a88a7@mail.gmail.com> Message-ID: <200611012055.20903.jaroslav@aster.pl> Dnia ?roda, 1 listopada 2006 20:21, Gianluca Cecchi napisa?: (...) > In fc6 it seems Ctrl+C is trapped, so it seems better in this way. > In graphical package updater instead, you have no way to say to it for > example "hey, I got a slooooow mirror; can you change it, please? Also > randomly, I don't want to choose a specific one..." There's a 'fastestmirror' plugin (available on yum homepage) which determines mirrors speeds automatically. regards, -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Nov 1 20:15:22 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Nov 2006 01:45:22 +0530 Subject: package updater optimization proposal In-Reply-To: <200611012055.20903.jaroslav@aster.pl> References: <561c252c0611011121jb68207cscf5f5a0bd31a88a7@mail.gmail.com> <200611012055.20903.jaroslav@aster.pl> Message-ID: <4549005A.90903@fedoraproject.org> Jaroslaw Gorny wrote: > Dnia ?roda, 1 listopada 2006 20:21, Gianluca Cecchi napisa?: > (...) >> In fc6 it seems Ctrl+C is trapped, so it seems better in this way. >> In graphical package updater instead, you have no way to say to it for >> example "hey, I got a slooooow mirror; can you change it, please? Also >> randomly, I don't want to choose a specific one..." > > There's a 'fastestmirror' plugin (available on yum homepage) which determines > mirrors speeds automatically. If you are going this route, yum install yum-utils (Fedora Extras). Rahul From tla-ml at rasmil.dk Wed Nov 1 20:30:39 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Wed, 01 Nov 2006 21:30:39 +0100 Subject: package updater optimization proposal In-Reply-To: <4549005A.90903@fedoraproject.org> References: <561c252c0611011121jb68207cscf5f5a0bd31a88a7@mail.gmail.com> <200611012055.20903.jaroslav@aster.pl> <4549005A.90903@fedoraproject.org> Message-ID: <454903EF.109@rasmil.dk> Rahul Sundaram wrote: > Jaroslaw Gorny wrote: >> Dnia ?roda, 1 listopada 2006 20:21, Gianluca Cecchi napisa?: >> (...) >>> In fc6 it seems Ctrl+C is trapped, so it seems better in this way. >>> In graphical package updater instead, you have no way to say to it for >>> example "hey, I got a slooooow mirror; can you change it, please? Also >>> randomly, I don't want to choose a specific one..." >> >> There's a 'fastestmirror' plugin (available on yum homepage) which >> determines mirrors speeds automatically. > > If you are going this route, yum install yum-utils (Fedora Extras). > > Rahul > the yum-utils package dont contain the plugins anymore, the plugins is split in separate packages: yum-allowdowngrade.noarch 1.0.1-1.fc6 extras yum-changelog.noarch 1.0.1-1.fc6 extras yum-downloadonly.noarch 1.0.1-1.fc6 extras yum-fastestmirror.noarch 1.0.1-1.fc6 extras yum-fedorakmod.noarch 1.0.1-1.fc6 extras yum-kernel-module.noarch 1.0.1-1.fc6 extras yum-priorities.noarch 1.0.1-1.fc6 extras yum-protectbase.noarch 1.0.1-1.fc6 extras yum-skip-broken.noarch 1.0.1-1.fc6 extras yum-tsflags.noarch 1.0.1-1.fc6 extras yum-versionlock.noarch 1.0.1-1.fc6 extras Just use : (as root) yum install yum-fastestmirror To install the fastestmirror plugin. Tim From michel.salim at gmail.com Thu Nov 2 01:56:57 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 1 Nov 2006 20:56:57 -0500 Subject: xine-lib xine-ui gxine In-Reply-To: References: <45475043.6070504@yahoo.es> Message-ID: <883cfe6d0611011756m4afac10dy80bd984ef181d7f1@mail.gmail.com> On 10/31/06, Aurelien Bompard wrote: > > There is no xine-ui or gxine package yet however, if you're interested in > contributing them, please follow the usual procedure : > http://fedoraproject.org/wiki/Extras/Contributors > There's a gxine review request on Livna: https://bugzilla.livna.org/show_bug.cgi?id=1165 that for some reason or another, has not been submitted for review for FE. -- Michel Salim http://the-dubois-papers.blogspot.com/ From michel.salim at gmail.com Thu Nov 2 01:56:57 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 1 Nov 2006 20:56:57 -0500 Subject: xine-lib xine-ui gxine In-Reply-To: References: <45475043.6070504@yahoo.es> Message-ID: <883cfe6d0611011756m4afac10dy80bd984ef181d7f1@mail.gmail.com> On 10/31/06, Aurelien Bompard wrote: > > There is no xine-ui or gxine package yet however, if you're interested in > contributing them, please follow the usual procedure : > http://fedoraproject.org/wiki/Extras/Contributors > There's a gxine review request on Livna: https://bugzilla.livna.org/show_bug.cgi?id=1165 that for some reason or another, has not been submitted for review for FE. -- Michel Salim http://the-dubois-papers.blogspot.com/ From sundaram at fedoraproject.org Thu Nov 2 02:13:21 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Nov 2006 07:43:21 +0530 Subject: xine-lib xine-ui gxine In-Reply-To: <883cfe6d0611011756m4afac10dy80bd984ef181d7f1@mail.gmail.com> References: <45475043.6070504@yahoo.es> <883cfe6d0611011756m4afac10dy80bd984ef181d7f1@mail.gmail.com> Message-ID: <45495441.80004@fedoraproject.org> Michel Salim wrote: > On 10/31/06, Aurelien Bompard wrote: >> >> There is no xine-ui or gxine package yet however, if you're interested in >> contributing them, please follow the usual procedure : >> http://fedoraproject.org/wiki/Extras/Contributors >> > There's a gxine review request on Livna: > > https://bugzilla.livna.org/show_bug.cgi?id=1165 > > that for some reason or another, has not been submitted for review for FE. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213511 Rahul From michel.salim at gmail.com Thu Nov 2 02:32:03 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 1 Nov 2006 21:32:03 -0500 Subject: xine-lib xine-ui gxine In-Reply-To: <45495441.80004@fedoraproject.org> References: <45475043.6070504@yahoo.es> <883cfe6d0611011756m4afac10dy80bd984ef181d7f1@mail.gmail.com> <45495441.80004@fedoraproject.org> Message-ID: <883cfe6d0611011832q4cf320bnf0958116e5e2379@mail.gmail.com> On 11/1/06, Rahul Sundaram wrote: > > There's a gxine review request on Livna: > > > > https://bugzilla.livna.org/show_bug.cgi?id=1165 > > > > that for some reason or another, has not been submitted for review for FE. > > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213511 > Aha! Thanks. -- Michel Salim http://the-dubois-papers.blogspot.com/ From kevin.kofler at chello.at Thu Nov 2 03:17:09 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 2 Nov 2006 03:17:09 +0000 (UTC) Subject: FC6 - Stock x86_64 stock install, installs about 158 i386/686 rpm's References: <4540C042.8060400@beowulf.net> <200610261006.20786.jkeating@redhat.com> <200610262101.57107.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > Because to the end user, what does that mean? More options and questions and > buttons suck more. Things need to work out of the box, and people can > cripple them after the fact. Yes, cripple. You've got hardware that is > capable of running both x86_64 and i386 (or ppc64 and ppc). Crippling the OS > to not support it is something we should _not_ do. One use case where you definitely DON'T want i386 multilibs is an x86_64 QEMU VM running on an i386 machine. If you want to build 32-bit packages, you're going to do it on your real hardware, not an emulated machine. And installing in QEMU is slow, so useless packages being pulled in is a PITA. Kevin Kofler From jkeating at redhat.com Thu Nov 2 03:22:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 1 Nov 2006 22:22:55 -0500 Subject: FC6 - Stock x86_64 stock install, installs about 158 i386/686 rpm's In-Reply-To: References: <4540C042.8060400@beowulf.net> <200610262101.57107.jkeating@redhat.com> Message-ID: <200611012222.58687.jkeating@redhat.com> On Wednesday 01 November 2006 22:17, Kevin Kofler wrote: > One use case where you definitely DON'T want i386 multilibs is an x86_64 > QEMU VM running on an i386 machine. If you want to build 32-bit packages, > you're going to do it on your real hardware, not an emulated machine. And > installing in QEMU is slow, so useless packages being pulled in is a PITA. And crippling the OS for a very corner case is also a PITA. Personally I'm all for an anaconda flag or super sekret option that allows you to add some yum defines, such as exclude=*.i?86. But I'm not for adding a graphical or even textual option box asking a user if they want this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Nov 2 03:31:03 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 2 Nov 2006 03:31:03 +0000 (UTC) Subject: FC6 - Stock x86_64 stock install, installs about 158 i386/686 rpm's References: <4540C042.8060400@beowulf.net> <200610262101.57107.jkeating@redhat.com> <200611012222.58687.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > And crippling the OS for a very corner case is also a PITA. Personally I'm > all for an anaconda flag or super sekret option that allows you to add some > yum defines, such as exclude=*.i?86. But I'm not for adding a graphical or > even textual option box asking a user if they want this. I agree an Anaconda flag would be a good solution. So should I file an RFE in Bugzilla for that? ;-) Or is there one already? Kevin Kofler From kevin.kofler at chello.at Thu Nov 2 03:33:56 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 2 Nov 2006 03:33:56 +0000 (UTC) Subject: FC6 on QEMU (was: Re: FC6 - Stock x86_64 stock install, installs about 158 i386/686 rpm's) References: <4540C042.8060400@beowulf.net> <200610261006.20786.jkeating@redhat.com> <200610262101.57107.jkeating@redhat.com> Message-ID: I wrote: > One use case where you definitely DON'T want i386 multilibs is an x86_64 QEMU > VM running on an i386 machine. If you want to build 32-bit packages, you're > going to do it on your real hardware, not an emulated machine. And installing > in QEMU is slow, so useless packages being pulled in is a PITA. Adding to that: By the way, if you want to run FC6 i386 or x86_64 in QEMU, you need the patches I just attached to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207843 This is already upstream (in fact I extracted the relevant change from upstream CVS). I hope this can be put into the FE package quickly, because FC6's qemu not running FC6 itself isn't very nice. ;-) Kevin Kofler From florin at andrei.myip.org Thu Nov 2 05:27:08 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 01 Nov 2006 21:27:08 -0800 Subject: aiglx discussions and issues Message-ID: <454981AC.6080201@andrei.myip.org> What is the best mailing list to discuss aiglx issues - in general, but also specific to FC6? For aiglx-related issues, which package should be selected when reporting a bug to bugzilla? -- Florin Andrei http://florin.myip.org/ From ich at frank-schmitt.net Thu Nov 2 09:15:01 2006 From: ich at frank-schmitt.net (Frank Schmitt) Date: Thu, 02 Nov 2006 10:15:01 +0100 Subject: Propose Emacs 22 for Fedora Core 7 References: Message-ID: Leo writes: > I'm a big fan of Emacs and I like to build Emacs from source. So > whether FC7 is gonna have Emacs 22 does not concern me much. However I > think it is important to have this modernized powerful tool available > to our current and prospective Fedora users. I'd like to second this. -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From buildsys at redhat.com Thu Nov 2 11:00:37 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 2 Nov 2006 06:00:37 -0500 Subject: rawhide report: 20061102 changes Message-ID: <200611021100.kA2B0bxT020922@hs20-bc2-6.build.redhat.com> Updated Packages: at-3.1.10-5.fc7 --------------- * Wed Oct 25 2006 Marcela Maslanova - 3.1.10-5 - daylight-saving * Tue Oct 24 2006 Marcela Maslanova - 3.1.10-3 - new version from upstream 3.1.10 * Wed Aug 23 2006 Marcela Maslanova - 3.1.8-82.fc6 - #176486 don't fork option added (patch from Enrico Scholz) bug-buddy-1:2.16.0-4.fc7 ------------------------ * Wed Nov 01 2006 Alexander Larsson - 1:2.16.0-4.fc7 - Add extra information to autogenerated bug reports ccid-1.1.0-1 ------------ * Thu Nov 02 2006 Bob Relyea - 1.1.0-1 - Pickup ccid 1.1.0 * Thu Jul 20 2006 Florian La Roche - 1.0.1-5 - require initscripts for post/postun cryptsetup-luks-1.0.3-3.fc7 --------------------------- * Wed Nov 01 2006 Peter Jones - 1.0.3-3 - Require newer libselinux (#213414) dhcdbd-2.2-1.fc7 ---------------- * Wed Nov 01 2006 David Cantrell - 2.2-1 - Set chkconfig start order to 97 so dhcdbd starts before NetworkManager evolution-data-server-1.9.1-3.fc7 --------------------------------- * Wed Nov 01 2006 Matthew Barnes - 1.9.1-3.fc7 - Add patch for Gnome.org bug #353924 (category sorting). gjdoc-0.7.7-12 -------------- * Wed Nov 01 2006 Andrew Overholt - 0.7.7-12 - Guard against missing rebuild-gcj-db in post and postun. - Add Requires(post,postun): java-gcj-compat to solve above. - Resolves: #213529. hplip-1.6.10-5.fc7 ------------------ * Wed Nov 01 2006 Tim Waugh 1.6.10-5 - Fixed debugging patch. * Wed Nov 01 2006 Tim Waugh 1.6.10-4 - Allow debugging of the SANE backend. htmlview-3.0.0-15.fc7 --------------------- * Wed Nov 01 2006 Matthias Clasen - 3.0.0-15 - Ensure that launchmail always brings up the mail component of evolution. (#212718) libsepol-1.15.2-1 ----------------- * Wed Nov 01 2006 Dan Walsh 1.15.2-1 - Upgrade to latest from NSA * Merged fix from Karl MacMillan for a segfault when linking non-MLS modules with users in them. libuser-0.54.8-1 ---------------- * Thu Nov 02 2006 Miloslav Trmac - 0.54.8-1 - Add importing of HOME from default/useradd Related: #204707 m17n-db-1.3.3-33.fc7 -------------------- * Wed Nov 01 2006 Mayank Jain - Added 09CE mapped to z in as-inscript (213372) * Wed Nov 01 2006 Mayank Jain - Imported m17n-db-indic-0.4.29.tar.gz from RHEL-5 package, changes happened from .28 version are - Added few more key combinations for ta-typewriter keymap - bug 209088 - Added ZWJ for hi-inscript and hi-phonetic keymaps - bug 211576 - Corrected kn-kgp and kn-inscript keymaps for keymapping of X - bug 209963 openoffice.org-1:2.0.4-5.7 -------------------------- * Wed Nov 01 2006 Caolan McNamara - 1:2.0.4-5.7 - Resolves: rhbz#213203 openoffice.org.2.0.4.oooXXXXX.i18npool.extendgrapheme.patch - Resolves: rhbz#212988 try /tmp if /home fails, and abort with a message instead of segv - Resolves: rhbz#213329 "." from numeric keypad not converted to "," in appropiate locales - Resolves: (partial) rhbz#213371 openoffice.org.2.0.4.oooXXXXX.i18npool.extendgrapheme.patch - Resolves: rhbz#212814 openoffice.org-2.0.4.ooo71076.dtrans.64bitdragdrop.patch - add openoffice.org-2.0.4.ooo71039.svx.purevirtual.patch for bad pure virtual - add openoffice.org-2.0.4.ooo71077.sc.purevirtual.patch for bad pure virtual - rebuild for curl pcsc-lite-1.3.2-1 ----------------- * Thu Nov 02 2006 Bob Relyea - 1.3.2-1 - Pick up 1.3.2 quota-1:3.13-1.2.3.1.fc7 ------------------------ * Wed Nov 01 2006 Steve Dickson 1:3.13-1.2.3.2 - Added range checking on -p flag (bz 205145) - Error message prints garbage characters (bz 201226) shadow-utils-2:4.0.18.1-1.fc7 ----------------------------- * Wed Nov 01 2006 Peter Vrabec 2:4.0.18.1-1 - upgrade tmpwatch-2.9.8-1 ---------------- * Wed Nov 01 2006 Miloslav Trmac - 2.9.8-1 - Add optional unit suffix to the "hours" (now "time") parameter (original patch by Alan J Rosenthal ) - Fix some format string vs. arguments mismatches - Fix some rpmlint warnings vorbis-tools-1:1.1.1-4.fc7 -------------------------- * Wed Nov 01 2006 Matthias Clasen - 1:1.1.1-4 - Rebuild against new curl - Don't use CURLOPT_MUTE wireshark-0.99.4-1 ------------------ * Wed Nov 01 2006 Radek Vok??l 0.99.4-1 - upgrade to 0.99.4 final * Tue Oct 31 2006 Radek Vok??l 0.99.4-0.pre2 - upgrade to 0.99.4pre2 Broken deps for ppc64 ---------------------------------------------------------- php - 5.1.6-3.ppc64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.ppc64 requires libcurl.so.3()(64bit) Broken deps for i386 ---------------------------------------------------------- php - 5.1.6-3.i386 requires libcurl.so.3 php-cli - 5.1.6-3.i386 requires libcurl.so.3 Broken deps for x86_64 ---------------------------------------------------------- php - 5.1.6-3.x86_64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.x86_64 requires libcurl.so.3()(64bit) Broken deps for ia64 ---------------------------------------------------------- php - 5.1.6-3.ia64 requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.ia64 requires libcurl.so.3()(64bit) Broken deps for s390 ---------------------------------------------------------- php - 5.1.6-3.s390 requires libcurl.so.3 php-cli - 5.1.6-3.s390 requires libcurl.so.3 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- php - 5.1.6-3.ppc requires libcurl.so.3 php-cli - 5.1.6-3.ppc requires libcurl.so.3 Broken deps for s390x ---------------------------------------------------------- php - 5.1.6-3.s390x requires libcurl.so.3()(64bit) php-cli - 5.1.6-3.s390x requires libcurl.so.3()(64bit) From jfrieben at freesurf.fr Thu Nov 2 13:57:41 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 2 Nov 2006 14:57:41 +0100 (CET) Subject: Spurious freezes and file system corruption Message-ID: <48496.194.94.224.254.1162475861.squirrel@jose.freesurf.fr> The "rpm" problems reported in my previous post: https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00870.html have also been observed by other users and have made their appearance in Red Hat Bugzilla as bug #211917: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211917 . System freezes, corrupted rpmdb ... this is a very serious issue which makes "FC6" and current "rawhide" essentially unusable on the affected systems. Any ideas? From jacliburn at bellsouth.net Thu Nov 2 14:00:07 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 2 Nov 2006 08:00:07 -0600 Subject: Request for git-core rebuild Message-ID: <20061102140006.GA3905@osprey.hogchain.net> I'm not sure if I'm asking the right question, but I've got a dependency problem with curl and git-core that I can't get past, and I think it could be resolved by rebuilding git-core (in extras). What's the right way to go about asking for a package rebuild? Or, if I'm not asking the right question, please correct me. Thanks, Jay [root at osprey ~]# yum list curl Setting up repositories Reading repository metadata in from local files Installed Packages curl.x86_64 7.15.5-1.fc6 installed curl.i386 7.15.5-1.fc6 installed Available Packages curl.x86_64 7.16.0-2.fc7 development curl.i386 7.16.0-2.fc7 development [root at osprey ~]# yum update curl Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package curl.i386 0:7.16.0-2.fc7 set to be updated ---> Package curl.x86_64 0:7.16.0-2.fc7 set to be updated --> Running transaction check --> Processing Dependency: libcurl.so.3()(64bit) for package: xine --> Processing Dependency: libcurl.so.3()(64bit) for package: curl-devel --> Processing Dependency: libcurl.so.3()(64bit) for package: git-core --> Processing Dependency: curl = 7.15.5-1.fc6 for package: curl-devel --> Processing Dependency: libcurl.so.3()(64bit) for package: vorbis-tools --> Processing Dependency: libcurl.so.3()(64bit) for package: gnupg --> Processing Dependency: libcurl.so.3 for package: curl-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package curl-devel.i386 0:7.16.0-2.fc7 set to be updated ---> Package vorbis-tools.x86_64 1:1.1.1-4.fc7 set to be updated ---> Package xine.x86_64 0:0.99.4-9.lvn7 set to be updated ---> Package gnupg.x86_64 0:1.4.5-5 set to be updated ---> Package curl-devel.x86_64 0:7.16.0-2.fc7 set to be updated --> Running transaction check --> Processing Dependency: libcurl.so.3()(64bit) for package: xine --> Processing Dependency: libcurl.so.3()(64bit) for package: git-core --> Finished Dependency Resolution Error: Missing Dependency: libcurl.so.3()(64bit) is needed by package git-core Error: Missing Dependency: libcurl.so.3()(64bit) is needed by package xine From jwboyer at jdub.homelinux.org Thu Nov 2 14:06:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 02 Nov 2006 08:06:56 -0600 Subject: Request for git-core rebuild In-Reply-To: <20061102140006.GA3905@osprey.hogchain.net> References: <20061102140006.GA3905@osprey.hogchain.net> Message-ID: <1162476416.11351.15.camel@zod.rchland.ibm.com> On Thu, 2006-11-02 at 08:00 -0600, Jay Cliburn wrote: > I'm not sure if I'm asking the right question, but I've got a dependency > problem with curl and git-core that I can't get past, and I think it > could be resolved by rebuilding git-core (in extras). > > What's the right way to go about asking for a package rebuild? Or, if > I'm not asking the right question, please correct me. You should file a bug against git-core. If curl changed enough, it might take more than a rebuild (though I would be surprised in this case). Do note though, you're running rawhide and breakage is normal. It might take a while to get it fixed, and then it might break the next day again. josh From jacliburn at bellsouth.net Thu Nov 2 14:29:12 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 2 Nov 2006 08:29:12 -0600 Subject: Request for git-core rebuild In-Reply-To: <1162476416.11351.15.camel@zod.rchland.ibm.com> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> Message-ID: <20061102142912.GA11345@osprey.hogchain.net> On Thu, Nov 02, 2006 at 08:06:56AM -0600, Josh Boyer wrote: > On Thu, 2006-11-02 at 08:00 -0600, Jay Cliburn wrote: > > I'm not sure if I'm asking the right question, but I've got a dependency > > problem with curl and git-core that I can't get past, and I think it > > could be resolved by rebuilding git-core (in extras). > > > > What's the right way to go about asking for a package rebuild? Or, if > > I'm not asking the right question, please correct me. > > You should file a bug against git-core. If curl changed enough, it > might take more than a rebuild (though I would be surprised in this > case). > > Do note though, you're running rawhide and breakage is normal. It might > take a while to get it fixed, and then it might break the next day > again. Thanks Josh. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213664 From paul at city-fan.org Thu Nov 2 14:35:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Nov 2006 14:35:27 +0000 Subject: Request for git-core rebuild In-Reply-To: <20061102142912.GA11345@osprey.hogchain.net> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> <20061102142912.GA11345@osprey.hogchain.net> Message-ID: <454A022F.6080803@city-fan.org> Jay Cliburn wrote: > On Thu, Nov 02, 2006 at 08:06:56AM -0600, Josh Boyer wrote: >> On Thu, 2006-11-02 at 08:00 -0600, Jay Cliburn wrote: >>> I'm not sure if I'm asking the right question, but I've got a dependency >>> problem with curl and git-core that I can't get past, and I think it >>> could be resolved by rebuilding git-core (in extras). >>> >>> What's the right way to go about asking for a package rebuild? Or, if >>> I'm not asking the right question, please correct me. >> You should file a bug against git-core. If curl changed enough, it >> might take more than a rebuild (though I would be surprised in this >> case). >> >> Do note though, you're running rawhide and breakage is normal. It might >> take a while to get it fixed, and then it might break the next day >> again. > > Thanks Josh. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213664 As a short-term workaround, you might try installing my libcurl7155 (aka compat-libcurl) package, which provides a parallel-installable libcurl.so.3: http://www.city-fan.org/ftp/contrib/sysutils/Mirroring/ Paul. From prarit at redhat.com Thu Nov 2 14:53:45 2006 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 02 Nov 2006 09:53:45 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available Message-ID: <454A0679.3080505@redhat.com> I've built a set of FC6 ia64 ISOs (CD set and DVD) which are available for download from ftp://oss.sgi.com/projects/fedora/ 9aea82e31ace9ceb3e5aba210f4cda14 FC6GOLD-ia64-disc1.iso c3b3dd2e4cc0e4c60e4589532e79b4b4 FC6GOLD-ia64-disc2.iso 093b5aa79be4cd9ab8aff6f743df9fec FC6GOLD-ia64-disc3.iso f90baccedc2a1d5b1a0582649235691f FC6GOLD-ia64-disc4.iso afcfa7f9d6b47b2f78107dcbcce63eef FC6GOLD-ia64-disc5.iso 88ad15a45ca9dad378636cf572f4be03 FC6GOLD-ia64-DVD.iso (Click on Download on left-hand side, and then the FC6 directory) These are labelled as FC6GOLD to differentiate them from the broken sets that Yanmin attempted to release last week. md5sums are provided. We have verified CD, DVD, NFS, http, ftp installs on various HP & SGI boxes. Please remember that FC6 ia64 is _unsupported_ by Fedora. You can file bugs, but be sure to file them against the devel branch of Fedora Core. Also, add "fedora-ia64" to the "blocks" field of the BZ. P. From arjan at fenrus.demon.nl Thu Nov 2 15:03:08 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 02 Nov 2006 16:03:08 +0100 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <454A0679.3080505@redhat.com> References: <454A0679.3080505@redhat.com> Message-ID: <1162479788.14530.43.camel@laptopd505.fenrus.org> On Thu, 2006-11-02 at 09:53 -0500, Prarit Bhargava wrote: > I've built a set of FC6 ia64 ISOs (CD set and DVD) which are available > for download from > > ftp://oss.sgi.com/projects/fedora/ Hi, are the src.rpm's also available somewhere? (you know, that open source thing ;) Also, are there plans to make expanded trees available? I tend to use those a lot more than isos.... Greetings, Arjan van de Ven From jkeating at redhat.com Thu Nov 2 15:08:24 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Nov 2006 10:08:24 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <1162479788.14530.43.camel@laptopd505.fenrus.org> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> Message-ID: <200611021008.27113.jkeating@redhat.com> On Thursday 02 November 2006 10:03, Arjan van de Ven wrote: > are the src.rpm's also available somewhere? (you know, that open source > thing ;) Also, are there plans to make expanded trees available? I tend > to use those a lot more than isos.... The same srpms are used as the shipped FC6 ones. Unified srpms. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andy at warmcat.com Thu Nov 2 15:20:52 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 02 Nov 2006 15:20:52 +0000 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <200611021008.27113.jkeating@redhat.com> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> <200611021008.27113.jkeating@redhat.com> Message-ID: <454A0CD4.9060309@warmcat.com> Jesse Keating wrote: > On Thursday 02 November 2006 10:03, Arjan van de Ven wrote: >> are the src.rpm's also available somewhere? (you know, that open source >> thing ;) Also, are there plans to make expanded trees available? I tend >> to use those a lot more than isos.... > > The same srpms are used as the shipped FC6 ones. Unified srpms. Sounds good to me but just a FYI ''... Warren Woodford, the founder of the MEPIS distribution, would prefer to be concentrating on polishing his latest release. Instead, he is distracted by an official notice from the Free Software Foundation that, because MEPIS has not previously supplied source code for the packages already available from the distribution it is based on -- once Debian, and now Ubuntu -- it is in violation of the GNU General Public License (GPL). Woodford intends to comply, but he worries about how this requirement might affect all distributions derived from other distributions -- especially those run by one or two people in their spare time. ...'' http://software.newsforge.com/article.pl?sid=06/06/23/1728205&tid=150 -Andy From ajackson at redhat.com Thu Nov 2 15:26:30 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 02 Nov 2006 10:26:30 -0500 Subject: aiglx discussions and issues In-Reply-To: <454981AC.6080201@andrei.myip.org> References: <454981AC.6080201@andrei.myip.org> Message-ID: <454A0E26.7060207@redhat.com> Florin Andrei wrote: > What is the best mailing list to discuss aiglx issues - in general, but > also specific to FC6? For FC6, here is fine. In general, xorg at lists.freedesktop.org. > For aiglx-related issues, which package should be selected when > reporting a bug to bugzilla? Start with xorg-x11-server, we'll triage from there. - ajax From jkeating at redhat.com Thu Nov 2 15:37:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Nov 2006 10:37:57 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <454A0CD4.9060309@warmcat.com> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> Message-ID: <200611021037.57855.jkeating@redhat.com> On Thursday 02 November 2006 10:20, Andy Green wrote: > Sounds good to me but just a FYI > > ''... Warren Woodford, the founder of the MEPIS distribution, would > prefer to be concentrating on polishing his latest release. Instead, he > is distracted by an official notice from the Free Software Foundation > that, because MEPIS has not previously supplied source code for the > packages already available from the distribution it is based on -- once > Debian, and now Ubuntu -- it is in violation of the GNU General Public > License (GPL). Woodford intends to comply, but he worries about how this > requirement might affect all distributions derived from other > distributions -- especially those run by one or two people in their > spare time. ...'' Yes, where MEPIS != Debian, but in this case the ia64 compose of Fedora = Fedora. There are no changes (afaik) the ia64 binary packages were built from the same srpms at the same time that the i386, x86_64, and ppc(64) binary rpms were built. -- Jesse Keating Release Engineer: Fedora -------------- 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 Thu Nov 2 15:41:14 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 2 Nov 2006 16:41:14 +0100 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <200611021037.57855.jkeating@redhat.com> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> <200611021037.57855.jkeating@redhat.com> Message-ID: <20061102164114.0cfd3569@banea.int.addix.net> Hi. On Thu, 2 Nov 2006 10:37:57 -0500, Jesse Keating wrote: > Yes, where MEPIS != Debian, but in this case the ia64 compose of > Fedora = Fedora. There are no changes (afaik) the ia64 binary > packages were built from the same srpms at the same time that the > i386, x86_64, and ppc(64) binary rpms were built. > The point is that ftp://oss.sgi.com/projects/fedora/ has to carry the SRPMS as well, I think. From andy at warmcat.com Thu Nov 2 15:55:23 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 02 Nov 2006 15:55:23 +0000 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <20061102164114.0cfd3569@banea.int.addix.net> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> <200611021037.57855.jkeating@redhat.com> <20061102164114.0cfd3569@banea.int.addix.net> Message-ID: <454A14EB.4070205@warmcat.com> Ralf Ertzinger wrote: > Hi. > > On Thu, 2 Nov 2006 10:37:57 -0500, Jesse Keating wrote: > >> Yes, where MEPIS != Debian, but in this case the ia64 compose of >> Fedora = Fedora. There are no changes (afaik) the ia64 binary >> packages were built from the same srpms at the same time that the >> i386, x86_64, and ppc(64) binary rpms were built. >> > > The point is that ftp://oss.sgi.com/projects/fedora/ has to carry the > SRPMS as well, I think. Personally I think it's fine to point back to RHAT for the sources, after all you click on a link and get taken to a server with the correct sources, it is very difficult to find something to complain about that it happens to be hosted by RHAT and not the same files elsewhere. If the files disappeared from RHAT or for some other reason users could not get at them, well then it can be time to worry about hosting sources yourself. But that does not seem to be the opinion of the FSF: ''... Talking on behalf of CentOS, Johnny Hughes says, "CentOS has been providing source for all packages, changed and unchanged, in their distribution. CentOS has the same understanding of the GPL as expressed by the FSF on this issue." ... "Before I was contacted by the FSF, I didn't know that we needed to actually offer the source code of binaries we didn't modify," says John Andrews, the source code maintainer of Damn Small Linux. "Yet we do comply now, and the FSF occasionally pops in with an email to make sure we do." Similarly, LinuxCD.org, a distributor, makes only Fedora source code available -- and only provides that because it was specifically requested to do so. ...'' -Andy From fedora at camperquake.de Thu Nov 2 16:02:13 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 2 Nov 2006 17:02:13 +0100 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <454A14EB.4070205@warmcat.com> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> <200611021037.57855.jkeating@redhat.com> <20061102164114.0cfd3569@banea.int.addix.net> <454A14EB.4070205@warmcat.com> Message-ID: <20061102170213.053559ac@banea.int.addix.net> Hi. On Thu, 02 Nov 2006 15:55:23 +0000, Andy Green wrote: > elsewhere. If the files disappeared from RHAT or for some other > reason users could not get at them, well then it can be time to worry > about hosting sources yourself. But that does not seem to be the > opinion of the FSF: I wonder what the FSF thinks of partial mirrors. From andy at warmcat.com Thu Nov 2 16:05:34 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 02 Nov 2006 16:05:34 +0000 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <20061102170213.053559ac@banea.int.addix.net> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> <200611021037.57855.jkeating@redhat.com> <20061102164114.0cfd3569@banea.int.addix.net> <454A14EB.4070205@warmcat.com> <20061102170213.053559ac@banea.int.addix.net> Message-ID: <454A174E.7080803@warmcat.com> Ralf Ertzinger wrote: >> elsewhere. If the files disappeared from RHAT or for some other >> reason users could not get at them, well then it can be time to worry >> about hosting sources yourself. But that does not seem to be the >> opinion of the FSF: > > I wonder what the FSF thinks of partial mirrors. Hi Ralf - I wonder what they think I ought to do when I gave my stepson a copy of the FC6 binary DVD! -Andy From prarit at redhat.com Thu Nov 2 16:18:18 2006 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 02 Nov 2006 11:18:18 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <1162479788.14530.43.camel@laptopd505.fenrus.org> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> Message-ID: <454A1A4A.2030206@redhat.com> > Hi, > > are the src.rpm's also available somewhere? (you know, that open source > thing ;) Also, are there plans to make expanded trees available? I tend > to use those a lot more than isos.... > > Yep. You can grab them out of the fedora devel branch. P. > Greetings, > Arjan van de Ven > > From williams at redhat.com Thu Nov 2 16:26:00 2006 From: williams at redhat.com (Clark Williams) Date: Thu, 02 Nov 2006 10:26:00 -0600 Subject: Propose Emacs 22 for Fedora Core 7 In-Reply-To: References: Message-ID: <454A1C18.8010200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Schmitt wrote: > Leo writes: > >> I'm a big fan of Emacs and I like to build Emacs from source. So >> whether FC7 is gonna have Emacs 22 does not concern me much. However I >> think it is important to have this modernized powerful tool available >> to our current and prospective Fedora users. > > I'd like to second this. > +1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFShwYHyuj/+TTEp0RAl96AKCaP+luIG5YHLjGdGbd9tQ8aTPyIgCeJwk0 18dGbwe5pmMG3A0Dpj73B4o= =cqPS -----END PGP SIGNATURE----- From arjan at fenrus.demon.nl Thu Nov 2 16:45:22 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 02 Nov 2006 17:45:22 +0100 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <454A1A4A.2030206@redhat.com> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> <454A1A4A.2030206@redhat.com> Message-ID: <1162485922.14530.59.camel@laptopd505.fenrus.org> On Thu, 2006-11-02 at 11:18 -0500, Prarit Bhargava wrote: > > Hi, > > > > are the src.rpm's also available somewhere? (you know, that open source > > thing ;) Also, are there plans to make expanded trees available? I tend > > to use those a lot more than isos.... > > > > > > Yep. You can grab them out of the fedora devel branch. that's a moving target though (esp since -devel has moved on quite a bit by now).. would be really nice to get a static set ;) From prarit at redhat.com Thu Nov 2 17:43:17 2006 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 02 Nov 2006 12:43:17 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <1162485922.14530.59.camel@laptopd505.fenrus.org> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> <454A1A4A.2030206@redhat.com> <1162485922.14530.59.camel@laptopd505.fenrus.org> Message-ID: <454A2E35.2030104@redhat.com> Arjan van de Ven wrote: > > > > that's a moving target though (esp since -devel has moved on quite a bit > by now).. would be really nice to get a static set ;) > Good point :) I'll up a set shortly ... P. From michel.salim at gmail.com Thu Nov 2 18:08:17 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 2 Nov 2006 13:08:17 -0500 Subject: Propose Emacs 22 for Fedora Core 7 In-Reply-To: References: Message-ID: <883cfe6d0611021008g1983f6f3jcae4e2278d1c7615@mail.gmail.com> On 10/29/06, Leo wrote: > Hi there, > > As we know RMS is extremely strict on fixing bugs, Emacs 22 has long > passed the production quality while still in development. A few days > ago, Emacs's developers have decided to enter pretest?. As it is in > the early stage of FC7 cycle, I'd propose we upgrade to Emacs 22. The > News is just too big for this mailing list, but you can read it here: > http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/etc/NEWS?root=emacs > +1 FWIW, even Emacs 23 (the unicode-2 branch) is stable enough for daily use. Emacs 22 should be even more ready, at least for Rawhide. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From sig at netdot.net Fri Nov 3 00:00:52 2006 From: sig at netdot.net (Aaron VanDevender) Date: Thu, 02 Nov 2006 18:00:52 -0600 Subject: gstreamer and selinux issue In-Reply-To: <44DDC008.50206@redhat.com> References: <1155326370.3461.18.camel@soncomputer> <1155327597.11275.5.camel@soncomputer> <44DDC008.50206@redhat.com> Message-ID: <1162512053.3339.41.camel@lazlo.netdot.net> On Sat, 2006-08-12 at 07:48 -0400, Daniel J Walsh wrote: > > > > I am also having problems with totem-mozplugin, totem's plugin for > > firefox. > > > > Aug 11 16:18:15 soncomputer kernel: audit(1155327494.846:63): avc: > > denied { execstack } for pid=11603 comm="totem-mozilla-v" > > scontext=user_u:system_r:unconfined_t:s0 > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > > > > Aug 11 16:18:15 soncomputer kernel: audit(1155327494.850:64): avc: > > denied { execstack } for pid=11603 comm="totem-mozilla-v" > > scontext=user_u:system_r:unconfined_t:s0 > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > > > > Aug 11 16:18:15 soncomputer kernel: audit(1155327494.850:65): avc: > > denied { execstack } for pid=11603 comm="totem-mozilla-v" > > scontext=user_u:system_r:unconfined_t:s0 > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > > > > > You have two choices with this turn on allow_execstack boolean or label > firefox unconfined_execmem_exec_t. Actually there is a better choice. Rather than change the context for totem (and firefox and pitivi and rhythmbox and everything else that uses gstreamer) you can just change the context of the pitfdll plugin that is causing problems. It needs to exec its own modifiable memory since it loads .dll files on to the heap, and then executes code that it cuts out of them. Try this: chcon -t texrel_shlib_t /usr/lib/gstreamer-0.10/libpitfdll.so Cheers, -Aaron -- sig at netdot.net Plead the First. From jacliburn at bellsouth.net Fri Nov 3 02:56:47 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 02 Nov 2006 20:56:47 -0600 Subject: Request for git-core rebuild In-Reply-To: <454A022F.6080803@city-fan.org> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> <20061102142912.GA11345@osprey.hogchain.net> <454A022F.6080803@city-fan.org> Message-ID: <454AAFEF.3000007@bellsouth.net> Paul Howarth wrote: > As a short-term workaround, you might try installing my libcurl7155 (aka > compat-libcurl) package, which provides a parallel-installable > libcurl.so.3: Paul, what's the best way to install libcurl7155? I guess I need to somehow move curl and curl-devel out of the way first, right? Then install libcurl7155? Or is it okay in this case to force the install of libcurl7155 over the top of curl and curl-devel? From paul at city-fan.org Fri Nov 3 09:14:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 03 Nov 2006 09:14:22 +0000 Subject: Request for git-core rebuild In-Reply-To: <454AAFEF.3000007@bellsouth.net> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> <20061102142912.GA11345@osprey.hogchain.net> <454A022F.6080803@city-fan.org> <454AAFEF.3000007@bellsouth.net> Message-ID: <454B086E.1020807@city-fan.org> Jay Cliburn wrote: > Paul Howarth wrote: > >> As a short-term workaround, you might try installing my libcurl7155 >> (aka compat-libcurl) package, which provides a parallel-installable >> libcurl.so.3: > > Paul, what's the best way to install libcurl7155? I guess I need to > somehow move curl and curl-devel out of the way first, right? Then > install libcurl7155? Or is it okay in this case to force the install of > libcurl7155 over the top of curl and curl-devel? Install the new curl, curl-devel, and libcurl7155 in the same RPM transaction: # rpm -Uvh curl*7.16.0*.rpm libcurl7155*.rpm No forcing should be needed. Paul. From dragoran at feuerpokemon.de Fri Nov 3 09:31:47 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 03 Nov 2006 10:31:47 +0100 Subject: Fedora Core 6 Common Issues In-Reply-To: <4544F0B3.2010802@fedoraproject.org> References: <4544F0B3.2010802@fedoraproject.org> Message-ID: <454B0C83.6090807@feuerpokemon.de> Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/Bugs/FC6Common > > We are in pretty good shape for this release. If you have any bugs > that needed to be added to this page and you have wiki access, go > ahead or let me know with the bugzilla report number. Offlist even. > Rahul > what about this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212370 From buildsys at redhat.com Fri Nov 3 11:07:39 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 3 Nov 2006 06:07:39 -0500 Subject: rawhide report: 20061103 changes Message-ID: <200611031107.kA3B7dca031405@hs20-bc2-6.build.redhat.com> New package libgnomekbd A keyboard configuration library Updated Packages: SDL-1.2.10-9 ------------ * Thu Nov 02 2006 Thomas Woerner 1.2.10-9 - fixed arch order in SDL_config.h wrapper anaconda-11.2-1 --------------- * Thu Nov 02 2006 Chris Lumens - 11.2 - Add name resolution support for IPv6 AAAA and ip6.arpa records (dcantrell). - Center anaconda window (#213350). - Make sure to set a default on the physical extent combo (#212317). - Fix updates on USB keys under kickstart installs. - Set language support on text installs (pnasrat, #212511). - Fix downloading kickstart files from nonstandard port numbers (#212622). - Add more fonts (katzj, #207428). - Fix localhost6 line (dcantrell, #211800, #210050). - Disable keepalive so we don't run out of file handles (#212571). - Display an error if we try to clear nonexistent hard drives (#212377). - Fix lang-table typo (#212304). - Fix file descriptor leak (katzj, #212191). - Fix ZFCP config, kickstart handling, and module probing (katzj, #210094). - Fix widget names on netconfig dialog (notting). - Always bring up the network if specified in kickstart (#191424). - Add Sinhala and Telugu (katzj, #207426, #207428). - Fix iutil traceback (pnasrat, #211830). - Continue if vname or vparm are NULL (dcantrell, #211502). - Add fonts-telugu (katzj, #207428). - Fix package installation progress bar size (katzj, #210531, #211526). - Fix installation with CTC networking (katzj, #210195). - Force swap formatting on ppc upgrades (pnasrat, #206523). - Forget partitioning changes when going back in the UI (#211255). - Don't specify a stdout or stderr for s390 shells (#210481). - Fix window dragging jerkiness (krh). - Add --noipv4 and --noipv6 (#208334). - Correct --onbiosdisk handling (#210705). - Set runlevel 3 by default on VNC installs (#211318). - Fix download failures/retries (pnasrat, katzj, #211117). - Don't use unicode line drawing characters on vt100-nav (katzj, #208374). - Fix /tmp/netinfo parsing (dcantrell, #207991). - Use virtualization instead of xen for the group name (katzj). - Write out iscsi config to kickststart (katzj). - Add qla2400 and qla2xxx to late sort module list (katzj, #210886). - Use a better regex for finding ISO loopback mount points (#205133). - Set up baseUrl correctly when given a list of URLs (#210877). - Network config screen fixes (dcantrell). - Tweak min/max swap numbers for low memory (#189490). - Only run auditDaemon if not in test or rootpath mode (pjones). - Fixes for supporting medium-less devices (Rez Kabir AT dell.com, #207331). - yum API fixes (pnasrat). - System language doesn't have to be in lang-table (#176538). - Fix UI traceback (#210190). * Mon Oct 09 2006 Jeremy Katz - 11.1.0.110-1 - Fix SELinux contexts for iscsi - Fix traceback if addrepos isn't shown (#209997) - Fix traceback looking up hostnames (clumens, #209672) - Fix split media (pnasrat) - Fix network to be enabled after install on non-network installs * Fri Oct 06 2006 Jeremy Katz - 11.1.0.109-1 - Fix iscsi for toolchain changes and targets with multiple IPs - Validate ips like 9.1.2.3 (dcantrel, #209654) eclipse-1:3.2.1-12.fc7 ---------------------- * Thu Nov 02 2006 Ben Konrath 3.2.1-12 - Move doc plugins to %{_libdir}/eclipse/plugins because of html is being generated differently on different arches. - Fix multilib problem when there are two or more jars within a jar. * Wed Nov 01 2006 Ben Konrath 3.2.1-11 - Move copy-platform to %{_libdir}/eclipse - Move the platform.source, icu4j, icu4j.source, help.webapp and update.core.linux plugins to %{_libdir}/eclipse/plugins because these plugins have platform specific content. Some of the platform specific content may be a result of bugs in libgcj. These need to be investigated. - Disable building the help indexes on all archs so that we have the same doc plugins on all archs. - Remove org.apache.ant_1.6.5/bin/runant.py to avoid multilib conflicts. - Repack all the jars and the jars within those jars. This is needed to make this package multilib compatible. - Put SWT symlinks in %{_libdir}/eclipse instead of %{_libdir}/eclipse/plugins. * Wed Nov 01 2006 Andrew Overholt 3.2.1-11 - Use equinox initializer instead of old patch to core.runtime. - Run initializer *after* splitting install into arch-specific and arch-independent locations. - Move copy-platform to arch-specific location. - Get rid of broken symlinks in tomcat plugin. ekiga-2.0.3-3.fc7 ----------------- * Fri Nov 02 2007 Daniel Veillard - 2.0.3-3 - Resolves: rhbz#201535 - fixes build-requires for opal-devel and pwlib-devel evolution-data-server-1.9.1-4.fc7 --------------------------------- * Thu Nov 02 2006 Matthew Barnes - 1.9.1-4.fc7 - Add patch for Gnome.org bug #369168, #369259, and #369261 (misc camel bugs reported by Hans Petter Jansson). gdb-6.5-14.fc7 -------------- * Thu Nov 02 2006 Jan Kratochvil - 6.5-14 - Fix "??" resolving of symbols from (non-prelinked) debuginfo packages. - Fix "??" resolving of symbols from overlapping functions (nanosleep(3)). - Also disable testcase "checkpoint.exp" for a possible kernel Bug 207002. - Provided (disabled during build) threading testsuite from BEA. * Sat Oct 14 2006 Jan Kratochvil - 6.5-13 - Fix deadlock accessing last address space byte; for corrupted backtraces. * Sun Oct 08 2006 Jan Kratochvil - 6.5-12 - Disabled IPv6 until its user visible syntax gets stable upstream. gmp-4.1.4-10 ------------ * Thu Nov 02 2006 Thomas Woerner 4.1.4-10 - fixed arch order in gmp.h and gmp-mparam.h wrapper for all architectures * Thu Nov 02 2006 Joe Orton 4.1.4-10 - include ppc64 header on ppc64 not ppc header gnome-screensaver-2.17.1-2.fc7 ------------------------------ * Thu Nov 02 2006 Ray Strode - 2.17.1-2 - temporarily revert smart card patches since they got broke in the switch to 2.17.1 and people can't login (bug 212194) gnucash-2.0.2-1.fc6 ------------------- * Wed Oct 11 2006 Bill Nottingham - 2.0.2-1 - update to 2.0.2 - update docs to 2.0.1 icu-3.6-9 --------- * Wed Oct 18 2006 Caolan McNamara - 3.6-9 - Resolves: rhbz#213648 extend prev/next to handle ZWJ * Wed Oct 18 2006 Caolan McNamara - 3.6-8 - Resolves: rhbz213375 (icu.icu5488.assamese.patch) irqbalance-1:1.13-6.fc7 ----------------------- * Thu Nov 02 2006 Neil Horman - 1.13-6 - bumping up MAX_INTERRUPTS to support xen kernels - rediffing patch1 and patch3 to remove fuzz * Tue Oct 17 2006 Neil Horman - 1.13-5 - Making oneshot mean oneshot always (bz 211178) * Wed Sep 13 2006 Peter Jones - 1.13-4 - Fix subsystem locking kudzu-1.2.60-1 -------------- * Thu Nov 02 2006 Bill Nottingham - 1.2.60-1 - yet more SUBCHANNELS related fixing (#204803) - rewrite vio probing (#213457) m17n-db-1.3.3-34.fc7 -------------------- * Thu Nov 02 2006 Mayank Jain - Added ZWNJ to hi-inscript/phonetic openssh-4.3p2-11.fc7 -------------------- * Thu Nov 02 2006 Tomas Mraz - 4.3p2-11 - merge sshd initscript patches - kill all ssh sessions when stop is called in halt or reboot runlevel - remove -TERM option from killproc so we don't race on sshd restart openssl-0.9.8b-9.fc7 -------------------- * Thu Nov 02 2006 Tomas Mraz 0.9.8b-9 - aliasing bug in engine loading, patch by IBM (#213216) * Mon Oct 02 2006 Tomas Mraz 0.9.8b-8 - CVE-2006-2940 fix was incorrect (#208744) * Mon Sep 25 2006 Tomas Mraz 0.9.8b-7 - fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276) - fix CVE-2006-2940 - parasitic public keys DoS (#207274) - fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940) - fix CVE-2006-4343 - sslv2 client DoS (#206940) parted-1.7.1-18.fc7 ------------------- * Thu Nov 02 2006 David Cantrell - 1.7.1-18 - Detect Apple_Boot partition types correctly (#204714) php-5.1.6-4 ----------- * Tue Oct 31 2006 Joseph Orton 5.1.6-4 - rebuild for curl soname bump - add build fix for curl 7.16 API tmpwatch-2.9.9-1 ---------------- * Thu Nov 02 2006 Miloslav Trmac - 2.9.9-1 - Exclude aquota.group and aquota.user files Resolves: 206258 - Don't require the user-specified paths to be absolute Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jonathan.underwood at gmail.com Fri Nov 3 11:17:08 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Nov 2006 11:17:08 +0000 Subject: Propose Emacs 22 for Fedora Core 7 In-Reply-To: <883cfe6d0611021008g1983f6f3jcae4e2278d1c7615@mail.gmail.com> References: <883cfe6d0611021008g1983f6f3jcae4e2278d1c7615@mail.gmail.com> Message-ID: <645d17210611030317r6ad1355et968e0af65dc41a62@mail.gmail.com> On 02/11/06, Michel Salim wrote: > FWIW, even Emacs 23 (the unicode-2 branch) is stable enough for daily > use. Emacs 22 should be even more ready, at least for Rawhide. Just to add another +1, I've been using emacs22 checked out from CVS periodically over the past 6 months, and it's already a lot more stable than a lot of release versions of other software (think Gaim). I am sure emacs22, even at this point, is ready for inclusion. Jonathan. From sundaram at fedoraproject.org Fri Nov 3 11:47:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 17:17:07 +0530 Subject: Fedora Core 6 Common Issues In-Reply-To: <454B0C83.6090807@feuerpokemon.de> References: <4544F0B3.2010802@fedoraproject.org> <454B0C83.6090807@feuerpokemon.de> Message-ID: <454B2C3B.6020007@fedoraproject.org> dragoran wrote: > Rahul Sundaram wrote: >> Hi >> >> http://fedoraproject.org/wiki/Bugs/FC6Common >> >> We are in pretty good shape for this release. If you have any bugs >> that needed to be added to this page and you have wiki access, go >> ahead or let me know with the bugzilla report number. Offlist even. >> Rahul >> > > what about this one: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212370 > Added. Rahul From sdl.web at gmail.com Fri Nov 3 12:33:05 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 03 Nov 2006 12:33:05 +0000 Subject: Propose Emacs 22 for Fedora Core 7 References: <883cfe6d0611021008g1983f6f3jcae4e2278d1c7615@mail.gmail.com> Message-ID: On Thu, 02/11/06, Michel Salim wrote: > On 10/29/06, Leo wrote: >> Hi there, >> >> As we know RMS is extremely strict on fixing bugs, Emacs 22 has long >> passed the production quality while still in development. A few days >> ago, Emacs's developers have decided to enter pretest?. As it is in >> the early stage of FC7 cycle, I'd propose we upgrade to Emacs 22. The >> News is just too big for this mailing list, but you can read it here: >> http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/etc/NEWS?root=emacs >> > +1 > > FWIW, even Emacs 23 (the unicode-2 branch) is stable enough for daily > use. Emacs 22 should be even more ready, at least for Rawhide. > Same here. I can't live without unicode support. -- Leo From rubin at xs4all.nl Fri Nov 3 12:51:47 2006 From: rubin at xs4all.nl (Rubin) Date: Fri, 03 Nov 2006 13:51:47 +0100 Subject: Strange behaviour with boottime loading of ipw2200 Message-ID: <454B3B63.3040501@xs4all.nl> Hi People, I noticed something weird with the ipw2200 drivers being autoloaded at boot. I have an "alias eth1 ipw2200" line in modprobe.conf. It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random. NetworkManager gets sort of confused by this. The interface does work though when configged by hand. Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" interface name. I was wondering if anyone has seen this kind of thing before. Maybe it is the result of a common misconfiguration? A few searches on google didn't show anything, hence my question here. Kind regards, Rubin. From jacliburn at bellsouth.net Fri Nov 3 12:50:34 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Fri, 03 Nov 2006 06:50:34 -0600 Subject: Request for git-core rebuild In-Reply-To: <454B086E.1020807@city-fan.org> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> <20061102142912.GA11345@osprey.hogchain.net> <454A022F.6080803@city-fan.org> <454AAFEF.3000007@bellsouth.net> <454B086E.1020807@city-fan.org> Message-ID: <454B3B1A.8050803@bellsouth.net> Paul Howarth wrote: > Jay Cliburn wrote: >> Paul Howarth wrote: >> >>> As a short-term workaround, you might try installing my libcurl7155 >>> (aka compat-libcurl) package, which provides a parallel-installable >>> libcurl.so.3: >> >> Paul, what's the best way to install libcurl7155? I guess I need to >> somehow move curl and curl-devel out of the way first, right? Then >> install libcurl7155? Or is it okay in this case to force the install >> of libcurl7155 over the top of curl and curl-devel? > > Install the new curl, curl-devel, and libcurl7155 in the same RPM > transaction: Of course... Thanks. And thanks for the curl compat lib. It works just fine. Jay From bigjoe1008 at gmail.com Fri Nov 3 13:48:34 2006 From: bigjoe1008 at gmail.com (Joe Harnish) Date: Fri, 3 Nov 2006 08:48:34 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B3B63.3040501@xs4all.nl> References: <454B3B63.3040501@xs4all.nl> Message-ID: <763fc8580611030548k5b0d25b5i97e76dd32c3baa01@mail.gmail.com> I see this about 33% of the time. During the FC6 development process I was getting an error with udev when I would get __tmp#####... but then after a few rebuilds of packages that went away. But the issue has come back. On 11/3/06, Rubin wrote: > > Hi People, > > I noticed something weird with the ipw2200 drivers being autoloaded at > boot. I have an "alias eth1 ipw2200" line in modprobe.conf. > > It used to work without a problem for a couple of days but suddenly I'm > getting very weird interface names. Instead of "eth1", I'm getting > "__tmp437329847239" where the number behind tmp is random. > > NetworkManager gets sort of confused by this. The interface does work > though when configged by hand. > > Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" > interface name. > > I was wondering if anyone has seen this kind of thing before. Maybe it > is the result of a common misconfiguration? A few searches on google > didn't show anything, hence my question here. > > Kind regards, > > > Rubin. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Nov 3 13:28:10 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 08:28:10 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B3B63.3040501@xs4all.nl> References: <454B3B63.3040501@xs4all.nl> Message-ID: <20061103132810.GA17328@nostromo.devel.redhat.com> Rubin (rubin at xs4all.nl) said: > It used to work without a problem for a couple of days but suddenly I'm > getting very weird interface names. Instead of "eth1", I'm getting > "__tmp437329847239" where the number behind tmp is random. Do you have an ifcfg file with the proper HWADDR for the device? Bill From denis at poolshark.org Fri Nov 3 14:50:52 2006 From: denis at poolshark.org (Denis Leroy) Date: Fri, 03 Nov 2006 15:50:52 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103132810.GA17328@nostromo.devel.redhat.com> References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> Message-ID: <454B574C.3000704@poolshark.org> Bill Nottingham wrote: > Rubin (rubin at xs4all.nl) said: >> It used to work without a problem for a couple of days but suddenly I'm >> getting very weird interface names. Instead of "eth1", I'm getting >> "__tmp437329847239" where the number behind tmp is random. > > Do you have an ifcfg file with the proper HWADDR for the device? I suffer from the same problem too. In some cases, it's the wireless that doesn't come up properly, and i have to restart things manually until it picks it up right. Yes, in my case i have the correct HWADDR lines in the ifcfg files. From fedoradevellist at helsinki.LA Fri Nov 3 15:17:34 2006 From: fedoradevellist at helsinki.LA (Henri Ala-Peijari) Date: Fri, 03 Nov 2006 17:17:34 +0200 Subject: No response to bug #189571 Message-ID: <454B5D8E.5030404@helsinki.LA> I experienced the bug #189571 regarding failed burning on K3B and reported that it's still there on FC6. No response to my bug report... what can I do to make someone notice? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189571 From darrellpf at gmail.com Fri Nov 3 15:28:32 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 3 Nov 2006 07:28:32 -0800 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B574C.3000704@poolshark.org> References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> <454B574C.3000704@poolshark.org> Message-ID: On 11/3/06, Denis Leroy wrote: > Bill Nottingham wrote: > > Rubin (rubin at xs4all.nl) said: > >> It used to work without a problem for a couple of days but suddenly I'm > >> getting very weird interface names. Instead of "eth1", I'm getting > >> "__tmp437329847239" where the number behind tmp is random. > > > > Do you have an ifcfg file with the proper HWADDR for the device? > > I suffer from the same problem too. In some cases, it's the wireless > that doesn't come up properly, and i have to restart things manually > until it picks it up right. Yes, in my case i have the correct HWADDR > lines in the ifcfg files. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > The random name seems to be created (by udev?) when the firmware doesn't load. I suspect it is a timing problem (or the 'failed' timeout needs to be just a bit longer). The issue was there for a while a about two months before FC6 release, disappeared for a bit and got worse just about FC6 release time. NetworkManager used to deal with the situation just fine, using the random name when it found it, but is often confused now. I have a machine that uses IPW2100 and even the module load/unload and a restart of NM doesn't always fix the problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210780 darrell From notting at redhat.com Fri Nov 3 15:38:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 10:38:08 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> <454B574C.3000704@poolshark.org> Message-ID: <20061103153808.GA20376@nostromo.devel.redhat.com> darrell pfeifer (darrellpf at gmail.com) said: > The random name seems to be created (by udev?) when the firmware > doesn't load. I suspect it is a timing problem (or the 'failed' > timeout needs to be just a bit longer). Hm, why is the firmware not loading right? What messages do you get from the kernel? Bill From adrian at lisas.de Fri Nov 3 15:46:15 2006 From: adrian at lisas.de (Adrian Reber) Date: Fri, 3 Nov 2006 16:46:15 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B3B63.3040501@xs4all.nl> References: <454B3B63.3040501@xs4all.nl> Message-ID: <20061103154615.GA20127@lisas.de> On Fri, Nov 03, 2006 at 01:51:47PM +0100, Rubin wrote: > I noticed something weird with the ipw2200 drivers being autoloaded at > boot. I have an "alias eth1 ipw2200" line in modprobe.conf. > > It used to work without a problem for a couple of days but suddenly I'm > getting very weird interface names. Instead of "eth1", I'm getting > "__tmp437329847239" where the number behind tmp is random. > > NetworkManager gets sort of confused by this. The interface does work > though when configged by hand. > > Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" > interface name. > > I was wondering if anyone has seen this kind of thing before. Maybe it > is the result of a common misconfiguration? A few searches on google > didn't show anything, hence my question here. I am seeing the same thing on a server using bonding with two ethernet interfaces. I have two different cards (e1000, acenic) and on every boot one of the card fails. The bond0 interface still works with only one card by I also have to do an rmmod, modprobe to get both cards working. So I have the same error in a different setup. Adrian From fedora at camperquake.de Fri Nov 3 15:53:14 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 03 Nov 2006 16:53:14 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B3B63.3040501@xs4all.nl> References: <454B3B63.3040501@xs4all.nl> Message-ID: <454B65EA.90403@camperquake.de> Hi. > It used to work without a problem for a couple of days but suddenly I'm > getting very weird interface names. Instead of "eth1", I'm getting > "__tmp437329847239" where the number behind tmp is random. I get this from time to time, too, on an iBook (airport driver, so no firmware involved). > NetworkManager gets sort of confused by this. The interface does work > though when configged by hand. NM seems to work, dhclient does not like those ifnames. From jkeating at redhat.com Fri Nov 3 15:54:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 10:54:02 -0500 Subject: No response to bug #189571 In-Reply-To: <454B5D8E.5030404@helsinki.LA> References: <454B5D8E.5030404@helsinki.LA> Message-ID: <200611031054.05205.jkeating@redhat.com> On Friday 03 November 2006 10:17, Henri Ala-Peijari wrote: > I experienced the bug #189571 regarding failed burning on K3B and > reported that it's still there on FC6. No response to my bug report... > what can I do to make someone notice? Have you tried burning with Nautilus on Gnome? Is it a KDE (k3b) specific thing or more of a general 'your burner doesn't work' thing? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Nov 3 15:54:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 10:54:52 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103154615.GA20127@lisas.de> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> Message-ID: <20061103155452.GA20476@nostromo.devel.redhat.com> Adrian Reber (adrian at lisas.de) said: > I am seeing the same thing on a server using bonding with two ethernet > interfaces. I have two different cards (e1000, acenic) and on every boot > one of the card fails. The bond0 interface still works with only one > card by I also have to do an rmmod, modprobe to get both cards working. > So I have the same error in a different setup. Not to sound like a broken record - but do you have ifcfg files with HWADDR in them? Background: PCI modules are loaded (essentially) in parallel. If one driver takes longer to initialize on a particular boot, the device ordering will change. We have code run by udev (/lib/udev/rename_device) to handle this, but it requires that ifcfg files have the HWADDR in them for the appropriate devices so it knows what should remain what. Bill From adrian at lisas.de Fri Nov 3 16:05:09 2006 From: adrian at lisas.de (Adrian Reber) Date: Fri, 3 Nov 2006 17:05:09 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103155452.GA20476@nostromo.devel.redhat.com> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> Message-ID: <20061103160509.GB20127@lisas.de> On Fri, Nov 03, 2006 at 10:54:52AM -0500, Bill Nottingham wrote: > Adrian Reber (adrian at lisas.de) said: > > I am seeing the same thing on a server using bonding with two ethernet > > interfaces. I have two different cards (e1000, acenic) and on every boot > > one of the card fails. The bond0 interface still works with only one > > card by I also have to do an rmmod, modprobe to get both cards working. > > So I have the same error in a different setup. > > Not to sound like a broken record - but do you have ifcfg files with > HWADDR in them? No. > Background: > > PCI modules are loaded (essentially) in parallel. If one driver takes > longer to initialize on a particular boot, the device ordering will change. > > We have code run by udev (/lib/udev/rename_device) to handle this, but > it requires that ifcfg files have the HWADDR in them for the appropriate > devices so it knows what should remain what. Okay. I will try it with HWADDR and see if it fixes our problem. Thanks for the information. Adrian From fedoradevellist at helsinki.LA Fri Nov 3 16:07:43 2006 From: fedoradevellist at helsinki.LA (Henri Ala-Peijari) Date: Fri, 03 Nov 2006 18:07:43 +0200 Subject: No response to bug #189571 In-Reply-To: <200611031054.05205.jkeating@redhat.com> References: <454B5D8E.5030404@helsinki.LA> <200611031054.05205.jkeating@redhat.com> Message-ID: <454B694F.8040607@helsinki.LA> Nautilus works ok. K3B just has the growisofs problem. Burner is a Sony and recognized as DW-Q28A firmware KYS3. Jesse Keating wrote: > On Friday 03 November 2006 10:17, Henri Ala-Peijari wrote: > >> I experienced the bug #189571 regarding failed burning on K3B and >> reported that it's still there on FC6. No response to my bug report... >> what can I do to make someone notice? >> > > Have you tried burning with Nautilus on Gnome? Is it a KDE (k3b) specific > thing or more of a general 'your burner doesn't work' thing? > > From darrellpf at gmail.com Fri Nov 3 16:15:25 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 3 Nov 2006 08:15:25 -0800 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103155452.GA20476@nostromo.devel.redhat.com> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> Message-ID: On 11/3/06, Bill Nottingham wrote: > Adrian Reber (adrian at lisas.de) said: > > I am seeing the same thing on a server using bonding with two ethernet > > interfaces. I have two different cards (e1000, acenic) and on every boot > > one of the card fails. The bond0 interface still works with only one > > card by I also have to do an rmmod, modprobe to get both cards working. > > So I have the same error in a different setup. > > Not to sound like a broken record - but do you have ifcfg files with > HWADDR in them? > > Background: > > PCI modules are loaded (essentially) in parallel. If one driver takes > longer to initialize on a particular boot, the device ordering will change. > > We have code run by udev (/lib/udev/rename_device) to handle this, but > it requires that ifcfg files have the HWADDR in them for the appropriate > devices so it knows what should remain what. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device (eth1) doesn't. I'm assuming that the /etc/sysconfig/networking/profiles/default path is the correct one, not either of /etc/sysconfig/networking/devices/ /etc/sysconfig/network-scripts/ >From the failure I see in /var/log/messages it looks like the Broadcom driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was left to find a random name. I'll try putting HWADDR in the IPW eth1 ifcfg file(s). darrell From jkeating at redhat.com Fri Nov 3 16:24:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 11:24:16 -0500 Subject: No response to bug #189571 In-Reply-To: <454B694F.8040607@helsinki.LA> References: <454B5D8E.5030404@helsinki.LA> <200611031054.05205.jkeating@redhat.com> <454B694F.8040607@helsinki.LA> Message-ID: <200611031124.16271.jkeating@redhat.com> On Friday 03 November 2006 11:07, Henri Ala-Peijari wrote: > Nautilus works ok. K3B just has the growisofs problem. Burner is a Sony > and recognized as DW-Q28A firmware KYS3. Filing the bug upstream so that it gets fixed up there is the best bet. Fedora (and everybody else that uses k3b) will then pick up the change next time they pull a new release from KDE. Once KDE does fix it upstream, it might be prudent filing a bugzilla for the update to the new upstream version to fix problems $foo and $bar... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Nov 3 16:27:55 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 11:27:55 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> Message-ID: <20061103162755.GA21398@nostromo.devel.redhat.com> darrell pfeifer (darrellpf at gmail.com) said: > In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device > (eth1) doesn't. I'm assuming that the > > /etc/sysconfig/networking/profiles/default > > path is the correct one, not either of > > /etc/sysconfig/networking/devices/ > /etc/sysconfig/network-scripts/ The last one is the path read (/etc/sysconfig/network-scripts.) > From the failure I see in /var/log/messages it looks like the Broadcom > driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was > left to find a random name. Kernel pays no attention to user configuration - it just grabs the first ethX name. The renaming is done by a udev rule. Bill From darrellpf at gmail.com Fri Nov 3 16:49:55 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 3 Nov 2006 08:49:55 -0800 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103162755.GA21398@nostromo.devel.redhat.com> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> <20061103162755.GA21398@nostromo.devel.redhat.com> Message-ID: On 11/3/06, Bill Nottingham wrote: > darrell pfeifer (darrellpf at gmail.com) said: > > In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device > > (eth1) doesn't. I'm assuming that the > > > > /etc/sysconfig/networking/profiles/default > > > > path is the correct one, not either of > > > > /etc/sysconfig/networking/devices/ > > /etc/sysconfig/network-scripts/ > > The last one is the path read (/etc/sysconfig/network-scripts.) > > > From the failure I see in /var/log/messages it looks like the Broadcom > > driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was > > left to find a random name. > > Kernel pays no attention to user configuration - it just grabs the first > ethX name. The renaming is done by a udev rule. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Added HWADDR for the IPW. That will hopefully fix the naming. Now we move to Network Manager. When I log in it fails to connect. A manual selection does work to connect afterwards. I'm using MAC filtering on this AP, not WPA darrell -------------------------------------------- Nov 3 08:34:11 localhost NetworkManager: Updating allowed wireless network lists. Nov 3 08:34:11 localhost NetworkManager: SWITCH: no current connection, found better connection 'eth1'. Nov 3 08:34:11 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason Nov 3 08:34:11 localhost NetworkManager: Will activate connection 'eth1/SMC'. Nov 3 08:34:11 localhost NetworkManager: Device eth1 activation scheduled... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) started... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) started... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Nov 3 08:34:11 localhost NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) starting... Nov 3 08:34:11 localhost NetworkManager: Activation (eth1/wireless): access point 'SMC' is unencrypted, no key needed. Nov 3 08:34:12 localhost NetworkManager: SUP: sending command 'INTERFACE_ADD eth1 wext /var/run/wpa_supplicant ' Nov 3 08:34:13 localhost bonobo-activation-server (darrell-2706): Passing command-line arguments in .server files is deprecated: "/usr/bin/tomboy --panel-applet" Nov 3 08:34:13 localhost NetworkManager: SUP: response was 'OK' Nov 3 08:34:13 localhost NetworkManager: Error opening control interface to supplicant. Nov 3 08:34:13 localhost NetworkManager: real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant. Nov 3 08:34:13 localhost NetworkManager: Activation (eth1) failure scheduled... Nov 3 08:34:13 localhost NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) complete. Nov 3 08:34:13 localhost NetworkManager: Activation (eth1) failed for access point (SMC) Nov 3 08:34:14 localhost kernel: ipw2200: Failed to send ASSOCIATE: Already sending a command. Nov 3 08:34:14 localhost NetworkManager: Activation (eth1) failed. Nov 3 08:34:14 localhost NetworkManager: Deactivating device eth1. Nov 3 08:34:17 localhost avahi-daemon[2345]: Withdrawing address record for fe80::213:ceff:febf:4eb6 on eth1. Nov 3 08:34:18 localhost avahi-daemon[2345]: Leaving mDNS multicast group on interface eth1.IPv6 with address fe80::213:ceff:febf:4eb6. Nov 3 08:34:18 localhost avahi-daemon[2345]: iface.c: interface_mdns_mcast_join() called but no local address available. Nov 3 08:34:18 localhost dhclient: receive_packet failed on eth1: Network is down Nov 3 08:34:18 localhost avahi-daemon[2345]: Interface eth1.IPv6 no longer relevant for mDNS. Nov 3 08:34:31 localhost ntpd[2197]: sendto(80.163.145.206) (fd=21): Invalid argument Nov 3 08:34:31 localhost ntpd[2197]: sendto(130.133.1.10) (fd=21): Invalid argument Nov 3 08:34:34 localhost ntpd[2197]: sendto(202.49.59.6) (fd=21): Invalid argument Nov 3 08:34:39 localhost avahi-daemon[2345]: New relevant interface eth1.IPv6 for mDNS. Nov 3 08:34:39 localhost avahi-daemon[2345]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::213:ceff:febf:4eb6. Nov 3 08:34:39 localhost avahi-daemon[2345]: Registering new address record for fe80::213:ceff:febf:4eb6 on eth1. Nov 3 08:34:43 localhost kernel: ipw2200: Firmware error detected. Restarting. Nov 3 08:34:52 localhost NetworkManager: User Switch: /org/freedesktop/NetworkManager/Devices/eth1 / SMC Nov 3 08:34:52 localhost NetworkManager: Deactivating device eth1. From shantanu_843 at yahoo.co.in Fri Nov 3 19:49:20 2006 From: shantanu_843 at yahoo.co.in (shantanu choudhary) Date: Fri, 3 Nov 2006 19:49:20 +0000 (GMT) Subject: hi all Message-ID: <644244.94189.qm@web7610.mail.in.yahoo.com> hi all this is shantanu. i m a student and studying computer engineering,3rd year. well i joined this comunity as i got through some links from RED HAT LORD OF CODE!! competetion. well i m intrested in all the work which you guys are doing but only thing is that i m REALLY NEW in tis field and dont know what to start and how to?? I have RHEL 4 installed but i use it rarely just to run some small programs in languages like perl,java etc. i am not a big programmer or of any sort i am starter and i want to ask that can you help me out to learn this work of yours!!!!! today we had a cool seminar on FOSS(Free And Open Source Software) and there was i actually went through relevance of these kinds of communities and kind of work they do..... Please dont consider my ignorance in this field in a negative way only i want is can i get some help!!!!!untill now what i was doing was just deleting all mails forwarded by you on this list. sorry about that i did it because those mails were like alien messages which i want ot understand and talk but cant just do it. Sorry for boring you all busy guys with stuff like this i hope that in your some of spare time you can give me your precious advice to me and i m confirming that i m going to count on that!!! thanks be happy and best of luckwith your work!! shantanu --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Fri Nov 3 20:51:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 02:21:38 +0530 Subject: hi all In-Reply-To: <644244.94189.qm@web7610.mail.in.yahoo.com> References: <644244.94189.qm@web7610.mail.in.yahoo.com> Message-ID: <454BABDA.90603@fedoraproject.org> shantanu choudhary wrote: > hi all > this is shantanu. i m a student and studying computer engineering,3rd year. > well i joined this comunity as i got through some links from RED HAT > LORD OF CODE!! competetion. well i m intrested in all the work which you > guys are doing but only thing is that i m REALLY NEW in tis field and > dont know what to start and how to?? > I have RHEL 4 installed but i use it rarely > just to run some small programs in languages like perl,java etc. i am > not a big programmer or of any sort i am starter and i want to ask that > can you help me out to learn this work of yours!!!!! > today we had a cool seminar on FOSS(Free And Open > Source Software) and there was i actually went through relevance of > these kinds of communities and kind of work they do..... > Please dont consider my > ignorance in this field in a negative way only i want is can i get some > help!!!!!untill now what i was doing was just deleting all mails > forwarded by you on this list. sorry about that i did it because those > mails were like alien messages which i want ot understand and talk but > cant just do it. > Sorry for boring you all > busy guys with stuff like this i hope that in your some of spare time > you can give me your precious advice to me and i m confirming that i m > going to count on that!!! > thanks > be happy and best of luckwith your work!! > shantanu If you are interested in contributing to Fedora, there are a number of sub projects that would welcome it very much. Refer to http://fedoraproject.org/wiki/HelpWanted and http://fedoraproject.org/wiki/Projects. Its understanding difficult for someone new to Linux or even Fedorato understand all the discussions in this list. Hang out more and you will be able to pick up more and more over time. Ignorance is a opportunity. Rahul From ich at frank-schmitt.net Fri Nov 3 18:57:31 2006 From: ich at frank-schmitt.net (Frank Schmitt) Date: Fri, 03 Nov 2006 19:57:31 +0100 Subject: Propose Emacs 22 for Fedora Core 7 References: <883cfe6d0611021008g1983f6f3jcae4e2278d1c7615@mail.gmail.com> Message-ID: Leo writes: >> FWIW, even Emacs 23 (the unicode-2 branch) is stable enough for daily >> use. Emacs 22 should be even more ready, at least for Rawhide. >> > > Same here. I can't live without unicode support. (Which is acceptable to poor in 21, but good in 22. Emacs 23 has a loooong way to go) -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From sundaram at fedoraproject.org Sat Nov 4 00:25:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 05:55:07 +0530 Subject: No response to bug #189571 In-Reply-To: <454B5D8E.5030404@helsinki.LA> References: <454B5D8E.5030404@helsinki.LA> Message-ID: <454BDDE3.4040209@fedoraproject.org> Henri Ala-Peijari wrote: > I experienced the bug #189571 regarding failed burning on K3B and > reported that it's still there on FC6. No response to my bug report... > what can I do to make someone notice? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189571 There will be a update on testing soon according to the last comment. Rahul From dragoran at feuerpokemon.de Sat Nov 4 08:29:33 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 04 Nov 2006 09:29:33 +0100 Subject: State of multilib development update In-Reply-To: <4541C56A.5070903@hhs.nl> References: <4541C56A.5070903@hhs.nl> Message-ID: <454C4F6D.1050102@feuerpokemon.de> I would like to add this: i386-devel packages do not create the symlinks needed by ld to find a lib. ld -lX11 will search for libX11.so If you have libX11-devel.x86_64 installed there will be a symlink /usr/lib64/libX11.so -> /usr/lib64/libX11.so.6.2.0 which is ok and works. But if you have installed libX11-devel.i386 there is no symlink which results into ld is unable to find the lib. libX11 was just an example, this happens with ALL i386-devel packages. From jonesc at hep.phy.cam.ac.uk Sat Nov 4 11:57:55 2006 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Sat, 4 Nov 2006 11:57:55 +0000 Subject: compiz window settings Message-ID: <200611041157.55630.jonesc@hep.phy.cam.ac.uk> Hi, I tried this question on the main fedora list, but with no response, so I'm hoping the more techy people here can help me :) I want to try and control which windows compiz includes in some of its visual effects, such as the scale and switcher plugins. Looking with gconf-editor I see that these plugins have a list of the window types they will include. However, I have no idea how different application windows get assigned to one of these types ? Could someone point me to where these sort of things get set up ? cheers Chris From buildsys at redhat.com Sat Nov 4 12:47:59 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 4 Nov 2006 07:47:59 -0500 Subject: rawhide report: 20061104 changes Message-ID: <200611041247.kA4Clx7Y005902@hs20-bc2-6.build.redhat.com> Updated Packages: bind-30:9.3.3-6.fc7 ------------------- * Mon Oct 30 2006 Martin Stransky - 30:9.3.3-6 - fix for #200465: named-checkzone and co. cannot be run as non-root user - fix for #212348: chroot'd named causes df permission denied error - fix for #211249, #211083 - problems with stopping named - fix for #212549: init script does not unmount /proc filesystem - fix for #211282: EDNS is globally enabled, crashing CheckPoint FW-1, added edns-enable options to named configuration file which can suppress EDNS in queries to DNS servers (see /usr/share/doc/bind-9.3.3/misc/options) - fix for #212961: bind-chroot doesn't clean up its mess on %preun - update to 9.3.3rc3, removed already merged patches * Fri Oct 13 2006 Martin Stransky - 30:9.3.3-5 - fix for #209359: bind-libs from compatlayer CD will not install on ia64 checkpolicy-1.32-1 ------------------ * Tue Oct 17 2006 Dan Walsh - 1.32-1 - Latest update from NSA * Updated version for release. cups-1:1.2.5-6.fc7 ------------------ * Fri Nov 03 2006 Tim Waugh 1:1.2.5-6 - Restore missed JobQueuedRemote D-Bus signal in ipp backend (part of bug #212763). * Thu Nov 02 2006 Tim Waugh - LSPP patch fix (bug #213498). * Wed Nov 01 2006 Tim Waugh 1:1.2.5-5 - Send QueueChanged D-Bus signal on all job state changes. dbus-0.95-1.fc7 --------------- * Fri Nov 03 2006 John (J5) Palmieri - 0.95-1 - Update to D-Bus 1.0 RC 3 (0.95) - don't build with tests on * Sat Oct 14 2006 John (J5) Palmieri - 0.94-1 - Update to D-Bus 1.0 RC 2 (0.94) * Sun Oct 01 2006 Jesse Keating - 0.93-3 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 desktop-printing-0.19-17.fc7 ---------------------------- * Fri Nov 03 2006 Matthias Clasen - 0.19-17 - Fix a problem where eggcups loses track of remote jobs (#212763) eclipse-1:3.2.1-15.fc7 ---------------------- * Fri Nov 03 2006 Andrew Overholt 3.2.1-15 - Make sdk require config.ini itself rather than the package to deal with the bi-arch installation situation. - Move sdk feature and plugin to %{_libdir} so we can check for its existence in the post scripts. * Thu Nov 02 2006 Andrew Overholt 3.2.1-14 - Remove post sections that munge eclipse.product; always set it to org.eclipse.platform.ide or org.eclipse.sdk.ide. - Remove changelogs prior to 3.2.0. foomatic-3.0.2-39.fc7 --------------------- * Fri Nov 03 2006 Tim Waugh 3.0.2-39 - Updated db-engine to 3.0-20061031. - Updated db to 3.0-20061031. - Remove references to foo2zjs and foo2oak (bug #208851). glibc-2.5.90-4 -------------- * Fri Nov 03 2006 Jakub Jelinek 2.5.90-4 - fix atexit backwards compatibility (#213388) - add mai_IN locale (#213415) - remove bogus /usr/lib/librt.so.1 symlink (#213555) - fix memusage (#213656) - change libc.info category (#209493) gnome-utils-1:2.16.1-2.fc7 -------------------------- * Fri Nov 03 2006 Matthias Clasen - 2.16.1-2 - Silence %pre libpfm-3.2-0.060926.3.fc7 ------------------------- * Fri Nov 03 2006 Will Cohen - 3.2-0.060926.3 - Add dist tag to build. * Sun Oct 01 2006 Will Cohen - 3.2-0.060926.2 - Eliminate unneeded libpfm-compat.patch. * Sun Oct 01 2006 Will Cohen - 3.2-0.060926.1 - Update to libpfm-3.2-060926. libsoup-2.2.96-5.fc7 -------------------- * Fri Nov 03 2006 Matthew Barnes - 2.2.96-5 - Revised patch for Gnome.org bug #356809 to match upstream. nautilus-cd-burner-2.17.1-2.fc7 ------------------------------- * Fri Nov 03 2006 Matthias Clasen - 2.17.1-2 - Silence %pre oprofile-0.9.2-3.fc7 -------------------- * Mon Sep 18 2006 Will Cohen - 0.9.2-3 - Add dist tag to build. * Mon Sep 18 2006 Will Cohen - 0.9.2-2 - Rebase on 0.9.2 release. pfmon-3.2-0.060926.3.fc7 ------------------------ * Fri Nov 03 2006 Will Cohen - 3.2-0.060926.3 - Add dist tag to build. * Sun Oct 01 2006 Will Cohen - 3.2-0.060926.1 - Update to pfmon-3.2-060926. selinux-policy-2.4.2-8 ---------------------- * Fri Nov 03 2006 Dan Walsh 2.4.2-8 - Lots of fixes for ricci * Fri Nov 03 2006 Dan Walsh 2.4.2-7 - Allow xen to read/write fixed devices with a boolean - Allow apache to search /var/log * Thu Nov 02 2006 James Antill 2.4.2-6 - Fix policygentool specfile problem. - Allow apache to send signals to it's logging helpers. - Resolves: rhbz#212731 shadow-utils-2:4.0.18.1-2.fc7 ----------------------------- * Fri Nov 03 2006 Peter Vrabec 2:4.0.18.1-2 - improve audit logging (#211659) - improve "-l" option. Do not reset faillog if it's used (#213450). system-config-kickstart-2.6.16-1.fc7 ------------------------------------ * Fri Nov 03 2006 Chris Lumens 2.6.16-1 - Fix partition growing traceback (#212955). xchat-1:2.6.6-8.fc7 ------------------- * Fri Nov 03 2006 Matthias Clasen - 1.2.6.6-8 - Silence %pre (#213838) yelp-2.16.1-6.fc7 ----------------- * Fri Nov 03 2006 Matthias Clasen - 2.16.1-6 - Improve the whatis parser * Fri Nov 03 2006 Matthias Clasen - 2.16.1-5 - Silence %pre yum-3.0.1-1 ----------- * Fri Nov 03 2006 Jeremy Katz - 3.0.1-1 - update to 3.0.1 * Fri Oct 13 2006 Paul Nasrat - 3.0-6 - fix package comparison for available packages * Thu Oct 12 2006 Jeremy Katz - 3.0-5 - fix traceback when syslog not available (#208773) - fix package comparison not properly handling different arches (#210316) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From laroche at redhat.com Sat Nov 4 13:43:49 2006 From: laroche at redhat.com (Florian La Roche) Date: Sat, 4 Nov 2006 14:43:49 +0100 Subject: bluez-pin Message-ID: <20061104134349.GA14286@dudweiler.stuttgart.redhat.com> Hello David, can bluez-pin be removed from FC-devel now? (It is obsoleted by bluez-gnome now.) regards, Florian La Roche From dwmw2 at infradead.org Sat Nov 4 14:23:14 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 04 Nov 2006 22:23:14 +0800 Subject: bluez-pin In-Reply-To: <20061104134349.GA14286@dudweiler.stuttgart.redhat.com> References: <20061104134349.GA14286@dudweiler.stuttgart.redhat.com> Message-ID: <1162650195.5876.252.camel@shinybook.infradead.org> (First response not accepted by list because the address you used isn't subscribed there. Please don't use that address for anything which isn't strictly company-ultra-sekkrit. In general, if I can read it without actually having to wear my company-issue tinfoil hat to prevent my mind from being read, then use my proper email address). On Sat, 2006-11-04 at 14:43 +0100, Florian La Roche wrote: > can bluez-pin be removed from FC-devel now? (It is > obsoleted by bluez-gnome now.) Yes, it can go. -- dwmw2 From benjy.grogan at gmail.com Sat Nov 4 16:20:46 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 4 Nov 2006 11:20:46 -0500 Subject: Linux Standard Base / Fedora Message-ID: Hello: Is Fedora Core 6 LSB 3.0 compliant? I wasn't able to find any information on FC6's lsb-compliance state on the web or in the FC6 release notes, where possibly in the future it would be a good idea to mention FC's compliance or non-compliance. According to the Free Standards Group FC5 was in fact not LSB-compliant (). I think the new thing is to be LSB 3.1 compliant now. What are Fedora's commitments to the LSB, if any? The LSB seems to be an organization trying hard to unite Linux distributions when everyone else is fighting for their piece of the marketplace. Nothing wrong with competition, but if there is to be fierce competition it would really help to have a strong Linux Standard Base to compete on. Benjy From alan at redhat.com Sat Nov 4 17:16:07 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 4 Nov 2006 12:16:07 -0500 Subject: Linux Standard Base / Fedora In-Reply-To: References: Message-ID: <20061104171607.GA31048@devserv.devel.redhat.com> On Sat, Nov 04, 2006 at 11:20:46AM -0500, Benjy Grogan wrote: > Is Fedora Core 6 LSB 3.0 compliant? I wasn't able to find any I don't believe anyone has paid to submit it for formal testing. From benjy.grogan at gmail.com Sat Nov 4 19:14:39 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 4 Nov 2006 14:14:39 -0500 Subject: Linux Standard Base / Fedora In-Reply-To: <20061104171607.GA31048@devserv.devel.redhat.com> References: <20061104171607.GA31048@devserv.devel.redhat.com> Message-ID: On 11/4/06, Alan Cox wrote: > On Sat, Nov 04, 2006 at 11:20:46AM -0500, Benjy Grogan wrote: > > Is Fedora Core 6 LSB 3.0 compliant? I wasn't able to find any > > I don't believe anyone has paid to submit it for formal testing. Did someone submit FC5 for formal testing? Is FC6 expected to pass LSB-3.0 or LSB-3.1? Benjy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From Dax at gurulabs.com Sat Nov 4 21:01:40 2006 From: Dax at gurulabs.com (Dax Kelson) Date: Sat, 04 Nov 2006 14:01:40 -0700 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <20061103155452.GA20476@nostromo.devel.redhat.com> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> Message-ID: <1555-SnapperMsg827D11E1C172B03B@[68.26.70.118]> ...... Original Message ....... On Fri, 3 Nov 2006 10:54:52 -0500 "Bill Nottingham" wrote: >We have code run by udev (/lib/udev/rename_device) to handle this, but >it requires that ifcfg files have the HWADDR in them for the appropriate >devices so it knows what should remain what. Bill, In RHEL4/FC3, besides HWADDR, you also must use ONBOOT=YES. It that still the case? ___ Dax Kelson Sent with my Treo (please pardon any brevity) From giallu at gmail.com Sat Nov 4 22:27:14 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 4 Nov 2006 23:27:14 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <454B3B63.3040501@xs4all.nl> References: <454B3B63.3040501@xs4all.nl> Message-ID: On 11/3/06, Rubin wrote: > It used to work without a problem for a couple of days but suddenly I'm > getting very weird interface names. Instead of "eth1", I'm getting > "__tmp437329847239" where the number behind tmp is random. I just installed FC6 on my laptop (ASUS M6Ne) and experienced the same problem. Of course at first boot the firmware was not loaded, so I quite expected wifi would not work OOTB. However, installing the firmware and starting NM did not work, but was enough to get it going on FC5 so something is less "smart" than before. I verified and the file /etc/sysconfig/networking/devices/ifcfg-eth1 does not contain the HWADDR line (can't tell if it was there on FC5 or not) Moreover, eth1 does not seems to be recognized as a wireless device (I think there is at least one bug in bugzilla for this) From chris at idlelion.net Sun Nov 5 03:30:37 2006 From: chris at idlelion.net (Chris Schumann) Date: Sat, 4 Nov 2006 21:30:37 -0600 Subject: 600X (A) Suspend, Resume and Sound In-Reply-To: <20060727133637.9773773B3F@hormel.redhat.com> Message-ID: <000701c7008a$c3b3dd20$6517a8c0@piv17> I've got a ThinkPad 600X with FC6 installed. Sound works at startup, and suspend works. Sound does not work after resume. ThinkWiki says the audio chip is CS4624/CS4297A. I think the problem is that the Gnome desktop app holds the sound device open. I cannot remain logged in and get it to work again. To get it to work again, I can log out of my Gnome session, log into a console, rmmod the snd_cs46xx or whatever, modprobe it, switch back to the GUI login and log in. What a pain! What needs to be fixed so I can suspend and resume... and more importantly, make it so that I can get my wife to switch to Fedora on her 600X?! The shutdown/startup times compared to the Windows suspend/resume are the major obstacle right now. Many thanks, Chris Schumann From chris at idlelion.net Sun Nov 5 03:30:37 2006 From: chris at idlelion.net (Chris Schumann) Date: Sat, 4 Nov 2006 21:30:37 -0600 Subject: 600X (V) Video Issues Message-ID: <000601c7008a$c3547f10$6517a8c0@piv17> I've got a ThinkPad 600X with FC6 installed. Video mostly works. The video chip is the NeoMagic MagicGraph 256ZX (NM2360) with 4MB VRAM. First: The Gnome task bars display garbage when I set them to any level of transparency. They work fine when solid. FC5 did not have this issue. Second: After a suspend/resume, the consoles are garbled. It's as if there's a loose video cable, but weirder. FC5 did exhibit this problem. I can post a picture if it will help. Tips and pointers on who to talk to or what to fix are most appreciated. Many thanks, Chris Schumann From nasumadu at bigpond.net.au Sun Nov 5 05:50:21 2006 From: nasumadu at bigpond.net.au (Nana Kofi Asumadu) Date: Sun, 5 Nov 2006 16:50:21 +1100 Subject: FC6 x86_64 Custom RPMS Message-ID: <5438268.1162705821678.JavaMail.root@web05sl> Hi All I have FC6 x86_64 rpm packages here ftp://ftp.golinux.net.au/plub/Linux/FC6/ for whoever may find them useful. These are custom packages that have gentoo, mandriva and some other patches applied to them. Hope you find them useful. Nana From nasumadu at bigpond.net.au Sun Nov 5 05:56:09 2006 From: nasumadu at bigpond.net.au (Nana Kofi Asumadu) Date: Sun, 5 Nov 2006 16:56:09 +1100 Subject: FC6 x86_64 Custom RPMS Message-ID: <13724218.1162706169883.JavaMail.root@web05sl> Ooops, made a mistake in the url. The link is: ftp://ftp.golinux.net.au/pub/Linux/FC6/ Nana ---- Nana Kofi Asumadu wrote: > Hi All > > I have FC6 x86_64 rpm packages here ftp://ftp.golinux.net.au/plub/Linux/FC6/ for whoever may find them useful. > > These are custom packages that have gentoo, mandriva and some other patches applied to them. > > Hope you find them useful. > > Nana > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From aphukan at redhat.com Sun Nov 5 06:44:04 2006 From: aphukan at redhat.com (Amitakhya Phukan) Date: Sun, 05 Nov 2006 12:14:04 +0530 Subject: how do i make compiz work with SiSM760GX card? Message-ID: <454D8834.9090603@redhat.com> $subject, the laptop is Acer Aspire 3003. The Acer company says that the card supports 3D Acceleration Graphics. but when i try to "enable desktop effects", it says "couldn't enable desktop effects". Xorg.0.log says the dri module is loaded but then it is unloaded. please help. is there any workaround?the xorg-x11-drv-sis is installed but still the desktop effects can't be enabled. regards, amit. -------------- next part -------------- A non-text attachment was scrubbed... Name: aphukan.vcf Type: text/x-vcard Size: 378 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Sun Nov 5 07:53:08 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 05 Nov 2006 08:53:08 +0100 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <5438268.1162705821678.JavaMail.root@web05sl> References: <5438268.1162705821678.JavaMail.root@web05sl> Message-ID: <454D9864.9050501@hhs.nl> Nana Kofi Asumadu wrote: > Hi All > > I have FC6 x86_64 rpm packages here ftp://ftp.golinux.net.au/plub/Linux/FC6/ for whoever may find them useful. > > These are custom packages that have gentoo, mandriva and some other patches applied to them. > > Hope you find them useful. > If you find these patches usefull, then why don't you file bugs for these packages in bugzilla with the request for these patches to be applied? Regards, Hans From buildsys at redhat.com Sun Nov 5 11:05:46 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 5 Nov 2006 06:05:46 -0500 Subject: rawhide report: 20061105 changes Message-ID: <200611051105.kA5B5k1f029334@hs20-bc2-6.build.redhat.com> Updated Packages: beagle-0.2.12-1.fc7 ------------------- * Sat Nov 04 2006 Matthias Clasen 0.2.12-1 - Update to 0.2.12 dasher-4.2.1-1.fc7 ------------------ * Sat Nov 04 2006 Matthias Clasen - 4.2.1-1 - Update to 4.2.1 gcc-4.1.1-32 ------------ * Sat Nov 04 2006 Jakub Jelinek 4.1.1-32 - update from gcc-4_1-branch (-r118025:118468) - PRs bootstrap/28400, fortran/29067, libgfortran/29563, middle-end/29250, rtl-optimization/28970, rtl-optimization/29631, target/29377, tree-optimization/27891 - fix infinite recursion in make_vector_type (#212848, PR tree-optimization/29637) - merge gomp fixes from the trunk (-r118133:118134) - PR fortran/29629 - fix A < 0 ? : 0 optimization (#213821, PR middle-end/29695) - fix ICE in gfc_get_derived_type (Paul Thomas, #212936, PR fortran/29641) gedit-1:2.16.2-1.fc7 -------------------- * Sat Nov 04 2006 Matthias Clasen - 1:2.16.2-1 - Update to 2.16.2 librsvg2-2.16.1-1.fc7 --------------------- * Sat Nov 04 2006 Matthias Clasen - 2.16.1-1 - Update to 2.16.1 libxklavier-3.1-2.fc7 --------------------- * Sat Nov 04 2006 Matthias Clasen - 3.1-2 - Fix a possible crash (#213419) * Sat Nov 04 2006 Matthias Clasen - 3.1-1 - Update to 3.1 shadow-utils-2:4.0.18.1-3.fc7 ----------------------------- * Sat Nov 04 2006 Peter Vrabec 2:4.0.18.1-3 - fix "-g" and "-G" option. tmpwatch-2.9.10-1 ----------------- * Sun Nov 05 2006 Miloslav Trmac - 2.9.10-1 - Reallow --exclude with nonexistent paths Resolves: 214034 totem-2.17.2-1.fc7 ------------------ * Sat Nov 04 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From gilboad at gmail.com Sun Nov 5 13:10:07 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 05 Nov 2006 15:10:07 +0200 Subject: rawhide report: 20061105 changes In-Reply-To: <200611051105.kA5B5k1f029334@hs20-bc2-6.build.redhat.com> References: <200611051105.kA5B5k1f029334@hs20-bc2-6.build.redhat.com> Message-ID: <1162732207.3488.0.camel@gilboa-home-nb.localhost> On Sun, 2006-11-05 at 06:05 -0500, buildsys at redhat.com wrote: > > > Updated Packages: > > beagle-0.2.12-1.fc7 > ------------------- > * Sat Nov 04 2006 Matthias Clasen 0.2.12-1 > - Update to 0.2.12 > Orbital laser time? - Gilboa From sundaram at fedoraproject.org Sun Nov 5 14:18:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 05 Nov 2006 19:48:34 +0530 Subject: Linux Standard Base / Fedora In-Reply-To: References: <20061104171607.GA31048@devserv.devel.redhat.com> Message-ID: <454DF2BA.3010905@fedoraproject.org> Benjy Grogan wrote: > On 11/4/06, Alan Cox wrote: >> On Sat, Nov 04, 2006 at 11:20:46AM -0500, Benjy Grogan wrote: >> > Is Fedora Core 6 LSB 3.0 compliant? I wasn't able to find any >> >> I don't believe anyone has paid to submit it for formal testing. > > Did someone submit FC5 for formal testing? No. That is basically what Alan Cox said. Is FC6 expected to pass > LSB-3.0 or LSB-3.1? Noone has tested that. My understanding is that LSB is a trailing edge standard for ISV (usually proprietary applications) which means they look at what distributions like Red Hat Enterprise Linux and SLES do commonly and bless that as a standard. That works when distribution stick with a base set of libraries and programs and backport fixes. For a fast moving distribution like Fedora even if a general release is said to be compliant, any of the updates might deviate from that since many components dont have any ABI compatibility guidelines (with a few like GTK as exceptions) and since new revisions of the standards wont be put out as fast as Fedora releases, this is unlikely to work out. Rahul From jkeating at redhat.com Sun Nov 5 16:15:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 5 Nov 2006 11:15:03 -0500 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <454D9864.9050501@hhs.nl> References: <5438268.1162705821678.JavaMail.root@web05sl> <454D9864.9050501@hhs.nl> Message-ID: <200611051115.03623.jkeating@redhat.com> On Sunday 05 November 2006 02:53, Hans de Goede wrote: > If you find these patches usefull, then why don't you file bugs for these > packages in bugzilla with the request for these patches to be applied? Or better yet upstream so that each distro doesn't have to carry around copies of the patches... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nasumadu at bigpond.net.au Sun Nov 5 21:36:13 2006 From: nasumadu at bigpond.net.au (Nana Kofi Asumadu) Date: Mon, 6 Nov 2006 8:36:13 +1100 Subject: FC6 x86_64 Custom RPMS Message-ID: <16229662.1162762573292.JavaMail.root@web02sl> Firstly, most of these packages are packages that Fedora/Redhat refuses to include in either main stream or extra because of possible patent/legal issue ( which I completely understand). Secondly, most of the patches applied are either in their respective cvs/svn or have been submitted for consideration for inclusion into the next new release. I find most of these packages useful and again, I completely understand Fedora/Redhat's stand on these. I merely provided the link for anyone else who may find them useful regardless of any political or individualistic view about these software. PS: Some of these packages are in Extra but have had bits are pieces removed, again, due to possible patent issue. Nana Kofi Asumadu ---- Jesse Keating wrote: > On Sunday 05 November 2006 02:53, Hans de Goede wrote: > > If you find these patches usefull, then why don't you file bugs for these > > packages in bugzilla with the request for these patches to be applied? > > Or better yet upstream so that each distro doesn't have to carry around copies > of the patches... > > -- > Jesse Keating > Release Engineer: Fedora From sundaram at fedoraproject.org Sun Nov 5 21:39:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Nov 2006 03:09:56 +0530 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <16229662.1162762573292.JavaMail.root@web02sl> References: <16229662.1162762573292.JavaMail.root@web02sl> Message-ID: <454E5A2C.4080801@fedoraproject.org> Nana Kofi Asumadu wrote: > Firstly, most of these packages are packages that Fedora/Redhat refuses to include in either main stream or extra because of possible patent/legal issue ( which I completely understand). > > Secondly, most of the patches applied are either in their respective cvs/svn or have been submitted for consideration for inclusion into the next new release. > > I find most of these packages useful and again, I completely understand Fedora/Redhat's stand on these. I merely provided the link for anyone else who may find them useful regardless of any political or individualistic view about these software. > > PS: Some of these packages are in Extra but have had bits are pieces removed, again, due to possible patent issue. If there are legal issues with these packages, this discussion doesnt really belong in the Fedora development list because we cant use these patches anyway. Some users not affected might be interested. That should go into fedora-list however. Rahul From jonathan.underwood at gmail.com Sun Nov 5 23:53:45 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 5 Nov 2006 23:53:45 +0000 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <13724218.1162706169883.JavaMail.root@web05sl> References: <13724218.1162706169883.JavaMail.root@web05sl> Message-ID: <645d17210611051553m6eabe3d8tb55a69e38a6513f9@mail.gmail.com> On 05/11/06, Nana Kofi Asumadu wrote: > Ooops, made a mistake in the url. The link is: > > ftp://ftp.golinux.net.au/pub/Linux/FC6/ That doesn't work either. From nasumadu at bigpond.net.au Mon Nov 6 01:26:26 2006 From: nasumadu at bigpond.net.au (Nana Kofi Asumadu) Date: Mon, 6 Nov 2006 12:26:26 +1100 Subject: FC6 x86_64 Custom RPMS Message-ID: <23381184.1162776387009.JavaMail.root@web10ps> try ftp://203.22.239.42/pub/Linux/FC6/ Cheers Nana ---- Jonathan Underwood wrote: > On 05/11/06, Nana Kofi Asumadu wrote: > > Ooops, made a mistake in the url. The link is: > > > > ftp://ftp.golinux.net.au/pub/Linux/FC6/ > > That doesn't work either. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From j.w.r.degoede at hhs.nl Mon Nov 6 06:27:16 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 06 Nov 2006 07:27:16 +0100 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <16229662.1162762573292.JavaMail.root@web02sl> References: <16229662.1162762573292.JavaMail.root@web02sl> Message-ID: <454ED5C4.3050709@hhs.nl> Nana Kofi Asumadu wrote: > Firstly, most of these packages are packages that Fedora/Redhat refuses to include in either main stream or extra because of possible patent/legal issue ( which I completely understand). > Now that you've provided a working URL I've taken a look and I see a lot of packages which cannot be explained by this. > Secondly, most of the patches applied are either in their respective cvs/svn or have been submitted for consideration for inclusion into the next new release. > Even if that is true, if the fixes are important enough to warrant you building a package please submit bugs with patches attached and let the maintainer decide wether he conciders this important enough to release an updated package or if he will wait till upstreams next release. > I find most of these packages useful and again, I completely understand Fedora/Redhat's stand on these. I merely provided the link for anyone else who may find them useful regardless of any political or individualistic view about these software. > I understand that you are trying to help, but in this way you aren't really helping at all, yet another repo (and one without repo data) will only serve to confuse users. If you've got improvements for packages in FE report them to the FE packaga maintainers, if you've got improvements for packages which legally cannot be in FE report them to livna. Stop doing double work, there are already enough repo's as is! Don't get me wrong your contributions are much appreciated, the way you contribute them though could be improved. Regards, Hans From sander at hoentjen.eu Mon Nov 6 08:55:14 2006 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 06 Nov 2006 09:55:14 +0100 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <454ED5C4.3050709@hhs.nl> References: <16229662.1162762573292.JavaMail.root@web02sl> <454ED5C4.3050709@hhs.nl> Message-ID: <1162803314.28094.24.camel@peecee.hoentjen.eu> On Mon, 2006-11-06 at 07:27 +0100, Hans de Goede wrote: > > > > I understand that you are trying to help, but in this way you aren't really helping at all, yet another repo > (and one without repo data) will only serve to confuse users. If you've got improvements for packages in FE report them to the FE packaga maintainers, if you've got improvements for packages which legally cannot be in FE report them to livna. Stop doing double work, there are already enough repo's as is! > > Don't get me wrong your contributions are much appreciated, the way you contribute them though could be > improved. > In addition I see you have amsn for example, but I see no differences from the version that was in extras (now the version in extras is even newer) Why not redirecting people to the extras package instead of providing it yourself? Kind regards, Sander From buildsys at redhat.com Mon Nov 6 10:53:00 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 6 Nov 2006 05:53:00 -0500 Subject: rawhide report: 20061106 changes Message-ID: <200611061053.kA6Ar0ke003563@hs20-bc2-6.build.redhat.com> Updated Packages: cairo-1.2.6-1.fc7 ----------------- * Sun Nov 05 2006 Matthias Clasen 1.2.6-1 - Update to 1.2.6 * Sun Aug 20 2006 Behdad Esfahbod 1.2.4-1 - Update to 1.2.4 - Drop libXt-devel BuildReq as it shouldn't need it anymore. * Wed Aug 09 2006 Behdad Esfahbod 1.2.2-3 - Remove unnecessary --disable-* arguments to configure, add --enable-* for those backends we really want to make sure are enabled. dbus-glib-0.71-2.fc7 -------------------- * Sun Nov 05 2006 Matthias Clasen - 0.71-2 - Fix up Requires for the -devel package gdm-1:2.17.1-1.fc7 ------------------ * Sun Nov 05 2006 Matthias Clasen - 1:2.17.1-1 - Update to 2.17.1 gnome-python2-2.16.2-1.fc7 -------------------------- * Sun Nov 05 2006 Matthew Barnes - 2.16.2-1.fc7 - Update to 2.16.2 * Sun Oct 29 2006 Matthew Barnes - 2.16.0-2.fc6 - Clean up spec file. - Remove unused patches. - Add subpackage gnome-python2-devel (bug #203532). * Tue Sep 05 2006 Matthias Clasen - 2.16.0-1.fc6 - Update to 2.16.0 gnome-speech-0.4.6-1.fc7 ------------------------ * Sun Nov 05 2006 Matthias Clasen - 0.4.6-1 - Update to 0.4.6 m17n-db-1.3.3-35.fc7 -------------------- * Mon Nov 06 2006 Mayank Jain - Fixed Bug 213633: Need changes in Assamese Inscript layout wireshark-0.99.4-1.fc7 ---------------------- Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jpmahowald at gmail.com Mon Nov 6 15:39:15 2006 From: jpmahowald at gmail.com (John Mahowald) Date: Mon, 6 Nov 2006 09:39:15 -0600 Subject: no repository available for repo extras-devel?? In-Reply-To: References: Message-ID: <3ea997540611060739g38f8cebsed98b243aa76df7d@mail.gmail.com> On 10/31/06, sean wrote: > > http://mirrors.fedoraproject.org/mirrorlist?repo=extras-devel&arch=x86_64 > > gives: > > # no repository available for repo extras-devel > > > yet > > http://mirrors.fedoraproject.org/ > > shows: > > http://mirrors.fedoraproject.org/extras-devel-US-x86_64.txt > > which contains a number of mirrors. > > ?? > It works and returns some mirrors now. I believe that is the mirrorlist script checking that the repositories have the latest metadata. Perhaps you were in the middle of an update sync. John From ajackson at redhat.com Mon Nov 6 15:56:40 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 06 Nov 2006 10:56:40 -0500 Subject: compiz window settings In-Reply-To: <200611041157.55630.jonesc@hep.phy.cam.ac.uk> References: <200611041157.55630.jonesc@hep.phy.cam.ac.uk> Message-ID: <454F5B38.2090601@redhat.com> Chris Jones wrote: > Hi, > > I tried this question on the main fedora list, but with no response, so I'm > hoping the more techy people here can help me :) > > I want to try and control which windows compiz includes in some of its visual > effects, such as the scale and switcher plugins. > > Looking with gconf-editor I see that these plugins have a list of the window > types they will include. However, I have no idea how different application > windows get assigned to one of these types ? Could someone point me to where > these sort of things get set up ? http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2527243 Defines the window manager properties anyway. Don't know offhand where in the toolkit you'd control that. - ajax From ajackson at redhat.com Mon Nov 6 16:08:45 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 06 Nov 2006 11:08:45 -0500 Subject: 600X (V) Video Issues In-Reply-To: <000601c7008a$c3547f10$6517a8c0@piv17> References: <000601c7008a$c3547f10$6517a8c0@piv17> Message-ID: <454F5E0D.6050804@redhat.com> Chris Schumann wrote: > I've got a ThinkPad 600X with FC6 installed. Video mostly works. > > The video chip is the NeoMagic MagicGraph 256ZX (NM2360) with 4MB VRAM. > > First: The Gnome task bars display garbage when I set them to any level of > transparency. They work fine when solid. FC5 did not have this issue. Please file this against xorg-x11-drv-neomagic in bugzilla, and attach the output of 'xdpyinfo', and the output from running 'xwininfo' and then clicking on either panel. IIRC, there's some crazy pseudocolor emulation code in the neomagic driver that could easily be broken. > Second: After a suspend/resume, the consoles are garbled. It's as if there's > a loose video cable, but weirder. FC5 did exhibit this problem. I can post a > picture if it will help. It would. Sounds like the palette isn't getting restored on resume, but I would have expected the server core to take care of that. Hm. - ajax From ajackson at redhat.com Mon Nov 6 16:16:32 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 06 Nov 2006 11:16:32 -0500 Subject: how do i make compiz work with SiSM760GX card? In-Reply-To: <454D8834.9090603@redhat.com> References: <454D8834.9090603@redhat.com> Message-ID: <454F5FE0.3030403@redhat.com> Amitakhya Phukan wrote: > $subject, > the laptop is Acer Aspire 3003. The Acer company says that the card > supports 3D Acceleration Graphics. but when i try to "enable desktop > effects", it says "couldn't enable desktop effects". Xorg.0.log says the > dri module is loaded but then it is unloaded. please help. is there any > workaround?the xorg-x11-drv-sis is installed but still the desktop > effects can't be enabled. > regards, > amit. You don't. SiS' numbering scheme is utter insanity, but basically it looks like this: (core: model numbers) Old: 5597, 5598, 6236, 530, 620 300: 300, 305, 540, 630, 730 315: 315, 55x, 650, 651, 740, 661, 741 330: 330 (aka "Xabre"), 760, 761 340: 34x, and various XGI Volari cards (Z7, Z9, V3XT, V3XE, V5, V8) The SiS DRI driver _only_ supports the 300 core, which means that's the only series where compiz is going to work. Fixing that would basically involve writing a new DRI driver, possibly up to one for each core. - ajax From notting at redhat.com Mon Nov 6 16:59:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Nov 2006 11:59:08 -0500 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <1555-SnapperMsg827D11E1C172B03B@[68.26.70.118]> References: <454B3B63.3040501@xs4all.nl> <20061103154615.GA20127@lisas.de> <20061103155452.GA20476@nostromo.devel.redhat.com> <1555-SnapperMsg827D11E1C172B03B@[68.26.70.118]> Message-ID: <20061106165908.GB25800@nostromo.devel.redhat.com> Dax Kelson (Dax at gurulabs.com) said: > In RHEL4/FC3, besides HWADDR, you also must use ONBOOT=YES. It that still > the case? No. Bill From nasumadu at bigpond.net.au Tue Nov 7 00:42:45 2006 From: nasumadu at bigpond.net.au (Nana Kofi Asumadu) Date: Tue, 7 Nov 2006 11:42:45 +1100 Subject: FC6 x86_64 Custom RPMS Message-ID: <26373924.1162860165938.JavaMail.root@web09ps> This is not meant to be a another repo. I have been building my own custom rpms since FC2. I am only making the link avaliable for anyone who cares to use them. I have no intention of setting up another repo. I couldn't even afford the time to even if I wanted to. If you find the packages, useful, use them. If not, who cares? Nana ---- Sander Hoentjen wrote: > On Mon, 2006-11-06 at 07:27 +0100, Hans de Goede wrote: > > > > > > > I understand that you are trying to help, but in this way you aren't really helping at all, yet another repo > > (and one without repo data) will only serve to confuse users. If you've got improvements for packages in FE report them to the FE packaga maintainers, if you've got improvements for packages which legally cannot be in FE report them to livna. Stop doing double work, there are already enough repo's as is! > > > > Don't get me wrong your contributions are much appreciated, the way you contribute them though could be > > improved. > > > In addition I see you have amsn for example, but I see no differences > from the version that was in extras (now the version in extras is even > newer) Why not redirecting people to the extras package instead of > providing it yourself? > > Kind regards, > Sander > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jacliburn at bellsouth.net Tue Nov 7 00:44:17 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 06 Nov 2006 18:44:17 -0600 Subject: Request for git-core rebuild In-Reply-To: <20061102142912.GA11345@osprey.hogchain.net> References: <20061102140006.GA3905@osprey.hogchain.net> <1162476416.11351.15.camel@zod.rchland.ibm.com> <20061102142912.GA11345@osprey.hogchain.net> Message-ID: <454FD6E1.507@bellsouth.net> Jay Cliburn wrote: > On Thu, Nov 02, 2006 at 08:06:56AM -0600, Josh Boyer wrote: >> On Thu, 2006-11-02 at 08:00 -0600, Jay Cliburn wrote: >>> I'm not sure if I'm asking the right question, but I've got a dependency >>> problem with curl and git-core that I can't get past, and I think it >>> could be resolved by rebuilding git-core (in extras). >>> >>> What's the right way to go about asking for a package rebuild? Or, if >>> I'm not asking the right question, please correct me. >> You should file a bug against git-core. If curl changed enough, it >> might take more than a rebuild (though I would be surprised in this >> case). >> >> Do note though, you're running rawhide and breakage is normal. It might >> take a while to get it fixed, and then it might break the next day >> again. > > Thanks Josh. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213664 > Fixed with git-core-1.4.2.4-2.fc7, released today. Thanks. From j.w.r.degoede at hhs.nl Tue Nov 7 07:41:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 07 Nov 2006 08:41:14 +0100 Subject: FC6 x86_64 Custom RPMS In-Reply-To: <26373924.1162860165938.JavaMail.root@web09ps> References: <26373924.1162860165938.JavaMail.root@web09ps> Message-ID: <4550389A.3020800@hhs.nl> Nana Kofi Asumadu wrote: > This is not meant to be a another repo. I have been building my own custom rpms since FC2. I am only making the link avaliable for anyone who cares to use them. > > I have no intention of setting up another repo. I couldn't even afford the time to even if I wanted to. > > If you find the packages, useful, use them. If not, who cares? > I care because that is not the way opensource works, if you do not merge your improvements back into the source of the software then your efforts to improve the software / packages is effectivly lost. Building these packages and searching together and writing all those patches must have cost you lots of time, why not invest that last few hours to file bugs with these patches attached so that all your work can really make a difference and can get used by many users instead of a few? Regards, Hans From buildsys at redhat.com Tue Nov 7 11:13:11 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 7 Nov 2006 06:13:11 -0500 Subject: rawhide report: 20061107 changes Message-ID: <200611071113.kA7BDB7r011229@hs20-bc2-6.build.redhat.com> Updated Packages: PyQt-3.17-1 ----------- * Mon Nov 06 2006 Than Ngo 3.17-1 - 3.17 ccid-1.1.0-2 ------------ * Mon Nov 06 2006 Bob Relyea - 1.1.0-2 - Fix version macro to remove '-' cups-1:1.2.6-3.fc7 ------------------ * Mon Nov 06 2006 Tim Waugh 1:1.2.6-3 - 1.2.6. * Mon Nov 06 2006 Tim Waugh 1:1.2.5-7 - One more D-Bus signal fix (bug #212763). dbus-0.95-2.fc7 --------------- * Mon Nov 06 2006 John (J5) Palmieri - 0.95-2 - Add /var/lib/dbus directory to %files * Fri Nov 03 2006 John (J5) Palmieri - 0.95-1 - Update to D-Bus 1.0 RC 3 (0.95) - don't build with tests on * Sat Oct 14 2006 John (J5) Palmieri - 0.94-1 - Update to D-Bus 1.0 RC 2 (0.94) doxygen-1:1.5.1-2 ----------------- * Fri Nov 03 2006 Than Ngo 1:1.5.1-2 - 1.5.1 eclipse-cdt-1:3.1.1-4.fc7 ------------------------- * Mon Nov 06 2006 Andrew Overholt 3.1.1-4 - Use the new location of copy-platform. eclipse-changelog-1:2.3.3-2.fc7 ------------------------------- * Mon Nov 06 2006 Andrew Overholt 2.3.3-2 - Use copy-platform in %{_libdir}. epiphany-2.17.2-1.fc7 --------------------- * Mon Nov 06 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 evolution-2.9.1-3.fc7 --------------------- * Mon Nov 06 2006 Matthew Barnes - 2.9.1-3.fc7 - Add patch for RH bug #176400 (reset calendar IM context). - Add patch for RH bug #182247 (calendar input glitch). * Fri Oct 20 2006 Matthew Barnes - 2.9.1-2.fc7 - Add patch for Gnome.org bug #356177 (deprecate EMutex). - Add patch for Gnome.org bug #363695 (deprecate EStrv/EPoolv). - Disable patch for RH bug #202751 (unwanted side-effects). * Mon Oct 16 2006 Matthew Barnes - 2.9.1-1.fc7 - Update to 2.9.1 - Bump eds_version to 1.9.1, evo_major to 2.10. - Remove patch for Gnome.org bug #359236 (fixed upstream). evolution-data-server-1.9.2-1.fc7 --------------------------------- * Mon Nov 06 2006 Matthew Barnes - 1.9.2-1.fc7 - Update to 1.9.2 - Remove patch for Gnome.org bugs #369168, #369259, and #369261 (fixed upstream). gjdoc-0.7.7-14.fc7 ------------------ * Mon Nov 06 2006 Ben Konrath - 0.7.7-14 - Add consistent html patch so that the javadocs are consistent across builds. * Thu Nov 02 2006 Andrew Overholt - 0.7.7-13 - Bump release and include %{dist}. gnome-keyring-0.7.1-1.fc7 ------------------------- * Mon Nov 06 2006 Matthias Clasen - 0.7.1-1 - Update to 0.7.1 * Mon Sep 04 2006 Alexander Larsson - 0.6.0-1 - update to 0.6.0 * Wed Aug 23 2006 Dan Williams - 0.5.2-2.fc6 - Fix null pointer dereference (Gnome.org #352587) gnome-pilot-2.0.14-3.fc7 ------------------------ * Mon Nov 06 2006 Matthew Barnes - 2.0.14-3.fc7 - Look for conduit files under $(libdir) instead of $(datadir). * Mon Nov 06 2006 Matthew Barnes - 2.0.14-2.fc7 - Add missing BuildRequires intltool. * Sun Nov 05 2006 Matthew Barnes - 2.0.14-1.fc7 - Update to 2.0.14 - Add patch for Gnome.org bug #362565 (sleep before syncing). - Remove unused patches. - Remove patches fixed upstream: gnome-pilot-2.0.10-fix_64bit.patch gnome-pilot-2.0.12-fix_icon.patch gnome-pilot-2.0.12-defines.patch gnome-pilot-2.0.12-move-conduits-code.patch gnome-pilot-2.0.12-move-conduits-autotools.patch gnome-pilot-2.0.12-port-to-pilot-link-0.12.patch gb-309077-attach-48373-fix-xml-properties-leak.patch gb-309130-attach-48413-backup-conduit-valgrind-fixes.patch rh-161799-attach-116013-backup_conduit_update.diff rh-161799-attach-116014-conduits_64bit.diff - Remove BuildRequires autoconf, automake (no longer needed). gnome-pilot-conduits-2.0.14-2.fc7 --------------------------------- * Mon Nov 06 2006 Matthew Barnes - 2.0.14-2.fc7 - Move conduit files under $(libdir) (RH bug #189369). * Sun Nov 05 2006 Matthew Barnes - 2.0.14-1.fc7 - Update to 2.0.14 - Remove patches fixed upstream: gnome-pilot-conduits-2.0.10-lib64.patch gnome-pilot-conduits-2.0.13-port-to-pilot-link-0.12.patch gnome-python2-extras-2.14.2-6.fc7 --------------------------------- * Mon Nov 06 2006 Jeremy Katz - 2.14.2-6 - fix to follow python packaging guidelines better * Mon Nov 06 2006 Jeremy Katz - 2.14.2-5 - rebuild against new firefox gnome-utils-1:2.17.0-1.fc7 -------------------------- * Mon Nov 06 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 - Temporarily build without api docs and baobab icon gperf-3.0.2-2 ------------- * Sat Nov 04 2006 Florian La Roche - 3.0.2 (#213852) gtkhtml3-3.13.2-1.fc7 --------------------- * Mon Nov 06 2006 Matthew Barnes - 3.13.2-1.fc7 - Update to 3.13.2 initscripts-8.47-1 ------------------ * Mon Nov 06 2006 Bill Nottingham 8.47-1 - lang.{sh,csh}: handle sinhalese as well in CJKI clauses (#212438) - rc.sysinit: add '--auto=yes' to mdadm invocation (#213671) - rename_device: fix incorrect handling of .bak files - mount tmpfs with -n (#213132) - various SUBCHANNELS related s390 fixage (#204803) - lang.{sh,csh}: support iso-8859-8 (#212738, ) libsoup-2.2.97-1.fc7 -------------------- * Mon Nov 06 2006 Matthew Barnes - 2.2.97-1 - Update to 2.2.97 - Remove patch for Gnome.org bug #356809 (fixed upstream). libvirt-0.1.8-2.fc7 ------------------- * Mon Nov 06 2006 Daniel Veillard 0.1.8-2 - fixing spec file, added .fc7, -devel requires pkgconfig and xen-devel - Resolves: rhbz#202320 metacity-2.17.2-1.fc7 --------------------- * Mon Nov 06 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 nautilus-cd-burner-2.17.2-1.fc7 ------------------------------- * Mon Nov 06 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 opal-2.2.3-3.fc7 ---------------- * Mon Nov 06 2006 Daniel Veillard - 2.2.3-3 - moved the .so to -devel - Resolves: rhbz#203633 openoffice.org-1:2.1.0-1.1 -------------------------- * Thu Nov 02 2006 Caolan McNamara - 1:2.1.0-1.1 - start of 2.1.0 - setlang patch partially upstreamed - drop upstreamed workspace.vcl66 upstreamed - drop upstreamed openoffice.org-2.0.4.ooo69325.cairocanvas.slowfills.patch - drop upstreamed workspace.sixtyfour08.patch - drop upstreamed openoffice.org-2.0.3.ooo67781.sc.reloadhiddenrows.patch - drop upstreamed openoffice.org-2.0.3.ooo68047.vcl.zwj.patch - drop upstreamed workspace.cmcfixes26.patch - drop upstreamed workspace.vcl65.patch - drop upstreamed openoffice.org-2.0.4.ooo68851.framework.disablemenuifempty.patch - drop upstreamed openoffice.org-2.0.4.ooo68919.sc.atk.patch - drop upstreamed openoffice.org-2.0.4.ooo69068.parallelxslt.patch - drop upstreamed workspace.cairofixes02.patch - drop upstreamed openoffice.org-2.0.4.ooo69530.sd.crash.patch - drop upstreamed workspace.cmcfixes28.patch - drop upstreamed openoffice.org-2.0.4.ooo69236.slideshow.esccrash.patch - drop upstreamed workspace.calc39.patch - drop upstreamed openoffice.org-2.0.4.ooo70361.vcl.atkfilechooser.patch - drop upstreamed openoffice.org-2.0.4.ooo69620.vcl.atkcombo.patch - drop upstreamed workspace.fwk53.patch - drop upstreamed workspace.opensymbol01.patch - add openoffice.org-2.1.0.ooo71111.sfx2.x86_64.patch - add workspace.gtkquickstart2.patch - add workspace.gtkquickstart2.patch - add openoffice.org-1.9.129.ooo54603.fontconfig.part4.patch for localized fontnames - Estonian dictionaries added pirut-1.2.7-1.fc7 ----------------- * Mon Nov 06 2006 Jeremy Katz - 1.2.7-1 - Fix traceback with packages with an empty description (#212276) - Show the dep dialog for removals and don't auto-timeout it (#212703) - Make puplet translations work (#212877) - Don't log in other langs (#213145) - Fix view menu (#213562) - Fix a silly typo in the cdinstaller text (#210696) - On failure, undo dep installs (#213628) - Allow multiple selection in pup (#195465) - Fix searching in pup to be more obvious (#213639) - Set puplet icon to downloading when we're getting things (#210463) redhat-menus-6.7.8-1.fc7 ------------------------ * Mon Nov 06 2006 Matthias Clasen - 6.7.8-1 - Pick up missing translations (#214241) * Wed Nov 01 2006 Matthias Clasen - 6.7.7-1 - Add a documentation menu (#213191) * Tue Oct 31 2006 Than Ngo - 6.7.6-2.el5 - add missing kdelegacydirs #213202 scim-1.4.5-1.fc7 ---------------- * Tue Nov 07 2006 Jens Petersen - 1.4.5-1 - update to 1.4.5 release - no longer need scim.pc-versioned-moduledir-179706.patch, scim_panel_gtk-systray-click-199187.patch, scim_panel_gtk-menu-recently-used-factories.patch, scim_backup-default-engine-2letter-locale-197058.patch, scim_utility-Assamese-locale-fix.patch, scim-gtkimm-underline-attrib-206397.patch, and scim_x11_frontend-underline-attrib-206397.patch - update scim-system-default-config.patch, scim_panel_gtk-icon-size-fixes.patch - add scim-1.4.5-panel-menu-fixes.patch to fix factory menu labelling - improve scim-restart script to also handle scim-bridge (#205547) - obsolete iiimf-csconv (#211875) * Thu Nov 02 2006 Jens Petersen - return scim-bridge-qt support to xinput script * Tue Oct 03 2006 Jens Petersen - 1.4.4-35 - reduce tray icon size to 12 to fit button in scim_panel_gtk-icon-size-fixes.patch - add scim-gtkimm-underline-attrib-206397.patch and scim_x11_frontend-underline-attrib-206397.patch from upstream cvs (#206397) - make Chinese full/half width icons darker selinux-policy-2.4.3-1 ---------------------- * Fri Nov 03 2006 Dan Walsh 2.4.3-1 - Merge with upstream sip-4.5-1 --------- * Mon Nov 06 2006 Than Ngo 4.5-1 - 4.5 slang-2.0.7-1.fc7 ----------------- * Mon Nov 06 2006 Miroslav Lichvar - 2.0.7-1 - update to 2.0.7 swig-1.3.29-2.fc7 ----------------- * Tue Nov 07 2006 Adam Tkac 1.3.29-2 - swig can determine architecture now (#211095) valgrind-1:3.2.1-6 ------------------ * Mon Nov 06 2006 Jakub Jelinek 3.2.1-6 - fix valgrind.pc (#213149) - handle Intel Core2 cache sizes in cachegrind (Ulrich Drepper) vim-2:7.0.158-1 --------------- * Mon Nov 06 2006 Karsten Hopp 7.0.158-1 - patchlevel 158 * Tue Oct 17 2006 Karsten Hopp 7.0.139-1 - patchlevel 139 - provide vim, vi (#210950) vino-2.17.2-1.fc7 ----------------- * Mon Nov 06 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 Broken deps for i386 ---------------------------------------------------------- libvirt-devel - 0.1.8-2.fc7.i386 requires pgkconfig Broken deps for ia64 ---------------------------------------------------------- libvirt-devel - 0.1.8-2.fc7.ia64 requires pgkconfig Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- libvirt-devel - 0.1.8-2.fc7.x86_64 requires pgkconfig libvirt-devel - 0.1.8-2.fc7.i386 requires pgkconfig From d.lesca at solinos.it Tue Nov 7 13:01:35 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 07 Nov 2006 14:01:35 +0100 Subject: fc6 install fail on HP ProLiant ML320 G4 In-Reply-To: <454C4D51.2040808@crc.dk> References: <20061103141858.6953C734C7@hormel.redhat.com> <454B5DB9.1070800@isc.cnr.it> <454C4D51.2040808@crc.dk> Message-ID: <1162904495.3425.111.camel@lesca.home.solinos.it> Il giorno sab, 04/11/2006 alle 09.20 +0100, Mogens Kjaer ha scritto: > Can you boot a knoppix cd and do an lspci and post the output here? I have grab some log with strace when anaconda start X .... http://www.solinos.it/pubblica/fc6-proliant-ml320.tar.gz The package contain this files: anaconda.log # log produced from start anaconda libuser.LDHEPT # anaconda logs... libuser.PMJQhY # anaconda logs... ramfs/ # anaconda dir ... startanaconda # shell to start anaconda with strace startx # (minitest on vt7) shell to start X and mini-wm syslog # anaconda logs... XConfig.test # anaconda Xconfig ... x.log # (minitest on vt7) strace log produced from startx o Start with NFS setup. o X start and block when sov the X cursor...... o CTR+ALT+F2 o Kill X and mini-wm process o Run the shell startanaconda to produce the anaconda.log o X start on vt6 great but stop when X cursor appear o CTRL+ALT+F2 o Grab this logs and scp on my notebook. Unfortunately I am not able to analyze the log and understand what happens. If someone is interested to analyze it and send me some suggest in order to install FC6 on this HP, today I can check the suggest Many thanks to all !! -- Dario Lesca From fedora-devel at tlarson.com Tue Nov 7 19:34:32 2006 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 07 Nov 2006 12:34:32 -0700 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> <454B574C.3000704@poolshark.org> Message-ID: <4550DFC8.104@tlarson.com> darrell pfeifer wrote: > The random name seems to be created (by udev?) when the firmware > doesn't load. I suspect it is a timing problem (or the 'failed' > timeout needs to be just a bit longer). > > The issue was there for a while a about two months before FC6 release, > disappeared for a bit and got worse just about FC6 release time. FWIW, this issue is not limited to FC6; I've seen it fairly consistently on FC5 as well (HP dv1000 laptop). I always thought it had something to do with initscripts, but I guess that's not the case. From rubin at xs4all.nl Tue Nov 7 21:11:59 2006 From: rubin at xs4all.nl (Rubin) Date: Tue, 07 Nov 2006 22:11:59 +0100 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <4550DFC8.104@tlarson.com> References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> <454B574C.3000704@poolshark.org> <4550DFC8.104@tlarson.com> Message-ID: <1162933919.4236.4.camel@localhost.localdomain> Hi. I started the thread. Someone responded that setting HWADDR in /etc/sysconfig/network-scripts/ifcfg-eth1 might make the problem disappear. And it did! After setting HWADDR with the MAC for the wireless card, the problem has not been encountered since. I guess it still is a problem, but it works. Not very nice for mom and pops at home trying out a user-friendly linux distro though. Greets, Rubin. On Tue, 2006-11-07 at 12:34 -0700, Tyler Larson wrote: > darrell pfeifer wrote: > > The random name seems to be created (by udev?) when the firmware > > doesn't load. I suspect it is a timing problem (or the 'failed' > > timeout needs to be just a bit longer). > > > > The issue was there for a while a about two months before FC6 release, > > disappeared for a bit and got worse just about FC6 release time. > FWIW, this issue is not limited to FC6; I've seen it fairly consistently > on FC5 as well (HP dv1000 laptop). I always thought it had something to > do with initscripts, but I guess that's not the case. > From hbasava at yahoo.com Wed Nov 8 02:12:41 2006 From: hbasava at yahoo.com (Basavaraj Hiremath) Date: Tue, 7 Nov 2006 18:12:41 -0800 (PST) Subject: copy_from_user() crashes.. Message-ID: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> Hi, I am using Fedora Core 5.0. My driver is crashing when I call copy_from_user() call. Does any one have idea about this ? Thanks much in advance... Thanks & Regards, Raj ____________________________________________________________________________________ Sponsored Link For just $24.99/mo., Vonage offers unlimited local and long- distance calling. Sign up now. http://www.vonage.com/startsavingnow/ From mrsam at courier-mta.com Wed Nov 8 03:27:59 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Nov 2006 22:27:59 -0500 Subject: copy_from_user() crashes.. References: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> Message-ID: Basavaraj Hiremath writes: > Hi, > I am using Fedora Core 5.0. My driver is crashing when > I call copy_from_user() call. > Does any one have idea about this ? Read http://catb.org/esr/faqs/smart-questions.html and then ask for help on the linux-kernel mailing list. When ask for help, be sure that you can explain your problem in better deal. If all you do is again complain that copy_from_user() crahses, without providing any further details, then you will not get anywhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rhl-devel-list at lnx.ro Wed Nov 8 07:44:39 2006 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Wed, 08 Nov 2006 09:44:39 +0200 Subject: Strange behaviour with boottime loading of ipw2200 In-Reply-To: <1162933919.4236.4.camel@localhost.localdomain> References: <454B3B63.3040501@xs4all.nl> <20061103132810.GA17328@nostromo.devel.redhat.com> <454B574C.3000704@poolshark.org> <4550DFC8.104@tlarson.com> <1162933919.4236.4.camel@localhost.localdomain> Message-ID: <1162971880.8809.18.camel@DustPuppy.LNX.RO> On Tue, 2006-11-07 at 22:11 +0100, Rubin wrote: > Hi. > > I started the thread. Someone responded that setting HWADDR > in /etc/sysconfig/network-scripts/ifcfg-eth1 might make the problem > disappear. Not for me. [cioby at DustPuppy cioby]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. ONBOOT=no USERCTL=yes IPV6INIT=no PEERDNS=yes TYPE=Wireless DEVICE=eth1 HWADDR=00:16:6f:5f:ce:99 BOOTPROTO=dhcp NETMASK= DHCP_HOSTNAME= IPADDR= DOMAIN= ESSID=xxxxxx CHANNEL=1 MODE=Managed RATE= > And it did! After setting HWADDR with the MAC for the wireless card, the > problem has not been encountered since. It happens mostly on boot for me. It's probably an timing issue. I don't boot much tho, thanks to suspend. service network restart;service NetworkManager restart fixes things for me. > I guess it still is a problem, but it works. Not very nice for mom and > pops at home trying out a user-friendly linux distro though. The HWADDR line should be set by the installer / system-config-network, not by hand so this is just a bug if not already. -- Cioby From j.w.r.degoede at hhs.nl Wed Nov 8 09:21:25 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 08 Nov 2006 10:21:25 +0100 Subject: Looking for some easy to fix code (not packaging) bugs Message-ID: <4551A195.3030305@hhs.nl> Hi, As you all know by now I'm a CS teacher as my daytime job. I'm currently working on a practicum where I want students to practice with / experience debugging / fault tracing. For this I'm looking for some bugs, which are 100% reproducable (no race conditions and other hard stuff) and should be relatively easy to fix. Basicly I'm looking for code bugs where lack of time is the most important reason for not fixing them. So please report any bugs in this thread or to my private email, thanks! Regards, Hans From arjan at fenrus.demon.nl Wed Nov 8 09:31:41 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 08 Nov 2006 10:31:41 +0100 Subject: copy_from_user() crashes.. In-Reply-To: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> References: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> Message-ID: <1162978301.3138.263.camel@laptopd505.fenrus.org> On Tue, 2006-11-07 at 18:12 -0800, Basavaraj Hiremath wrote: > Hi, > I am using Fedora Core 5.0. My driver is crashing when > I call copy_from_user() call. > Does any one have idea about this ? Hi, you forgot to attach your source code, so nobody can help you since you didn't include the most crucial part of the information... From gilboad at gmail.com Wed Nov 8 09:44:56 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 08 Nov 2006 11:44:56 +0200 Subject: copy_from_user() crashes.. In-Reply-To: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> References: <20061108021241.23894.qmail@web36102.mail.mud.yahoo.com> Message-ID: <1162979096.25302.3.camel@gilboa-home-nb.localhost> On Tue, 2006-11-07 at 18:12 -0800, Basavaraj Hiremath wrote: > Hi, > I am using Fedora Core 5.0. My driver is crashing when > I call copy_from_user() call. > Does any one have idea about this ? > > Thanks much in advance... > > Thanks & Regards, > Raj I'd venture to guess that either the kernel buffer is invalid or the buffer size is invalid. - Gilboa From d.lesca at solinos.it Wed Nov 8 09:45:07 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 08 Nov 2006 10:45:07 +0100 Subject: SOLVED: fc6 install fail on HP ProLiant ML320 G4 In-Reply-To: <020001c70275$d8f67c50$1601a8c0@VIITYACINE> References: <013501c701c5$4a60ee40$1601a8c0@VIITYACINE> <1162909320.3093.7.camel@lesca.home.solinos.it> <020001c70275$d8f67c50$1601a8c0@VIITYACINE> Message-ID: <1162979107.3255.89.camel@lesca.home.solinos.it> Il giorno mar, 07/11/2006 alle 14.37 +0100, FX ha scritto: > Did you try the "linux nodmraid" command ? Great!! with this boot option the X start and work like a charm . curiosity: how you have had this idea? I have test the option yesterday but I have not been able to conclude the installation why the server was already operating with FC5. Many thanks!! -- Dario Lesca From atkac at redhat.com Wed Nov 8 10:50:51 2006 From: atkac at redhat.com (Adam Tkac) Date: Wed, 08 Nov 2006 11:50:51 +0100 Subject: I think, rsh is quite obsolete Message-ID: <1162983051.4459.6.camel@numenor> I think, It's no argument to include rsh in next versions of fc/rhel. OpenSSH could successfully substitute this component. SSH is more secure than rsh and has all features of rsh. Do you think anything else?? -- Adam Tkac From aph at redhat.com Wed Nov 8 10:55:18 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Nov 2006 10:55:18 +0000 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <17745.46998.157810.696590@zebedee.pink> Adam Tkac writes: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? High performance environments are one obvious example. I've used rsh for high-load testing of systems, where you don't want encryption overhead to get in the way. Andrew. From rhl-devel-list at lnx.ro Wed Nov 8 11:03:02 2006 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Wed, 08 Nov 2006 13:03:02 +0200 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <1162983783.2943.3.camel@DustPuppy.LNX.RO> On Wed, 2006-11-08 at 11:50 +0100, Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? Some of us use rsh to connect to ancient equipements who don't know better (or we can't really change the firmware). -- Cioby From tmraz at redhat.com Wed Nov 8 11:07:46 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 08 Nov 2006 12:07:46 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <17745.46998.157810.696590@zebedee.pink> References: <1162983051.4459.6.camel@numenor> <17745.46998.157810.696590@zebedee.pink> Message-ID: <1162984067.3723.11.camel@perun.kabelta.loc> On Wed, 2006-11-08 at 10:55 +0000, Andrew Haley wrote: > Adam Tkac writes: > > I think, It's no argument to include rsh in next versions of fc/rhel. > > OpenSSH could successfully substitute this component. SSH is more secure > > than rsh and has all features of rsh. Do you think anything else?? > > High performance environments are one obvious example. I've used rsh > for high-load testing of systems, where you don't want encryption > overhead to get in the way. Yes, definitely. There are also other problems with scp/sftp protocols which lower their performance on fast networks. These are being remedied with the HPN patch (http://www.psc.edu/networking/projects/hpn-ssh/) but upstream still refuses to accept the patch and we don't want to diverge from it so much. There is also a question if this patch couldn't cause incompatibility with unpatched OpenSSH clients/servers in some circumstances. So I'd say, keep the rsh for now. Or even better possibility would be to move it to Extras as Extras are NOT a second class citizen and RHEL can still include it. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jos at xos.nl Wed Nov 8 11:08:51 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 8 Nov 2006 12:08:51 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor>; from atkac@redhat.com on Wed, Nov 08, 2006 at 11:50:51AM +0100 References: <1162983051.4459.6.camel@numenor> Message-ID: <20061108120851.C8784@xos037.xos.nl> On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? Don't break traditional UNIX compatibility when there is no good reason to do so. Rsh and friends (rexec, rcp) are used in more legacy UNIX scripts than you think. I don't know or these are part of POSIX.* or some Open Group standard (I don't think so, as these commands originates from the BSD-world). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at redhat.com Wed Nov 8 11:13:30 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 8 Nov 2006 06:13:30 -0500 Subject: rawhide report: 20061108 changes Message-ID: <200611081113.kA8BDUik030233@hs20-bc2-6.build.redhat.com> Updated Packages: at-spi-1.7.13-1.fc7 ------------------- * Tue Nov 07 2006 Matthias Clasen - 1.7.13-1 - Update to 1.7.13 autofs-1:5.0.1-0.rc2.21 ----------------------- * Wed Nov 08 2006 Ian Kent - 5.0.1-0.rc2.21 - mitigate manual umount of automounts where possible. - fix multiply recursive bind mounts. - check kernel module version and require 5.00 or above. - fix expire regression introduced in the "mitigate manual umount" patch. - still more on multiply recursive bind mounts. dbus-python-0.70-7.fc7 ---------------------- * Tue Nov 07 2006 Matthias Clasen - 0.70-7 - Fix a typo in the spec file dhcp-12:3.0.5-1.fc7 ------------------- * Tue Nov 07 2006 David Cantrell - 12:3.0.5-1 - Upgrade to ISC dhcp-3.0.5 * Fri Oct 27 2006 David Cantrell - 12:3.0.4-24 - Put typedef for dhcp_state_e before it's used in libdhcp_control.h (#212612) - Remove dhcpctl.3 from minires/Makefile.dist because it's in dhcpctl - Remove findptrsize.c and just set compiler flag for ppc64 and s390x * Sat Oct 14 2006 David Cantrell - 12:3.0.4-23 - Remove NODEBUGINFO junk from the spec file as well as old/unused code - Rolled all 68 patches in to one patch since more than half of them get overridden by later patches anyway. eclipse-1:3.2.1-16.fc7 ---------------------- * Mon Nov 06 2006 Ben Konrath 3.2.1-16 - Move copy-platform back to %{_datadir}/eclipse. - Require gjdoc >= 0.7.7-14 as it generates consistent html across archs. - Move most of the doc plugins back to %{_datatdir}/eclipse now that gjdoc is fixed. eel2-2.16.1-2.fc7 ----------------- * Tue Nov 07 2006 Alexander Larsson - 2.16.1-2.fc7 - update to 2.16.1 evolution-2.9.2-2.fc7 --------------------- * Tue Nov 07 2006 Matthew Barnes - 2.9.2-2.fc7 - Revise patch for RH bug #202751 and re-enable it. * Mon Nov 06 2006 Matthew Barnes - 2.9.2-1.fc7 - Update to 2.9.2 - Remove patch for Gnome.org bug #360240 (fixed upstream). - Remove patch for Gnome.org bug #360619 (fixed upstream). file-roller-2.17.2-1.fc7 ------------------------ * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 foomatic-3.0.2-40.fc7 --------------------- * Tue Nov 07 2006 Tim Waugh 3.0.2-40 - Clean up gimp-print-ijs/gutenprint recommended drivers. - Updated db-hpijs to 20061031. gnome-desktop-2.17.2-1.fc7 -------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 gnome-games-1:2.17.2-1.fc7 -------------------------- * Tue Nov 07 2006 Matthias Clasen - 1:2.17.2-1 - Update to 2.17.2 gnome-icon-theme-2.17.2-1.fc7 ----------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 gnome-menus-2.17.2-1.fc7 ------------------------ * Mon Nov 06 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 - Don't ship static libraries - Fix python packaging gnome-mime-data-2.4.3-1.fc7 --------------------------- * Wed Nov 08 2006 Matthias Clasen - 2.4.3-1 - Update to 2.4.3 - Require pkgconfig gnome-screensaver-2.17.2-1.fc7 ------------------------------ * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 gnome-session-2.17.2-1.fc7 -------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 * Thu Oct 26 2006 Ray Strode - 2.16.1-2.fc7 - don't hose users with a stale http_proxy variable if they use autoconfiguration and uses to use manual configuration. Patch by Mark McLoughlin (bug 212319) gnome-system-monitor-2.17.2-1.fc7 --------------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 - Update Requires gnome-themes-2.17.2-1.fc7 ------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 gnome-vfs2-2.16.2-2.fc7 ----------------------- * Tue Nov 07 2006 Alexander Larsson - 2.16.2-2.fc7 - Update to 2.16.2 gnome-volume-manager-2.17.0-1.fc7 --------------------------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 gphoto2-2.2.0-3.fc7 ------------------- * Fri Nov 03 2006 Jindrich Novy 2.2.0-3 - fix BuildRoot, use dist tag - specify version of libgphoto2 in Provides libgnome-2.17.0-1.fc7 --------------------- * Wed Nov 08 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 libgnomekbd-2.17.2-1.fc7 ------------------------ * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 libnotify-0.4.2-5.fc7 --------------------- * Tue Nov 07 2006 Matthias Clasen - 0.4.2-5 - Fix typos in the spec (#214275) libvirt-0.1.8-3.fc7 ------------------- * Tue Nov 07 2006 Daniel Veillard 0.1.8-3 - it's pkgconfig not pgkconfig ! nautilus-2.16.2-2.fc7 --------------------- * Tue Nov 07 2006 Alexander Larsson - 2.16.2-2.fc7 - Update to 2.16.2 * Sat Oct 21 2006 Matthias Clasen - 2.16.1-1 - Update to 2.16.1 * Wed Oct 18 2006 Matthias Clasen - 2.16.0-6 - Fix scripts according to the packaging guidelines - Require GConf2 for the scripts - Require pkgconfig for the -devel package openoffice.org-1:2.1.0-1.2 -------------------------- * Mon Nov 06 2006 Caolan McNamara - 1:2.1.0-1.2 - Resolves: rhbz#213710 additional application.version vba support - Resolves: rhbz#214187 openoffice.org-2.0.4.ooo71285.tools.ulongmax.patch orca-2.17.2-1.fc7 ----------------- * Tue Nov 07 2006 Matthias Clasen - 2.17.2-1 - Update to orca 2.17.2 * Tue Nov 07 2006 Matthias Clasen - 2.17.1-2 - Fix typos in the spec policycoreutils-1.32-2 ---------------------- * Mon Nov 06 2006 Dan Walsh 1.32-2 - Fix genhomedircon man page postfix-2:2.3.4-1 ----------------- * Tue Nov 07 2006 Thomas Woerner 2:2.3.4-1 - new version 2.3.4 ppc64-utils-0.11-1.fc7 ---------------------- * Mon Oct 30 2006 Paul Nasrat - 0.11-1 - Update powerpc-utils to 1.0.3 (#212181) * Mon Oct 16 2006 Paul Nasrat - 0.10-1 - Include powerpc-utils and powerpc-utils-papr (#184685) scim-chewing-0.3.1-7.fc7 ------------------------ * Wed Nov 08 2006 Caius Chance - 0.3.1-8.fc7 - Fixed bz#206120 : gedit crashes when select-all with preedit exists. scrollkeeper-0.3.14-10.fc7 -------------------------- * Tue Nov 07 2006 Matthias Clasen - 0.3.4-10 - Fix Requires selinux-policy-2.4.3-2 ---------------------- * Tue Nov 07 2006 Dan Walsh 2.4.3-2 - Fix rpc_port_types - Add aide policy for mls * Mon Nov 06 2006 Dan Walsh 2.4.3-1 - Merge with upstream * Fri Nov 03 2006 Dan Walsh 2.4.2-8 - Lots of fixes for ricci setarch-2.0-2.fc7 ----------------- * Tue Nov 07 2006 Jindrich Novy 2.0-2 - use dist tag - fix BuildRoot setroubleshoot-1.4-1.fc7 ------------------------ * Tue Oct 24 2006 Dan Walsh - 1.4-1 - Many fixes - Changed the api smartmontools-1:5.36-5.fc7 -------------------------- * Tue Nov 07 2006 Tomas Mraz - 1:5.36-5 - set cloexec on device descriptor so it doesn't leak to sendmail (#214182) - fixed minor bug in initscript (#213683) - backported SATA disk detection from upstream squid-7:2.6.STABLE5-1.fc7 ------------------------- * Mon Nov 06 2006 Martin Stransky - 7:2.6.STABLE5-1 - update to the latest upstream * Thu Oct 26 2006 Martin Stransky - 7:2.6.STABLE4-4 - added fix for #205568 - marked cachemgr.conf as world readable system-config-printer-0.7.35-1.fc7 ---------------------------------- * Tue Nov 07 2006 Tim Waugh 0.7.35-1 - 0.7.35. * Thu Nov 02 2006 Tim Waugh - Updated to pycups-1.9.14 (bug #213136). * Tue Oct 31 2006 Tim Waugh - Update desktop database (bug #213249). udev-103-1 ---------- wireshark-0.99.4-2.fc7 ---------------------- * Tue Nov 07 2006 Radek Vokal 0.99.4-2.fc7 - Requires: net-snmp for the list of MIB modules xorg-x11-drv-ati-6.6.3-1.fc7 ---------------------------- * Tue Nov 07 2006 Adam Jackson 6.6.3-1.fc7 - Update to 6.6.3. xorg-x11-drv-i810-1.6.5-10.fc7 ------------------------------ * Tue Nov 07 2006 Adam Jackson 1.6.5-10 - i965-xv-hang-fix.patch: Backport Xv hang fix for G965. Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From atkac at redhat.com Wed Nov 8 11:30:50 2006 From: atkac at redhat.com (Adam Tkac) Date: Wed, 08 Nov 2006 12:30:50 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <1162984067.3723.11.camel@perun.kabelta.loc> References: <1162983051.4459.6.camel@numenor> <17745.46998.157810.696590@zebedee.pink> <1162984067.3723.11.camel@perun.kabelta.loc> Message-ID: <1162985450.4459.13.camel@numenor> Tomas Mraz p??e v St 08. 11. 2006 v 12:07 +0100: > On Wed, 2006-11-08 at 10:55 +0000, Andrew Haley wrote: > > Adam Tkac writes: > > > I think, It's no argument to include rsh in next versions of fc/rhel. > > > OpenSSH could successfully substitute this component. SSH is more secure > > > than rsh and has all features of rsh. Do you think anything else?? > > > > High performance environments are one obvious example. I've used rsh > > for high-load testing of systems, where you don't want encryption > > overhead to get in the way. > > Yes, definitely. There are also other problems with scp/sftp protocols > which lower their performance on fast networks. These are being remedied > with the HPN patch (http://www.psc.edu/networking/projects/hpn-ssh/) but > upstream still refuses to accept the patch and we don't want to diverge > from it so much. There is also a question if this patch couldn't cause > incompatibility with unpatched OpenSSH clients/servers in some > circumstances. > > So I'd say, keep the rsh for now. Or even better possibility would be to > move it to Extras as Extras are NOT a second class citizen and RHEL can > still include it. > > -- > Tomas Mraz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > You're truly right. This idea about high-performance systems doesn't strike me. I'm going to look forward to this idea when upstream of OpenSSH accepts HPN patch (or other improvement for this problem). From denis at poolshark.org Wed Nov 8 11:52:17 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Nov 2006 12:52:17 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <4551C4F1.7030304@poolshark.org> Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? I'm sorry but that's very narrow thinking. rsh is lightweight and fast. There are environments where the security issues are irrelevant. From andreas at bawue.net Wed Nov 8 12:10:38 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 8 Nov 2006 13:10:38 +0100 (CET) Subject: I think, rsh is quite obsolete In-Reply-To: <1162983783.2943.3.camel@DustPuppy.LNX.RO> References: <1162983051.4459.6.camel@numenor> <1162983783.2943.3.camel@DustPuppy.LNX.RO> Message-ID: On Wed, 8 Nov 2006, Dumitru Ciobarcianu wrote: > On Wed, 2006-11-08 at 11:50 +0100, Adam Tkac wrote: >> I think, It's no argument to include rsh in next versions of fc/rhel. >> OpenSSH could successfully substitute this component. SSH is more secure >> than rsh and has all features of rsh. Do you think anything else?? > > Some of us use rsh to connect to ancient equipements who don't know > better (or we can't really change the firmware). Or the hardware connects to our machines. We've got a pool of dial-in servers from Livingston. They do ppp internally, but as soon as someone requests a uucp connection, the user is logged into the uucp server via rlogin. The portmaster is never going to support openssh. regards, Andreas From aph at redhat.com Wed Nov 8 12:29:28 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Nov 2006 12:29:28 +0000 Subject: I think, rsh is quite obsolete In-Reply-To: <1162985450.4459.13.camel@numenor> References: <1162983051.4459.6.camel@numenor> <17745.46998.157810.696590@zebedee.pink> <1162984067.3723.11.camel@perun.kabelta.loc> <1162985450.4459.13.camel@numenor> Message-ID: <17745.52648.71493.699160@zebedee.pink> Adam Tkac writes: > Tomas Mraz p??e v St 08. 11. 2006 v 12:07 +0100: > > On Wed, 2006-11-08 at 10:55 +0000, Andrew Haley wrote: > > > Adam Tkac writes: > > > > I think, It's no argument to include rsh in next versions of fc/rhel. > > > > OpenSSH could successfully substitute this component. SSH is more secure > > > > than rsh and has all features of rsh. Do you think anything else?? > > > > > > High performance environments are one obvious example. I've used rsh > > > for high-load testing of systems, where you don't want encryption > > > overhead to get in the way. > > > > Yes, definitely. There are also other problems with scp/sftp protocols > > which lower their performance on fast networks. These are being remedied > > with the HPN patch (http://www.psc.edu/networking/projects/hpn-ssh/) but > > upstream still refuses to accept the patch and we don't want to diverge > > from it so much. There is also a question if this patch couldn't cause > > incompatibility with unpatched OpenSSH clients/servers in some > > circumstances. > > > > So I'd say, keep the rsh for now. Or even better possibility would be to > > move it to Extras as Extras are NOT a second class citizen and RHEL can > > still include it. > > > > -- > > Tomas Mraz > > No matter how far down the wrong road you've gone, turn back. > > Turkish proverb > > > > You're truly right. This idea about high-performance systems doesn't > strike me. I'm going to look forward to this idea when upstream of > OpenSSH accepts HPN patch (or other improvement for this problem). The acid test is this, run over a fast network: $ tar cf - foo | rsh bar tar xfBp - This should hit the bandwidth of the connection. Andrew. From redhat at olen.net Wed Nov 8 12:46:54 2006 From: redhat at olen.net (Ola Thoresen) Date: Wed, 08 Nov 2006 13:46:54 +0100 Subject: rawhide report: 20061107 changes In-Reply-To: <200611071113.kA7BDB7r011229@hs20-bc2-6.build.redhat.com> References: <200611071113.kA7BDB7r011229@hs20-bc2-6.build.redhat.com> Message-ID: <1162990015.18466.4.camel@ws21.ns5.powertech.no> On tir, 2006-11-07 at 06:13 -0500, buildsys at redhat.com wrote: > > > Updated Packages: > initscripts-8.47-1 > ------------------ > * Mon Nov 06 2006 Bill Nottingham 8.47-1 > - lang.{sh,csh}: handle sinhalese as well in CJKI clauses (#212438) > - rc.sysinit: add '--auto=yes' to mdadm invocation (#213671) > - rename_device: fix incorrect handling of .bak files > - mount tmpfs with -n (#213132) > - various SUBCHANNELS related s390 fixage (#204803) > - lang.{sh,csh}: support iso-8859-8 (#212738, ) hmm...Is thins intentional? (...) Updating : initscripts [131/644]warning: /etc/inittab created as /etc/inittab.rpmnew diff -u /etc/inittab /etc/inittab.rpmnew --- /etc/inittab 2006-11-08 13:33:56.000000000 +0100 +++ /etc/inittab.rpmnew 2006-11-06 19:41:02.000000000 +0100 @@ -15,7 +15,7 @@ # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # -id:5:initdefault: +id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc.sysinit Rgds. Ola Thoresen From jkeating at redhat.com Wed Nov 8 13:03:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 08:03:27 -0500 Subject: rawhide report: 20061107 changes In-Reply-To: <1162990015.18466.4.camel@ws21.ns5.powertech.no> References: <200611071113.kA7BDB7r011229@hs20-bc2-6.build.redhat.com> <1162990015.18466.4.camel@ws21.ns5.powertech.no> Message-ID: <200611080803.27307.jkeating@redhat.com> On Wednesday 08 November 2006 07:46, Ola Thoresen wrote: > ?# > -id:5:initdefault: > +id:3:initdefault: I do believe the default for the initscripts package is run level 3. During install, if you're doing a graphical install, anaconda would change this to 5 for you. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Wed Nov 8 16:00:26 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 8 Nov 2006 10:00:26 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <3237e4410611080800w44b193dcx758d213a8b818d15@mail.gmail.com> On 11/8/06, Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? > -- > Adam Tkac > What you're asking is for us to take the option away from our end users. Probably not going to happen, users like options :D -Mike From notting at redhat.com Wed Nov 8 16:22:28 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Nov 2006 11:22:28 -0500 Subject: rawhide report: 20061107 changes In-Reply-To: <200611080803.27307.jkeating@redhat.com> References: <200611071113.kA7BDB7r011229@hs20-bc2-6.build.redhat.com> <1162990015.18466.4.camel@ws21.ns5.powertech.no> <200611080803.27307.jkeating@redhat.com> Message-ID: <20061108162228.GA7316@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Wednesday 08 November 2006 07:46, Ola Thoresen wrote: > > ?# > > -id:5:initdefault: > > +id:3:initdefault: > > I do believe the default for the initscripts package is run level 3. During > install, if you're doing a graphical install, anaconda would change this to 5 > for you. Correct. The .rpmnew is because the invocation of /etc/X11/prefdm changed in rawhide - for existing installs, this is handled with a sed script in the %post. Bill From terraformers at gmail.com Wed Nov 8 17:42:34 2006 From: terraformers at gmail.com (Lars G) Date: Wed, 08 Nov 2006 18:42:34 +0100 Subject: rawhide report: 20061108 changes In-Reply-To: <200611081113.kA8BDUik030233@hs20-bc2-6.build.redhat.com> References: <200611081113.kA8BDUik030233@hs20-bc2-6.build.redhat.com> Message-ID: <1163007753.3645.2.camel@kinichahau.homebase> On Wed, 2006-11-08 at 06:13 -0500, buildsys at redhat.com wrote: ... After today's update, my desktop icons are shuffling around. -- Lars G From michel.salim at gmail.com Wed Nov 8 20:41:00 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 8 Nov 2006 15:41:00 -0500 Subject: yum module idea: force-install high-priority updates Message-ID: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> Today's Firefox update causes problems on machines with the liferea package from Fedora Extras, which depends on a specific version of Firefox. This sets me thinking: what if a vital security update is being pushed, and we don't mind breaking the packages that block the update for the time being? Not really familiar with yum's innards, but would it be possible to write a module that would, in case of high-security updates (probably marked as such in the repodata, and perhaps incorporating user input, e.g. --force-update glob and --ignore-force-update glob), remove conflicting packages, apply the update, and keep track of which packages were removed so that they can be automatically reinstalled when no longer in conflict. There might be a problem if the conflicting package is not available from any repository, but in general, does the idea seem sound? Regards, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From jspaleta at gmail.com Wed Nov 8 22:05:46 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Nov 2006 13:05:46 -0900 Subject: yum module idea: force-install high-priority updates In-Reply-To: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> Message-ID: <604aa7910611081405p583454d1ne7cf0dc3f6bc678d@mail.gmail.com> On 11/8/06, Michel Salim wrote: > There might be a problem if the conflicting package is not available > from any repository, but in general, does the idea seem sound? Technically... this is possible... the 'security' label is available in the updateinfo.xml.gz now being generated for updates to fc6. Whether or not such a plugin is rational or even sane, will be a matter of opinion based on individual administrator situations. This would never be appropriate as something to install by default, and should only be used by people who know wtf they are doing. You would most certaintly want the plugin be advenced enough so admins could identify a list of 'important' packages which should not be allowed to break in the effort to force a security update. Its one think to break liferea it's another to break the deps to httpd, if the machine is primarily a webserver. -jef From naoki at valuecommerce.com Wed Nov 8 23:36:02 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 09 Nov 2006 08:36:02 +0900 Subject: yum module idea: force-install high-priority updates In-Reply-To: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> Message-ID: <455269E2.9050205@valuecommerce.com> Michel Salim wrote: > Today's Firefox update causes problems on machines with the liferea > package from Fedora Extras, which depends on a specific version of > Firefox. This sets me thinking: what if a vital security update is > being pushed, and we don't mind breaking the packages that block the > update for the time being? > > Not really familiar with yum's innards, but would it be possible to > write a module that would, in case of high-security updates (probably > marked as such in the repodata, and perhaps incorporating user input, > e.g. --force-update glob and --ignore-force-update glob), remove > conflicting packages, apply the update, and keep track of which > packages were removed so that they can be automatically reinstalled > when no longer in conflict. > > There might be a problem if the conflicting package is not available > from any repository, but in general, does the idea seem sound? Good pro-active idea, I've just never been a fan of trying to prioritize security patching, it's kind of like deciding which door in your house should get a lock first. Sure remote root is "worse" than random app X having a buffer overrun, but both could end up losing you data so at the end of the day it's the same pool full of marmots. Since it's hard to tell exactly how a security bug could be used against you it's best just to patch everything, always, as quickly as possible. In this specific case I'd be wondering why liferea needs a very specific version of firefox. I just checked the app in question and it states a requirement of : firefox = 1.5.0.7 I would propose that this isn't really normal behavior, to require a specific patch version unless API changed, which in this case I do not think happened. So perhaps this could be brought to the attention of the lifrea maintainer first. From davej at redhat.com Wed Nov 8 23:58:18 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Nov 2006 18:58:18 -0500 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <20061108235818.GM3309@redhat.com> On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? The rsh _client_ has its uses in legacy environments. The daemon, questionable. Likewise, why we still ship telnet-server in core is beyond me. Dave -- http://www.codemonkey.org.uk From admin at zapped.2y.net Thu Nov 9 00:00:37 2006 From: admin at zapped.2y.net (Erik van Pienbroek) Date: Thu, 09 Nov 2006 01:00:37 +0100 Subject: yum module idea: force-install high-priority updates In-Reply-To: <455269E2.9050205@valuecommerce.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> Message-ID: <1163030437.19039.10.camel@localhost.localdomain> Op donderdag 09-11-2006 om 08:36 uur [tijdzone +0900], schreef Naoki: > In this specific case I'd be wondering why liferea needs a very specific > version of firefox. I just checked the app in question and it states a > requirement of : > firefox = 1.5.0.7 I'm not familiar with liferea, but I am a developer of a application which uses GtkEmbedMoz, an GTK firefox embedding widget and I think liferea is in the same situation as I am. The problem is that each version of Mozilla/Firefox uses a different installation prefix. For Firefox 1.5.0.7 this is /usr/lib/firefox-1.5.0.7 When a application links with some Mozilla/Firefox library the full path gets saved in the final executable. If a new firefox release appears, the application still tries to search the Mozilla/Firefox library in the old directory instead of the new firefox prefix. So a rebuild (or a LD_LIBRARY_PATH hack) is necessary for the application to become operational again. So the question for this case should be if this isn't a firefox packaging bug instead of a liferea bug as this problem applies to other programs as well (epiphany for example). Regards, Erik van Pienbroek From lmacken at redhat.com Thu Nov 9 00:01:51 2006 From: lmacken at redhat.com (Luke Macken) Date: Wed, 8 Nov 2006 19:01:51 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <604aa7910611081405p583454d1ne7cf0dc3f6bc678d@mail.gmail.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <604aa7910611081405p583454d1ne7cf0dc3f6bc678d@mail.gmail.com> Message-ID: <20061109000151.GA27956@tomservo.rh.rit.edu> On Wed, Nov 08, 2006 at 01:05:46PM -0900, Jeff Spaleta wrote: > On 11/8/06, Michel Salim wrote: > >There might be a problem if the conflicting package is not available > >from any repository, but in general, does the idea seem sound? > > Technically... this is possible... the 'security' label is available > in the updateinfo.xml.gz now being generated for updates to fc6. > > Whether or not such a plugin is rational or even sane, will be a > matter of opinion based on individual administrator situations. This > would never be appropriate as something to install by default, and > should only be used by people who know wtf they are doing. > > You would most certaintly want the plugin be advenced enough so admins > could identify a list of 'important' packages which should not be > allowed to break in the effort to force a security update. Its one > think to break liferea it's another to break the deps to httpd, if the > machine is primarily a webserver. I'm in the process of finishing up some api changes to the update metdata module for yum (yum.update_md), and I have a couple of yum plugins/tools I'm going to be getting out the door shortly (once/if I make it through finals next week). The first is a 'securityonly' yum plugin, which will only install updates flagged as security. At the moment the updateinfo.xml.gz metadata, which contains this information, is only being generated for core updates, thus making this plugin only partially useful. I'm currently working on coding up a new and improved updates system[0] for Fedora (encompassing core/extras/legacy) that will give us this metadata for all updates. As for having it purposely break things for 'important' updates, I'm not sure that's the best approach to solving the problem. At the least, I'd like to making sure the user/admin is *well aware* that they have security updates that are unable to be installed (and offer a potential solution). But in a Perfect World (with unified build/update systems, QA, etc), dependency issues like the liferea one Michel mentioned wouldn't happen. The second tool I'm working on is a standalone script to query package update notices via the commandline (by CVE/bug/package/etc). More on that in the near future. luke [0]: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem From cmadams at hiwaay.net Thu Nov 9 00:48:46 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Nov 2006 18:48:46 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <20061108235818.GM3309@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> Message-ID: <20061109004846.GA673446@hiwaay.net> Once upon a time, Dave Jones said: > On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > > I think, It's no argument to include rsh in next versions of fc/rhel. > > OpenSSH could successfully substitute this component. SSH is more secure > > than rsh and has all features of rsh. Do you think anything else?? > > The rsh _client_ has its uses in legacy environments. > The daemon, questionable. > Likewise, why we still ship telnet-server in core is beyond me. I have needed telnet-server a few times when trying to debug when connecting from network gear (no ssh in most). Also, where we allow shell access to web hosting customers, we still allow telnet (most of them are on Windows and it only includes a telnet client). Both telnet and rsh (client and server) are stable packages with few security issues historically. They are old protocols, but they do still have their uses. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From michel.salim at gmail.com Thu Nov 9 00:59:10 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 8 Nov 2006 19:59:10 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <1163030437.19039.10.camel@localhost.localdomain> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> Message-ID: <883cfe6d0611081659i2d634cdfifd9b42c79c703e1e@mail.gmail.com> On 11/8/06, Erik van Pienbroek wrote: > Op donderdag 09-11-2006 om 08:36 uur [tijdzone +0900], schreef Naoki: > > In this specific case I'd be wondering why liferea needs a very specific > > version of firefox. I just checked the app in question and it states a > > requirement of : > > firefox = 1.5.0.7 > > I'm not familiar with liferea, but I am a developer of a application > which uses GtkEmbedMoz, an GTK firefox embedding widget and I think > liferea is in the same situation as I am. > > The problem is that each version of Mozilla/Firefox uses a > different installation prefix. For Firefox 1.5.0.7 this > is /usr/lib/firefox-1.5.0.7 > > When a application links with some Mozilla/Firefox library > the full path gets saved in the final executable. > In case of liferea, the dependency is not actually that hard-coded. liferea uses LD_LIBRARY_PATH to add Firefox's installation directory before calling the actual liferea-bin binary. This path is detected at build time and hardcoded into the script. > So the question for this case should be if this isn't a firefox > packaging bug instead of a liferea bug as this problem applies > to other programs as well (epiphany for example). > In liferea's case, yes, the problem would go away if the last version of Firefox installed would just create a symlink of %{_libdir}/firefox-%{version} to %{_libdir}/firefox In an ideal world, Fedora Core and Extras packages would get automatically rebuilt if their dependencies would be broken by an update. As I understand it, such rebuilds are now done by hand? -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From michel.salim at gmail.com Thu Nov 9 01:10:59 2006 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 8 Nov 2006 20:10:59 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <20061109000151.GA27956@tomservo.rh.rit.edu> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <604aa7910611081405p583454d1ne7cf0dc3f6bc678d@mail.gmail.com> <20061109000151.GA27956@tomservo.rh.rit.edu> Message-ID: <883cfe6d0611081710y3b820788hcd35bb0d8f79bc1d@mail.gmail.com> On 11/8/06, Luke Macken wrote: > The first is a 'securityonly' yum plugin, which will only install updates > flagged as security. At the moment the updateinfo.xml.gz metadata, > which contains this information, is only being generated for core updates, > thus making this plugin only partially useful. I'm currently working on > coding up a new and improved updates system[0] for Fedora (encompassing > core/extras/legacy) that will give us this metadata for all updates. > That would be nice - a Microsoft-esque "automatic update" solution would be less annoying if it can be limited to just security updates. > The second tool I'm working on is a standalone script to query package update > notices via the commandline (by CVE/bug/package/etc). More on that in > the near future. > Something like Advisory Check? http://advchk.unixgu.ru/ (Mental note to self: package this for FE) Regards, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From zaitcev at redhat.com Thu Nov 9 01:22:30 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Nov 2006 17:22:30 -0800 Subject: I think, rsh is quite obsolete In-Reply-To: <20061108235818.GM3309@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> Message-ID: <20061108172230.16a3d9b6.zaitcev@redhat.com> On Wed, 8 Nov 2006 18:58:18 -0500, Dave Jones wrote: > The rsh _client_ has its uses in legacy environments. > The daemon, questionable. > Likewise, why we still ship telnet-server in core is beyond me. Dave, what do you use for file transfers from your C3? I know you have them. Mine is an 800MHz part, and scp -o blowfish pegs the CPU on it. If they had scp -o null, it'd be awesome. Telnet server though, that I wonder myself. These days ssh clients are ubiqutous. I think they even them them for Sidekicks, let alone Pilots or any Linux-based PDAs. -- Pete From jkeating at redhat.com Thu Nov 9 01:38:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 20:38:22 -0500 Subject: Announcing pungi-0.1.0 Message-ID: <200611082038.25862.jkeating@redhat.com> I am pleased (and scared) to announce the 0.1.0 release of pungi. This is the first release and thus it is a bit rough around the edges, but I firmly believe in release early release often. With this release pungi has the ability to gather packages and their deps from a given repo or set of repos, run anaconda tools to make installable trees, and create CD and DVD isos (DVD only if you ask for more than one CD). I have included some reference config files and a comps file I have been using to develop with. Currently pungi needs to be ran on the architecture you are composing for, although one could use mock with setarch as well. See README for more details on design and usage of pungi. To download pungi, visit http://linux.duke.edu/projects/pungi/release/ and pick up either the tarball, the source rpm, or the Fedora Core 6 binary rpm. Mercurial repo is http://linux.duke.edu/projects/pungi Discussion regarding the use or development of pungi happens on the fedora-buildsys-list mailing list: http://www.redhat.com/mailman/listinfo/fedora-buildsys-list Currently bugs are not tracked anywhere other than my inbox, I will most likely rectify this situation soon, but for now email works. Enjoy! -- Jesse Keating Release Engineer: Fedora -------------- 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 Thu Nov 9 01:53:24 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Nov 2006 20:53:24 -0500 Subject: I think, rsh is quite obsolete In-Reply-To: <20061108172230.16a3d9b6.zaitcev@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> Message-ID: <20061109015324.GB805@redhat.com> On Wed, Nov 08, 2006 at 05:22:30PM -0800, Pete Zaitcev wrote: > On Wed, 8 Nov 2006 18:58:18 -0500, Dave Jones wrote: > > > The rsh _client_ has its uses in legacy environments. > > The daemon, questionable. > > Likewise, why we still ship telnet-server in core is beyond me. > > Dave, what do you use for file transfers from your C3? I know you have > them. Mine is an 800MHz part, and scp -o blowfish pegs the CPU on it. > If they had scp -o null, it'd be awesome. Hmm. mine is a 1.2GHz Nehemiah, which is probably a bit speedier than the older 800MHz parts. Samuel core ? It's still no speed daemon, but I don't find it that slow. I assume you meant -c blowfish above, as -o doesn't seem too happy. Oddly, -o blowfish is faster than the default. Copying over a 100Mbit LAN, I get a 7MB/s by default, and 8MB/s with blowfish. I know the newer C3's have crypto magic, so maybe openssh is taking advantage of that. I honestly don't know for sure. > Telnet server though, that I wonder myself. These days ssh clients > are ubiqutous. I think they even them them for Sidekicks, let alone > Pilots or any Linux-based PDAs. My new TV recording gizmo has a telnetd. It's the first device/computer that I've owned that runs one in about 6-7 years. I can understand maybe including them in embedded devices (though it's somewhat bad to be doing that, and having a passwordless root acct, and also talk about how you can hook up the device to wireless) as a telnetd is a) less cpu intensive and b) smaller flash space than openssh. But for Fedora, I can't think of a valid reason why someone would want to enable a telnetd given the security concerns of non encrypted sessions. Dave -- http://www.codemonkey.org.uk From ndbecker2 at gmail.com Thu Nov 9 01:55:50 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Nov 2006 20:55:50 -0500 Subject: Announcing pungi-0.1.0 References: <200611082038.25862.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > I am pleased (and scared) to announce the 0.1.0 release of pungi. This is > the first release and thus it is a bit rough around the edges, but I > firmly believe in release early release often. > > With this release pungi has the ability to gather packages and their deps > from a given repo or set of repos, run anaconda tools to make installable > trees, > and create CD and DVD isos (DVD only if you ask for more than one CD). I > have included some reference config files and a comps file I have been > using > to develop with. Currently pungi needs to be ran on the architecture you > are > composing for, although one could use mock with setarch as well. See > README for more details on design and usage of pungi. > > To download pungi, visit http://linux.duke.edu/projects/pungi/release/ and > pick up either the tarball, the source rpm, or the Fedora Core 6 binary > rpm. > Mercurial repo is http://linux.duke.edu/projects/pungi Discussion > regarding the use or development of pungi happens on the > fedora-buildsys-list mailing > list: http://www.redhat.com/mailman/listinfo/fedora-buildsys-list > Currently bugs are not tracked anywhere other than my inbox, I will most > likely rectify this situation soon, but for now email works. > > Enjoy! > Cool. In README, should that test be --version 6.89, rather than --release 6.89? From jkeating at redhat.com Thu Nov 9 01:56:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 20:56:56 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: References: <200611082038.25862.jkeating@redhat.com> Message-ID: <200611082056.56464.jkeating@redhat.com> On Wednesday 08 November 2006 20:55, Neal Becker wrote: > In README, should that test be --version 6.89, rather than --release 6.89? Hahah, good catch! I'll fix in hg. -- Jesse Keating Release Engineer: Fedora -------------- 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 Nov 9 02:02:12 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Nov 2006 20:02:12 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109015324.GB805@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> Message-ID: <20061109020212.GC673446@hiwaay.net> Once upon a time, Dave Jones said: > But for Fedora, I can't think of a valid reason why someone would want > to enable a telnetd given the security concerns of non encrypted sessions. For some setups, encryption is not a concern. Besides, FTP, POP3, IMAP, etc. are still included. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From davej at redhat.com Thu Nov 9 02:28:20 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Nov 2006 21:28:20 -0500 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109004846.GA673446@hiwaay.net> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061109004846.GA673446@hiwaay.net> Message-ID: <20061109022820.GA11430@redhat.com> On Wed, Nov 08, 2006 at 06:48:46PM -0600, Chris Adams wrote: > Once upon a time, Dave Jones said: > > On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > > > I think, It's no argument to include rsh in next versions of fc/rhel. > > > OpenSSH could successfully substitute this component. SSH is more secure > > > than rsh and has all features of rsh. Do you think anything else?? > > > > The rsh _client_ has its uses in legacy environments. > > The daemon, questionable. > > Likewise, why we still ship telnet-server in core is beyond me. > > I have needed telnet-server a few times when trying to debug when > connecting from network gear (no ssh in most). hmm, would they have had rsh? > Also, where we allow > shell access to web hosting customers, we still allow telnet (most of > them are on Windows and it only includes a telnet client). by default yes, but there are a number of good free windows ssh clients. > Both telnet and rsh (client and server) are stable packages with few > security issues historically. security-wise, they are inherently broken by design in that they transmit everything in cleartext. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Nov 9 02:33:47 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Nov 2006 21:33:47 -0500 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109020212.GC673446@hiwaay.net> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> Message-ID: <20061109023347.GB11430@redhat.com> On Wed, Nov 08, 2006 at 08:02:12PM -0600, Chris Adams wrote: > Once upon a time, Dave Jones said: > > But for Fedora, I can't think of a valid reason why someone would want > > to enable a telnetd given the security concerns of non encrypted sessions. > > For some setups, encryption is not a concern. Besides, FTP, POP3, IMAP, > etc. are still included. These can be wrapped with SSL. Dave -- http://www.codemonkey.org.uk From cmadams at hiwaay.net Thu Nov 9 02:38:58 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Nov 2006 20:38:58 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109022820.GA11430@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061109004846.GA673446@hiwaay.net> <20061109022820.GA11430@redhat.com> Message-ID: <20061109023858.GD673446@hiwaay.net> Once upon a time, Dave Jones said: > On Wed, Nov 08, 2006 at 06:48:46PM -0600, Chris Adams wrote: > > I have needed telnet-server a few times when trying to debug when > > connecting from network gear (no ssh in most). > > hmm, would they have had rsh? Old Ciscos have telnet, rsh, and tftp. Rsh is a step up in security from tftp. > > Also, where we allow > > shell access to web hosting customers, we still allow telnet (most of > > them are on Windows and it only includes a telnet client). > > by default yes, but there are a number of good free windows ssh clients. I know (and I use them when I have to use Windows), but we are talking about customers. We have had some that can't figure out how to upload their site so they bring it to us on a CD, but they can follow a "friend's" instructions on how to install this neat-o counter CGI that say "telnet www.mydomain.com". > > Both telnet and rsh (client and server) are stable packages with few > > security issues historically. > > security-wise, they are inherently broken by design in that they transmit > everything in cleartext. Well, if that is the sole reason to remove them, there are a bunch of other things that do the same. Are all of them going to go? Will HTTP simple authentication be disabled in Apache? What about when such protocols are used over IPSec (or even an ssh tunnel)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Thu Nov 9 02:42:14 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Nov 2006 20:42:14 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109023347.GB11430@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> Message-ID: <20061109024213.GE673446@hiwaay.net> Once upon a time, Dave Jones said: > On Wed, Nov 08, 2006 at 08:02:12PM -0600, Chris Adams wrote: > > Once upon a time, Dave Jones said: > > > But for Fedora, I can't think of a valid reason why someone would want > > > to enable a telnetd given the security concerns of non encrypted sessions. > > > > For some setups, encryption is not a concern. Besides, FTP, POP3, IMAP, > > etc. are still included. > > These can be wrapped with SSL. Telnet and rsh can be used over networks that are secured in other ways. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From zaitcev at redhat.com Thu Nov 9 03:05:30 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Nov 2006 19:05:30 -0800 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109015324.GB805@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> Message-ID: <20061108190530.caa77440.zaitcev@redhat.com> On Wed, 8 Nov 2006 20:53:24 -0500, Dave Jones wrote: > I assume you meant -c blowfish above, as -o doesn't seem too happy. I dunno why I typed that. Yes, of course it's -c > Oddly, -o blowfish is faster than the default. Now you're doing it :-) > Copying over a 100Mbit LAN, I get a 7MB/s by default, and 8MB/s with blowfish. I get about the same picture here, and yes, the default cipher is slower. > But for Fedora, I can't think of a valid reason why someone would want > to enable a telnetd given the security concerns of non encrypted sessions. There's one niche application: running s390 installs. Without telnet, you have to edit your .ssh/known_hosts all the time. It's quite annoying. Although I don't understand why we can't just launch a vnc server. -- Pete From katzj at redhat.com Thu Nov 9 03:38:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Nov 2006 22:38:47 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <1163030437.19039.10.camel@localhost.localdomain> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> Message-ID: <1163043527.19271.4.camel@aglarond.local> On Thu, 2006-11-09 at 01:00 +0100, Erik van Pienbroek wrote: > Op donderdag 09-11-2006 om 08:36 uur [tijdzone +0900], schreef Naoki: > > In this specific case I'd be wondering why liferea needs a very specific > > version of firefox. I just checked the app in question and it states a > > requirement of : > > firefox = 1.5.0.7 > > I'm not familiar with liferea, but I am a developer of a application > which uses GtkEmbedMoz, an GTK firefox embedding widget and I think > liferea is in the same situation as I am. > > The problem is that each version of Mozilla/Firefox uses a > different installation prefix. For Firefox 1.5.0.7 this > is /usr/lib/firefox-1.5.0.7 > > When a application links with some Mozilla/Firefox library > the full path gets saved in the final executable. > > If a new firefox release appears, the application still tries to > search the Mozilla/Firefox library in the old directory instead > of the new firefox prefix. So a rebuild (or a LD_LIBRARY_PATH hack) > is necessary for the application to become operational again. > > So the question for this case should be if this isn't a firefox > packaging bug instead of a liferea bug as this problem applies > to other programs as well (epiphany for example). It's not just the location, but there also aren't guarantees around API or ABI stability when using firefox/mozilla as an embedding engine. xulrunner[1] will be the answer to this, but it's not ready yet Jeremy [1] http://developer.mozilla.org/en/docs/XULRunner From admin at zapped.2y.net Thu Nov 9 06:55:11 2006 From: admin at zapped.2y.net (Erik van Pienbroek) Date: Thu, 09 Nov 2006 07:55:11 +0100 Subject: yum module idea: force-install high-priority updates In-Reply-To: <1163043527.19271.4.camel@aglarond.local> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> <1163043527.19271.4.camel@aglarond.local> Message-ID: <1163055311.19039.14.camel@localhost.localdomain> Op woensdag 08-11-2006 om 22:38 uur [tijdzone -0500], schreef Jeremy Katz: > It's not just the location, but there also aren't guarantees around API > or ABI stability when using firefox/mozilla as an embedding engine. That this is a issue for new releases I can understand, but is the API/ABI even unstable for patch releases? (1.5.0.7 -> 1.5.0.8) Regards, Erik van Pienbroek From pbrobinson at gmail.com Thu Nov 9 07:44:52 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 9 Nov 2006 07:44:52 +0000 Subject: I think, rsh is quite obsolete In-Reply-To: <20061108235818.GM3309@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> Message-ID: <5256d0b0611082344t71e1f642o20a4c166e69dbc99@mail.gmail.com> > On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > > I think, It's no argument to include rsh in next versions of fc/rhel. > > OpenSSH could successfully substitute this component. SSH is more secure > > than rsh and has all features of rsh. Do you think anything else?? > > The rsh _client_ has its uses in legacy environments. > The daemon, questionable. > Likewise, why we still ship telnet-server in core is beyond me. Telnet client is invaluable, server maybe not so much. Legacy Cisco equipment and other networking gear makes some of the stuff useful but when it comes to it none of it is enabled by default and its not like they take up tens of megabytes on the installer CDs. Peter From kzak at redhat.com Thu Nov 9 09:09:50 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 9 Nov 2006 10:09:50 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109023347.GB11430@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> Message-ID: <20061109090950.GB4324@petra.dvoda.cz> On Wed, Nov 08, 2006 at 09:33:47PM -0500, Dave Jones wrote: > On Wed, Nov 08, 2006 at 08:02:12PM -0600, Chris Adams wrote: > > Once upon a time, Dave Jones said: > > > But for Fedora, I can't think of a valid reason why someone would want > > > to enable a telnetd given the security concerns of non encrypted sessions. > > > > For some setups, encryption is not a concern. Besides, FTP, POP3, IMAP, > > etc. are still included. > > These can be wrapped with SSL. Yes, but do you need it all time and everywhere? I don't know why I should use SSL if my server and client are on localhost where is my account only. Karel -- Karel Zak From kzak at redhat.com Thu Nov 9 09:26:58 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 9 Nov 2006 10:26:58 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <20061109092658.GC4324@petra.dvoda.cz> On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > I think, It's no argument to include rsh in next versions of fc/rhel. > OpenSSH could successfully substitute this component. SSH is more secure > than rsh and has all features of rsh. Do you think anything else?? Yes, definitely. I've spent last two years to make it useful and I think it requires minimal time for maintenance now (it's reason why I've left this package). We have feedback from our customers and FC users that they need it and they use it. Reasons: - high-performance - security overhead - traditional UNIX compatibility - around us are people who use non-Linux systems and rsh is very important for them Maybe we're already somewhere on the way between classic UNIX and Windows, but I think it's still to early to forget classic UNIX rule: The right tool for the job. Karel -- Karel Zak From fedora at wir-sind-cool.org Thu Nov 9 09:58:12 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Nov 2006 10:58:12 +0100 Subject: yum module idea: force-install high-priority updates In-Reply-To: <883cfe6d0611081659i2d634cdfifd9b42c79c703e1e@mail.gmail.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> <883cfe6d0611081659i2d634cdfifd9b42c79c703e1e@mail.gmail.com> Message-ID: <20061109105812.3a8954e4.fedora@wir-sind-cool.org> On Wed, 8 Nov 2006 19:59:10 -0500, Michel Salim wrote: > > Op donderdag 09-11-2006 om 08:36 uur [tijdzone +0900], schreef Naoki: > > > In this specific case I'd be wondering why liferea needs a very specific > > > version of firefox. I just checked the app in question and it states a > > > requirement of : > > > firefox = 1.5.0.7 > > > > I'm not familiar with liferea, but I am a developer of a application > > which uses GtkEmbedMoz, an GTK firefox embedding widget and I think > > liferea is in the same situation as I am. > > > > The problem is that each version of Mozilla/Firefox uses a > > different installation prefix. For Firefox 1.5.0.7 this > > is /usr/lib/firefox-1.5.0.7 > > > > When a application links with some Mozilla/Firefox library > > the full path gets saved in the final executable. > > > In case of liferea, the dependency is not actually that hard-coded. It is, it is. This has been the result of discussion in an upstream bug ticket. > liferea uses LD_LIBRARY_PATH to add Firefox's installation directory > before calling the actual liferea-bin binary. This path is detected at > build time and hardcoded into the script. It used to be like this, but has been error-prone (leading to crashes, even) and has changed to a really hardcoded path in the binary. From dtimms at iinet.net.au Thu Nov 9 10:02:44 2006 From: dtimms at iinet.net.au (David Timms) Date: Thu, 09 Nov 2006 21:02:44 +1100 Subject: rawhide report: 20061108 changes In-Reply-To: <1163007753.3645.2.camel@kinichahau.homebase> References: <200611081113.kA8BDUik030233@hs20-bc2-6.build.redhat.com> <1163007753.3645.2.camel@kinichahau.homebase> Message-ID: <4552FCC4.5080207@iinet.net.au> Lars G wrote: > On Wed, 2006-11-08 at 06:13 -0500, buildsys at redhat.com wrote: > ... > > After today's update, my desktop icons are shuffling around. Nice, sounds like one of those cool desktop effects ;) Seriously though, your haven't really described the effect. How much movement, did they move once and stop or are they continuing to move ? DaveT. From mike at miketc.com Thu Nov 9 10:07:31 2006 From: mike at miketc.com (Mike Chambers) Date: Thu, 09 Nov 2006 04:07:31 -0600 Subject: rawhide report: 20061108 changes In-Reply-To: <4552FCC4.5080207@iinet.net.au> References: <200611081113.kA8BDUik030233@hs20-bc2-6.build.redhat.com> <1163007753.3645.2.camel@kinichahau.homebase> <4552FCC4.5080207@iinet.net.au> Message-ID: <1163066851.3654.1.camel@scrappy.miketc.com> On Thu, 2006-11-09 at 21:02 +1100, David Timms wrote: > Lars G wrote: > > On Wed, 2006-11-08 at 06:13 -0500, buildsys at redhat.com wrote: > > ... > > > > After today's update, my desktop icons are shuffling around. > Nice, sounds like one of those cool desktop effects ;) > > Seriously though, your haven't really described the effect. How much > movement, did they move once and stop or are they continuing to move ? They went from being (well on my system as I saw same thing) all 3 icons in upper left to middle left. And the icons themselves in the whole theme changed (this was the new stuff that was in rawhide after FC6), to generic gnome theme. I changed to BlueCurve for the time being. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From buildsys at redhat.com Thu Nov 9 10:52:57 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 9 Nov 2006 05:52:57 -0500 Subject: rawhide report: 20061109 changes Message-ID: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> Updated Packages: aspell-12:0.60.4-1.fc7 ---------------------- * Wed Nov 08 2006 Ivana Varekova - 12:0.60.4-1 - update to 0.60.4 * Wed Jul 12 2006 Jesse Keating - 12:0.60.3-7.1 - rebuild * Tue May 23 2006 Ivana Varekova - 12:0.60.3-7 - fix multilib problem (used pkgconfig) control-center-1:2.17.1-3.fc7 ----------------------------- * Wed Nov 08 2006 Matthias Clasen - 2.17.1-3 - Work around a file conflict with libgnomekbd (#214608) cups-1:1.2.6-4.fc7 ------------------ * Wed Nov 08 2006 Tim Waugh 1:1.2.6-4 - Fixed pdftops.conf (bug #214611). desktop-printing-0.19-18.fc7 ---------------------------- * Wed Nov 08 2006 Tim Waugh - 0.19-18 - Fixed HAL printer interface API name (bug #214619). dmraid-1.0.0.rc14-1.fc7 ----------------------- * Wed Nov 08 2006 Heinz Mauelshagen - 1.0.0.rc14-1 - asr.c: fixed Adaptec HostRAID DDF1 metadata discovery (bz#211016) - ddf1_crc.c: added crc() routine to avoid linking to zlib alltogether, because Ubuntu had problems with this - dropped zlib build requirement * Thu Oct 26 2006 Heinz Mauelshagen - 1.0.0.rc14-bz211016-1 - ddf1.c: get_size() fixed (bz#211016) - ddf1_lib.c: ddf1_cr_off_maxpds_helper() fixed (bz#211016) evolution-data-server-1.9.2-2.fc7 --------------------------------- * Wed Nov 08 2006 Matthew Barnes - 1.9.2-2.fc7 - Add patch for RH bug #203058 (name selector dialog glitch). fonts-chinese-3.03-1.fc7 ------------------------ * Thu Nov 09 2006 Caius Chance - 3.03-1.fc7 - Included new release of arphic uming & ukai (20060928). gaim-2:2.0.0-0.19.beta4.fc7 --------------------------- * Wed Nov 08 2006 Warren Togami - 2:2.0.0-0.19.beta4 - buildreq NetworkManager-glib-devel FC5+ (katzj) - #213800 debug window freeze fix - #212818 IRC SIGPIPE crash fix * Wed Oct 25 2006 Warren Togami - 2:2.0.0-0.17.beta4 - temporary workaround for gstreamer build bug in beta4 --enable-gstreamer prevented it from working =) NOTE: beta4 removed libao support entirely. Distros that lack gstreamer-0.10+ will need to use command line sound output from now on. - Gadu Gadu is re-included in beta4 without requirement of external library * Mon Oct 23 2006 Warren Togami - 2:2.0.0-0.16.beta4 - 2.0.0 beta4 - gaim-text ncurses interface! - gstreamer integration with FC5+ gdm-1:2.17.2-1.fc7 ------------------ * Tue Nov 07 2006 Matthias Clasen - 1:2.17.2-1 - Update to 2.17.2 gnome-games-1:2.17.2-2.fc7 -------------------------- * Wed Nov 08 2006 Matthias Clasen - 1:2.17.2-2 - Add Provides/Obsoletes for gnome-sudoku (#214589) hal-cups-utils-0.6.2-6 ---------------------- * Wed Nov 08 2006 Tim Waugh - 0.6.2-6 - Use printer.commandset when matching printers (bug #214180). - Fixed HAL printer interface API name (bug #214598). icu-3.6-11 ---------- * Wed Nov 08 2006 Caolan McNamara - 3.6-11 - Resolves: icu.icu5501.sinhala.biggerexpand.patch * Wed Nov 08 2006 Caolan McNamara - 3.6-10 - Resolves: rhbz#214555 icu.icu5500.devicetablecrash.patch irqbalance-1:1.13-7.fc7 ----------------------- * Wed Nov 08 2006 Neil Horman - 1.13-7 - fix up irqbalance to detect multicore (not ht) (bz 211183) kdebase-6:3.5.5-0.4.fc6 ----------------------- * Fri Nov 03 2006 Than Ngo 6:3.5.5-0.4.fc6 - rebuild * Thu Nov 02 2006 Than Ngo 6:3.5.5-0.3.fc6 - rebuild * Thu Nov 02 2006 Than Ngo 6:3.5.5-0.2.fc6 - apply upstream patch to fix #213219, KWin focus issue - fix pam config issue libX11-1.0.3-6.fc7 ------------------ * Thu Nov 09 2006 Caius Chance 1.0.3-6.fc7 - Fixed with RHEL5 clone bug #201284: XIM hangs when switching Input Context. - Patch file is created by Soeren Sandmann Pedersen (sandmann at redhat.com). * Fri Oct 13 2006 Kristian H??gsberg 1.0.3-5.fc7 - Add pkgconfig dependency for -devel package. mc-1:4.6.1a-34.fc7 ------------------ * Thu Nov 02 2006 Jindrich Novy 4.6.1a-34 - fix #214255 - sh vfs disconnects with special character in filename - drop fish-upload patch, applied upstream * Tue Oct 31 2006 Jindrich Novy 4.6.1a-33 - display also conflicts in addition to provides/obsoletes/requires while browsing RPM vfs * Fri Oct 27 2006 Jindrich Novy 4.6.1a-32 - update to new CVS snapshot - fix IPv6 FISH support - use better UTF-8 characters for scrollbars nautilus-2.16.2-4.fc7 --------------------- * Wed Nov 08 2006 Alexander Larsson - 2.16.2-4.fc7 - Revert upstream icon placement patch as it seems broken * Tue Nov 07 2006 Alexander Larsson - 2.16.2-2.fc7 - Update to 2.16.2 * Sat Oct 21 2006 Matthias Clasen - 2.16.1-1 - Update to 2.16.1 ncpfs-2.2.6-6 ------------- * Thu Nov 09 2006 Miloslav Trmac - 2.2.6-6 - Add missing #include to fix build - Remove unnecessary ncpfs-2.2.3-array.patch, the overflow was fixed in ncpfs-2.2.4. Note that this changes the libncp ABI. - Clean up %install, manually list %files - Drop libncp.a - Fix some rpmlint warnings openoffice.org-1:2.1.0-2.1 -------------------------- * Tue Nov 07 2006 Caolan McNamara - 1:2.1.0-2.1 - next upstream - drop upstreamed openoffice.org-2.0.3.ooo67976.svx.macroscrash.patch - drop upstreamed openoffice.org-2.0.3.ooo68018.svx.classpathdialog.patch - drop upstreamed openoffice.org-2.0.4.ooo70601.sd.sal_uInt32_aslong.patch - drop upstreamed openoffice.org-2.1.0.ooo71111.sfx2.x86_64.patch - drop upstreamed workspace.gtkquickstart2.patch selinux-policy-2.4.3-6 ---------------------- * Wed Nov 08 2006 Dan Walsh 2.4.3-6 - Fix unconfined access to shadow file * Wed Nov 08 2006 Dan Walsh 2.4.3-5 - Allow xend to create files in xen_image_t directories * Wed Nov 08 2006 Dan Walsh 2.4.3-4 - Fixes for /var/lib/hal setroubleshoot-1.5-1.fc7 ------------------------ * Wed Nov 08 2006 Dan Walsh - 1.5-1 - Speed up startup of service * Mon Nov 06 2006 Dan Walsh - 1.4-1 - Many fixes - Changed the api * Tue Oct 24 2006 Dan Walsh - 1.3-1 - Speed enhancments - John Dennis * log file parsing now approx 4 times faster * greatly enhance the statistics reporting capability in attempt to diagnose slow log file parsing performance * make gathering of environmenatal information optional, environment information is only relevant at the time the alert fires, not in a post processing scenario * clean up several places where environmental information was assumed and/or was always gathered, or gathered in the wrong place. subversion-1.4.2-3 ------------------ * Wed Nov 08 2006 Joe Orton 1.4.2-3 - update to 1.4.2 * Mon Sep 11 2006 Joe Orton 1.4.0-2 - update to 1.4.0 sysstat-7.0.2-1.fc7 ------------------- * Wed Nov 08 2006 Ivana Varekova - 7.0.2-1 - update to 7.0.2 system-config-kickstart-2.6.17-1.fc7 ------------------------------------ * Wed Nov 08 2006 Chris Lumens 2.6.17-1 - Fix traceback when looking for the base Fedora repo (#190999). texinfo-4.8-14.fc7 ------------------ * Sun Nov 05 2006 Miloslav Trmac - 4.8-14 - Remove off-line sorting from texindex (fixes CVE 2006-4810) valgrind-1:3.2.1-7 ------------------ * Wed Nov 08 2006 Jakub Jelinek 3.2.1-7 - some cachegrind improvements (Ulrich Drepper) Broken deps for ia64 ---------------------------------------------------------- python-pyblock - 0.24-2.ia64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.ia64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for i386 ---------------------------------------------------------- python-pyblock - 0.24-2.i386 requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.i386 requires libdmraid.so.1.0.0.rc13 Broken deps for ppc64 ---------------------------------------------------------- python-pyblock - 0.24-2.ppc64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.ppc64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for s390x ---------------------------------------------------------- python-pyblock - 0.24-2.s390x requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.s390x requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for s390 ---------------------------------------------------------- python-pyblock - 0.24-2.s390 requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.s390 requires libdmraid.so.1.0.0.rc13 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- python-pyblock - 0.24-2.x86_64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.x86_64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for ppc ---------------------------------------------------------- python-pyblock - 0.24-2.ppc requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.ppc requires libdmraid.so.1.0.0.rc13 From d.lesca at solinos.it Thu Nov 9 10:55:58 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 09 Nov 2006 11:55:58 +0100 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611082038.25862.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> Message-ID: <1163069759.3279.74.camel@lesca.home.solinos.it> Il giorno mer, 08/11/2006 alle 20.38 -0500, Jesse Keating ha scritto: > > Enjoy! > I have test the utilities but I get this error: > [lesca at lesca work]$ sudo rpm -ivh pungi-0.1.0-1.fc6.noarch.rpm > Password: > Preparing... ########################################### [100%] > 1:pungi ########################################### [100%] > [lesca at lesca work]$ pungi > Traceback (most recent call last): > File "/usr/bin/pungi", line 100, in ? > main() > File "/usr/bin/pungi", line 24, in main > pkglist = get_packagelist(opts.comps) > File "/usr/bin/pungi", line 92, in get_packagelist > print >> sys.stderr, "pungi: No such file:\'%s\'" % opts.comps > NameError: global name 'opts' is not defined > [lesca at lesca work]$ cat /etc/issue > Fedora Core release 5 (Bordeaux) > Kernel \r on an \m > What's wrong? Many thanks -- Dario Lesca From ndbecker2 at gmail.com Thu Nov 9 11:29:50 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Nov 2006 06:29:50 -0500 Subject: Announcing pungi-0.1.0 References: <200611082038.25862.jkeating@redhat.com> Message-ID: Tried the test. Just went round in circles saying "finding deps for ..." or some words to that effect. I let it run overnight. Never got out of that loop. From david at lovesunix.net Thu Nov 9 11:53:06 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 09 Nov 2006 12:53:06 +0100 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611082038.25862.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> Message-ID: <1163073186.3123.41.camel@price> ons, 08 11 2006 kl. 20:38 -0500, skrev Jesse Keating: > I am pleased (and scared) to announce the 0.1.0 release of pungi. This is the > first release and thus it is a bit rough around the edges, but I firmly > believe in release early release often. > > With this release pungi has the ability to gather packages and their deps from > a given repo or set of repos, run anaconda tools to make installable trees, > and create CD and DVD isos (DVD only if you ask for more than one CD). I > have included some reference config files and a comps file I have been using > to develop with. Currently pungi needs to be ran on the architecture you are > composing for, although one could use mock with setarch as well. See README > for more details on design and usage of pungi. > > To download pungi, visit http://linux.duke.edu/projects/pungi/release/ and > pick up either the tarball, the source rpm, or the Fedora Core 6 binary rpm. > Mercurial repo is http://linux.duke.edu/projects/pungi Discussion regarding > the use or development of pungi happens on the fedora-buildsys-list mailing > list: http://www.redhat.com/mailman/listinfo/fedora-buildsys-list Currently > bugs are not tracked anywhere other than my inbox, I will most likely rectify > this situation soon, but for now email works. > > Enjoy! Can one assume you will submit pungi for Extras? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jamatos at fc.up.pt Thu Nov 9 12:16:56 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 9 Nov 2006 12:16:56 +0000 Subject: Announcing pungi-0.1.0 In-Reply-To: <1163073186.3123.41.camel@price> References: <200611082038.25862.jkeating@redhat.com> <1163073186.3123.41.camel@price> Message-ID: <200611091216.57092.jamatos@fc.up.pt> On Thursday 09 November 2006 11:53 am, David Nielsen wrote: > Can one assume you will submit pungi for Extras? It is there already, and it was approved today: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214730 > - David -- Jos? Ab?lio From buc at odusz.so-cdu.ru Thu Nov 9 13:00:47 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 09 Nov 2006 16:00:47 +0300 Subject: I think, rsh is quite obsolete In-Reply-To: <1162983051.4459.6.camel@numenor> References: <1162983051.4459.6.camel@numenor> Message-ID: <4553267F.3090205@odu.neva.ru> Adam Tkac wrote: >I think, It's no argument to include rsh in next versions of fc/rhel. >OpenSSH could successfully substitute this component. SSH is more secure >than rsh and has all features of rsh. Do you think anything else?? > > The "krb5-workstation" package has rsh with kerberos support. That way it is possible to provide secure auth and even traffic encryption (rsh -x). A lot of currently used UN*Xes have no ssh, but have rsh/rlogin and friends with kerberos support. Dmitry Butskoy From jkeating at redhat.com Thu Nov 9 13:24:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 08:24:46 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: References: <200611082038.25862.jkeating@redhat.com> Message-ID: <200611090824.49538.jkeating@redhat.com> On Thursday 09 November 2006 06:29, Neal Becker wrote: > Tried the test. Just went round in circles saying "finding deps for ..." > or some words to that effect. I let it run overnight. Never got out of > that loop. What arch did you run it on, and did you change the comps file at all? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 13:25:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 08:25:47 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <1163069759.3279.74.camel@lesca.home.solinos.it> References: <200611082038.25862.jkeating@redhat.com> <1163069759.3279.74.camel@lesca.home.solinos.it> Message-ID: <200611090825.47570.jkeating@redhat.com> On Thursday 09 November 2006 05:55, Dario Lesca wrote: > What's wrong? pungi takes a lot of options to run, see the README file. Apparently I forgot to wire up a usage spew... (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 13:36:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 08:36:53 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611090824.49538.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> <200611090824.49538.jkeating@redhat.com> Message-ID: <200611090836.53753.jkeating@redhat.com> On Thursday 09 November 2006 08:24, Jesse Keating wrote: > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > Tried the test. ?Just went round in circles saying "finding deps for ..." > > or some words to that effect. ?I let it run overnight. ?Never got out of > > that loop. > > What arch did you run it on, and did you change the comps file at all? oh wait, I forgot about this. There was/is a bug in yum that made package comparison not work quite right. It was fixed upstream and I thought we issued an update for FC6 that would resolve this. Seth? Jeremy? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Nov 9 13:51:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 09 Nov 2006 08:51:58 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611090836.53753.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> <200611090824.49538.jkeating@redhat.com> <200611090836.53753.jkeating@redhat.com> Message-ID: <1163080318.13997.0.camel@cutter> On Thu, 2006-11-09 at 08:36 -0500, Jesse Keating wrote: > On Thursday 09 November 2006 08:24, Jesse Keating wrote: > > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > > Tried the test. Just went round in circles saying "finding deps for ..." > > > or some words to that effect. I let it run overnight. Never got out of > > > that loop. > > > > What arch did you run it on, and did you change the comps file at all? > > oh wait, I forgot about this. There was/is a bug in yum that made package > comparison not work quite right. It was fixed upstream and I thought we > issued an update for FC6 that would resolve this. 1. it was in 3.0-6 2. it's included in the yum 3.0.1 release tarball. -sv From jkeating at redhat.com Thu Nov 9 14:00:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 09:00:54 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <1163080318.13997.0.camel@cutter> References: <200611082038.25862.jkeating@redhat.com> <200611090836.53753.jkeating@redhat.com> <1163080318.13997.0.camel@cutter> Message-ID: <200611090900.55086.jkeating@redhat.com> On Thursday 09 November 2006 08:51, seth vidal wrote: > 1. it was in 3.0-6 Actually I just verified that it missed 3.0-6. My test box had yum patched locally :/ > 2. it's included in the yum 3.0.1 release tarball. I'm asking our yum maintainer(s) to issue an update for FC-6 so that this will work correctly. It should work in rawhide too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lsomike at futzin.com Thu Nov 9 14:18:50 2006 From: lsomike at futzin.com (Mike Klinke) Date: Thu, 9 Nov 2006 08:18:50 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109015324.GB805@redhat.com> References: <1162983051.4459.6.camel@numenor> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> Message-ID: <200611090818.50513.lsomike@futzin.com> On Wednesday 08 November 2006 19:53, Dave Jones wrote: > But for Fedora, I can't think of a valid reason why someone would > want to enable a telnetd given the security concerns of non > encrypted sessions. Small embedded systems use telnet servers and clients because of the low overhead. Look at the Dallas Semi-conductor's TINI for an example. It is quite handy to be able to telnet to a PC hosting telnetd from one of these devices. Regards, Mike Klinke From katzj at redhat.com Thu Nov 9 14:31:32 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Nov 2006 09:31:32 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <1163055311.19039.14.camel@localhost.localdomain> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> <1163043527.19271.4.camel@aglarond.local> <1163055311.19039.14.camel@localhost.localdomain> Message-ID: <1163082692.22973.3.camel@aglarond.local> On Thu, 2006-11-09 at 07:55 +0100, Erik van Pienbroek wrote: > Op woensdag 08-11-2006 om 22:38 uur [tijdzone -0500], schreef Jeremy > Katz: > > It's not just the location, but there also aren't guarantees around API > > or ABI stability when using firefox/mozilla as an embedding engine. > > That this is a issue for new releases I can understand, but is the > API/ABI even unstable for patch releases? (1.5.0.7 -> 1.5.0.8) That's my understanding. Jeremy From michel.salim at gmail.com Thu Nov 9 14:34:22 2006 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 9 Nov 2006 09:34:22 -0500 Subject: yum module idea: force-install high-priority updates In-Reply-To: <20061109105812.3a8954e4.fedora@wir-sind-cool.org> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> <883cfe6d0611081659i2d634cdfifd9b42c79c703e1e@mail.gmail.com> <20061109105812.3a8954e4.fedora@wir-sind-cool.org> Message-ID: <883cfe6d0611090634k47da2a4y1ecaecacf6ee1eeb@mail.gmail.com> On 11/9/06, Michael Schwendt wrote: > On Wed, 8 Nov 2006 19:59:10 -0500, Michel Salim wrote: > > > > Op donderdag 09-11-2006 om 08:36 uur [tijdzone +0900], schreef Naoki: > > > > In this specific case I'd be wondering why liferea needs a very specific > > > > version of firefox. I just checked the app in question and it states a > > > > requirement of : > > > > firefox = 1.5.0.7 > > > > > > I'm not familiar with liferea, but I am a developer of a application > > > which uses GtkEmbedMoz, an GTK firefox embedding widget and I think > > > liferea is in the same situation as I am. > > > > > > The problem is that each version of Mozilla/Firefox uses a > > > different installation prefix. For Firefox 1.5.0.7 this > > > is /usr/lib/firefox-1.5.0.7 > > > > > > When a application links with some Mozilla/Firefox library > > > the full path gets saved in the final executable. > > > > > In case of liferea, the dependency is not actually that hard-coded. > > It is, it is. > > This has been the result of discussion in an upstream bug ticket. > > > liferea uses LD_LIBRARY_PATH to add Firefox's installation directory > > before calling the actual liferea-bin binary. This path is detected at > > build time and hardcoded into the script. > > It used to be like this, but has been error-prone (leading to > crashes, even) and has changed to a really hardcoded path in the > binary. > My mystake, then. The ones in Extras still use the script, and ldd-ing the actual binary did not show a dependency on Firefox. -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From fedora at wir-sind-cool.org Thu Nov 9 14:44:48 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Nov 2006 15:44:48 +0100 Subject: yum module idea: force-install high-priority updates In-Reply-To: <883cfe6d0611090634k47da2a4y1ecaecacf6ee1eeb@mail.gmail.com> References: <883cfe6d0611081241l7a4c941ci6752f82984b965d0@mail.gmail.com> <455269E2.9050205@valuecommerce.com> <1163030437.19039.10.camel@localhost.localdomain> <883cfe6d0611081659i2d634cdfifd9b42c79c703e1e@mail.gmail.com> <20061109105812.3a8954e4.fedora@wir-sind-cool.org> <883cfe6d0611090634k47da2a4y1ecaecacf6ee1eeb@mail.gmail.com> Message-ID: <20061109154448.31ea4d6a.fedora@wir-sind-cool.org> On Thu, 9 Nov 2006 09:34:22 -0500, Michel Salim wrote: > > > > The problem is that each version of Mozilla/Firefox uses a > > > > different installation prefix. For Firefox 1.5.0.7 this > > > > is /usr/lib/firefox-1.5.0.7 > > > > > > > > When a application links with some Mozilla/Firefox library > > > > the full path gets saved in the final executable. > > > > > > > In case of liferea, the dependency is not actually that hard-coded. > > > > It is, it is. > > > > This has been the result of discussion in an upstream bug ticket. > > > > > liferea uses LD_LIBRARY_PATH to add Firefox's installation directory > > > before calling the actual liferea-bin binary. This path is detected at > > > build time and hardcoded into the script. > > > > It used to be like this, but has been error-prone (leading to > > crashes, even) and has changed to a really hardcoded path in the > > binary. > > > My mystake, then. The ones in Extras still use the script, and ldd-ing > the actual binary did not show a dependency on Firefox. $ strings /usr/lib/liferea/liblihtmlm.so |grep fire /usr/lib/firefox-1.5.0.7 From cmadams at hiwaay.net Thu Nov 9 15:03:40 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 9 Nov 2006 09:03:40 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <5256d0b0611082344t71e1f642o20a4c166e69dbc99@mail.gmail.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <5256d0b0611082344t71e1f642o20a4c166e69dbc99@mail.gmail.com> Message-ID: <20061109150340.GB1168161@hiwaay.net> Once upon a time, Peter Robinson said: > Telnet client is invaluable, server maybe not so much. Legacy Cisco > equipment and other networking gear makes some of the stuff useful but > when it comes to it none of it is enabled by default and its not like > they take up tens of megabytes on the installer CDs. Also, for both telnet and rsh, the client and server come from the same source tarball/SRPM. The telnet-server RPM is 36K and the rsh-server RPM is 40K; what are you trying to save by dropping them? Packaging either server for Extras would just take the same SRPM and build only the server and not the client (while Core would use the same SRPM and build only the client). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From selinux at gmail.com Thu Nov 9 15:05:25 2006 From: selinux at gmail.com (Tom London) Date: Thu, 9 Nov 2006 07:05:25 -0800 Subject: rawhide report: 20061109 changes In-Reply-To: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530611090705o6dbf72c2w4f0c6ad8607e0fb6@mail.gmail.com> On 11/9/06, buildsys at redhat.com wrote: > > gdm-1:2.17.2-1.fc7 > ------------------ > * Tue Nov 07 2006 Matthias Clasen - 1:2.17.2-1 > - Update to 2.17.2 > This update 'saved' my /etc/pam.d/gdm in /etc/pam.d/gdm.rpmsave, but failed to create a new /etc/pam.d/gdm. This made gdmgreeter very unhappy. Copying it back appears to 'make it work again'. tom -- Tom London From buc at odusz.so-cdu.ru Thu Nov 9 15:10:04 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 09 Nov 2006 18:10:04 +0300 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109150340.GB1168161@hiwaay.net> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <5256d0b0611082344t71e1f642o20a4c166e69dbc99@mail.gmail.com> <20061109150340.GB1168161@hiwaay.net> Message-ID: <455344CC.2030006@odu.neva.ru> Chris Adams wrote: >Also, for both telnet and rsh, the client and server come from the same >source tarball/SRPM. The telnet-server RPM is 36K and the rsh-server >RPM is 40K; what are you trying to save by dropping them? > decreasing the amount of the responsibility? ;) ~buc From kloczek at zie.pg.gda.pl Thu Nov 9 18:30:39 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 09 Nov 2006 19:30:39 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> Message-ID: <1163097039.5920.32.camel@kloczek01.pracownicy.zie> Dnia 09-11-2006, czw o godzinie 05:52 -0500, buildsys at redhat.com napisa?(a): [..] > control-center-1:2.17.1-3.fc7 > ----------------------------- > * Wed Nov 08 2006 Matthias Clasen - 2.17.1-3 > - Work around a file conflict with libgnomekbd (#214608) Still in %post, %postun, %preun is registered/unregistered desktop_gnome_peripherals_keyboard_xkb.schemas. BTW introducing new schema for register/unregister schema files. IMO new schema is to complicated and still not guarantee produce always correct schamas database. Current template looks: %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule \ %pre if [ "$1" -gt 1 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule \ fi %postun if [ "$1" -eq 0 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule \ fi In case not registering in previous release some packages some new schemas this still do not prevent fixing this kind bugs. Probably better will be regenerate each time schemas database. IMO better/simpler schema for registered/unregistered can look only like: %post GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ gconftool-2 --makefile-install-rule \ /etc/gconf/schemas/*.schemas >& /dev/null %postun GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ gconftool-2 --makefile-install-rule \ /etc/gconf/schemas/*.schemas >& /dev/null Yes .. regenerate schemas database takes longer time but will guarantee schamas database correct content. kloczek From fedora at wir-sind-cool.org Thu Nov 9 19:14:44 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Nov 2006 20:14:44 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <1163097039.5920.32.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> Message-ID: <20061109201444.d2a2b907.fedora@wir-sind-cool.org> On Thu, 09 Nov 2006 19:30:39 +0100, Tomasz K?oczko wrote: > Dnia 09-11-2006, czw o godzinie 05:52 -0500, buildsys at redhat.com > napisa?(a): > [..] > > control-center-1:2.17.1-3.fc7 > > ----------------------------- > > * Wed Nov 08 2006 Matthias Clasen - 2.17.1-3 > > - Work around a file conflict with libgnomekbd (#214608) > > Still in %post, %postun, %preun is registered/unregistered > desktop_gnome_peripherals_keyboard_xkb.schemas. > > BTW introducing new schema for register/unregister schema files. > IMO new schema is to complicated and still not guarantee produce always > correct schamas database. Current template looks: > > %post > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > gconftool-2 --makefile-install-rule \ > > > %pre > if [ "$1" -gt 1 ]; then > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > gconftool-2 --makefile-install-rule \ > > fi > > %postun > if [ "$1" -eq 0 ]; then > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > gconftool-2 --makefile-install-rule \ > > fi > > In case not registering in previous release some packages some new > schemas this still do not prevent fixing this kind bugs. > Probably better will be regenerate each time schemas database. > IMO better/simpler schema for registered/unregistered can look only > like: > > %post > GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ > gconftool-2 --makefile-install-rule \ > /etc/gconf/schemas/*.schemas >& /dev/null > > %postun > GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ > gconftool-2 --makefile-install-rule \ > /etc/gconf/schemas/*.schemas >& /dev/null > > Yes .. regenerate schemas database takes longer time but will guarantee > schamas database correct content. > > kloczek Where's --makefile-uninstall-rule with your system? From kloczek at zie.pg.gda.pl Thu Nov 9 19:44:25 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 09 Nov 2006 20:44:25 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <20061109201444.d2a2b907.fedora@wir-sind-cool.org> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> Message-ID: <1163101465.5920.38.camel@kloczek01.pracownicy.zie> Dnia 09-11-2006, czw o godzinie 20:14 +0100, Michael Schwendt napisa?(a): [..] > > %postun > > GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ > > gconftool-2 --makefile-install-rule \ > > /etc/gconf/schemas/*.schemas >& /dev/null > > > > Yes .. regenerate schemas database takes longer time but will > guarantee > > schamas database correct content. > > > > kloczek > > Where's --makefile-uninstall-rule with your system? Corrected %postun example: %postun export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` rm -f $GCONF_CONFIG_SOURCE/* gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas >& /dev/null Probably better will be have handle regenerate schemas database directly as gconftool-2 switch. kloczek From kloczek at zie.pg.gda.pl Thu Nov 9 20:12:40 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 09 Nov 2006 21:12:40 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <1163101465.5920.38.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> Message-ID: <1163103160.5920.49.camel@kloczek01.pracownicy.zie> Dnia 09-11-2006, czw o godzinie 20:44 +0100, Tomasz K?oczko napisa?(a): [..] > %postun > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > rm -f $GCONF_CONFIG_SOURCE/* > gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas > >& /dev/null After run above from hand as next I'm run (just for exercise/check): # gconftool-2 --makefile-uninstall-rule /etc/gconf/schemas/*.schemas >& /dev/null It do not produces xml files with empty trees in $GCONF_CONFIG_SOURCE directory. Is it correct ? (IMO not) Probably --makefile-{,un}install-rule switches are not fully symmetric. kloczek From selinux at gmail.com Thu Nov 9 20:36:32 2006 From: selinux at gmail.com (Tom London) Date: Thu, 9 Nov 2006 12:36:32 -0800 Subject: rawhide report: 20061109 changes In-Reply-To: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530611091236t7efe6266t2711cb4cd7d6f181@mail.gmail.com> On 11/9/06, buildsys at redhat.com wrote: > setroubleshoot-1.5-1.fc7 > ------------------------ > * Wed Nov 08 2006 Dan Walsh - 1.5-1 > - Speed up startup of service > Wow..... now takes ~1 second vs 8-10 seconds! tom -- Tom London From sdl.web at gmail.com Thu Nov 9 21:02:46 2006 From: sdl.web at gmail.com (Leo) Date: Thu, 09 Nov 2006 21:02:46 +0000 Subject: Move from TeTeX to TeXLive Message-ID: Hi there, The TeTeX project had this announcement in May this year which was in the beginning of FC6 cycle: ,---- | I (Thomas Esser) have decided not to make new releases of teTeX any | more (May 2006). The information below might get out of date as time | goes by. I suggest anybody interested in teTeX to join the TeX Live | project. `---- Now it is the beginning of FC7, I would suggest Fedora core 7 move to texlive. Here is how debian packages texlive: http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} Thanks, -- Leo From fedora at wir-sind-cool.org Thu Nov 9 21:20:34 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Nov 2006 22:20:34 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <1163103160.5920.49.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> <1163103160.5920.49.camel@kloczek01.pracownicy.zie> Message-ID: <20061109222034.4663f015.fedora@wir-sind-cool.org> On Thu, 09 Nov 2006 21:12:40 +0100, Tomasz K?oczko wrote: > Dnia 09-11-2006, czw o godzinie 20:44 +0100, Tomasz K?oczko napisa?(a): > [..] > > %postun > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > rm -f $GCONF_CONFIG_SOURCE/* > > gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas > > >& /dev/null > > After run above from hand as next I'm run (just for exercise/check): > > # gconftool-2 --makefile-uninstall-rule /etc/gconf/schemas/*.schemas > >& /dev/null > > It do not produces xml files with empty trees in $GCONF_CONFIG_SOURCE > directory. Is it correct ? (IMO not) > Probably --makefile-{,un}install-rule switches are not fully symmetric. They are. Still I'm confused as what you try to accomplish. If your %postun does not evaluate $1 properly, your old package's %postun script is executed last and reverts changes your new package needs. The following page covers this, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets and also suggests a work-around for package upgrades where you want to remove old schema files, which are obsolete. From kloczek at zie.pg.gda.pl Thu Nov 9 21:48:01 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 09 Nov 2006 22:48:01 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <20061109222034.4663f015.fedora@wir-sind-cool.org> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> <1163103160.5920.49.camel@kloczek01.pracownicy.zie> <20061109222034.4663f015.fedora@wir-sind-cool.org> Message-ID: <1163108881.5920.62.camel@kloczek01.pracownicy.zie> Dnia 09-11-2006, czw o godzinie 22:20 +0100, Michael Schwendt napisa?(a): [..] > > It do not produces xml files with empty trees in $GCONF_CONFIG_SOURCE > > directory. Is it correct ? (IMO not) > > Probably --makefile-{,un}install-rule switches are not fully symmetric. > > They are. So what are doing all not removed keys from this xml files ? Example from my /etc/gconf/gconf.xml.defaults/%%gconf-tree-af.xml: Indien waar, sal Nautilus jou toelaat om van die meer esoteriese l? eropsies van 'n l?er in die l?ervoorkeurdiaaloog laat verander. Helderheid-op se kortpad. Helderheid-af se kortpad. > Still I'm confused as what you try to accomplish. If your %postun does not > evaluate $1 properly, your old package's %postun script is executed last > and reverts changes your new package needs. > > The following page covers this, > > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets > > and also suggests a work-around for package upgrades where you want > to remove old schema files, which are obsolete. install upgrade uninstall %pre $1 == 1 $1 == 2 -- %post $1 == 1 $1 == 2 -- %preun -- $1 == 1 $1 == 0 %postun -- $1 == 1 $1 == 0 If you want replace register/unregister subset schemas by reinstall all files you need hook only in %post and %postun .. *unconditionaly*. No matter is it first install, upgrade or uninstall. BTW. I have small modification %post/%postun script template: if [ -x %{_bindir}/gconftool-2 ]; then export GCONF_CONFIG_SOURCE=`%{_bindir}/gconftool-2 --get-default-source` rm -f $GCONF_CONFIG_SOURCE/* %{_bindir}/gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas >& /dev/null fi It will allow remove all "Requires(post,postun): GConf", "Prereq: GConf" or Requires(post,postun): /usr/bin/gconftool-2 rules. kloczek From a.badger at gmail.com Thu Nov 9 22:13:44 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 09 Nov 2006 14:13:44 -0800 Subject: rawhide report: 20061109 changes In-Reply-To: <1163101465.5920.38.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> Message-ID: <1163110424.2914.10.camel@localhost> On Thu, 2006-11-09 at 20:44 +0100, Tomasz K?oczko wrote: > Corrected %postun example: > > %postun > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > rm -f $GCONF_CONFIG_SOURCE/* > gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas > >& /dev/null > %postun is the wrong scriptlet to run this in. Once you get to %postun, the original schema file is no longer present. (For an upgrade, this has to be done in %pre (Because the upgrading package will overwrite the old schema), for a removal in %preun (Because there won't be an install at that point to trigger the %pre scriptlet)) -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 a.badger at gmail.com Thu Nov 9 22:37:47 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 09 Nov 2006 14:37:47 -0800 Subject: rawhide report: 20061109 changes In-Reply-To: <1163108881.5920.62.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> <1163103160.5920.49.camel@kloczek01.pracownicy.zie> <20061109222034.4663f015.fedora@wir-sind-cool.org> <1163108881.5920.62.camel@kloczek01.pracownicy.zie> Message-ID: <1163111867.2914.25.camel@localhost> On Thu, 2006-11-09 at 22:48 +0100, Tomasz K?oczko wrote: > BTW. I have small modification %post/%postun script template: > > if [ -x %{_bindir}/gconftool-2 ]; then > export GCONF_CONFIG_SOURCE=`%{_bindir}/gconftool-2 --get-default-source` > rm -f $GCONF_CONFIG_SOURCE/* > %{_bindir}/gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas >& /dev/null > fi > > It will allow remove all "Requires(post,postun): GConf", "Prereq: GConf" > or Requires(post,postun): /usr/bin/gconftool-2 rules. For the general case of making a Requires(post) optional you need to make sure that the package that you are making optional invokes its update program when it installs. For instance: Use this when a package drops an XML file in %{_datadir}/mime/packages. %post update-mime-database %{_datadir}/mime &> /dev/null || : $ rpm -q --scripts shared-mime-info postinstall scriptlet (using /bin/sh): /usr/bin/update-mime-database /usr/share/mime &> /dev/null For the specific case of gconf schemas, you don't gain much by making this optional. The program itself depends on GConf2 so you have to pull it in for the program whether or not the scriptlet depends on it. This in contrast to gtk-update-icon-cache for kde apps and update-mime-database where the program can run fine without installing gtk2 or shared-mime-info. -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 jnovy at redhat.com Fri Nov 10 08:16:15 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 10 Nov 2006 09:16:15 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: References: Message-ID: <1163146575.2609.7.camel@redhat.usu> Hi Leo, On Thu, 2006-11-09 at 21:02 +0000, Leo wrote: > The TeTeX project had this announcement in May this year which was in > the beginning of FC6 cycle: > > ,---- > | I (Thomas Esser) have decided not to make new releases of teTeX any > | more (May 2006). The information below might get out of date as time > | goes by. I suggest anybody interested in teTeX to join the TeX Live > | project. > `---- > > Now it is the beginning of FC7, I would suggest Fedora core 7 move to > texlive. Here is how debian packages texlive: The conversion to TeX Live is definitely decided. I'm currently discussing the future shape of it with TeX Live upstream which variant will be most suitable for FC7. > http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} Thanks for the link, I'll have a look. Jindrich From jochen.schlick at comsoft.de Fri Nov 10 08:24:18 2006 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Fri, 10 Nov 2006 09:24:18 +0100 Subject: seamonkey crashes everytime on startup Message-ID: <45543732.8000208@comsoft.de> Hi everyone, this is the output of different versions of seamonkey (various nightly builds, the new beta version...) since 9/Nov/2006. ... Gecko: CRITICAL **:AT_SPI_was not started at session startup Gecko: WARNING **:IOR not set ** ERROR **: Could not locate registry aborting I'm not a gecko/seamonkey/mozilla expert but I noticed that there were some gnome updates in rwahide during the last few days. I send this message from a seamonkey (nightly build) on FC5 pc. And this seamonkey version is one of the versions that crash since yesterday on current rawhide. best regards Jochen From ellson at research.att.com Fri Nov 10 10:22:47 2006 From: ellson at research.att.com (John Ellson) Date: Fri, 10 Nov 2006 05:22:47 -0500 Subject: seamonkey crashes everytime on startup In-Reply-To: <45543732.8000208@comsoft.de> References: <45543732.8000208@comsoft.de> Message-ID: <455452F7.6020801@research.att.com> Jochen Schlick wrote: > Hi everyone, > > this is the output of different versions of seamonkey (various nightly > builds, > the new beta version...) since 9/Nov/2006. > > ... > Gecko: CRITICAL **:AT_SPI_was not started at session startup > Gecko: WARNING **:IOR not set > > ** ERROR **: Could not locate registry > aborting > > > I'm not a gecko/seamonkey/mozilla expert but I noticed that there were > some gnome > updates in rwahide during the last few days. I send this message from > a seamonkey > (nightly build) on FC5 pc. And this seamonkey version is one of the > versions that > crash since yesterday on current rawhide. > > > > best regards > Jochen > > This sounds like it might be the same problem as I've been seeing with thunderbird, caused by something in the latest at-spi upgrade. Reported in bug#214696 John From buildsys at redhat.com Fri Nov 10 10:36:24 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 10 Nov 2006 05:36:24 -0500 Subject: rawhide report: 20061110 changes Message-ID: <200611101036.kAAAaOAs020675@hs20-bc2-6.build.redhat.com> Updated Packages: autoconf-2.60-4 --------------- * Thu Nov 09 2006 Karsten Hopp 2.60-4 - autoconf-2.60 binutils-2.17.50.0.6-3 ---------------------- * Thu Nov 09 2006 Jakub Jelinek 2.17.50.0.6-3 - fix popcnt instruction assembly and disassembly on amd64 (#214767) eclipse-1:3.2.1-17.fc7 ---------------------- * Thu Nov 09 2006 Ben Konrath 3.2.1-17 - Add file level requirement for swt fragment to rcp and platform packages. This is needed so that the rcp and platform packages pull in the swt package of the correct word size. * Mon Nov 06 2006 Ben Konrath 3.2.1-16 - Move copy-platform back to %{_datadir}/eclipse. - Require gjdoc >= 0.7.7-14 as it generates consistent html across archs. - Move most of the doc plugins back to %{_datatdir}/eclipse now that gjdoc is fixed. * Fri Nov 03 2006 Andrew Overholt 3.2.1-15 - Make sdk require config.ini itself rather than the package to deal with the bi-arch installation situation. - Move sdk feature and plugin to %{_libdir} so we can check for its existence in the post scripts. evolution-data-server-1.9.2-3.fc7 --------------------------------- * Fri Nov 10 2006 Matthew Barnes - 1.9.2-3.fc7 - Add patch for RH bug #210142 (calendar crash in indic locales). gdb-6.5-15.fc7 -------------- * Thu Nov 09 2006 Jan Kratochvil - 6.5-15 - Fix readline segfault on excessively long hand-typed lines. * Thu Nov 02 2006 Jan Kratochvil - 6.5-14 - Fix "??" resolving of symbols from (non-prelinked) debuginfo packages. - Fix "??" resolving of symbols from overlapping functions (nanosleep(3)). - Also disable testcase "checkpoint.exp" for a possible kernel Bug 207002. - Provided (disabled during build) threading testsuite from BEA. * Sat Oct 14 2006 Jan Kratochvil - 6.5-13 - Fix deadlock accessing last address space byte; for corrupted backtraces. glibc-2.5.90-5 -------------- * Thu Nov 09 2006 Jakub Jelinek 2.5.90-5 - fix sysconf (_SC_LEVEL{2,3}_CACHE_SIZE) on Intel Core Duo CPUs - fix libthread_db.so on TLS_DTV_AT_TP architectures - fix --inhibit-rpath (#214569) - fix _r_debug content when prelinked ld.so executes a program as its argument - fix strxfrm - powerpc-cpu add-on updates hal-cups-utils-0.6.2-7 ---------------------- * Thu Nov 09 2006 Tim Waugh - 0.6.2-7 - IEEE 1284 Device ID in CUPS backend (bug #214755). libgsf-1.14.3-1 --------------- * Thu Nov 09 2006 Caolan McNamara 1.14.3-1 - bump to 1.14.3 * Wed Nov 01 2006 Dan Williams - 1.14.2-2 - Split to remove gnome-vfs2 dependency on core sub-packages m17n-db-1.3.3-36.fc7 -------------------- * Thu Nov 09 2006 Mayank Jain - Fixed an errounous fix of ZWNJ to hi-inscript/phonetic mdadm-2.5.4-3.fc7 ----------------- * Thu Nov 09 2006 Doug Ledford - 2.5.4-3 - Add a fix for the broken printout of array GUID when using the -E --brief flags * Fri Oct 13 2006 Doug Ledford - 2.5.4-2 - tag present on another branch and can't be forcibly moved required number bump mikmod-3.1.6-39.fc7 ------------------- * Thu Nov 09 2006 Martin Stransky - 3.1.6-39 - removed obsoletes on tracker (#214112) mysql-5.0.27-1.fc7 ------------------ * Thu Nov 09 2006 Tom Lane 5.0.27-1 - Update to MySQL 5.0.27 (see CVE-2006-4031, CVE-2006-4226, CVE-2006-4227) Resolves: #202247, #202675, #203427, #203428, #203432, #203434, #208641 - Fix init script to return status 1 on server start timeout Resolves: #203910 - Move mysqldumpslow from base package to mysql-server Resolves: #193559 - Adjust link options for BDB module Resolves: #199368 * Wed Jul 12 2006 Jesse Keating - 5.0.22-2.1 - rebuild * Sat Jun 10 2006 Tom Lane 5.0.22-2 - Work around brew's tendency not to clean up failed builds completely, by adding code in mysql-testing.patch to kill leftover mysql daemons. openoffice.org-1:2.1.0-2.2 -------------------------- * Tue Nov 07 2006 Caolan McNamara - 1:2.1.0-2.2 - Resolves: rhbz#213996 openoffice.org-2.1.0.ooo65491.psprint.enablenups.patch - Resolves: rhbz#213996 distinguish properly between ppd and cups option - Resolves: rhbz#213996 openoffice.org-2.1.0.ooo71379.psprint.endfeatureonnewline.patch - Resolves: rhbz#214773 openoffice.org-2.1.0.ooo61812.svx.a11ycrash.patch perl-DateManip-5.44-2.fc7 ------------------------- * Fri Nov 10 2006 Robin Norwood - 5.44-2 - Add support for KRAT and KRAST timezones - Include magic dist tag in release - Resolves: rhbz#214709 - Related: rhbz#100786 policycoreutils-1.32-3 ---------------------- * Thu Nov 09 2006 Dan Walsh 1.32-3 - No longer requires rhpl qt-1:3.3.7-1.fc7 ---------------- * Thu Nov 09 2006 Than Ngo 1:3.3.7-1.fc6 - update to 3.3.7 - fix #209097, ml_IN font rendering - fix #209970, pa font rendering - fix #209098, or_IN font rendering - fix #209972, as_IN font rendering - fix #209975, bn_IN font rendering - fix #211259, te_IN font rendering - fix #211436, as_IN font rendering thanks Sachin Tawniya, LingNing Zhang for the fixes - move html files to devel - add sqlite plugin - fix #189012, qt settings should be readable for other * Thu Aug 31 2006 Than Ngo 1:3.3.6-13 - add missing desktop files * Mon Jul 17 2006 Than Ngo 1:3.3.6-12 - rebuild s390utils-2:1.5.3-11 -------------------- * Tue Nov 07 2006 Phil Knirsch 2:1.5.3-11 - Make src_vipa.sh a proper SOURCE selinux-policy-2.4.3-8 ---------------------- * Thu Nov 09 2006 Dan Walsh 2.4.3-8 - Allow xen to search automount * Thu Nov 09 2006 Dan Walsh 2.4.3-7 - Fix spec of jre files tzdata-2006o-1.fc7 ------------------ * Thu Nov 09 2006 Petr Machata - 2006o-1 - Cuba has ended its three years of permanent DST. - Updates in historical timestamps for Chile. virt-manager-0.2.6-1.fc7 ------------------------ * Thu Nov 09 2006 Daniel P. Berrange - 0.2.6-1.fc7 - Imported translations from Fedora i18n repository - Make (most) scrollbar policies automatic - Set busy cursor while creating new VMs - Preference for controlling keygrab policy - Preference for when to automatically open console (bz 211385) - Re-try VNC connection attempt periodically in case VNC daemon hasn't finished starting up - Added activation of URLs for about dialog (bz 210782) - Improved error reporting when connecting to HV (bz 211229) - Add command line args to open specific windows - Don't skip para/full virt wizard step - instead gray out full virt option & tell user why - Change 'physical' to 'logical' when refering to host CPUs - Include hostname in titlebar - Disable wizard sensitivity while creating VM xorg-x11-server-1.1.1-50.fc7 ---------------------------- * Thu Nov 09 2006 Adam Jackson 1.1.1-50.fc7 - Fix man page globs to not care whether it's .1.gz or .1x.gz, etc. * Wed Nov 08 2006 Adam Jackson 1.1.1-49.fc7 - Switch to using the x86emu version of libint10 even on x86. Unifies behaviour among CPUs and works around Xen vm86 emulation bogosity. * Wed Nov 08 2006 Adam Jackson - Add FC7 todo list - Bump Release number back to 48, got reduced somehow. yaboot-1.3.13-3.fc7 ------------------- * Thu Nov 09 2006 Paul Nasrat - 1.3.13-3 - Apply addnote patch (#184714) Broken deps for i386 ---------------------------------------------------------- python-pyblock - 0.24-2.i386 requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.i386 requires libdmraid.so.1.0.0.rc13 Broken deps for ia64 ---------------------------------------------------------- python-pyblock - 0.24-2.ia64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.ia64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for x86_64 ---------------------------------------------------------- python-pyblock - 0.24-2.x86_64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.x86_64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for s390 ---------------------------------------------------------- python-pyblock - 0.24-2.s390 requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.s390 requires libdmraid.so.1.0.0.rc13 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- python-pyblock - 0.24-2.ppc64 requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.ppc64 requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for s390x ---------------------------------------------------------- python-pyblock - 0.24-2.s390x requires libdmraid.so.1.0.0.rc13(Base)(64bit) python-pyblock - 0.24-2.s390x requires libdmraid.so.1.0.0.rc13()(64bit) Broken deps for ppc ---------------------------------------------------------- python-pyblock - 0.24-2.ppc requires libdmraid.so.1.0.0.rc13(Base) python-pyblock - 0.24-2.ppc requires libdmraid.so.1.0.0.rc13 From ndbecker2 at gmail.com Fri Nov 10 12:13:30 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 10 Nov 2006 07:13:30 -0500 Subject: Proposal - replace beagle with tracker Message-ID: I don't know much about this subject, but I saw this thread on ubuntu. I, as many others, have seen problems with beagle. BTW, this ubuntu whiteboard is also very interesting. https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration https://launchpad.net/products/tracker --------------- Forwarded message (begin) Subject: Re: Beagle badness From: Johan Kiviniemi Date: Fri, 10 Nov 2006 03:46:24 -0500 Newsgroup: gmane.linux.ubuntu.devel On Thu, Nov 09, 2006 at 08:18:04PM -0500, Samuel Cormier-Iijima wrote: > There is a proposal to include Tracker by default: > https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration > I think this would fix most of the performance problems people are > having In addition to minimal resource usage, Meta Tracker has some very appealing features over Beagle, such as RDF searches and very flexible metadata storage (arbitrary tags or other metadata can be attached to files). The CVS version has evolved nicely since the last release. -- J?han Kiviniemi http://johan.kiviniemi.name/ --------------- Forwarded message (end) From rob at choralone.org Fri Nov 10 11:57:59 2006 From: rob at choralone.org (Rob Andrews) Date: Fri, 10 Nov 2006 11:57:59 +0000 Subject: wireless NICs, wpa In-Reply-To: <1163155515.17650.10.camel@fred.scooby.net> References: <1163155515.17650.10.camel@fred.scooby.net> Message-ID: <20061110115759.GB6767@aphasia.badger.choralone.org> On 10-Nov-2006 10:45.15 (GMT), Gabriel M. Elder wrote: > I'm > also looking to use wpa personal with tkip. Native driver support is > preferred, but i guess i can live with it if it works with ndiswrapper. network-scripts still don't support WPA. At present, the simplest way to use WPA is by using NetworkManager, but for us people who don't want to have to log in to activate networking, another solution is required. I've made some changes to the network scripts to handle WPA if you want to use it when the interfaces are brought up on startup. http://choralone.org/cruft/random/ns.diff They are by no means perfect, and I vaguely remember that there are some alterations I need to make to them in order to complete them. To get them working, download the diff. cd /etc/sysconfig/network-scripts/ patch -p1 < /path/to/ns.diff Then edit /etc/sysconfig/network-scripts/wpa_supplicant.conf - insert the details of your WPA network into that file. Then edit the /etc/sysconfig/network-scripts/ifcfg-ethN interface and add: WPA=yes WPADRIVER=(hostap|prism54|madwifi|atmel|wext|ndiswrapper|wired) (pick one WPADRIVER - I use wext on my Intel ipw2200 & ipw2915 cards) As I remember, this needs to be altered as wired interfaces can be 802.1x managed and this inserts WPA code into the wireless scripts. Once I've completed these and am happy that they will be robust for use, I'll see if anyone upstream is interested. But I don't know if the intention is to handle WPA in the network scripts. (crossposted to fedora-devel, please reply-to-all with care) -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From sundaram at fedoraproject.org Fri Nov 10 12:23:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 17:53:07 +0530 Subject: Proposal - replace beagle with tracker In-Reply-To: References: Message-ID: <45546F2B.2020009@fedoraproject.org> Neal Becker wrote: > I don't know much about this subject, but I saw this thread on ubuntu. I, > as many others, have seen problems with beagle. > > BTW, this ubuntu whiteboard is also very interesting. > https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration > https://launchpad.net/products/tracker Well Tracker is now in Fedora Extras. So end users can use both. Pros: Written in C. Much faster index, searching and memory consumption Cons: Missing filters yet for email, IM and a lot of code churn. Rahul From jonathan.underwood at gmail.com Fri Nov 10 13:15:56 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 10 Nov 2006 13:15:56 +0000 Subject: Move from TeTeX to TeXLive In-Reply-To: <1163146575.2609.7.camel@redhat.usu> References: <1163146575.2609.7.camel@redhat.usu> Message-ID: <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> On 10/11/06, Jindrich Novy wrote: > Hi Leo, > > On Thu, 2006-11-09 at 21:02 +0000, Leo wrote: > > The TeTeX project had this announcement in May this year which was in > > the beginning of FC6 cycle: > > > > ,---- > > | I (Thomas Esser) have decided not to make new releases of teTeX any > > | more (May 2006). The information below might get out of date as time > > | goes by. I suggest anybody interested in teTeX to join the TeX Live > > | project. > > `---- > > > > Now it is the beginning of FC7, I would suggest Fedora core 7 move to > > texlive. Here is how debian packages texlive: > > The conversion to TeX Live is definitely decided. I'm currently > discussing the future shape of it with TeX Live upstream which variant > will be most suitable for FC7. > > > http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} > > Thanks for the link, I'll have a look. Note that Michael Peters has already done a lot of work packaging up texlive as RPMs here: http://www.tetexrpm.org/texjive.html Jonathan From ndbecker2 at gmail.com Fri Nov 10 13:23:08 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 10 Nov 2006 08:23:08 -0500 Subject: Proposal - replace beagle with tracker References: <45546F2B.2020009@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Neal Becker wrote: >> I don't know much about this subject, but I saw this thread on ubuntu. >> I, as many others, have seen problems with beagle. >> >> BTW, this ubuntu whiteboard is also very interesting. >> https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration >> https://launchpad.net/products/tracker > > Well Tracker is now in Fedora Extras. So end users can use both. > Is that maybe in devel only? I don't see any tracker in FC6 extras: smart search tracker adplug - A software library for AdLib (OPL2) emulation dumb - IT, XM, S3M and MOD player library gnotime - Tracks and reports time spent ktorrent - A BitTorrent program for KDE rt3 - Request tracker 3 soundtracker - Sound module composer/player svnmailer - Tool to post subversion repository commit information tcpick - A tcp stream sniffer, tracker and capturer trac - Enhanced wiki and issue tracking system From skvidal at linux.duke.edu Fri Nov 10 13:28:22 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 10 Nov 2006 08:28:22 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: References: <45546F2B.2020009@fedoraproject.org> Message-ID: <1163165302.3416.4.camel@cutter> On Fri, 2006-11-10 at 08:23 -0500, Neal Becker wrote: > Rahul Sundaram wrote: > > > Neal Becker wrote: > >> I don't know much about this subject, but I saw this thread on ubuntu. > >> I, as many others, have seen problems with beagle. > >> > >> BTW, this ubuntu whiteboard is also very interesting. > >> https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration > >> https://launchpad.net/products/tracker > > > > Well Tracker is now in Fedora Extras. So end users can use both. > > > > Is that maybe in devel only? I don't see any tracker in FC6 extras: > smart search tracker > > adplug - A software library for AdLib (OPL2) emulation > dumb - IT, XM, S3M and MOD player library > gnotime - Tracks and reports time spent > ktorrent - A BitTorrent program for KDE > rt3 - Request tracker 3 > soundtracker - Sound module composer/player > svnmailer - Tool to post subversion repository commit information > tcpick - A tcp stream sniffer, tracker and capturer > trac - Enhanced wiki and issue tracking system > there's one small problem with tracker, actually. mikmod - in core obsoletes 'tracker'. this is obviously an old obsolete but it does prevent you from installing tracker on fc6 machines. run this: yum --exclude=mikmod install tracker and it will install, however, it will be removed on the next yum update run w/mikmod. maybe a bug against mikmod to clip that old obsolete? -sv From sundaram at fedoraproject.org Fri Nov 10 13:37:42 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 19:07:42 +0530 Subject: Proposal - replace beagle with tracker In-Reply-To: <1163165302.3416.4.camel@cutter> References: <45546F2B.2020009@fedoraproject.org> <1163165302.3416.4.camel@cutter> Message-ID: <455480A6.6090506@fedoraproject.org> seth vidal wrote: > > there's one small problem with tracker, actually. > > mikmod - in core obsoletes 'tracker'. > > this is obviously an old obsolete but it does prevent you from > installing tracker on fc6 machines. > > run this: > yum --exclude=mikmod install tracker > > and it will install, however, it will be removed on the next yum update > run w/mikmod. > > maybe a bug against mikmod to clip that old obsolete? The review here https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214025 says that mikmod issue has been fixed in rawhide, so it probably just requires a push into updates now. Rahul From kloczek at zie.pg.gda.pl Fri Nov 10 13:28:26 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Fri, 10 Nov 2006 14:28:26 +0100 Subject: rawhide report: 20061109 changes In-Reply-To: <1163110424.2914.10.camel@localhost> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> <1163110424.2914.10.camel@localhost> Message-ID: <1163165306.5920.64.camel@kloczek01.pracownicy.zie> Dnia 09-11-2006, czw o godzinie 14:13 -0800, Toshio Kuratomi napisa?(a): > On Thu, 2006-11-09 at 20:44 +0100, Tomasz K?oczko wrote: > > Corrected %postun example: > > > > %postun > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > rm -f $GCONF_CONFIG_SOURCE/* > > gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas > > >& /dev/null > > > %postun is the wrong scriptlet to run this in. Once you get to %postun, > the original schema file is no longer present. And this is correct because on regenerate schema database we don't want have registered this schema. kloczek From jnovy at redhat.com Fri Nov 10 13:48:11 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 10 Nov 2006 14:48:11 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> Message-ID: <1163166491.2609.45.camel@redhat.usu> On Fri, 2006-11-10 at 13:15 +0000, Jonathan Underwood wrote: > On 10/11/06, Jindrich Novy wrote: > > On Thu, 2006-11-09 at 21:02 +0000, Leo wrote: > > > Now it is the beginning of FC7, I would suggest Fedora core 7 move to > > > texlive. Here is how debian packages texlive: > > > > The conversion to TeX Live is definitely decided. I'm currently > > discussing the future shape of it with TeX Live upstream which variant > > will be most suitable for FC7. > > > > > http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} > > > > Thanks for the link, I'll have a look. > > Note that Michael Peters has already done a lot of work packaging up > texlive as RPMs here: > > http://www.tetexrpm.org/texjive.html Yes, I made TeXLive upstream aware of Michael's work, so adopting his work is also an option. Jindrich From gilboad at gmail.com Fri Nov 10 14:17:06 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 10 Nov 2006 16:17:06 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox Message-ID: <1163168226.26941.21.camel@gilboa-home-dev.localhost> Hello all, The attached patch (which should cover all 64bit arches) enable you to start the 32bit version of firefox (if it's installed) by starting firefox with the "--32" command line option. Before I submit this to bugzilla, I have two questions: - Do we rather have a single firefox script that executes both 32bit and 64bit or do we want to break the it to dedicated firefox[64] and firefox32 scripts. - Where should I submit this patch? Mozilla or redhat? - Gilboa -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox.patch Type: text/x-patch Size: 1124 bytes Desc: not available URL: From gilboad at gmail.com Fri Nov 10 14:55:42 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 10 Nov 2006 16:55:42 +0200 Subject: Testing Fedora - small (?) suggestion. Message-ID: <1163170542.26941.60.camel@gilboa-home-dev.localhost> Hello all, I use Fedora daily, and I have a vested interest in -actively- helping Fedora (and in-turn RHEL) become a better product. I don't have a dedicated Rawhide machine, I do play with it from time to time using VMWare Server, but this is fairly light testing as I'm pretty short on time. (Just to see what's new) I -do- try to install (at least on a VM machine) every test release and give it a day or two of testing - but even this is hardly enough. FC6 was a good release, but certain managed to slip through... some of them rather critical (i586 kernel springs to mind) which should have been found by us. (Read: testers) As I see it, there's not enough Rawhide users to reduce the release bug count, mainly because: A. In my experience, 1 out of 2 rawhide installs break due to missing dependencies - and spending four hours (and ~1+GB of bandwidth) just to watch Anaconda choke on missing pygtk package is very frustrating. B. Rawhide tends to break, a-lot. C. As much as I disagree with this notion, people view Fedora as RHEL's Alpha and view Rawhide as "experimental Alpha". More then anything FC6 proved that 3 test releases may not be enough to get a bug free release, so let me suggest the following: A. Create more mile-stone releases. Once the tree reaches build integrity (no missing packages), spin a test release. (Fixes P1, P2) B. Change the terms that are being used to describe each test release. Whether we like it or not, people are used to the "Alpha", "Beta" and "RC" terms, and tend to consider "Test release" as "Alpha release". I understand that the term "Test" was used to differentiate the ever-rolling Fedora from the release-based RHEL, but Fedora has aged enough to be viewed as an entity by itself and we can drop the "Test" term. Using "normal" terms should help combat the "RHEL Alpha" and 'RHEL Alpha experimental" image problem (Fixes P3). C. Once Fedora hits RC, only bug fixes go into the tree. No last minute 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the release. Nada. New features can always enter the tree as updates once the release ISOs have been sent. Here's a mock Fedora release schedule: T-4 Months: Alpha1 T-X Months: AlphaX T-1 Months: Beta T-3 weeks: RC1 - Tree go into lock mode. T-1.5 weeks: RC2 T+n weeks: unexpected RC3. T: release. Part time. - Gilboa From sdl.web at gmail.com Fri Nov 10 14:58:44 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 10 Nov 2006 14:58:44 +0000 Subject: Move from TeTeX to TeXLive References: <1163146575.2609.7.camel@redhat.usu> Message-ID: On Fri, 10/11/06, Jindrich Novy wrote: > Hi Leo, > > On Thu, 2006-11-09 at 21:02 +0000, Leo wrote: >> The TeTeX project had this announcement in May this year which was in >> the beginning of FC6 cycle: >> >> ,---- >> | I (Thomas Esser) have decided not to make new releases of teTeX any >> | more (May 2006). The information below might get out of date as time >> | goes by. I suggest anybody interested in teTeX to join the TeX Live >> | project. >> `---- >> >> Now it is the beginning of FC7, I would suggest Fedora core 7 move to >> texlive. Here is how debian packages texlive: > > The conversion to TeX Live is definitely decided. I'm currently > discussing the future shape of it with TeX Live upstream which variant > will be most suitable for FC7. > >> http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} > > Thanks for the link, I'll have a look. > > Jindrich I'm very happy to hear that as a user of LaTeX. And thank you very much for your effort. -- Leo From ajackson at redhat.com Fri Nov 10 15:21:55 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 10 Nov 2006 10:21:55 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163170542.26941.60.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> Message-ID: <45549913.1040508@redhat.com> Gilboa Davara wrote: > A. In my experience, 1 out of 2 rawhide installs break due to missing > dependencies - and spending four hours (and ~1+GB of bandwidth) just to > watch Anaconda choke on missing pygtk package is very frustrating. This seems like something we could prevent proactively at tree compose time. - ajax From fedora at camperquake.de Fri Nov 10 15:31:45 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 10 Nov 2006 16:31:45 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163170542.26941.60.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> Message-ID: <20061110163145.287a052d@nausicaa.camperquake.de> Hi. Gilboa Davara wrote: > B. Rawhide tends to break, a-lot. As someone who has been running rawhide since pre-FC1: no, it does not, to my continuing amazement. Yes, the rawhide tree may not always be installable or upgradable, if you meant to say that you're right. But once you get the software on your disk it is usable almost all the time. And it has not eaten my babies yet. -- In a hurry are we, sir? From mspevack at redhat.com Fri Nov 10 15:34:47 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 10 Nov 2006 10:34:47 -0500 (EST) Subject: FedoraSummit Message-ID: Posting to both fedora-advisory-board and fedora-devel-list. Encourage anyone who is interested to check out this page: http://fedoraproject.org/wiki/FedoraSummit Next week is going to be a busy one for Fedora, and we want to do everything we can to make sure the folks on these two lists (as well as our blogs) are in the loop as to what is happening. That said, the FedoraSummit page in the wiki will give everyone an idea of what our discussion plans are, as well as our communication and transparency plans. Thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From gilboad at gmail.com Fri Nov 10 16:13:25 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 10 Nov 2006 18:13:25 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <20061110163145.287a052d@nausicaa.camperquake.de> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <20061110163145.287a052d@nausicaa.camperquake.de> Message-ID: <1163175205.26941.63.camel@gilboa-home-dev.localhost> On Fri, 2006-11-10 at 16:31 +0100, Ralf Ertzinger wrote: > Hi. > > Gilboa Davara wrote: > > > B. Rawhide tends to break, a-lot. > > As someone who has been running rawhide since pre-FC1: no, it does not, > to my continuing amazement. Yes, the rawhide tree may not always be > installable or upgradable, if you meant to say that you're right. But once > you get the software on your disk it is usable almost all the time. > > And it has not eaten my babies yet. It did it main... at least twice. But this doesn't really matter... rawhide is supposed to break, isn't it? Never the less, it doesn't change the fact the installing rawhide can be a very frustrating experience. - Gilboa From dakingun at gmail.com Fri Nov 10 16:23:04 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 10 Nov 2006 11:23:04 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: <1163165302.3416.4.camel@cutter> References: <45546F2B.2020009@fedoraproject.org> <1163165302.3416.4.camel@cutter> Message-ID: On 11/10/06, seth vidal wrote: > > there's one small problem with tracker, actually. > > mikmod - in core obsoletes 'tracker'. > This has been fixed yesterday on FC-5, FC-6 and devel. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214112) Deji From ajackson at redhat.com Fri Nov 10 16:32:00 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 10 Nov 2006 11:32:00 -0500 Subject: X in FC7 Message-ID: <4554A980.6060204@redhat.com> I've started a wiki page for some ideas of things I'd like to see us get done for X in FC7: http://fedoraproject.org/wiki/XInFC7 Currently a bit skeletal, but please do add ideas, no matter how wild. - ajax From caillon at redhat.com Fri Nov 10 16:54:11 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 10 Nov 2006 11:54:11 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: References: Message-ID: <4554AEB3.8010701@redhat.com> Neal Becker wrote: > I don't know much about this subject, but I saw this thread on ubuntu. I, > as many others, have seen problems with beagle. > > BTW, this ubuntu whiteboard is also very interesting. > https://features.launchpad.net/distros/ubuntu/+spec/tracker-integration > https://launchpad.net/products/tracker Tracker has been proposed[1] to be included into GNOME and has been rejected for various reasons. See the thread for full details, but Joe's reply[2] lists some good reasons to not include tracker at this time. [1]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html [2]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00211.html From wolfgang+gnus200611 at dailyplanet.dontspam.wsrcc.com Fri Nov 10 18:18:08 2006 From: wolfgang+gnus200611 at dailyplanet.dontspam.wsrcc.com (Wolfgang S. Rupprecht) Date: Fri, 10 Nov 2006 10:18:08 -0800 Subject: wireless NICs, wpa References: <1163155515.17650.10.camel@fred.scooby.net> <20061110115759.GB6767@aphasia.badger.choralone.org> Message-ID: <87ac2zupwf.fsf@arbol.wsrcc.com> Rob Andrews writes: > network-scripts still don't support WPA. At present, the simplest way to use > WPA is by using NetworkManager, but for us people who don't want to have to > log in to activate networking, another solution is required. Under fc5 and fc6 I run wpa_supplicant and the network scripts. The wireless with WPA2 comes up automatically as expected. The only change needed is that wpa_supplicant init needs to be called before the networking scripts are called. emacs /etc/init.d/wpa_supplicant - chkconfig: - 12 88 + chkconfig: - 9 88 chkconfig wpa_supplicant on > http://choralone.org/cruft/random/ns.diff This is much more extensive than I use. (Not to say this is a bad idea, but this is more intrusive than needed to get things working.) -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ From jnovy at redhat.com Fri Nov 10 18:48:31 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 10 Nov 2006 19:48:31 +0100 Subject: db4 is now updated to 4.5.20 and compat-db to 4.3.29 Message-ID: <1163184511.28734.18.camel@redhat.usu> Hi all, db4 is now updated to 4.5.20, so please if you are a maintainer of a package listed below, which is dependent on it, consider rebuilding ASAP so that I don't break rawhide for too long ;-) If your package is for some *IMPORTANT* reason incompatible with db4.5, you can switch BuildRequires to compat-db, which now contains former rawhide db4-3.29 including header files in %{_includedir}/db4.3.29 so you might want to update your include paths as well. compat-db-4.3.29 contains also db-4.2.52 libraries, db-4.1.25 was removed. Intermediate db4.4.20 release, which wasn't in Fedora will not be supported. If you have questions or if you need help with rebuilding your package, don't hesitate to ask. Thanks, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V -------------- next part -------------- P: db4 <- pam_ccreds-3-5 [development] p: libdb-4.3.so <- apr-util-1.2.7-3 [development] p: libdb-4.3.so <- bogofilter-1.0.3-1.fc6 [extras] p: libdb-4.3.so <- cfengine-2.1.21-2.fc6 [extras] p: libdb-4.3.so <- clisp-2.41-1.fc6 [extras] p: libdb-4.3.so <- compat-libgda-1.2.3-4.fc6 [extras] p: libdb-4.3.so <- cyrus-imapd-2.3.7-4.fc6 [extras] p: libdb-4.3.so <- cyrus-imapd-utils-2.3.7-4.fc6 [extras] p: libdb-4.3.so <- evolution-data-server-1.9.2-3.fc7 [development] p: libdb-4.3.so <- exim-4.63-5.fc6 [extras] p: libdb-4.3.so <- gift-openft-0.2.1.6-3.fc6 [extras] p: libdb-4.3.so <- httpd-2.2.3-5 [development] p: libdb-4.3.so <- iproute-2.6.18-1.fc6 [development] p: libdb-4.3.so <- jabberd-2.0-0.s11.11.fc6 [extras] p: libdb-4.3.so <- jigdo-0.7.3-2.fc6 [extras] p: libdb-4.3.so <- kdesdk-3.5.5-0.1.fc6 [development] p: libdb-4.3.so <- kdevelop-3.3.5-0.1.fc6 [development] p: libdb-4.3.so <- libapreq2-2.09-0.rc1.3.1.fc6 [extras] p: libdb-4.3.so <- libetpan-0.48-1.fc6 [extras] p: libdb-4.3.so <- libgda-1.9.100-10.fc6 [extras] p: libdb-4.3.so <- mod_perl-2.0.2-6.1 [development] p: libdb-4.3.so <- netatalk-2.0.3-7.fc6 [development] p: libdb-4.3.so <- nmh-1.1-19.fc6 [extras] p: libdb-4.3.so <- openoffice.org-core-2.1.0-2.2 [development] p: libdb-4.3.so <- pam_abl-0.2.3-2.fc6 [extras] p: libdb-4.3.so <- perl-5.8.8-10 [development] p: libdb-4.3.so <- perl-BerkeleyDB-0.31-2.fc6 [extras] p: libdb-4.3.so <- perl-eperl-2.2.14-3.fc6 [extras] p: libdb-4.3.so <- perl-libapreq2-2.09-0.rc1.3.1.fc6 [extras] p: libdb-4.3.so <- php-cli-5.1.6-4 [development] p: libdb-4.3.so <- php-dba-5.1.6-4 [development] p: libdb-4.3.so <- poedit-1.3.6-1.fc6 [extras] p: libdb-4.3.so <- postfix-2.3.4-1 [development] p: libdb-4.3.so <- python-2.4.4-1.fc7 [development] p: libdb-4.3.so <- rapidsvn-0.9.3-2.fc6 [extras] p: libdb-4.3.so <- ruby-bdb-0.5.9-6.fc6 [extras] p: libdb-4.3.so <- sendmail-8.13.8-2 [development] p: libdb-4.3.so <- squidGuard-1.2.0-14.fc6 [extras] p: libdb-4.3.so <- subversion-1.4.2-3 [development] p: libdb-4.3.so <- sylpheed-claws-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-bogofilter-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-clamav-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-dillo-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-etpan-privacy-2.5.2-4.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-maildir-2.5.2-4.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-pgp-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- sylpheed-claws-plugins-spamassassin-2.6.0-1.fc6 [extras] p: libdb-4.3.so <- webalizer-2.01_10-30.1 [development] p: libdb_cxx-4.3.so <- kdeaddons-3.5.5-0.1.fc6 [development] p: libdb_cxx-4.3.so <- xca-0.5.1-6.fc6 [extras] P: db4-devel <- apr-util-devel-1.2.7-3 [development] P: db4-devel <- compat-libgda-devel-1.2.3-4.fc6 [extras] P: db4-devel <- libetpan-devel-0.48-1.fc6 [extras] P: db4-devel <- libgda-devel-1.9.100-10.fc6 [extras] P: db4-utils <- cyrus-imapd-2.3.7-4.fc6 [extras] From jkeating at redhat.com Fri Nov 10 20:42:59 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 15:42:59 -0500 Subject: db4 is now updated to 4.5.20 and compat-db to 4.3.29 In-Reply-To: <1163184511.28734.18.camel@redhat.usu> References: <1163184511.28734.18.camel@redhat.usu> Message-ID: <200611101542.59664.jkeating@redhat.com> On Friday 10 November 2006 13:48, Jindrich Novy wrote: > db4 is now updated to 4.5.20, so please if you are a maintainer of a > package listed below, which is dependent on it, consider rebuilding ASAP > so that I don't break rawhide for too long Um, this broke our build system, as pam couldn't be installed with the new db4. Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/dist-fc7-build-132984-25233/root install 'libX11-devel' 'libXt-devel' 'libICE-devel' 'libXmu-devel' 'libXrender-devel' 'libXext-devel' 'gettext' 'automake' 'control-center-devel' 'gnome-desktop-devel' 'libwnck-devel' 'libSM-devel' 'libtool' 'libdrm-devel' 'libXrandr-devel' 'desktop-file-utils' 'GConf2-devel' 'intltool >= 0.35' 'libXcomposite-devel' 'libXfixes-devel' 'autoconf' 'libXdamage-devel' Error: pam conflicts with db4 >= 4.4.0 I've untagged your builds so that the buildroots can continue to be used. When changing a low level package like db4, it is important to work with the release engineering/buildsystem team to prevent buildroot breakage. We'll need to discuss how to get your update integrated into the buildroots. For now, its out. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Fri Nov 10 23:47:46 2006 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 10 Nov 2006 15:47:46 -0800 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163170542.26941.60.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> Message-ID: <1163202467.7535.59.camel@localhost.localdomain> On Fri, 2006-11-10 at 16:55 +0200, Gilboa Davara wrote: > A. In my experience, 1 out of 2 rawhide installs break due to missing > dependencies - and spending four hours (and ~1+GB of bandwidth) just to > watch Anaconda choke on missing pygtk package is very frustrating. If that is a frequent problem for you, I highly recommend mirroring whatever you are interested in locally. David From marcel at mesa.nl Fri Nov 10 23:48:29 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 11 Nov 2006 00:48:29 +0100 Subject: AT_SPI_REGISTRY Message-ID: <20061110234829.GB21277@joshua.mesa.nl> After installing rawhide(-extras) x86-64 on my laptop I get the following when starting gnumeric: % gnumeric Bonobo accessibility support initialized GTK Accessibility Module initialized ** (gnumeric:17572): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. ** (gnumeric:17572): WARNING **: IOR not set. ** ERROR **: Could not locate registry aborting... Bonobo accessibility support initialized GTK Accessibility Module initialized ** (gnome_segv2:17573): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. ** (gnome_segv2:17573): WARNING **: IOR not set. ** ERROR **: Could not locate registry aborting... Bonobo accessibility support initialized GTK Accessibility Module initialized ** (gnome_segv2:17574): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. ** (gnome_segv2:17574): WARNING **: IOR not set. ** ERROR **: Could not locate registry aborting... and around another 100 more of these, ending with Xlib: connection to ":0.0" refused by server Xlib: Maximum number of clients reached (gnome_segv2:17682): Gtk-WARNING **: cannot open display: And no gnumeric starting up. Something similar happens when running the 32-bit firefox (to be able to see some flash sites). 64-bit firefox strarts up fine. Scanning google or lists did not give any clues... I'm running kde if that matters. Any idea? -Marcel From a.badger at gmail.com Sat Nov 11 00:13:17 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 10 Nov 2006 16:13:17 -0800 Subject: rawhide report: 20061109 changes In-Reply-To: <1163165306.5920.64.camel@kloczek01.pracownicy.zie> References: <200611091052.kA9Aqv8Q010389@hs20-bc2-6.build.redhat.com> <1163097039.5920.32.camel@kloczek01.pracownicy.zie> <20061109201444.d2a2b907.fedora@wir-sind-cool.org> <1163101465.5920.38.camel@kloczek01.pracownicy.zie> <1163110424.2914.10.camel@localhost> <1163165306.5920.64.camel@kloczek01.pracownicy.zie> Message-ID: <1163203997.4695.14.camel@localhost> On Fri, 2006-11-10 at 14:28 +0100, Tomasz K?oczko wrote: > Dnia 09-11-2006, czw o godzinie 14:13 -0800, Toshio Kuratomi napisa?(a): > > On Thu, 2006-11-09 at 20:44 +0100, Tomasz K?oczko wrote: > > > Corrected %postun example: > > > > > > %postun > > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > > rm -f $GCONF_CONFIG_SOURCE/* > > > gconftool-2 --makefile-install-rule /etc/gconf/schemas/*.schemas > > > >& /dev/null > > > > > %postun is the wrong scriptlet to run this in. Once you get to %postun, > > the original schema file is no longer present. > > And this is correct because on regenerate schema database we don't want > have registered this schema. Oops. I thought you had fixed this by using --makefile-uninstall-rule. My mistake. But you're going to have to try again to fix your scriptlet:: $ echo `gconftool-2 --get-default-source` xml:merged:/etc/gconf/gconf.xml.defaults So your rm -f won't do what you think it will. A few more iterations and we'll have reached the point where your scriptlet is as complex as the currently advocated method. -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 markmc at redhat.com Sat Nov 11 00:21:10 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 10 Nov 2006 19:21:10 -0500 Subject: AT_SPI_REGISTRY In-Reply-To: <20061110234829.GB21277@joshua.mesa.nl> References: <20061110234829.GB21277@joshua.mesa.nl> Message-ID: <1163204470.3033.8.camel@blaa> On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > After installing rawhide(-extras) x86-64 on my laptop I get the following > when starting gnumeric: gnumeric.i386 or gnumeric.x86_64 ? This reminds me of an issue we had previously where e.g. - you have a 64 bit bonobo-activation-server running - 32 bit app requests activation of an shlib component (e.g. the OAFIID moniker) - b-a-s returns the path to a 64 bit library which the 32 bit app fails to load I don't think that's actually the problem, though ... > I'm running kde if that matters. That's probably the problem ... we've just updated to gnome-session 2.17.2 which includes this: http://bugzilla.gnome.org/show_bug.cgi?id=345428 Basically, gnome-session starts at-registryd now ... Cheers, Mark. From caolanm at redhat.com Sat Nov 11 00:31:50 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 11 Nov 2006 00:31:50 +0000 Subject: AT_SPI_REGISTRY In-Reply-To: <20061110234829.GB21277@joshua.mesa.nl> References: <20061110234829.GB21277@joshua.mesa.nl> Message-ID: <1163205176.32462.13.camel@soulcrusher.caolan.org> On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > After installing rawhide(-extras) x86-64 on my laptop I get the following > when starting gnumeric: > > > % gnumeric > > Bonobo accessibility support initialized > GTK Accessibility Module initialized Yeah, something has one horribly wrong with rawhide a11y, probably temporary. In the the meantime, something like > gconftool-2 -s "/desktop/gnome/interface/accessibility" false --type bool > unset GTK_MODULES might get you running gnome stuff without a11y enabled. C. From marcel at mesa.nl Sat Nov 11 00:35:50 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 11 Nov 2006 01:35:50 +0100 Subject: AT_SPI_REGISTRY In-Reply-To: <1163204470.3033.8.camel@blaa> References: <20061110234829.GB21277@joshua.mesa.nl> <1163204470.3033.8.camel@blaa> Message-ID: <20061111003550.GC21277@joshua.mesa.nl> On Fri, Nov 10, 2006 at 07:21:10PM -0500, Mark McLoughlin wrote: > On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > > After installing rawhide(-extras) x86-64 on my laptop I get the following > > when starting gnumeric: > > gnumeric.i386 or gnumeric.x86_64 ? That is another thing that puzzles me. I just ran yum install gnumeric. % grep gnumeric /var/log/rpmpkgs gnumeric-1.6.3-5.fc6.i386.rpm gnumeric-1.6.3-5.fc6.x86_64.rpm So both versions are installed, but both have /usr/bin/gnumeric-1.6.3. I guess installing both should have given an error or so. But apperantly the 64-bit has precedence: % file /usr/bin/gnumeric-1.6.3 /usr/bin/gnumeric-1.6.3: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped > > This reminds me of an issue we had previously where e.g. > > - you have a 64 bit bonobo-activation-server running > > - 32 bit app requests activation of an shlib component (e.g. the > OAFIID moniker) > > - b-a-s returns the path to a 64 bit library which the 32 bit app > fails to load > > I don't think that's actually the problem, though ... > > > I'm running kde if that matters. > > That's probably the problem ... we've just updated to gnome-session > 2.17.2 which includes this: > > http://bugzilla.gnome.org/show_bug.cgi?id=345428 > > Basically, gnome-session starts at-registryd now ... > Right. So this needs a bit tweaking in some scripts... % /usr/libexec/at-spi-registryd Xlib: extension "XEVIE" missing on display ":0.0". Suspended % bg [3] /usr/libexec/at-spi-registryd & % gnumeric Bonobo accessibility support initialized GTK Accessibility Module initialized And gnumeric is happily running. -Marcel From jbarnes at virtuousgeek.org Sat Nov 11 00:37:07 2006 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 10 Nov 2006 16:37:07 -0800 Subject: X in FC7 In-Reply-To: <4554A980.6060204@redhat.com> References: <4554A980.6060204@redhat.com> Message-ID: <200611101637.07377.jbarnes@virtuousgeek.org> On Friday, November 10, 2006 8:32 am, Adam Jackson wrote: > I've started a wiki page for some ideas of things I'd like to see us > get done for X in FC7: > > http://fedoraproject.org/wiki/XInFC7 > > Currently a bit skeletal, but please do add ideas, no matter how > wild. Well, I created an account but can't seem to edit the page. Anyway, I like the idea of getting rid of xfs, it seems fairly useless. And to quote mharris from awhile back: > Long term, what would be really nice, is if someone figured > out a way to implement core fonts using fontconfig/Xft > underneath so we have one font system, and it provides > legacy compatibility to ancient applications that have not > been updated to modern interfaces. That is something that > would need to be spearheaded at the X.Org level rather than > at a specific distribution however. That said, which apps care about core fonts these days? Would it make sense to just build-in a fixed font or something and let everything else use fontconfig (as most decent apps do these days)? And does the new Emacs still require libXaw or is a gtk-only build possible? If so, dropping Xaw would only mean losing xterm (a pain, but there are lots of alternatives available, but only one Emacs). Also, which input drivers should we be using? Isn't synaptics much better for laptops than the default mouse driver? What about evdev? Should it be the default? Anyway, just some random questions & ideas. Jesse From michel.salim at gmail.com Sat Nov 11 00:57:59 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 10 Nov 2006 19:57:59 -0500 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <883cfe6d0611101657s6bbbeae8h6380ed14dd6200d8@mail.gmail.com> On 11/10/06, Jesse Barnes wrote: > > Long term, what would be really nice, is if someone figured > > out a way to implement core fonts using fontconfig/Xft > > underneath so we have one font system, and it provides > > legacy compatibility to ancient applications that have not > > been updated to modern interfaces. That is something that > > would need to be spearheaded at the X.Org level rather than > > at a specific distribution however. > > That said, which apps care about core fonts these days? Would it make > sense to just build-in a fixed font or something and let everything > else use fontconfig (as most decent apps do these days)? > Emacs. But hopefully Emacs 22, which has a GTK-only build option, will be in Core 7. > And does the new Emacs still require libXaw or is a gtk-only build > possible? If so, dropping Xaw would only mean losing xterm (a pain, > but there are lots of alternatives available, but only one Emacs). > Regards, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From n0dalus+redhat at gmail.com Sat Nov 11 02:22:01 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 11 Nov 2006 12:52:01 +1030 Subject: Proposal - replace beagle with tracker In-Reply-To: <4554AEB3.8010701@redhat.com> References: <4554AEB3.8010701@redhat.com> Message-ID: <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> On 11/11/06, Christopher Aillon wrote: > > Tracker has been proposed[1] to be included into GNOME and has been > rejected for various reasons. See the thread for full details, but > Joe's reply[2] lists some good reasons to not include tracker at this time. > > [1]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html > [2]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00211.html > His main complaint seems to be that tracker hasn't had a lot of testing. Maybe Fedora can help in that respect by putting it in devel and getting the community using it. n0dalus. From jreiser at BitWagon.com Sat Nov 11 02:46:35 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 10 Nov 2006 18:46:35 -0800 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <4555398B.2020901@BitWagon.com> Jesse Barnes wrote: > Well, I created an account but can't seem to edit the page. Anyway, I > like the idea of getting rid of xfs, it seems fairly useless. And to > quote mharris from awhile back: > > >>Long term, what would be really nice, is if someone figured >>out a way to implement core fonts using fontconfig/Xft >>underneath so we have one font system, and it provides >>legacy compatibility to ancient applications that have not >>been updated to modern interfaces. That is something that >>would need to be spearheaded at the X.Org level rather than >>at a specific distribution however. > > > That said, which apps care about core fonts these days? Many hundreds of user-written vertical-integration apps that run on Fedora boxes, but are not in any Fedora repository. The X11 font system has been reasonably well documented for _decades_, including a significant period when those documents were a noted improvement on the documents for the "successor" font systems. -- From michel.salim at gmail.com Sat Nov 11 03:37:48 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 10 Nov 2006 22:37:48 -0500 Subject: empty mirrorlist for updates-testing-source, development-source and extras-development-source Message-ID: <883cfe6d0611101937l1e48ec8cg1955d52a09f08e95@mail.gmail.com> Hi, Per subject line, yum and yumdownloader fails when I try enabling the repositories above, because there are no known mirrors. Could the mirror list be updated? I know for certain that mirrors.kernel.org has the files. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From vonbrand at inf.utfsm.cl Fri Nov 10 15:25:23 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 10 Nov 2006 12:25:23 -0300 Subject: I think, rsh is quite obsolete In-Reply-To: Message from Chris Adams of "Wed, 08 Nov 2006 18:48:46 MDT." <20061109004846.GA673446@hiwaay.net> Message-ID: <200611101525.kAAFPNRP003865@laptop13.inf.utfsm.cl> Chris Adams wrote: > Once upon a time, Dave Jones said: > > On Wed, Nov 08, 2006 at 11:50:51AM +0100, Adam Tkac wrote: > > > I think, It's no argument to include rsh in next versions of fc/rhel. > > > OpenSSH could successfully substitute this component. SSH is more secure > > > than rsh and has all features of rsh. Do you think anything else?? > > > > The rsh _client_ has its uses in legacy environments. > > The daemon, questionable. > > Likewise, why we still ship telnet-server in core is beyond me. > I have needed telnet-server a few times when trying to debug when > connecting from network gear (no ssh in most). Also, where we allow > shell access to web hosting customers, we still allow telnet (most of > them are on Windows and it only includes a telnet client). Tell them to use putty or some such SSH client for Windows. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From cmadams at hiwaay.net Sat Nov 11 04:27:04 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Nov 2006 22:27:04 -0600 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <20061111042704.GA847601@hiwaay.net> Once upon a time, Jesse Barnes said: > And does the new Emacs still require libXaw or is a gtk-only build > possible? If so, dropping Xaw would only mean losing xterm (a pain, > but there are lots of alternatives available, but only one Emacs). There's only one xterm as well; for example, nobody else has Tek4014 emulation (useful for legacy apps). Also, xterm is lighter weight than gnome-terminal. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Sat Nov 11 04:30:25 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Nov 2006 22:30:25 -0600 Subject: X in FC7 In-Reply-To: <4555398B.2020901@BitWagon.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <4555398B.2020901@BitWagon.com> Message-ID: <20061111043025.GB847601@hiwaay.net> Once upon a time, John Reiser said: > Many hundreds of user-written vertical-integration apps that > run on Fedora boxes, but are not in any Fedora repository. > The X11 font system has been reasonably well documented for > _decades_, including a significant period when those documents > were a noted improvement on the documents for the "successor" > font systems. IIRC, getting rid of xfs does _not_ mean getting rid of old-style fonts. The X server can handle font rendering directly (that's how it was done before using xfs after all). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwmw2 at infradead.org Sat Nov 11 05:02:03 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 11 Nov 2006 13:02:03 +0800 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163168226.26941.21.camel@gilboa-home-dev.localhost> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> Message-ID: <1163221323.4727.126.camel@shinybook.infradead.org> On Fri, 2006-11-10 at 16:17 +0200, Gilboa Davara wrote: > The attached patch (which should cover all 64bit arches) enable you to > start the 32bit version of firefox (if it's installed) by starting > firefox with the "--32" command line option. > > Before I submit this to bugzilla, I have two questions: > > - Do we rather have a single firefox script that executes both 32bit and > 64bit or do we want to break the it to dedicated firefox[64] and > firefox32 scripts. Please make sure it defaults to 32-bit firefox on ppc64, just like most of the rest of userspace does (including the Java and RealPlayer plugins). If you _really_ want ppc64 firefox, you should need to run with '--64' to get it. -- dwmw2 From franklinux392 at yahoo.com Sat Nov 11 06:01:40 2006 From: franklinux392 at yahoo.com (Frank S.) Date: Fri, 10 Nov 2006 22:01:40 -0800 (PST) Subject: wireles Message-ID: <20061111060140.77397.qmail@web54302.mail.yahoo.com> Sorry to bother you I know i should ask this questions in a forum but i have try with no result so: I need to get a wireless wifi PC card for my laptop and a pci wifi card for my desktop, I do NOT want to use Ndiswrap or anything similar to that I would to get one that works out of the box, PLEASE could you recommend me one Thank you very much --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilboad at gmail.com Sat Nov 11 06:55:03 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 11 Nov 2006 08:55:03 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163221323.4727.126.camel@shinybook.infradead.org> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <1163221323.4727.126.camel@shinybook.infradead.org> Message-ID: <1163228103.26941.65.camel@gilboa-home-dev.localhost> On Sat, 2006-11-11 at 13:02 +0800, David Woodhouse wrote: > On Fri, 2006-11-10 at 16:17 +0200, Gilboa Davara wrote: > > The attached patch (which should cover all 64bit arches) enable you to > > start the 32bit version of firefox (if it's installed) by starting > > firefox with the "--32" command line option. > > > > Before I submit this to bugzilla, I have two questions: > > > > - Do we rather have a single firefox script that executes both 32bit and > > 64bit or do we want to break the it to dedicated firefox[64] and > > firefox32 scripts. > > Please make sure it defaults to 32-bit firefox on ppc64, just like most > of the rest of userspace does (including the Java and RealPlayer > plugins). If you _really_ want ppc64 firefox, you should need to run > with '--64' to get it. > Done. - Gilboa -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox.patch Type: text/x-patch Size: 1430 bytes Desc: not available URL: From gilboad at gmail.com Sat Nov 11 07:03:38 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 11 Nov 2006 09:03:38 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163202467.7535.59.camel@localhost.localdomain> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <1163202467.7535.59.camel@localhost.localdomain> Message-ID: <1163228618.26941.75.camel@gilboa-home-dev.localhost> On Fri, 2006-11-10 at 15:47 -0800, David Lutterkort wrote: > On Fri, 2006-11-10 at 16:55 +0200, Gilboa Davara wrote: > > A. In my experience, 1 out of 2 rawhide installs break due to missing > > dependencies - and spending four hours (and ~1+GB of bandwidth) just to > > watch Anaconda choke on missing pygtk package is very frustrating. > > If that is a frequent problem for you, I highly recommend mirroring > whatever you are interested in locally. > > David > > I'm not passing judgment, I understand that what I'm proposing means adding additional workload to RH/FC personal but your answer raising a philosophical question, does Fedora have a vest interest in -helping- people test Fedora test/beta/rawhide/etc. (By lowering the bar) If Fedora doesn't want/need additional testers, then a "mirror the files locally" solution is sufficient. if Fedora -does- want attract more testers (and in the long run, users), then Fedora should consider spinning rawhide ISO every time the rawhide build reaches minimal level of integrity (Read: no missing packages) More-ever, I re-raise my suggestion to use normal software terms (Alpha, beta, RC) instead of using the enigmatic "test release" - Gilboa From giallu at gmail.com Sat Nov 11 08:41:15 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 11 Nov 2006 09:41:15 +0100 Subject: wireles In-Reply-To: <20061111060140.77397.qmail@web54302.mail.yahoo.com> References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> Message-ID: On 11/11/06, Frank S. wrote: > I need to get a wireless wifi PC card for my laptop and a pci wifi card for > my desktop, I do NOT want to use Ndiswrap or anything similar to that I > would to get one that works out of the box, PLEASE could you recommend me > one "Wireless" and "OOTB" does not go very well together: at the very least, you need to install some firmware from livna (like for centrino based laptops), but you often end up installing also a kernel module. For my desktop PC I have an atheros based card which works quite well, apart some minor quirks, in WPA mode with the livna madwifi driver. I also used to work with a US Robotics PCMCIA wifi card, based on a TI chipset working with the acx100 driver, but it is in a drawer for quite some time now, so I can not comment on its current state of support. From arjan at fenrus.demon.nl Sat Nov 11 09:03:24 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 11 Nov 2006 10:03:24 +0100 Subject: wireles In-Reply-To: <20061111060140.77397.qmail@web54302.mail.yahoo.com> References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> Message-ID: <1163235804.3138.809.camel@laptopd505.fenrus.org> On Fri, 2006-11-10 at 22:01 -0800, Frank S. wrote: > Sorry to bother you I know i should ask this questions in a forum but > i have try with no result so: > I need to get a wireless wifi PC card for my laptop and a pci wifi > card for my desktop, I do NOT want to use Ndiswrap or anything similar > to that I would to get one that works out of the box, PLEASE could you > recommend me one > Thank you very much the Intel 2100/2200 cards have in-kernel drivers (supported by Intel) but you need to get some firmware (hopefully that can go into Fedora proper soon, the license terms are matching with the Fedora requirements afaiks) The Intel 3945 cards have an out of tree driver (supported by Intel) and firmware, and at this point need a binary userspace daemon (but that will go away in the next months). When that happens the driver can go into the kernel (together with devicescape or once devicescape gets merged) The Broadcom cards have an in-tree, reverse engineered driver but firmware is a bit of a mess; most work apparently (but it's unlikely that that will be shipped in fedora, it's more of a "take the windows driver and copy a part of it" than a "vendor allows us to") There is madwifi which is always going to be a nightmare (binary kernel component that is hard to ship by anyone due to it's strange gpl/non-gpl mix); result is continuous pain of outside, binary driver but little chance of that changing There's a whole bunch of others which are smaller in the market, most of them have GPL drivers but aren't merged yet, several are waiting for devicescape to get merged first. So it's not all that bad, as long as you're willing to check before, and look around for drivers a bit. The good news is that you hardly need ndiswrapper anymore, and even can avoid binary drivers since most cards have SOME open driver now. From pertusus at free.fr Sat Nov 11 09:22:26 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 11 Nov 2006 10:22:26 +0100 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <20061111092226.GB3041@free.fr> > > That said, which apps care about core fonts these days? Would it make > sense to just build-in a fixed font or something and let everything > else use fontconfig (as most decent apps do these days)? Oldish decent apps use core fonts. Some apps in extras do and there are certainly more around that are interesting, especially in the scientific community where users are not interested in eye-candy. -- Pat From jspaleta at gmail.com Sat Nov 11 09:28:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 00:28:10 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163170542.26941.60.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> Message-ID: <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> On 11/10/06, Gilboa Davara wrote: > A. Create more mile-stone releases. Once the tree reaches build > integrity (no missing packages), spin a test release. (Fixes P1, P2) Logic fault... we dont have enough testers right now... more mile-stone releases will actually mean even fewer people will be testing each of those releases. We don't magically gain more manhours of testing by having 14 individual isosets in the wild. > B. Change the terms that are being used to describe each test release. > Whether we like it or not, people are used to the "Alpha", "Beta" and > "RC" terms, and tend to consider "Test release" as "Alpha release". I > understand that the term "Test" was used to differentiate the > ever-rolling Fedora from the release-based RHEL, but Fedora has aged > enough to be viewed as an entity by itself and we can drop the "Test" > term. Complete redherring. Changing the naming scheme...again... will only cause additional confusion because it will require yet another change in things such as mirror url locations and updating available documentation on the procecss. This is a pointless change for the sake of change simply because its an easy thing to do, without quantifiable metrics as to the importance of this particular issue. I decree this is completely not important. I'm not even sure how valuable technical feedback is from people who are confused by the naming scheme. At best I expect "those" people to bitch about colorschemes, font glyphs and other stylist aspects which are not of an important technical nature. > C. Once Fedora hits RC, only bug fixes go into the tree. No last minute > 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the > release. Nada. New features can always enter the tree as updates once > the release ISOs have been sent. Easier said than done... and in fact against the very nature of how kernel updates are done once is a release is out. Say it with me... Upstream Upstream Upstream! I think you underestimate the amount of work and time it would require to hand pick individual patches and backport them instead of lifting the next upstream kernel which includes a superset of issues identified in Fedora based testing. The current kernel maintainer may want to comment on this particular issue in more detail, but in an effort to save him his valuable time, I would strongly suggest that you take a look back through the history of fedora-devel mailinglist for kernel maintainer comments concerning the overall goal of reducing the amount of patches being applied to fedora kernels and to stay as close to upstream as is reasonable. I don't think what you are suggesting here as a remedy to the kernel in particular is realistically possible. > > Here's a mock Fedora release schedule: > T-4 Months: Alpha1 > T-X Months: AlphaX > T-1 Months: Beta > T-3 weeks: RC1 - Tree go into lock mode. > T-1.5 weeks: RC2 > T+n weeks: unexpected RC3. > T: release. Part time. Forget for a second the substantial additional burden on the release engineering team associated with the scheduling associated with all the new self-consistent isos you want to see spun up. Or the fact that you have to institute additional freeze deadlines which make it more difficult for individual maintainers to get new tech into the tree at all. Do you really expect a significant number of testers to install even half of these images and do the due dilligence associated with testing of the installer looking for regressions? And if a significant number of people aren't going to be doing the regression testing..then you haven't solved the problem you were aiming to solve. -jef"Every single iso image deadline in that mock up that you expect to pass through release engineering will slip by a week..garunteed. You want a to see 8 milestone isos.. that 2 months of delay associated with any strawman schedule. Hold your breath."spaleta From nicolas.mailhot at laposte.net Sat Nov 11 09:34:07 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 11 Nov 2006 10:34:07 +0100 Subject: X in FC7 In-Reply-To: <20061111092226.GB3041@free.fr> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <20061111092226.GB3041@free.fr> Message-ID: <1163237647.3520.10.camel@rousalka.dyndns.org> Le samedi 11 novembre 2006 ? 10:22 +0100, Patrice Dumas a ?crit : > > > > That said, which apps care about core fonts these days? Would it make > > sense to just build-in a fixed font or something and let everything > > else use fontconfig (as most decent apps do these days)? > > Oldish decent apps use core fonts. Some apps in extras do and there are > certainly more around that are interesting, especially in the scientific > community where users are not interested in eye-candy. Even there I bet they'd love something a little more i18n friendly than core fonts Anyway I pretty much don't care if we keep xfs or not, but I do hope we get rid of the legacy backend that breaks every time an index file slightly changes. Read the fonts at runtime without massaging ? la fontconfig. And pretend you're the old system to legacy apps where people are still rationalising why they don't need to do fixing. -- Nicolas Mailhot From jspaleta at gmail.com Sat Nov 11 09:45:17 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 00:45:17 -0900 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109092658.GC4324@petra.dvoda.cz> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> Message-ID: <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> On 11/9/06, Karel Zak wrote: > - around us are people who use non-Linux systems and rsh is very > important for them > > > Maybe we're already somewhere on the way between classic UNIX and > Windows, but I think it's still to early to forget classic UNIX rule: > > The right tool for the job. Yes assuredly... there are situations to use things like rsh and even telnet-server. But the unanswered question here is.. can those situations be served by moving this functionality into Extras and out of Core? I believe that they can. I also believe that continuing to narrow the focus of Core and to keep Core technology-forward looking is important. We need to be expanding the role that Extras plays in accomidating advanced usage patterns.. even if those advanced usage patterns are what some of us thing are traditional, normal use. How do we make it so we don't need to have all the legacy tools that we need in Core to feel that our needs are being adequately met? How does Extras need to be expanded so that we feel comfortable having our critically important legacy tools live there? -jef"I use rsh..but I don't need it in Core"spaleta From nicolas.mailhot at laposte.net Sat Nov 11 09:52:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 11 Nov 2006 10:52:32 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> Message-ID: <1163238753.3520.15.camel@rousalka.dyndns.org> Hi The OP is right though that having our few rawhide users spend their time doing yum --exclude instead of opening & verifying bugs is hardly a good resource use. We have nice scripts to check repo sanity post release, couldn't they be run pre-release to block obviously broken changes ? Regards, -- Nicolas Mailhot From jspaleta at gmail.com Sat Nov 11 10:02:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 01:02:19 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163238753.3520.15.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> Message-ID: <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> On 11/11/06, Nicolas Mailhot wrote: > Hi > > The OP is right though that having our few rawhide users spend their > time doing yum --exclude instead of opening & verifying bugs is hardly a > good resource use. We have nice scripts to check repo sanity post > release, couldn't they be run pre-release to block obviously broken > changes ? or we instruct testers to use yum-skip-broken plugin that is now available as of fe6. -jef From jos at xos.nl Sat Nov 11 10:31:01 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 11 Nov 2006 11:31:01 +0100 Subject: wireles In-Reply-To: <1163235804.3138.809.camel@laptopd505.fenrus.org>; from arjan@fenrus.demon.nl on Sat, Nov 11, 2006 at 10:03:24AM +0100 References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> <1163235804.3138.809.camel@laptopd505.fenrus.org> Message-ID: <20061111113101.B7204@xos037.xos.nl> On Sat, Nov 11, 2006 at 10:03:24AM +0100, Arjan van de Ven wrote: > the Intel 2100/2200 cards have in-kernel drivers (supported by Intel) > but you need to get some firmware (hopefully that can go into Fedora > proper soon, the license terms are matching with the Fedora requirements > afaiks) Are (external) 2200-based PC Cards sold by Intel and/or OEM'ers? I know them only as built-in/mini-PC cards on Centrino-based laptops (they work fine, also using stock RHEL4 with firmware added) and, given the rest of your answer, they seem to be the best choice when looking for a stable, well-supported 54 Mbps card. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at redhat.com Sat Nov 11 11:00:57 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 11 Nov 2006 06:00:57 -0500 Subject: rawhide report: 20061111 changes Message-ID: <200611111100.kABB0vtB031577@hs20-bc2-6.build.redhat.com> Updated Packages: agg-2.4-3 --------- * Fri Nov 10 2006 Caolan McNamara - 2.4-3 - Resolves: rhbz#214970 rebuild with new 2.4 sources apr-util-1.2.7-4 ---------------- * Sat Nov 11 2006 Joe Orton 1.2.7-4 - add support for BDB 4.5 from upstream, rebuild compiz-0.3.2-1.fc7 ------------------ * Fri Nov 10 2006 Matthias Clasen - 0.3.2-1 - Update to 0.3.2 - Drop upstreamed patches - Work with new metacity theme api coreutils-5.97-14.fc7 --------------------- * Fri Nov 10 2006 Tim Waugh 5.97-14 - Clarified runcon man page (bug #213846). cups-1:1.2.6-5.fc7 ------------------ * Fri Nov 10 2006 Tim Waugh 1:1.2.6-5 - Reload, don't restart, when logrotating (bug #215023). dhcp-12:3.0.5-2.fc7 ------------------- * Fri Nov 10 2006 David Cantrell - 12:3.0.5-2 - Change the way libdhcp4client is compiled (patch main source, create new Makefile rather than copy and patch code after main patches) - Fix up problems generating compiler warnings - Use 'gcc' for making dependencies - Pass -fPIC instead of -fpie/-fPIE in compiler flags - Combine the extended new option info changes in to one patch file (makes it easier for outside projects that want to use dhcdbd and NetworkManager) * Tue Nov 07 2006 David Cantrell - 12:3.0.5-1 - Upgrade to ISC dhcp-3.0.5 * Fri Oct 27 2006 David Cantrell - 12:3.0.4-24 - Put typedef for dhcp_state_e before it's used in libdhcp_control.h (#212612) - Remove dhcpctl.3 from minires/Makefile.dist because it's in dhcpctl - Remove findptrsize.c and just set compiler flag for ppc64 and s390x eclipse-1:3.2.1-18.fc7 ---------------------- * Fri Nov 10 2006 Ben Konrath 3.2.1-18 - Remove SWT ON_TOP patch as it is fixed in 3.2.1. foomatic-3.0.2-41.fc7 --------------------- * Fri Nov 10 2006 Tim Waugh 3.0.2-41 - Updated db-engine to 3.0-20061109 (bug #197331). glibc-2.5.90-6 -------------- * Fri Nov 10 2006 Jakub Jelinek 2.5.90-6 - fix strxfrm fix - fix i?86 floor and ceil inlines (BZ#3451) httpd-2.2.3-6 ------------- * Sat Nov 11 2006 Joe Orton 2.2.3-6 - rebuild for BDB soname bump lvm2-2.02.14-1.fc7 ------------------ * Sat Nov 11 2006 Alasdair Kergon - 2.02.14-1 - New upstream - see WHATS_NEW. openoffice.org-1:2.1.0-2.4 -------------------------- * Fri Nov 10 2006 Caolan McNamara - 1:2.1.0-2.4 - Resolves: rhbz#214889 - drop using agg - rebuild for new db4 * Fri Nov 10 2006 Caolan McNamara - 1:2.1.0-2.3 - Resolves: rhbz#214896 pt/pt_BR translations - Resolves: rhbz#214887 pt/pt_BR translations - Resolves: rhbz#214973 collate print setting openssh-4.3p2-12.fc7 -------------------- * Fri Nov 10 2006 Tomas Mraz - 4.3p2-12 - CVE-2006-5794 - properly detect failed key verify in monitor (#214641) pirut-1.2.8-1.fc7 ----------------- * Fri Nov 10 2006 Jeremy Katz - 1.2.8-1 - Clear deps on transaction cancel (#213421) - Make puplet text be "View Updates..." (#214627) - More verbose error for yum-updatesd not being available (#213520) - Stick information about a package requiring a reboot in the details (#214794) python-pyblock-0.24-3 --------------------- * Fri Nov 10 2006 Peter Jones - 0.24-3 - Rebuild for new dmraid redhat-artwork-5.0.8-3.fc7 -------------------------- * Thu Nov 09 2006 Matthias Clasen 5.0.8-3 - Make sure the trash applet uses the right icon selinux-policy-2.4.3-10 ----------------------- * Fri Nov 10 2006 Dan Walsh 2.4.3-10 - Allow xen to connect to xen port * Fri Nov 10 2006 Dan Walsh 2.4.3-9 - Allow cups to search samba_etc_t directory - Allow xend_t to list auto_mountpoints shared-mime-info-0.19-2.fc7 --------------------------- * Fri Nov 10 2006 Christopher Aillon - 0.19-2 - Alias image/pdf to application/pdf system-config-nfs-1.3.21-1.fc7 ------------------------------ * Fri Nov 10 2006 Nils Philippsen 1.3.21 - don't apply string-escape decoder on /etc/exports - add dist tag * Thu Nov 09 2006 Nils Philippsen - handle multilines between client specs (#214163) - don't barf on optionless clients * Wed Nov 08 2006 Nils Philippsen - begin to understand multilines (#214163) system-config-printer-0.7.36-1.fc7 ---------------------------------- * Fri Nov 10 2006 Tim Waugh 0.7.36-1 - 0.7.36: - Match against commandset (bug #214181). - Parse 'ieee1284' foomatic autodetect entries (bug #214761). - Don't remove foomatic PPDs from the list (bug #197331). udev-103-2 ---------- * Fri Nov 10 2006 Harald Hoyer - 103-2 - changed SYSFS to new ATTR rules - Resolves: rhbz#214898 * Fri Nov 10 2006 Harald Hoyer - 103-1 - Removed 51-hotplug.rules - Resolves: rhbz#214277 vim-2:7.0.162-1 --------------- * Fri Nov 10 2006 Karsten Hopp 7.0.162-1 - patchlevel 162 xorg-x11-server-1.1.1-51.fc7 ---------------------------- * Fri Nov 10 2006 Adam Jackson 1.1.1-51.fc7 - xorg-x11-server-1.1.1-no-scanpci.patch: Drop scanpci, it's huge and there's no added value relative to lspci. - xorg-x11-server-1.1.1-spurious-libxf1bpp-link.patch: Minor linktime fixup. There's no reason for libxf4bpp to link against libxf1bpp. xorg-x11-xinit-1.0.2-14.fc7 --------------------------- * Fri Nov 10 2006 Ray Strode - 1.0.2-14 - start client in its own session with no controlling tty (bug 214649) yum-3.0.1-2.fc7 --------------- * Fri Nov 10 2006 Jeremy Katz - 3.0.1-2 - yum-updatesd fixes (#213622, #212494, #212507) * Fri Nov 03 2006 Jeremy Katz - 3.0.1-1 - update to 3.0.1 * Fri Oct 13 2006 Paul Nasrat - 3.0-6 - fix package comparison for available packages Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From arjan at fenrus.demon.nl Sat Nov 11 11:02:37 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 11 Nov 2006 12:02:37 +0100 Subject: wireles In-Reply-To: <20061111113101.B7204@xos037.xos.nl> References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> <1163235804.3138.809.camel@laptopd505.fenrus.org> <20061111113101.B7204@xos037.xos.nl> Message-ID: <1163242958.3293.3.camel@laptopd505.fenrus.org> On Sat, 2006-11-11 at 11:31 +0100, Jos Vos wrote: > On Sat, Nov 11, 2006 at 10:03:24AM +0100, Arjan van de Ven wrote: > > > the Intel 2100/2200 cards have in-kernel drivers (supported by Intel) > > but you need to get some firmware (hopefully that can go into Fedora > > proper soon, the license terms are matching with the Fedora requirements > > afaiks) > > Are (external) 2200-based PC Cards sold by Intel and/or OEM'ers? For 2200 I don't know; they might be. For 3945 I know you can get a version that is using the PCI Express variant van cardbus/pcmcia... de nieuwere laptops hebben daar een slot voor (mijn t43 heeft dat al en die's zowat een jaar oud) From arjan at fenrus.demon.nl Sat Nov 11 11:05:28 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 11 Nov 2006 12:05:28 +0100 Subject: wireles In-Reply-To: <1163242958.3293.3.camel@laptopd505.fenrus.org> References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> <1163235804.3138.809.camel@laptopd505.fenrus.org> <20061111113101.B7204@xos037.xos.nl> <1163242958.3293.3.camel@laptopd505.fenrus.org> Message-ID: <1163243128.3293.6.camel@laptopd505.fenrus.org> On Sat, 2006-11-11 at 12:02 +0100, Arjan van de Ven wrote: > On Sat, 2006-11-11 at 11:31 +0100, Jos Vos wrote: > > On Sat, Nov 11, 2006 at 10:03:24AM +0100, Arjan van de Ven wrote: > > > > > the Intel 2100/2200 cards have in-kernel drivers (supported by Intel) > > > but you need to get some firmware (hopefully that can go into Fedora > > > proper soon, the license terms are matching with the Fedora requirements > > > afaiks) > > > > Are (external) 2200-based PC Cards sold by Intel and/or OEM'ers? > > For 2200 I don't know; they might be. For 3945 I know you can get a > version that is using the PCI Express variant van cardbus/pcmcia... de > nieuwere laptops hebben daar een slot voor (mijn t43 heeft dat al en > die's zowat een jaar oud) eh if I start in English I should finish in English For 2200 I don't know; they might be. For 3945 I know you can get a version that is using the PCI Express variant of cardbus/pcmcia... (mini pci express or something). The newer laptops have a slot for that; my t43 has one and it's about a year old already. > From n0dalus+redhat at gmail.com Sat Nov 11 11:05:33 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 11 Nov 2006 21:35:33 +1030 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> Message-ID: <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> On 11/11/06, Jeff Spaleta wrote: > or we instruct testers to use yum-skip-broken plugin that is now > available as of fe6. > I think that's missing the point. Testers should have to do as little voodoo as possible on their machines to get a working rawhide install. Telling them to install a yum plugin is just as bad as telling them to --exclude={,,,}. Multiply every minute you expect testers to sit there trying to work out why updates aren't happening and installing plugins by the number of testers and the result is a substantial waste of time (that could have been used to find real bugs). Maybe the yum-skip-broken plugin should be installed by default in test releases. Or maybe we could just fix the build system. Any new update generated by the build system that isn't installable due to dependencies should be put in a temporary place until the dependent packages arrive. n0dalus. From jos at xos.nl Sat Nov 11 11:07:49 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 11 Nov 2006 12:07:49 +0100 Subject: wireles In-Reply-To: <1163242958.3293.3.camel@laptopd505.fenrus.org>; from arjan@fenrus.demon.nl on Sat, Nov 11, 2006 at 12:02:37PM +0100 References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> <1163235804.3138.809.camel@laptopd505.fenrus.org> <20061111113101.B7204@xos037.xos.nl> <1163242958.3293.3.camel@laptopd505.fenrus.org> Message-ID: <20061111120749.C7204@xos037.xos.nl> On Sat, Nov 11, 2006 at 12:02:37PM +0100, Arjan van de Ven wrote: > For 2200 I don't know; they might be. For 3945 I know you can get a > version that is using the PCI Express variant van cardbus/pcmcia... de > nieuwere laptops hebben daar een slot voor (mijn t43 heeft dat al en > die's zowat een jaar oud) You switched to Dutch in the middle of the answer... :-). Which I can understand, but some others might not... :-). Anyway, I need a solution for a non-laptop computer that has a built-in PC Card slot type II. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dragoran at feuerpokemon.de Sat Nov 11 11:27:38 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 11 Nov 2006 12:27:38 +0100 Subject: rawhide report: 20061111 changes In-Reply-To: <200611111100.kABB0vtB031577@hs20-bc2-6.build.redhat.com> References: <200611111100.kABB0vtB031577@hs20-bc2-6.build.redhat.com> Message-ID: <4555B3AA.9030605@feuerpokemon.de> > > compiz-0.3.2-1.fc7 > ------------------ > * Fri Nov 10 2006 Matthias Clasen - 0.3.2-1 > - Update to 0.3.2 > - Drop upstreamed patches > - Work with new metacity theme api > can we have this as a fc6 update (after some testing)? see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208044 From linux_4ever at yahoo.com Sat Nov 11 12:14:34 2006 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 11 Nov 2006 04:14:34 -0800 (PST) Subject: rawhide report: 20061111 changes - beware of yum !! In-Reply-To: <200611111100.kABB0vtB031577@hs20-bc2-6.build.redhat.com> Message-ID: <840796.47949.qm@web51502.mail.yahoo.com> >yum-3.0.1-2.fc7 >--------------- >* Fri Nov 10 2006 Jeremy Katz - 3.0.1-2 >- yum-updatesd fixes (#213622, #212494, #212507) Downloading Packages: (1/1): yum-3.0.1-2.fc7.no 100% |=========================| 479 kB 00:02 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction warning: /etc/yum.conf saved as /etc/yum.conf.rpmsave Removing : yum ######################### [1/2] Updating : yum ######################### [2/2] Updated: yum.noarch 0:3.0.1-2.fc7 Complete! [root at localhost ~]# yum update CRITICAL:yum.cli:Config Error: Error accessing file for config file:///etc/yum.conf [root at localhost ~]# ls -l /etc/ | grep yum drwxr-xr-x 3 root root 4096 Nov 10 11:56 yum -rw-r--r-- 1 root root 368 Nov 6 11:28 yum.conf.rpmsave drwxr-xr-x 2 root root 4096 Nov 10 11:56 yum.repos.d Does yum have a download only mode anymore? I think I want to go back to using just rpm to do updates to see if this is caused by yum or rpm. I've heard rumors of other critical config files dissappearing by doing yum update. -Steve ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index From vonbrand at inf.utfsm.cl Fri Nov 10 21:19:31 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 10 Nov 2006 18:19:31 -0300 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: Message from Gilboa Davara of "Fri, 10 Nov 2006 16:55:42 +0200." <1163170542.26941.60.camel@gilboa-home-dev.localhost> Message-ID: <200611102121.kAALJVf2010542@laptop13.inf.utfsm.cl> Gilboa Davara wrote: > I use Fedora daily, and I have a vested interest in -actively- helping > Fedora (and in-turn RHEL) become a better product. Report problems as you find them. Check out test packages for stuff you care about. > I don't have a dedicated Rawhide machine, I do play with it from time to > time using VMWare Server, but this is fairly light testing as I'm pretty > short on time. (Just to see what's new) > I -do- try to install (at least on a VM machine) every test release and > give it a day or two of testing - but even this is hardly enough. It will help weed out DOA problems, so it does help. > FC6 was a good release, but certain managed to slip through... some of > them rather critical (i586 kernel springs to mind) which should have > been found by us. (Read: testers) Need more of that stuff. Right. > As I see it, there's not enough Rawhide users to reduce the release bug > count, mainly because: > A. In my experience, 1 out of 2 rawhide installs break due to missing > dependencies - and spending four hours (and ~1+GB of bandwidth) just to > watch Anaconda choke on missing pygtk package is very frustrating. I'm running rawhide, udated (almost) daily by yum. When stuff doesn't update OK, it is usually enough to add it with --exclude and try again. Luckily, yum keeps what it's got already in cache, so... > B. Rawhide tends to break, a-lot. Not in my experience... yes, packages do break (sometimes), but on the whole it works just fine (for me). > C. As much as I disagree with this notion, people view Fedora as RHEL's > Alpha and view Rawhide as "experimental Alpha". Can't change that perception easily... > More then anything FC6 proved that 3 test releases may not be enough to > get a bug free release, A 100 test releases won't, so... > so let me suggest the following: > A. Create more mile-stone releases. Once the tree reaches build > integrity (no missing packages), spin a test release. (Fixes P1, P2) Test 1 should (at the very least) be there, and so should the others. > B. Change the terms that are being used to describe each test release. > Whether we like it or not, people are used to the "Alpha", "Beta" and > "RC" terms, and tend to consider "Test release" as "Alpha release". I > understand that the term "Test" was used to differentiate the > ever-rolling Fedora from the release-based RHEL, but Fedora has aged > enough to be viewed as an entity by itself and we can drop the "Test" > term. Yep. Alpha == don't ever use it if you aren't downright suicidal Beta == Use only when you don't care one bit for your data/machine/sanity RC == Let's wait until it is there "for real", let others get burned > Using "normal" terms should help combat the "RHEL Alpha" and 'RHEL Alpha > experimental" image problem (Fixes P3). Fedora users /should/ have gotten the message by now... > C. Once Fedora hits RC, only bug fixes go into the tree. No last minute > 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the > release. Nada. New features can always enter the tree as updates once > the release ISOs have been sent. Look at the roadmaps that have been published for, e.g., Fedora 5 and 6... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From benny+usenet at amorsen.dk Sat Nov 11 13:10:08 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 11 Nov 2006 14:10:08 +0100 Subject: Testing Fedora - small (?) suggestion. References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> -jef"Every single iso image deadline in that mock up that you JS> expect to pass through release engineering will slip by a JS> week..garunteed. You want a to see 8 milestone isos.. that 2 JS> months of delay associated with any strawman schedule. Hold your JS> breath."spaleta Would it be possible to automatically detect when the rawhide tree is in shape for installation, and then spin an ISO? I bet it would mean some broken ISO's in the beginning, but hopefully the automatic problem detection would be improved over time. /Benny From arjan at fenrus.demon.nl Sat Nov 11 13:26:02 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 11 Nov 2006 14:26:02 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> Message-ID: <1163251562.3293.25.camel@laptopd505.fenrus.org> On Sat, 2006-11-11 at 14:10 +0100, Benny Amorsen wrote: > >>>>> "JS" == Jeff Spaleta writes: > > JS> -jef"Every single iso image deadline in that mock up that you > JS> expect to pass through release engineering will slip by a > JS> week..garunteed. You want a to see 8 milestone isos.. that 2 > JS> months of delay associated with any strawman schedule. Hold your > JS> breath."spaleta > > Would it be possible to automatically detect when the rawhide tree is > in shape for installation, and then spin an ISO? I bet it would mean > some broken ISO's in the beginning, but hopefully the automatic > problem detection would be improved over time. with something like KVM (kvm.sf.net) you could do fully automatic ISO spinning, and then do a trial install automated into the virtual machine (using kickstart) that then could "phone home" when finished. It's a good QA thing, and it's a first step towards more frequent/more reliable iso spins, but it's not a substitute for humans doing trial installs/freezes :( From katzj at redhat.com Sat Nov 11 13:35:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 11 Nov 2006 08:35:49 -0500 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <1163252149.25333.10.camel@aglarond.local> On Fri, 2006-11-10 at 16:37 -0800, Jesse Barnes wrote: > Also, which input drivers should we be using? Isn't synaptics much > better for laptops than the default mouse driver? If you go through anaconda and we detect that you've got a synaptics (or similar) device present, we go ahead and set up the mouse device for it. Jeremy From gilboad at gmail.com Sat Nov 11 15:21:06 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 11 Nov 2006 17:21:06 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> Message-ID: <1163258466.26941.146.camel@gilboa-home-dev.localhost> On Sat, 2006-11-11 at 00:28 -0900, Jeff Spaleta wrote: > On 11/10/06, Gilboa Davara wrote: > > A. Create more mile-stone releases. Once the tree reaches build > > integrity (no missing packages), spin a test release. (Fixes P1, P2) > > Logic fault... we dont have enough testers right now... more > mile-stone releases will actually mean even fewer people will be > testing each of those releases. We don't magically gain more manhours > of testing by having 14 individual isosets in the wild. You've missed my point. Take Mozilla - each and every night they release a nightly build. Do all of these builds get used? -Far- from it. So why do they do it? Simple, because they want to -lower- the amount of voodoo magic required by a tester in-order to get the damn thing (excuse my language) built/installed. Point of reason: A. The biggest issue with any Linux distribution is the installer. B. We don't have enough rawhide testers. C. Trying to install Rawhide from scratch (in-order to test the Anaconda) is a -very- frustrating experience. (As I said, at least for me, it's has a 50% chance of blowing up). E. A tester that had his Rawhide installer die due to missing package, is a tester that may never try Rawhide again. So as a result... F. ...most rawhide users avoid the frustration by installing the latest release and using yum-to-development to jump (plus massive --exclude) to get Rawhide installed. However.... G. ..install Rawhide using yum doesn't test the installer. But... H. Spinning ISO is a labor intensive task. Solution: A. Create* a tool that's capable of detecting tree integrity. B. Execute this tool once a day. C. Once the said tools finds no broken packages (for arch N), copy the packages to a different directory, label it by date and... D. Send an automated message to fedora-devel, testers, that a new label is out. * I assume that such capability already exists within yum. > > B. Change the terms that are being used to describe each test release. > > Whether we like it or not, people are used to the "Alpha", "Beta" and > > "RC" terms, and tend to consider "Test release" as "Alpha release". I > > understand that the term "Test" was used to differentiate the > > ever-rolling Fedora from the release-based RHEL, but Fedora has aged > > enough to be viewed as an entity by itself and we can drop the "Test" > > term. > > Complete redherring. Changing the naming scheme...again... Why again? > will only cause additional confusion because it will require yet another change > in things such as mirror url locations and updating available > documentation on the procecss. I doubt it. Current test releases are called .9, and it had been so since, baah, RedHat 4? URL won't change. As for documentation - I don't know enough to comment about that. > This is a pointless change for the > sake of change simply because its an easy thing to do, without > quantifiable metrics as to the importance of this particular issue. I > decree this is completely not important. > I'm not even sure how valuable technical feedback is from people who > are confused by the naming scheme. At best I expect "those" people to > bitch about colorschemes, font glyphs and other stylist aspects which > are not of an important technical nature. While my sampling group is small, not more then 15 Linux using friends and coworkers. They all work in Hi-Tech companies. Most of them are active in local LUGs and/or contribute time/code/etc to the OSS world. Most of them are using unstable distributions - Debian Sid, Unstable Gentoo (assuminh there's a stable one...) and OpenSUSE (Though I'd assume OpenSUSE will drop like a stone now) Neither of them is "ugly-font-joe-six-pack"... far from it. Come to think about it, "ugly-font-joe-six-pack" doesn't know what Alpha/beta/RC means - he may understand what test means. Anyone living in the software development world is used to judge the stability of software by the term Alpha/Beta/RC and lack of them is confusing. > > > C. Once Fedora hits RC, only bug fixes go into the tree. No last minute > > 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the > > release. Nada. New features can always enter the tree as updates once > > the release ISOs have been sent. > > Easier said than done... and in fact against the very nature of how > kernel updates are done once is a release is out. Say it with me... > Upstream Upstream Upstream! I think you underestimate the amount of > work and time it would require to hand pick individual patches and > backport them instead of lifting the next upstream kernel which > includes a superset of issues identified in Fedora based testing. One of the basic thumb rules in software development is that if you change basic-component-X within product-Z, most/all of the testing that has been conducted up to this day should be repeated. Put a new glibc and/or kernel, 4 days before the release, and you'll need at least one major RC release to clean up the mess or you may end up with a broken release. (And being a long time FC user, I do remember a couple of those...) > > The current kernel maintainer may want to comment on this particular > issue in more detail, but in an effort to save him his valuable time, > I would strongly suggest that you take a look back through the history > of fedora-devel mailinglist for kernel maintainer comments concerning > the overall goal of reducing the amount of patches being applied to > fedora kernels and to stay as close to upstream as is reasonable. I > don't think what you are suggesting here as a remedy to the kernel in > particular is realistically possible. The problem is not upstream vs. patch-set. The problem is "release a new kernel/glibc two days before the release without any type of meaningful testing" > > > > Here's a mock Fedora release schedule: > > T-4 Months: Alpha1 > > T-X Months: AlphaX > > T-1 Months: Beta > > T-3 weeks: RC1 - Tree go into lock mode. > > T-1.5 weeks: RC2 > > T+n weeks: unexpected RC3. > > T: release. Part time. > > Forget for a second the substantial additional burden on the release > engineering team associated with the scheduling associated with all > the new self-consistent isos you want to see spun up. Or the fact > that you have to institute additional freeze deadlines which make it > more difficult for individual maintainers to get new tech into the > tree at all. Do you really expect a significant number of testers to > install even half of these images and do the due dilligence associated > with testing of the installer looking for regressions? And if a > significant number of people aren't going to be doing the regression > testing..then you haven't solved the problem you were aiming to solve. See above. Question: Can pungi be used to auto-create the ISOs? > > > -jef"Every single iso image deadline in that mock up that you expect > to pass through release engineering will slip by a week..garunteed. > You want a to see 8 milestone isos.. that 2 months of delay associated > with any strawman schedule. Hold your breath."spaleta Gilboa "unless the ISO is being mastered and uploaded automatically by a script every time depcheck decides that there's no missing packages" Davara From gilboad at gmail.com Sat Nov 11 15:47:57 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 11 Nov 2006 17:47:57 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611102121.kAALJVf2010542@laptop13.inf.utfsm.cl> References: <200611102121.kAALJVf2010542@laptop13.inf.utfsm.cl> Message-ID: <1163260077.26941.173.camel@gilboa-home-dev.localhost> On Fri, 2006-11-10 at 18:19 -0300, Horst H. von Brand wrote: > Gilboa Davara wrote: > > I use Fedora daily, and I have a vested interest in -actively- helping > > Fedora (and in-turn RHEL) become a better product. > > Report problems as you find them. Check out test packages for stuff you > care about. Being done. > > I don't have a dedicated Rawhide machine, I do play with it from time to > > time using VMWare Server, but this is fairly light testing as I'm pretty > > short on time. (Just to see what's new) > > I -do- try to install (at least on a VM machine) every test release and > > give it a day or two of testing - but even this is hardly enough. > > It will help weed out DOA problems, so it does help. I know. That's why I'm doing it ;) > > > FC6 was a good release, but certain managed to slip through... some of > > them rather critical (i586 kernel springs to mind) which should have > > been found by us. (Read: testers) > > Need more of that stuff. Right. > > > As I see it, there's not enough Rawhide users to reduce the release bug > > count, mainly because: > > A. In my experience, 1 out of 2 rawhide installs break due to missing > > dependencies - and spending four hours (and ~1+GB of bandwidth) just to > > watch Anaconda choke on missing pygtk package is very frustrating. > > I'm running rawhide, udated (almost) daily by yum. When stuff doesn't > update OK, it is usually enough to add it with --exclude and try > again. Luckily, yum keeps what it's got already in cache, so... Problem is, using yum to install Rawhide (from latest stable release) doesn't test the installer, and the installer is one of the biggest test items. (... Touchy subject, I just lost a machine due to a botched upgrade... eeek! [already in Bugzilla]) > > > B. Rawhide tends to break, a-lot. > > Not in my experience... yes, packages do break (sometimes), but on the > whole it works just fine (for me). During the FC4 -> FC5 -> FC6. I tried installing (from scratch) and/or upgrading (using Anaconda) Rawhide at least 10 times. If I recall, I only see firstboot... err.... twice. That's ~20% success rate. Doing yum -> rawhide is easy... but as I said, Anaconda is my favorite testing pet ;) > > > C. As much as I disagree with this notion, people view Fedora as RHEL's > > Alpha and view Rawhide as "experimental Alpha". > > Can't change that perception easily... But we -should- try. > > > More then anything FC6 proved that 3 test releases may not be enough to > > get a bug free release, > > A 100 test releases won't, so... I agree. > > > so let me suggest the following: > > A. Create more mile-stone releases. Once the tree reaches build > > integrity (no missing packages), spin a test release. (Fixes P1, P2) > > Test 1 should (at the very least) be there, and so should the others. OK. > > B. Change the terms that are being used to describe each test release. > > Whether we like it or not, people are used to the "Alpha", "Beta" and > > "RC" terms, and tend to consider "Test release" as "Alpha release". I > > understand that the term "Test" was used to differentiate the > > ever-rolling Fedora from the release-based RHEL, but Fedora has aged > > enough to be viewed as an entity by itself and we can drop the "Test" > > term. > > Yep. > > Alpha == don't ever use it if you aren't downright suicidal > Beta == Use only when you don't care one bit for your data/machine/sanity > RC == Let's wait until it is there "for real", let others get burned People who view Alpha/beta/RC as suicidal won't touch test release and won't even think about using Rawhide, so we don't really care about them (in the testing context), do we? As I see it, most people won't touch Alpha, but some brave souls will. (Lets assume Test1 is pretty much Alpha-stuff) More people will touch Beta 1 - a number that will slowly increase as Beta count progresses. When the thing hits RC, usage numbers should increase dramatically. (look at the Vista download count... they are huge! [and we are talking about ... Windows users. *Cough]). RC releases give you enough time to fix last minute bugs that may make Fedora look like Alpha-ware once the main release is out. (Read: missing print_tained export [FC5] or i586 kernel [FC6]). > > > Using "normal" terms should help combat the "RHEL Alpha" and 'RHEL Alpha > > experimental" image problem (Fixes P3). > > Fedora users /should/ have gotten the message by now... Yes, but Fedora testers < Fedora users < Linux users < Software users. I (as in, well, I) want a bigger share of the pie. More users and in the long term, more testers. > > > C. Once Fedora hits RC, only bug fixes go into the tree. No last minute > > 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the > > release. Nada. New features can always enter the tree as updates once > > the release ISOs have been sent. > > Look at the roadmaps that have been published for, e.g., Fedora 5 and 6... I don't remember much about FC1/2/3, but FC4/5/6 all over-shoot the initial schedule - FC5 and 6 saw lot of last minute breakage. (Though I'm the last to talk about schedules... the project I'm working on is 8 months over-due... ;)) - Gilboa From wtogami at redhat.com Sat Nov 11 16:19:18 2006 From: wtogami at redhat.com (Warren Togami) Date: Sat, 11 Nov 2006 11:19:18 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163168226.26941.21.camel@gilboa-home-dev.localhost> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> Message-ID: <4555F806.80709@redhat.com> Gilboa Davara wrote: > Hello all, > > The attached patch (which should cover all 64bit arches) enable you to > start the 32bit version of firefox (if it's installed) by starting > firefox with the "--32" command line option. > > Before I submit this to bugzilla, I have two questions: > > - Do we rather have a single firefox script that executes both 32bit and > 64bit or do we want to break the it to dedicated firefox[64] and > firefox32 scripts. > - Where should I submit this patch? Mozilla or redhat? > > - Gilboa https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214100 I wrote an alternative implementation in this bug. I don't fully agree with the rejection of this, but I do agree that the best long-term solution is to fix nspluginwrapper to offload *ALL* plugins to a separate process. A separate process also allows greater security control with selinux. Logic of my Implementation: * If only the /usr/lib browser is installed, run it. * If only the /usr/lib64 browser is installed, run it. * If both are installed, run /usr/lib64 unless it is overridden in /etc/sysconfig/firefox-arch. * Allow editing /etc/sysconfig/firefox-arch as the official means for the system administrator to override their arch selection. %config(noreplace) %{_sysconfdir}/sysconfig/firefox-arch This is necessary in the %files section of firefox.spec. Benefits of this approach: 1) This DOES NOT CHANGE the behavior from its current default, which works with browsers shipped on x86_64. 2) This defines an explicit way for the system administrator to override their arch selection in a way that wont break with future package updates. This effectively enables CHOICE. Warren Togami wtogami at redhat.com From fedora at camperquake.de Sat Nov 11 16:19:50 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 11 Nov 2006 17:19:50 +0100 Subject: X in FC7 In-Reply-To: <20061111042704.GA847601@hiwaay.net> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <20061111042704.GA847601@hiwaay.net> Message-ID: <20061111171950.62af0203@nausicaa.camperquake.de> Hi. Chris Adams wrote: > There's only one xterm as well; for example, nobody else has Tek4014 > emulation (useful for legacy apps). Also, xterm is lighter weight than > gnome-terminal. And it works, which is more than could be said about gnome-terminal for quite some time (I asmit that I do not know the current state of vte, for lack of interest). -- Trust the computer industry to shorten "Year 2000" to Y2K. It was this kind of thinking that caused the problem in the first place. From fedora at camperquake.de Sat Nov 11 16:23:36 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 11 Nov 2006 17:23:36 +0100 Subject: wireles In-Reply-To: <20061111060140.77397.qmail@web54302.mail.yahoo.com> References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> Message-ID: <20061111172336.636a8616@nausicaa.camperquake.de> Hi. "Frank S." wrote: > Sorry to bother you I know i should ask this questions in a forum but > i have try with no result so: I need to get a wireless wifi PC card for > my laptop and a pci wifi card for my desktop, I do NOT want to use > Ndiswrap or anything similar to that I would to get one that works out > of the box, PLEASE could you recommend me one Thank you very much If you can live with it (and if you can find it, which will be quite more complicated): something based on the old hermes/orinoco chipsets. Which will only do 11b (11MBit), but work without funny firmwares. -- Michael Jordan makes more money from Nike annually than all of the Nike factory workers in Malaysia combined. From Lam at Lam.pl Sat Nov 11 16:34:39 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 11 Nov 2006 17:34:39 +0100 Subject: X in FC7 In-Reply-To: <20061111171950.62af0203@nausicaa.camperquake.de> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <20061111042704.GA847601@hiwaay.net> <20061111171950.62af0203@nausicaa.camperquake.de> Message-ID: <1163262879.9428.6.camel@pensja.lam.pl> Dnia 11-11-2006, sob o godzinie 17:19 +0100, Ralf Ertzinger napisa?(a): > > Also, xterm is lighter weight than > > gnome-terminal. > And it works, which is more than could be said about gnome-terminal for > quite some time (I asmit that I do not know the current state of vte, > for lack of interest). After last truly working version being 1.4.x, it was made working again... in FC5 updates (2.14.1, vte 0.12.1). You should recheck :) Personally I gave up multi-gnome-terminal 1.6.2 at last :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From fedora at camperquake.de Sat Nov 11 17:00:40 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 11 Nov 2006 18:00:40 +0100 Subject: Proposal: Consolidate yum directory usage Message-ID: <20061111180040.5c959414@nausicaa.camperquake.de> Hi. I think the current usage of configuration files and directories for yum has somewhat gotten out of hand. yum-3.0.1-1 uses one config file (yum.conf), and two configuration directories (yum.repos.d and yum, which in turn just contains pluginconf.d) under /etc. I propose to move all yum configuration files and directories to /etc/yum (move /etc/yum.conf to /etc/yum/yum.conf, move /etc/yum.repos.d to /etc/yum/repos.d). This could easily be done by a %post scriptlet during an RPM transaction. Symlinks ought to be set (yum.conf -> yum/yum.conf and yum.repos.d -> yum/repos.d) to keep other packages working which drop files in yum.repos.d. And there are tons of documents which reference /etc/yum.conf. Maybe yum ought to show warnings (after FC7, maybe) when it detects that /etc/yum.conf or /etc/yum.repos.d still exist (even as symlinks) and advise the user that usage of these files is deprecated. If there is interest in this I'll produce patches for the spec file (to migrate the config) and for yum (to find files in the new locations and to show deprecation warnings) -- "All men are frauds. The only difference between them is that some admit it. I myself deny it." -- H.L. Mencken From jkeating at redhat.com Sat Nov 11 18:04:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 13:04:14 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> Message-ID: <200611111304.14744.jkeating@redhat.com> On Saturday 11 November 2006 06:05, n0dalus wrote: > Maybe the yum-skip-broken plugin should be installed by default in > test releases. Or maybe we could just fix the build system. Any new > update generated by the build system that isn't installable due to > dependencies should be put in a temporary place until the dependent > packages arrive. And then we'll never get a rawhide tree out. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Nov 11 18:05:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 13:05:58 -0500 Subject: Proposal: Consolidate yum directory usage In-Reply-To: <20061111180040.5c959414@nausicaa.camperquake.de> References: <20061111180040.5c959414@nausicaa.camperquake.de> Message-ID: <200611111305.58973.jkeating@redhat.com> On Saturday 11 November 2006 12:00, Ralf Ertzinger wrote: > If there is interest in this I'll produce patches for the spec file > (to migrate the config) and for yum (to find files in the new locations > and to show deprecation warnings) This is better discussed in the upstream yum development list. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Nov 11 18:09:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 13:09:34 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163258466.26941.146.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163258466.26941.146.camel@gilboa-home-dev.localhost> Message-ID: <200611111309.35147.jkeating@redhat.com> On Saturday 11 November 2006 10:21, Gilboa Davara wrote: > Question: Can pungi be used to auto-create the ISOs? Cron is your friend. Missing deps isn't the problem, its the actual functionality of the installer, or of the packages being installed. These are harder to test automatically, and harder to fix without a freeze in place. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Nov 11 18:11:59 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 13:11:59 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163238753.3520.15.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> Message-ID: <200611111312.00030.jkeating@redhat.com> On Saturday 11 November 2006 04:52, Nicolas Mailhot wrote: > The OP is right though that having our few rawhide users spend their > time doing yum --exclude instead of opening & verifying bugs is hardly a > good resource use. We have nice scripts to check repo sanity post > release, couldn't they be run pre-release to block obviously broken > changes ? The broken dep isn't always something everybody would hit, and with the size of the package base it would be pretty hard to hold up trees from being released until such time the entire package set has no broken deps. It would leave testers out in the cold for testing specific package functionality or testing bugfixes. I think we're putting too much emphasis on rawhide being a completely installable tree. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Nov 11 18:26:09 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 11 Nov 2006 19:26:09 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111304.14744.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <200611111304.14744.jkeating@redhat.com> Message-ID: <1163269570.7856.32.camel@rousalka.dyndns.org> Le samedi 11 novembre 2006 ? 13:04 -0500, Jesse Keating a ?crit : > On Saturday 11 November 2006 06:05, n0dalus wrote: > > Maybe the yum-skip-broken plugin should be installed by default in > > test releases. Or maybe we could just fix the build system. Any new > > update generated by the build system that isn't installable due to > > dependencies should be put in a temporary place until the dependent > > packages arrive. > > And then we'll never get a rawhide tree out. Not if we block only the broken parts. You know, instead of using testers to shame maintainers in fixing broken deps, have the buildsys do it, and only expose sane trees to users (with the "broken" packagesets being held where the buildsys can find them till they're complete) -- Nicolas Mailhot From jkeating at redhat.com Sat Nov 11 18:34:52 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 13:34:52 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163269570.7856.32.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111304.14744.jkeating@redhat.com> <1163269570.7856.32.camel@rousalka.dyndns.org> Message-ID: <200611111334.52442.jkeating@redhat.com> On Saturday 11 November 2006 13:26, Nicolas Mailhot wrote: > Not if we block only the broken parts. You know, instead of using > testers to shame maintainers in fixing broken deps, have the buildsys do > it, and only expose sane trees to users (with the "broken" packagesets > being held where the buildsys can find them till they're complete) Thats quite the complexity to try spinning the tree, find broken deps, drop out packages, try again, rather, rinse repeat. Look, rawhide is just a work in progress, a snapshot of what happened the day before. We can't aways have a completely stable tree. Trying for that is the road to insanity. This is why we have test releases where we freeze things to get the tree into a sane state. Could we do more frozen iso releases? Possibly, depending on the build system we use and how freezes can be handled. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux at gmail.com Sat Nov 11 19:03:30 2006 From: selinux at gmail.com (Tom London) Date: Sat, 11 Nov 2006 11:03:30 -0800 Subject: rawhide report: 20061111 changes - beware of yum !! In-Reply-To: <840796.47949.qm@web51502.mail.yahoo.com> References: <200611111100.kABB0vtB031577@hs20-bc2-6.build.redhat.com> <840796.47949.qm@web51502.mail.yahoo.com> Message-ID: <4c4ba1530611111103n1e0398a9h3274bce74964d677@mail.gmail.com> On 11/11/06, Steve G wrote: > > >yum-3.0.1-2.fc7 > >--------------- > >* Fri Nov 10 2006 Jeremy Katz - 3.0.1-2 > >- yum-updatesd fixes (#213622, #212494, #212507) > > > Downloading Packages: > (1/1): yum-3.0.1-2.fc7.no 100% |=========================| 479 kB 00:02 > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > warning: /etc/yum.conf saved as /etc/yum.conf.rpmsave > Removing : yum ######################### [1/2] > Updating : yum ######################### [2/2] > > Updated: yum.noarch 0:3.0.1-2.fc7 > Complete! > [root at localhost ~]# yum update > CRITICAL:yum.cli:Config Error: Error accessing file for config > file:///etc/yum.conf > [root at localhost ~]# ls -l /etc/ | grep yum > drwxr-xr-x 3 root root 4096 Nov 10 11:56 yum > -rw-r--r-- 1 root root 368 Nov 6 11:28 yum.conf.rpmsave > drwxr-xr-x 2 root root 4096 Nov 10 11:56 yum.repos.d > > > Does yum have a download only mode anymore? I think I want to go back to using > just rpm to do updates to see if this is caused by yum or rpm. I've heard rumors > of other critical config files dissappearing by doing yum update. > > -Steve > Try reverting rpm packages (rpm, rpm-libs, rpm-python, rpm-devel, rpm-build) to 4.4.2-32 and see if that fixes this. Perhaps this is similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196590 tom -- Tom London From jspaleta at gmail.com Sat Nov 11 19:47:12 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 10:47:12 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> Message-ID: <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> On 11/11/06, n0dalus wrote: > On 11/11/06, Jeff Spaleta wrote: > > or we instruct testers to use yum-skip-broken plugin that is now > > available as of fe6. > > > > I think that's missing the point. Testers should have to do as little > voodoo as possible on their machines to get a working rawhide install. I think you are missing the point... we should ALL need to do as little as possible to get a working install. Its called "the ideal situation." You are free to continue to wax eloquently about it all you want.. but some of us live in reality.. you are welcome to join us in finding reasonable. balanced solutions which strike the most equitable balanced use of the amount of currently available manhours and assocsiated infrastructure resources. > Telling them to install a yum plugin is just as bad as telling them to > --exclude={,,,}. Multiply every minute you expect testers to sit there > trying to work out why updates aren't happening and installing plugins > by the number of testers and the result is a substantial waste of time > (that could have been used to find real bugs). Sorry, but I look at testing as the exact opposite problem. Testers need MORE guidance... MORE instruction... not less. Dear god, if installing a defined set of tester oriented tools that is not in the default install usage senario is over-burdensome, I'm almost at a loss for words. The expectation that testers don't have to do any additional software installs to be effective is ...tragic. > > Maybe the yum-skip-broken plugin should be installed by default in > test releases. Maybe... testers should be more informed about the point of the test releases. Let me remind you right now, it is to be as close to the final shipping solution as possible, If we make the defaults oriented for testers specifically..we are no longer testing the final release as it is going to be shipping. What we do is start spinning up a suite of tester oriented tools as an optional group of packages and spin up guidance associated with how to use those tester oriented tools. > Or maybe we could just fix the build system. Any new > update generated by the build system that isn't installable due to > dependencies should be put in a temporary place until the dependent > packages arrive. I don't know if this is feasible or not. I'd be concerned that such a situation would make it easier for maintainers to forget about rebuilding, if there isn't public pressure to clean up the tree in a timely manner. If the staging area lets built packages from maintainer A fester outside of general availability for long periods of time due to inaction from maintainer B we are actually de-valuing the effort made by maintainer A to get packages out to chew on. These issues however can be addressed with the appropriate level of script logic to inform the general community what was built and held back. Also scripts to ensure cross-maintainer notification so that a maintainer for a library can be informed as to exactly why her library is being held back. Additionally any pre-publish staging area would have to be mirrored and accessible to anyone else in the community who need to track packages in rawhide. People working on extras-development packages would need to have reasonable access to this staging area to run mock based local builds against on their own computers. If a library packages lingers in a private staging area because one app in Core hasn't been rebuilt against it yet... that could seriously impact the abiliity of multiple application maintainers in Extras to rebuild in a timely manner. -jef" You need to make sure that in your efforts to make testing push-button simple for testers, you aren't amplifying the burden on other parts of the community. It's never going to be perfect, but there is a direction forward:: http://fedoraproject.org/wiki/QA/Beaker https://testing.108.redhat.com/ "spaleta From nicolas.mailhot at laposte.net Sat Nov 11 20:23:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 11 Nov 2006 21:23:32 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111334.52442.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111304.14744.jkeating@redhat.com> <1163269570.7856.32.camel@rousalka.dyndns.org> <200611111334.52442.jkeating@redhat.com> Message-ID: <1163276617.9577.21.camel@rousalka.dyndns.org> Le samedi 11 novembre 2006 ? 13:34 -0500, Jesse Keating a ?crit : > On Saturday 11 November 2006 13:26, Nicolas Mailhot wrote: > > Not if we block only the broken parts. You know, instead of using > > testers to shame maintainers in fixing broken deps, have the buildsys do > > it, and only expose sane trees to users (with the "broken" packagesets > > being held where the buildsys can find them till they're complete) > > Thats quite the complexity to try spinning the tree, find broken deps, drop > out packages, try again, rather, rinse repeat. The yum plugin does it, the auto-dep check does it, I won't say it's peanuts technically, but it's not rocket science anymore. Even if it takes an hour of CPU time that's better than making hundreds of testers waste 15 min. > Look, rawhide is just a work in progress, a snapshot of what happened the day > before. We can't aways have a completely stable tree. Trying for that is > the road to insanity. No it isn't. A release ago you'd have written forcing every maintainer to get its buildeps right would never work. The problem is only to get the right tools in the right place, and try harder. > This is why we have test releases where we freeze > things to get the tree into a sane state. Could we do more frozen iso > releases? Possibly, depending on the build system we use and how freezes can > be handled. You're not hearing what people are saying. Releasing broken tree and isos actively discourages testing. When rawhide breaks a lot of testers will will just pass and wait till anaconda and yum are happy. Others will try to update nevertheless, spend all their energy manually workarounding the breakage, and not test anything once the update boots, because they'll have wasted their free time testing budget. No matter how you look at it, every period when the tree is broken is a neat loss on the QA front. If you want Fedora get the polish it lacks rawhide need to be installable 90% of the times and FC Test users need to spend their time on something else than getting the release to boot. Remember "upstream, upstream upstream". If a problem is not detected early enough to percolate upstream and get fixed in time for inclusion, we're only doing testing for other distros. The final release will always reflect the standard you used in the devel branch, no last-minute test release effort will change this. -- Nicolas Mailhot From jspaleta at gmail.com Sat Nov 11 21:05:59 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 12:05:59 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> Message-ID: <604aa7910611111305ida7cf66me971967ef67a1147@mail.gmail.com> On 11 Nov 2006 14:10:08 +0100, Benny Amorsen wrote: > Would it be possible to automatically detect when the rawhide tree is > in shape for installation, and then spin an ISO? Sure you could detect that... that's not the issue. The issue is the probability of having a fully consistent tree is very low from day to day and you could never predict the frequency nor the actual days that rawhide would spontenously be self-consistent. Self-consistency of any merit will require release engineering and the establishment of freeze deadlines and post freeze reviews. -jef"A stopped watch is right twice a day, and rawhide doesn't have the luxury of being stopped"spaleta From caillon at redhat.com Sat Nov 11 21:31:42 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 11 Nov 2006 16:31:42 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> References: <4554AEB3.8010701@redhat.com> <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> Message-ID: <4556413E.8050406@redhat.com> n0dalus wrote: > On 11/11/06, Christopher Aillon wrote: >> >> Tracker has been proposed[1] to be included into GNOME and has been >> rejected for various reasons. See the thread for full details, but >> Joe's reply[2] lists some good reasons to not include tracker at this >> time. >> >> [1]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html >> >> [2]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00211.html >> >> > > His main complaint seems to be that tracker hasn't had a lot of > testing. Maybe Fedora can help in that respect by putting it in devel > and getting the community using it. > > n0dalus. > There are also problems with the code quality, or lack thereof. It's dissected somewhere else in the thread. From jspaleta at gmail.com Sat Nov 11 21:36:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 12:36:53 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163258466.26941.146.camel@gilboa-home-dev.localhost> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163258466.26941.146.camel@gilboa-home-dev.localhost> Message-ID: <604aa7910611111336o4fd2c730r8ae16a72b81ffdb@mail.gmail.com> On 11/11/06, Gilboa Davara wrote: > On Sat, 2006-11-11 at 00:28 -0900, Jeff Spaleta wrote: > > On 11/10/06, Gilboa Davara wrote: > > > A. Create more mile-stone releases. Once the tree reaches build > > > integrity (no missing packages), spin a test release. (Fixes P1, P2) > > > > Logic fault... we dont have enough testers right now... more > > mile-stone releases will actually mean even fewer people will be > > testing each of those releases. We don't magically gain more manhours > > of testing by having 14 individual isosets in the wild. > > > You've missed my point. > Take Mozilla - each and every night they release a nightly build. First of all you can't respin all of rawhide in one night. Are you seriously suggesting that we re-engineer rawhide in such a way that we do a full respin of the entire codebase and then push the full tree as one unit..everytime we make a public push? Let's keep the scale of the problems in mind please. Rawhide has dependancy issues because the codebase is so large that it can't be easily re-mastered in one big push. Mass rebuilds when they are required are major multiday efforts, and we can not rely on that left of churn as the primary way to get individual component updates out and tested. > Point of reason: > A. The biggest issue with any Linux distribution is the installer. I'm going to focus on this one item, since most of the others are associated with the idea of getting better testing of the installer specifically. I have an alternative proposal for installer testing instead of attempting to force more structure into the rawhide process. I agree that the installer itself is a very special case, a case that rawhide's structure isn't well suited for. If we want to develop a regiment for testing the installer functionality specifically... then we should be discussing nightly builds of the installer against a simple to use and very static package-payload that does not represent the full rawhide image. We don't need full rawhide tree consistency to better test the installer. There's no reason that we need to make the full rawhide tree available for people who want to continually test the installer functionality and do regression testing for things like partition creation and handling. All you need to do is to identify a basic set of payload packages that is neceessary to test the installer.. make that payload set semi-static.. and pump out test images of the installer as the installer codebase gets updated using this cutdown package payload. Update that cutdown package payload as it become self-consistent regardless of the full state of the rawhide tree. We don't need openoffice to be in a consistent state in the full rawhide tree to test the installer for regressions. So let me recap for anyone who could make this happen. Problem statement: Better testing of the installer functionality regardless of the state of the full rawhide tree. Proposal: creation of a semi-static payload tree that nightly builds of the installer targets so testers can avoid depchain breakage at install time, while still being able to test all installer based functionality. Additionally the semi-static payload would provide a test of the firstboot process as well. While there is no substitute for bare metal, allow for a xen based testing process so testers without dedicated hardware can chew on these nightly installer builds to do some regression testing. Thoughts from the release-eng and installer people inside RedHat as to the feasibility and usefulness of this proposal? -jef From skvidal at linux.duke.edu Sat Nov 11 22:22:17 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 11 Nov 2006 17:22:17 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: <4556413E.8050406@redhat.com> References: <4554AEB3.8010701@redhat.com> <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> <4556413E.8050406@redhat.com> Message-ID: <1163283737.9312.32.camel@cutter> On Sat, 2006-11-11 at 16:31 -0500, Christopher Aillon wrote: > n0dalus wrote: > > On 11/11/06, Christopher Aillon wrote: > >> > >> Tracker has been proposed[1] to be included into GNOME and has been > >> rejected for various reasons. See the thread for full details, but > >> Joe's reply[2] lists some good reasons to not include tracker at this > >> time. > >> > >> [1]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html > >> > >> [2]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00211.html > >> > >> > > > > His main complaint seems to be that tracker hasn't had a lot of > > testing. Maybe Fedora can help in that respect by putting it in devel > > and getting the community using it. > > > > n0dalus. > > > > There are also problems with the code quality, or lack thereof. It's > dissected somewhere else in the thread. If we're not going to let packages in based on code quality "standards" then we're going to be kicking out a lot packages I think. -sv From nicolas.mailhot at laposte.net Sat Nov 11 22:20:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 11 Nov 2006 23:20:15 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611111305ida7cf66me971967ef67a1147@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <604aa7910611111305ida7cf66me971967ef67a1147@mail.gmail.com> Message-ID: <1163283616.3218.15.camel@rousalka.dyndns.org> Le samedi 11 novembre 2006 ? 12:05 -0900, Jeff Spaleta a ?crit : > On 11 Nov 2006 14:10:08 +0100, Benny Amorsen wrote: > > Would it be possible to automatically detect when the rawhide tree is > > in shape for installation, and then spin an ISO? > > Sure you could detect that... that's not the issue. The issue is the > probability of having a fully consistent tree is very low from day to > day and you could never predict the frequency nor the actual days that > rawhide would spontenously be self-consistent. rawhide will never be spontaneously self-consistent with the tools we use today. That's why people ask autoblocking of the packageset pushes that break its consistency (not blocking *all* the updates just those not complete yet) > Self-consistency of > any merit will require release engineering and the establishment of > freeze deadlines and post freeze reviews. Self consistency only requires holding packageset pushes that break the repo till they're complete, and packagers talking to each other instead of communicating through angry testers. Release engineering is only required if a package is not updated timely enough to unblock the packageset but : 1. that's not the general case 2. the worst offenders will be AWOL at the next test mass rebuild, so you're spreading the load, not adding to it 3. if the blocking package is not critical it can always be dropped from the devel repo. That's better than keeping it without the needed deps anyway (both for users and would-be new maintainers). If the blocking package is critical breaking blocking till it's fixed is the only sane thing to do. -- Nicolas Mailhot From jkeating at redhat.com Sat Nov 11 22:57:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Nov 2006 17:57:42 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163276617.9577.21.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111334.52442.jkeating@redhat.com> <1163276617.9577.21.camel@rousalka.dyndns.org> Message-ID: <200611111757.45700.jkeating@redhat.com> On Saturday 11 November 2006 15:23, Nicolas Mailhot wrote: > You're not hearing what people are saying. Releasing broken tree and > isos actively discourages testing. When rawhide breaks a lot of testers > will will just pass and wait till anaconda and yum are happy. Others > will try to update nevertheless, spend all their energy manually > workarounding the breakage, and not test anything once the update boots, > because they'll have wasted their free time testing budget. No matter > how you look at it, every period when the tree is broken is a neat loss > on the QA front. I didn't say we'd be releasing broken isos. I'm just saying that treating rawhide as an installable tree is a broken concept. Rawhide is nothing more than a collection of packages at a given point during the night. In fact, for this next development cycle, I'd like to change how the boot.iso and such work for rawhide, in that it doesn't KNOW about any packages, rather it just has core and extras as preselected remote repositories. This way you can use a good combination of kernel and anaconda to install day after day after day, and rawhide becomes nothing more than a createrepo call. > > If you want Fedora get the polish it lacks rawhide need to be > installable 90% of the times and FC Test users need to spend their time > on something else than getting the release to boot. Remember "upstream, > upstream upstream". If a problem is not detected early enough to > percolate upstream and get fixed in time for inclusion, we're only doing > testing for other distros. The final release will always reflect the > standard you used in the devel branch, no last-minute test release > effort will change this. And if we force developers to spend too much time on making rawhide dep free each and every day they'll have no time to actually work on functionality or enhancements. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jacliburn at bellsouth.net Sun Nov 12 00:22:01 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 18:22:01 -0600 Subject: Recent rawhide instability Message-ID: <45566929.8090805@bellsouth.net> I'm seeing unstable behavior on my rawhide systems (x86_64) lately, pretty much since dbus started segfaulting on October 25 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212303). This was fixed, but I've had this nebulous feeling of instability ever since. Has anyone else noticed it? Here are some problems on my systems. * Thunderbird just coredumped -- three times in a row. I have core files. This problem is actually what prompted me to send this message. No bz yet; it just now started happening. * gnome-power-manager crashes and takes hald with it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 * CDs and DVDs no longer automount. This used to work flawlessly. I can mount them manually, but they no longer show up on my desktop like they used to. (I use gnome/nautilus, and no compiz.) No bz yet. * When I insert a USB pendrive, hald segfaults. I can't find a core file. How do I generate a backtrace for this? No bz yet. usb 5-5: new high speed USB device using ehci_hcd and address 3 usb 5-5: configuration #1 chosen from 1 choice Initializing USB Mass Storage driver... scsi2 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning usbcore: registered new driver usb-storage USB Mass Storage support registered. Vendor: LEXAR Model: JUMPDRIVE SPORT Rev: 1000 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdb: 2030592 512-byte hdwr sectors (1040 MB) sdb: Write Protect is off sdb: Mode Sense: 43 00 00 00 sdb: assuming drive cache: write through SCSI device sdb: 2030592 512-byte hdwr sectors (1040 MB) sdb: Write Protect is off sdb: Mode Sense: 43 00 00 00 sdb: assuming drive cache: write through sdb: sdb1 sd 2:0:0:0: Attached scsi removable disk sdb sd 2:0:0:0: Attached scsi generic sg1 type 0 usb-storage: device scan complete hald[1960]: segfault at 0000000000000021 rip 00000039fec74e50 rsp 00007fff515e3c08 error 4 From n0dalus+redhat at gmail.com Sun Nov 12 00:28:38 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 12 Nov 2006 10:58:38 +1030 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> Message-ID: <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> On 11/12/06, Jeff Spaleta wrote: > > > Or maybe we could just fix the build system. Any new > > update generated by the build system that isn't installable due to > > dependencies should be put in a temporary place until the dependent > > packages arrive. > > I don't know if this is feasible or not. I'd be concerned that such a > situation would make it easier for maintainers to forget about > rebuilding, if there isn't public pressure to clean up the tree in a > timely manner. If the staging area lets built packages from maintainer > A fester outside of general availability for long periods of time due > to inaction from maintainer B we are actually de-valuing the effort > made by maintainer A to get packages out to chew on. These issues > however can be addressed with the appropriate level of script logic to > inform the general community what was built and held back. Also > scripts to ensure cross-maintainer notification so that a maintainer > for a library can be informed as to exactly why her library is being > held back. Sounds like a good solution to that concern. > Additionally any pre-publish staging area would have to be mirrored > and accessible to anyone else in the community who need to track > packages in rawhide. People working on extras-development packages > would need to have reasonable access to this staging area to run mock > based local builds against on their own computers. If a library > packages lingers in a private staging area because one app in Core > hasn't been rebuilt against it yet... that could seriously impact the > abiliity of multiple application maintainers in Extras to rebuild in a > timely manner. One way of dealing with this is to put the packages in the usual spot, but modify createrepo to have an option to ignore packages that can't be installed. Or just have a subdirectory containing the packages held back (or even a repository). So far I've mainly considered what to do if a new package requires something that doesn't exist (or requires a higher version than is currently provided). What should be done if the new package is installable but causes other packages to become uninstallable? We wouldn't usually want the new package to be held back in that case, but I'm not sure what the best way to handle it is -- is it ok to just (re)move the uninstallable package from the repository? n0dalus. From hughsient at gmail.com Sun Nov 12 00:31:45 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 12 Nov 2006 00:31:45 +0000 Subject: Recent rawhide instability In-Reply-To: <45566929.8090805@bellsouth.net> References: <45566929.8090805@bellsouth.net> Message-ID: <1163291505.14322.8.camel@localhost.localdomain> On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: > * gnome-power-manager crashes and takes hald with it. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 ... > * When I insert a USB pendrive, hald segfaults. I can't find a core file. How > do I generate a backtrace for this? No bz yet. Known bug[1]. HAL needs to be updated to CVS head to work with the latest DBUS (the one in rawhide). You can find *experimental* HAL rpms in my repo[2]. WARNING: Don't update to all the packages in this repo (especially pm-utils) as suspend and hibernate _will_ break if you do. Richard. [1] http://lists.freedesktop.org/archives/hal/2006-November/006464.html [2] http://people.freedesktop.org/~hughsient/fedora/utopia.repo From jacliburn at bellsouth.net Sun Nov 12 00:34:38 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 18:34:38 -0600 Subject: Recent rawhide instability In-Reply-To: <45566929.8090805@bellsouth.net> References: <45566929.8090805@bellsouth.net> Message-ID: <45566C1E.7030207@bellsouth.net> Jay Cliburn wrote: > * CDs and DVDs no longer automount. This used to work flawlessly. I > can mount them manually, but they no longer show up on my desktop like > they used to. (I use gnome/nautilus, and no compiz.) No bz yet. Manually running "gnome-mount -d /dev/dvd" causes the dvd to correctly mount and show up on the desktop. From darrellpf at gmail.com Sun Nov 12 00:35:06 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 11 Nov 2006 16:35:06 -0800 Subject: Recent rawhide instability In-Reply-To: <45566929.8090805@bellsouth.net> References: <45566929.8090805@bellsouth.net> Message-ID: Jay, I'm running a current rawhide on X86. There are some inline comments... On 11/11/06, Jay Cliburn wrote: > I'm seeing unstable behavior on my rawhide systems (x86_64) lately, pretty much > since dbus started segfaulting on October 25 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212303). This was fixed, > but I've had this nebulous feeling of instability ever since. > > Has anyone else noticed it? Here are some problems on my systems. > > * Thunderbird just coredumped -- three times in a row. I have core files. This > problem is actually what prompted me to send this message. No bz yet; it just > now started happening. > > * gnome-power-manager crashes and takes hald with it. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 Yes. I know that hald has crashed mostly on shutting down when the message appears. A couple of days ago the gnome bug reporter kept activating on login and it had something to say about hal, though I haven't seen that in a couple of days. > > * CDs and DVDs no longer automount. This used to work flawlessly. I can mount > them manually, but they no longer show up on my desktop like they used to. (I > use gnome/nautilus, and no compiz.) No bz yet. > > * When I insert a USB pendrive, hald segfaults. I can't find a core file. How > do I generate a backtrace for this? No bz yet. My usb camera didn't automount. I tried to print with my usb laser printer and it wasn't seen at all. > > usb 5-5: new high speed USB device using ehci_hcd and address 3 > usb 5-5: configuration #1 chosen from 1 choice > Initializing USB Mass Storage driver... > scsi2 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 3 > usb-storage: waiting for device to settle before scanning > usbcore: registered new driver usb-storage > USB Mass Storage support registered. > Vendor: LEXAR Model: JUMPDRIVE SPORT Rev: 1000 > Type: Direct-Access ANSI SCSI revision: 00 > SCSI device sdb: 2030592 512-byte hdwr sectors (1040 MB) > sdb: Write Protect is off > sdb: Mode Sense: 43 00 00 00 > sdb: assuming drive cache: write through > SCSI device sdb: 2030592 512-byte hdwr sectors (1040 MB) > sdb: Write Protect is off > sdb: Mode Sense: 43 00 00 00 > sdb: assuming drive cache: write through > sdb: sdb1 > sd 2:0:0:0: Attached scsi removable disk sdb > sd 2:0:0:0: Attached scsi generic sg1 type 0 > usb-storage: device scan complete > hald[1960]: segfault at 0000000000000021 rip 00000039fec74e50 rsp > 00007fff515e3c08 error 4 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I've also had lots of problems with wireless networking not being seen properly by network manager. The latest ATI driver is having problems sending output to an external projector. For a long time it only seemed to work if you booted with the projector on, then for a while recently it worked just by plugging the projector in, but now it doesn't work in either case. Reverted back to the previous version. After a (long) freeze I always have an expectation of instability. darrell From jacliburn at bellsouth.net Sun Nov 12 01:04:33 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 19:04:33 -0600 Subject: Recent rawhide instability In-Reply-To: <1163291505.14322.8.camel@localhost.localdomain> References: <45566929.8090805@bellsouth.net> <1163291505.14322.8.camel@localhost.localdomain> Message-ID: <45567321.6070404@bellsouth.net> Richard Hughes wrote: > On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: >> * gnome-power-manager crashes and takes hald with it. >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 > ... >> * When I insert a USB pendrive, hald segfaults. I can't find a core file. How >> do I generate a backtrace for this? No bz yet. > > Known bug[1]. HAL needs to be updated to CVS head to work with the > latest DBUS (the one in rawhide). You can find *experimental* HAL rpms > in my repo[2]. Thanks for the info. I notice you had only i386 packages, so I downloaded the source rpm. Unfortunately I ran into some dependency issues building the x86_64 rpm. [root at osprey SPECS]# rpmbuild -bp --target $(uname -m) hal.spec Building target platforms: x86_64 Building for target x86_64 error: Failed build dependencies: PolicyKit >= 0.2 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 libvolume_id-devel is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 parted-devel >= 1.7.1 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 libusb-devel >= 0.1.10a-1 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 From jacliburn at bellsouth.net Sun Nov 12 01:11:07 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 19:11:07 -0600 Subject: Recent rawhide instability In-Reply-To: <45567321.6070404@bellsouth.net> References: <45566929.8090805@bellsouth.net> <1163291505.14322.8.camel@localhost.localdomain> <45567321.6070404@bellsouth.net> Message-ID: <455674AB.1080901@bellsouth.net> Jay Cliburn wrote: > Richard Hughes wrote: >> On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: >>> * gnome-power-manager crashes and takes hald with it. >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 >> ... >>> * When I insert a USB pendrive, hald segfaults. I can't find a core >>> file. How do I generate a backtrace for this? No bz yet. >> >> Known bug[1]. HAL needs to be updated to CVS head to work with the >> latest DBUS (the one in rawhide). You can find *experimental* HAL rpms >> in my repo[2]. > > Thanks for the info. I notice you had only i386 packages, so I > downloaded the source rpm. Unfortunately I ran into some dependency > issues building the x86_64 rpm. > > [root at osprey SPECS]# rpmbuild -bp --target $(uname -m) hal.spec > Building target platforms: x86_64 > Building for target x86_64 > error: Failed build dependencies: > PolicyKit >= 0.2 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 > libvolume_id-devel is needed by > hal-0.5.9-0.20061111.hughsie6.x86_64 > parted-devel >= 1.7.1 is needed by > hal-0.5.9-0.20061111.hughsie6.x86_64 > libusb-devel >= 0.1.10a-1 is needed by > hal-0.5.9-0.20061111.hughsie6.x86_64 > Sigh... I think I'll just wait... [root at osprey SPECS]# rpmbuild -bp --target $(uname -m) PolicyKit.spec Building target platforms: x86_64 Building for target x86_64 error: Failed build dependencies: xmlto is needed by PolicyKit-0.2-0.20061111.hughsie6.x86_64 [root at osprey SPECS]# yum install xmlto.x86_64 Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for xmlto to pack into transaction set. xmlto-0.0.18-13.1.x86_64. 100% |=========================| 7.9 kB 00:00 ---> Package xmlto.x86_64 0:0.0.18-13.1 set to be updated --> Running transaction check --> Processing Dependency: passivetex >= 1.11 for package: xmlto --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for passivetex to pack into transaction set. passivetex-1.25-5.1.1.noa 100% |=========================| 5.7 kB 00:00 ---> Package passivetex.noarch 0:1.25-5.1.1 set to be updated --> Running transaction check --> Processing Dependency: tetex for package: passivetex --> Processing Dependency: xmltex >= 20000118-4 for package: passivetex --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for xmltex to pack into transaction set. xmltex-20020625-8.noarch. 100% |=========================| 7.2 kB 00:00 ---> Package xmltex.noarch 0:20020625-8 set to be updated ---> Downloading header for tetex to pack into transaction set. tetex-3.0-32.fc6.x86_64.r 100% |=========================| 245 kB 00:04 ---> Package tetex.x86_64 0:3.0-32.fc6 set to be updated --> Running transaction check --> Processing Dependency: tetex-latex for package: xmltex --> Processing Dependency: tetex-fonts = 3.0 for package: tetex --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for tetex-fonts to pack into transaction set. tetex-fonts-3.0-32.fc6.x8 100% |=========================| 760 kB 00:10 ---> Package tetex-fonts.x86_64 0:3.0-32.fc6 set to be updated ---> Downloading header for tetex-latex to pack into transaction set. tetex-latex-3.0-32.fc6.x8 100% |=========================| 249 kB 00:01 ---> Package tetex-latex.x86_64 0:3.0-32.fc6 set to be updated --> Running transaction check --> Processing Dependency: tetex-dvips = 3.0 for package: tetex-latex --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for tetex-dvips to pack into transaction set. tetex-dvips-3.0-32.fc6.x8 100% |=========================| 73 kB 00:00 ---> Package tetex-dvips.x86_64 0:3.0-32.fc6 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: xmlto x86_64 0.0.18-13.1 development 27 k Installing for dependencies: passivetex noarch 1.25-5.1.1 development 75 k tetex x86_64 3.0-32.fc6 development 14 M tetex-dvips x86_64 3.0-32.fc6 development 604 k tetex-fonts x86_64 3.0-32.fc6 development 29 M tetex-latex x86_64 3.0-32.fc6 development 5.4 M xmltex noarch 20020625-8 development 41 k Transaction Summary ============================================================================= Install 7 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 49 M Is this ok [y/N]: From hughsient at gmail.com Sun Nov 12 01:15:39 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 12 Nov 2006 01:15:39 +0000 Subject: Recent rawhide instability In-Reply-To: <45567321.6070404@bellsouth.net> References: <45566929.8090805@bellsouth.net> <1163291505.14322.8.camel@localhost.localdomain> <45567321.6070404@bellsouth.net> Message-ID: <1163294139.3670.3.camel@localhost.localdomain> On Sat, 2006-11-11 at 19:04 -0600, Jay Cliburn wrote: > Richard Hughes wrote: > > On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: > >> * gnome-power-manager crashes and takes hald with it. > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214090 > > ... > >> * When I insert a USB pendrive, hald segfaults. I can't find a core file. How > >> do I generate a backtrace for this? No bz yet. > > > > Known bug[1]. HAL needs to be updated to CVS head to work with the > > latest DBUS (the one in rawhide). You can find *experimental* HAL rpms > > in my repo[2]. > > Thanks for the info. I notice you had only i386 packages, so I downloaded the > source rpm. Unfortunately I ran into some dependency issues building the x86_64 > rpm. Yup. > [root at osprey SPECS]# rpmbuild -bp --target $(uname -m) hal.spec > Building target platforms: x86_64 > Building for target x86_64 > error: Failed build dependencies: > PolicyKit >= 0.2 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 This you will have to rebuild and install from my repo. > libvolume_id-devel is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 > parted-devel >= 1.7.1 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 > libusb-devel >= 0.1.10a-1 is needed by hal-0.5.9-0.20061111.hughsie6.x86_64 You can get these from fedora, as you would any other package. If things break, you get to keep both bits. It might be better to just wait for rawhide to sync with a cvs snapshot (with PolicyKit turned off) unless you are comfortable with mucking about with random packages. :-) Richard. From jspaleta at gmail.com Sun Nov 12 01:25:17 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Nov 2006 16:25:17 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> Message-ID: <604aa7910611111725mded9a15g196ed69172504961@mail.gmail.com> On 11/11/06, n0dalus wrote: > One way of dealing with this is to put the packages in the usual spot, > but modify createrepo to have an option to ignore packages that can't > be installed. Or just have a subdirectory containing the packages held > back (or even a repository). Whatever you hold back has to be in a mirrored repository structure.. or else community build tools like mock can't see those packages and extras maintainers won't be able to prep builds against those packages. > What should be done if the new package is > installable but causes other packages to become uninstallable? We > wouldn't usually want the new package to be held back in that case, > but I'm not sure what the best way to handle it is -- is it ok to just > (re)move the uninstallable package from the repository? I bet its not generally okay to do, i bet there will be some very interesting and significant problems with auto-removals from the rawhide tree if you attempt that. They only way we are going to find out is if someone tracks the day-to-day behavior of rawhide with a toy set of scripts and buildups an empirical understanding as to expected gotcha situations. It will be hard enough to make a strict holdback mechanism work effectively.. if you also try to auto-remove items from the tree to force consistency you risk massive cascade removals which don't do anyone any good.... triggers and obsoletes coulld complicate any removal logic you dream up. And again, auto-removals from Core will add yet more complications for Extras developers who are building Extras packages against deps in Core. If a package disappears from Core due to an auto-removal..doesn't that automatically require a cascade of removels for Extras packages tha depend on it... madness...just avoid removals from the tree. -jef"off to figure out why I can't reproduce the crash reports about fe6 istanbul on my hardware"spaleta From rstrode at redhat.com Sun Nov 12 01:26:31 2006 From: rstrode at redhat.com (Ray Strode) Date: Sat, 11 Nov 2006 20:26:31 -0500 Subject: Recent rawhide instability In-Reply-To: <45566929.8090805@bellsouth.net> References: <45566929.8090805@bellsouth.net> Message-ID: <1163294791.5022.11.camel@halflap.boston.devel.redhat.com> Hi, On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: > I'm seeing unstable behavior on my rawhide systems (x86_64) lately, pretty much > since dbus started segfaulting on October 25 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212303). This was fixed, > but I've had this nebulous feeling of instability ever since. Note, right now rawhide isn't going to be that stable. It's really early in the fc7 development cycle so experimental/unfinished things are going in and also a lot of red hat engineers are currently dogfooding RHEL5 snapshots instead of rawhide to finish stabilizing and polishing it for its release. --Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacliburn at bellsouth.net Sun Nov 12 01:48:43 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 19:48:43 -0600 Subject: Recent rawhide instability In-Reply-To: <1163294791.5022.11.camel@halflap.boston.devel.redhat.com> References: <45566929.8090805@bellsouth.net> <1163294791.5022.11.camel@halflap.boston.devel.redhat.com> Message-ID: <45567D7B.10202@bellsouth.net> Ray Strode wrote: > Hi, > > On Sat, 2006-11-11 at 18:22 -0600, Jay Cliburn wrote: >> I'm seeing unstable behavior on my rawhide systems (x86_64) lately, pretty much >> since dbus started segfaulting on October 25 >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212303). This was fixed, >> but I've had this nebulous feeling of instability ever since. > > Note, right now rawhide isn't going to be that stable. It's really > early in the fc7 development cycle so experimental/unfinished things are > going in and also a lot of red hat engineers are currently dogfooding > RHEL5 snapshots instead of rawhide to finish stabilizing and polishing > it for its release. Fair enough; I just wanted confirmation it wasn't only me. I started running rawhide a few weeks after FC5 was released, so this is my first transition through one release and into the next. Thanks, Jay From kevin.kofler at chello.at Sun Nov 12 02:15:01 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 12 Nov 2006 02:15:01 +0000 (UTC) Subject: wireles References: <20061111060140.77397.qmail@web54302.mail.yahoo.com> Message-ID: Frank S. yahoo.com> writes: > Sorry to bother you I know? i should ask this questions in a forum but i have try with no result so:I need to get a wireless wifi PC card for my laptop and a pci wifi card for my desktop, I do NOT want to use Ndiswrap or anything similar to that I would to get one that works out of the box, PLEASE could you recommend me one Thank you very much Unfortunately, as others have already said, there isn't really something which works out of the box except for older 802.11b-only chipsets. There are currently 4 categories of drivers I can think of: 1. driver (GPL) in the kernel, but needs a separate firmware download (under a restrictive license). Examples: ipw2100, ipw2200, bcm43xx. 2. GPL driver, no firmware download required, but not merged yet. Examples: rt2400, rt2500, rt2570, rtl8180. See the rest of my e-mail for details. 3. GPL driver, not merged yet, requires separate firmware. Examples: rt61, rt73. 4. Instead of or in addition to the firmware, the driver has some other proprietary portions. Examples: ipw3945 (binary regulatory daemon), madwifi (for Atheros cards, uses a binary hardware abstraction layer). One solution if you don't want binary firmware is Ralink rt2500-based cards (there's a USB version called rt2570, the PCI and PC Card versions are called rt2500). These have a GPL driver and don't need binary firmware (presumably, they have some firmware on a ROM on the chip, but you don't have to deal with licenses or separate downloads). The downside is that the driver is out-of-tree, so it has to be built separately. However, the newer rt2x00 driver which also supports these chipsets is under review for Extras. I don't know when or if it will be approved though. The nice thing about rt2500/2570 is that these support 54 Mbps 802.11g, unlike old chipsets like Orinoco, the drawback is that the drivers are still not in the kernel (they want to get rt2x00 working because the original driver is essentially a port of Ralink's Window$ driver which isn't ideal for Linux, and rt2x00 1. is not finished and 2. is waiting for the DeviceScape 802.11 stack to go into the kernel first, this problem has already been mentioned). Be warned though that the newer rt61 (PCI/PC-Card) and rt73 (USB) chips do need a firmware binary downloadable from the Ralink site, with no license text attached at all (so you can only guess at what the terms are, no redistribution, I assume), at least that was the situation last I checked. As another 802.11g option, Realtek 8180 chips also work without firmware downloads and with a GPL-ed driver, but that hasn't been merged into the kernel either. I don't know what the status of that driver is. Kevin Kofler From n0dalus+redhat at gmail.com Sun Nov 12 02:30:23 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 12 Nov 2006 13:00:23 +1030 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611111725mded9a15g196ed69172504961@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <604aa7910611111725mded9a15g196ed69172504961@mail.gmail.com> Message-ID: <6280325c0611111830q27e8c1c2qf49fa96639f758ed@mail.gmail.com> On 11/12/06, Jeff Spaleta wrote: > > > What should be done if the new package is > > installable but causes other packages to become uninstallable? We > > wouldn't usually want the new package to be held back in that case, > > but I'm not sure what the best way to handle it is -- is it ok to just > > (re)move the uninstallable package from the repository? > > I bet its not generally okay to do, i bet there will be some very > interesting and significant problems with auto-removals from the > rawhide tree if you attempt that. They only way we are going to find > out is if someone tracks the day-to-day behavior of rawhide with a toy > set of scripts and buildups an empirical understanding as to expected > gotcha situations. It will be hard enough to make a strict holdback > mechanism work effectively.. if you also try to auto-remove items from > the tree to force consistency you risk massive cascade removals which > don't do anyone any good.... triggers and obsoletes coulld complicate > any removal logic you dream up. And again, auto-removals from Core > will add yet more complications for Extras developers who are building > Extras packages against deps in Core. If a package disappears from > Core due to an auto-removal..doesn't that automatically require a > cascade of removels for Extras packages tha depend on it... > madness...just avoid removals from the tree. > Yeah I can't really think of a way to manage this case well. It would still be nice to have packages held back in the case that they require something that isn't there though, and I think it would work quite well in stopping the majority of rawhide breakage. n0dalus. From jacliburn at bellsouth.net Sun Nov 12 02:32:45 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sat, 11 Nov 2006 20:32:45 -0600 Subject: Recent rawhide instability In-Reply-To: References: <45566929.8090805@bellsouth.net> Message-ID: <455687CD.9030506@bellsouth.net> darrell pfeifer wrote: > Jay, > > I'm running a current rawhide on X86. There are some inline comments... Thanks. I appreciate your comments. Jay From franklinux392 at yahoo.com Sun Nov 12 03:03:26 2006 From: franklinux392 at yahoo.com (Frank S.) Date: Sat, 11 Nov 2006 19:03:26 -0800 (PST) Subject: Wireless .02 Message-ID: <20061112030326.40199.qmail@web54302.mail.yahoo.com> Thank you very much to every one, for taking your time. Now I understand everything about the wifi cards. sincerely Frank --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sun Nov 12 04:50:05 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 12 Nov 2006 10:20:05 +0530 Subject: Proposal - replace beagle with tracker In-Reply-To: <1163283737.9312.32.camel@cutter> References: <4554AEB3.8010701@redhat.com> <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> <4556413E.8050406@redhat.com> <1163283737.9312.32.camel@cutter> Message-ID: <4556A7FD.3040001@fedoraproject.org> seth vidal wrote: > On Sat, 2006-11-11 at 16:31 -0500, Christopher Aillon wrote: > >>> >> There are also problems with the code quality, or lack thereof. It's >> dissected somewhere else in the thread. > > If we're not going to let packages in based on code quality "standards" > then we're going to be kicking out a lot packages I think. What is going to be default generally has higher standards applied to them. There already is a lot of packages discouraged for their code quality. I know atleast phpbb and webmin were put up for review and left off in the middle when people pointed out their security history and need for constant vigilance. Rahul From gilboad at gmail.com Sun Nov 12 09:13:29 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 11:13:29 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <4555F806.80709@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> Message-ID: <1163322809.1615.6.camel@gilboa-work-dev> On Sat, 2006-11-11 at 11:19 -0500, Warren Togami wrote: > Gilboa Davara wrote: > > Hello all, > > > > The attached patch (which should cover all 64bit arches) enable you to > > start the 32bit version of firefox (if it's installed) by starting > > firefox with the "--32" command line option. > > > > Before I submit this to bugzilla, I have two questions: > > > > - Do we rather have a single firefox script that executes both 32bit and > > 64bit or do we want to break the it to dedicated firefox[64] and > > firefox32 scripts. > > - Where should I submit this patch? Mozilla or redhat? > > > > - Gilboa > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214100 > I wrote an alternative implementation in this bug. I don't fully agree > with the rejection of this, but I do agree that the best long-term > solution is to fix nspluginwrapper to offload *ALL* plugins to a > separate process. A separate process also allows greater security > control with selinux. > > Logic of my Implementation: > > * If only the /usr/lib browser is installed, run it. > * If only the /usr/lib64 browser is installed, run it. > * If both are installed, run /usr/lib64 unless it is overridden in > /etc/sysconfig/firefox-arch. > * Allow editing /etc/sysconfig/firefox-arch as the official means for > the system administrator to override their arch selection. > > %config(noreplace) %{_sysconfdir}/sysconfig/firefox-arch > This is necessary in the %files section of firefox.spec. > > Benefits of this approach: > 1) This DOES NOT CHANGE the behavior from its current default, which > works with browsers shipped on x86_64. > 2) This defines an explicit way for the system administrator to override > their arch selection in a way that wont break with future package > updates. This effectively enables CHOICE. > This a nice solution - though I rather have a simple method of overriding the selection without editing a configuration file and/or making it system wide. IMHO, adding a command line parameters seems like the obvious choice as it gives the user additional means of controlling which version is executed. I can combine your patch with mine - read, use the default in /etc/sysconfig/firefox-arch unless the user specifically requested something else. Does it sound reasonable to you? - Gilboa From nicolas.mailhot at laposte.net Sun Nov 12 09:22:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Nov 2006 10:22:36 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111757.45700.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111334.52442.jkeating@redhat.com> <1163276617.9577.21.camel@rousalka.dyndns.org> <200611111757.45700.jkeating@redhat.com> Message-ID: <1163323357.6043.1.camel@rousalka.dyndns.org> Le samedi 11 novembre 2006 ? 17:57 -0500, Jesse Keating a ?crit : > And if we force developers to spend too much time on making rawhide dep free > each and every day they'll have no time to actually work on functionality or > enhancements. You forget that a dep free rawhide will actually save time to other developpers which are working on another part of the repo -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sun Nov 12 09:41:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Nov 2006 10:41:56 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> Message-ID: <1163324521.6043.21.camel@rousalka.dyndns.org> Le dimanche 12 novembre 2006 ? 10:58 +1030, n0dalus a ?crit : > One way of dealing with this is to put the packages in the usual spot, > but modify createrepo to have an option to ignore packages that can't > be installed. Or just have a subdirectory containing the packages held > back (or even a repository). > > So far I've mainly considered what to do if a new package requires > something that doesn't exist (or requires a higher version than is > currently provided). What should be done if the new package is > installable but causes other packages to become uninstallable? We > wouldn't usually want the new package to be held back in that case, > but I'm not sure what the best way to handle it is -- is it ok to just > (re)move the uninstallable package from the repository? Ideally the situation would be the following : 1. developer A releases a set of packages breaking R or BR of packages of maintainers B, C, D 2. buildsys detects the breakage, assigns a temporary repo to the broken packageset, warns A, B, C, D of the situation (maybe auto-opening bugzilla entries). Waits some standard period. Nags A, B, C, D every other day by mail. 3. During the period fixed packages from B, C, and D are added to the temporary repo till it's complete. When it reaches completion it's merged with the main repo. 4. if the breakage is not fixed by the timeout, send a mail to rel eng asking if they want to wait another period of proceed. If rel eng says wait, repeat. If rel eng says push, push to rawhide removing the packages broken as a side-effect (and mail the relevant fedora lists packages are being dropped ; probably auto-orphan them if they're not back by another period) The only hard part may be to assign different temp repos to different broken packagesets, so maybe it'd be easier to work at the package level : A. have a single staging repo, B. move every new build to this repo, and check at push time what packages can be safely moved to main C. assign TTLs to each individual package in this area This would minimize the work of everyone and only escalate to rel eng when there is an actual problem Regards, -- Nicolas Mailhot From laroche at redhat.com Sun Nov 12 09:59:34 2006 From: laroche at redhat.com (Florian La Roche) Date: Sun, 12 Nov 2006 10:59:34 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163324521.6043.21.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <1163324521.6043.21.camel@rousalka.dyndns.org> Message-ID: <20061112095934.GA5580@dudweiler.stuttgart.redhat.com> On Sun, Nov 12, 2006 at 10:41:56AM +0100, Nicolas Mailhot wrote: > Le dimanche 12 novembre 2006 ? 10:58 +1030, n0dalus a ?crit : > > > One way of dealing with this is to put the packages in the usual spot, > > but modify createrepo to have an option to ignore packages that can't > > be installed. Or just have a subdirectory containing the packages held > > back (or even a repository). > > > > So far I've mainly considered what to do if a new package requires > > something that doesn't exist (or requires a higher version than is > > currently provided). What should be done if the new package is > > installable but causes other packages to become uninstallable? We > > wouldn't usually want the new package to be held back in that case, > > but I'm not sure what the best way to handle it is -- is it ok to just > > (re)move the uninstallable package from the repository? > > > > Ideally the situation would be the following : > > 1. developer A releases a set of packages breaking R or BR of packages > of maintainers B, C, D > > 2. buildsys detects the breakage, assigns a temporary repo to the broken > packageset, warns A, B, C, D of the situation (maybe auto-opening > bugzilla entries). Waits some standard period. Nags A, B, C, D every > other day by mail. > > 3. During the period fixed packages from B, C, and D are added to the > temporary repo till it's complete. When it reaches completion it's > merged with the main repo. > > 4. if the breakage is not fixed by the timeout, send a mail to rel eng > asking if they want to wait another period of proceed. If rel eng says > wait, repeat. If rel eng says push, push to rawhide removing the > packages broken as a side-effect (and mail the relevant fedora lists > packages are being dropped ; probably auto-orphan them if they're not > back by another period) > > The only hard part may be to assign different temp repos to different > broken packagesets, so maybe it'd be easier to work at the package > level : > A. have a single staging repo, > B. move every new build to this repo, and check at push time what > packages can be safely moved to main > C. assign TTLs to each individual package in this area > > This would minimize the work of everyone and only escalate to rel eng > when there is an actual problem > > Setting this up within a new tree that is adding in the rawhide changes incrementally should also be possible. Then we can just see how many people are happy with this setup and use it. regards, Florian La Roche From nicolas.mailhot at laposte.net Sun Nov 12 10:04:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Nov 2006 11:04:08 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <6280325c0611111830q27e8c1c2qf49fa96639f758ed@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <604aa7910611111725mded9a15g196ed69172504961@mail.gmail.com> <6280325c0611111830q27e8c1c2qf49fa96639f758ed@mail.gmail.com> Message-ID: <1163325851.6043.30.camel@rousalka.dyndns.org> Le dimanche 12 novembre 2006 ? 13:00 +1030, n0dalus a ?crit : > On 11/12/06, Jeff Spaleta wrote: > > if you also try to auto-remove items from > > the tree to force consistency you risk massive cascade removals which > > don't do anyone any good... Letting things rot till the last FCT is not any better > > triggers and obsoletes could complicate > > any removal logic you dream up. Logic does not need to be perfect at first. Treating the 80% easy cases would still make work that much easier for other devs and testers (easy cases being openssl updates, multi-day xorg or gnome rebuilds, packagers forgetting to coordinate with others before a push?) > > And again, auto-removals from Core > > will add yet more complications for Extras developers who are building > > Extras packages against deps in Core. I'm not proposing a Core policy but a Fedora policy. We're merging, remember ? > It would still be nice to have packages held back in the case that > they require something that isn't there though, and I think it would > work quite well in stopping the majority of rawhide breakage. +1 Also the one big problem of the current system is a push will remove the previous "working" version, so unless you have the old one on your system (not the case for new anaconda installs or lazy updates) you're out of business. Including if you need to build against one of the broken packages -- Nicolas Mailhot From fedora at wir-sind-cool.org Sun Nov 12 12:18:54 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 12 Nov 2006 13:18:54 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163323357.6043.1.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111334.52442.jkeating@redhat.com> <1163276617.9577.21.camel@rousalka.dyndns.org> <200611111757.45700.jkeating@redhat.com> <1163323357.6043.1.camel@rousalka.dyndns.org> Message-ID: <20061112131854.5255bd88.fedora@wir-sind-cool.org> On Sun, 12 Nov 2006 10:22:36 +0100, Nicolas Mailhot wrote: > Le samedi 11 novembre 2006 ? 17:57 -0500, Jesse Keating a ?crit : > > > And if we force developers to spend too much time on making rawhide dep free > > each and every day they'll have no time to actually work on functionality or > > enhancements. > > You forget that a dep free rawhide will actually save time to other > developpers which are working on another part of the repo *Applause!* This is the typical discuss-things-endlessly-before-even-trying type of conversation. Meanwhile, the "Package EVR problems in FC+FE" report [1] gets longer (even ".FC6" dist tags pop up in there - what the heck?!), and Extras packagers don't rebuild their devel packages either. Even if they managed to do so with a time-consuming mock build, they could not update their rawhide machines (or upgrade FC6 to rawhide) without trying to hack a long list of excludes. Only if it can be installed, it can be tested. [1] Question to the Core Steering people: Are you happy with what you see here? https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00097.html -- And to make one thing clear, I don't mind occasional run-time surprises. That's the risk I choose to take when trying out rawhide. From fedora at wir-sind-cool.org Sun Nov 12 12:56:50 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 12 Nov 2006 13:56:50 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163324521.6043.21.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <1163324521.6043.21.camel@rousalka.dyndns.org> Message-ID: <20061112135650.05c86401.fedora@wir-sind-cool.org> On Sun, 12 Nov 2006 10:41:56 +0100, Nicolas Mailhot wrote: > > > Ideally the situation would be the following : > > 1. developer A releases a set of packages breaking R or BR of packages > of maintainers B, C, D > > 2. buildsys detects the breakage, assigns a temporary repo to the broken > packageset, warns A, B, C, D of the situation (maybe auto-opening > bugzilla entries). Waits some standard period. Nags A, B, C, D every > other day by mail. > > 3. During the period fixed packages from B, C, and D are added to the > temporary repo till it's complete. When it reaches completion it's > merged with the main repo. One question raised here: What to do with the "temporary repo" with regard to subsequent build jobs? The stuff that builds successfully, but breaks something, must be made available to subsequent build jobs. Else developers B,C,D could not build "against" the most recent builds. So, what happens if developer E builds something with developer A's new packages successfully? His builds must be held up, too, because A's packages are not released yet. Things in the temporary repo pile up (a single huge dependency, which got broken, can hold up many small packages, which rebuilt fine without further breakage). And unless the temporary repo is a publicly available repo, which can be used as a yum repo, it is a trap for some packages, and an unexpected trap for further packages. Meanwhile, other developers are confronted with another target. Their local installation and the stuff available to the buildsys's "quarantine repo". And BR breakage is another beast, since BR breakage can occur also at the API-level (or in configuration tools) and can lead to even longer chains of things which are held up while waiting for fixes. One solution for that is to avoid the most common breakage (aka compatibility packages, libfooMAJOR-devel packages during ABI upgrades, no dangerous renames -- and probably automated rebuilds of dependency chains, regardless of whether the results work). From nicolas.mailhot at laposte.net Sun Nov 12 13:09:19 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Nov 2006 14:09:19 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <20061112135650.05c86401.fedora@wir-sind-cool.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <1163324521.6043.21.camel@rousalka.dyndns.org> <20061112135650.05c86401.fedora@wir-sind-cool.org> Message-ID: <1163336961.6043.43.camel@rousalka.dyndns.org> Le dimanche 12 novembre 2006 ? 13:56 +0100, Michael Schwendt a ?crit : > On Sun, 12 Nov 2006 10:41:56 +0100, Nicolas Mailhot wrote: > > > > > > > Ideally the situation would be the following : > > > > 1. developer A releases a set of packages breaking R or BR of packages > > of maintainers B, C, D > > > > 2. buildsys detects the breakage, assigns a temporary repo to the broken > > packageset, warns A, B, C, D of the situation (maybe auto-opening > > bugzilla entries). Waits some standard period. Nags A, B, C, D every > > other day by mail. > > > > 3. During the period fixed packages from B, C, and D are added to the > > temporary repo till it's complete. When it reaches completion it's > > merged with the main repo. > > One question raised here: What to do with the "temporary repo" with > regard to subsequent build jobs? I thing everyone agrees the temporary/staging/quarantine repo must be used by the buildsys for subsequent builds, and be published for maintainers to build again in mock (not for tester installation though) > One solution for that > is to avoid the most common breakage (aka compatibility packages, > libfooMAJOR-devel packages during ABI upgrades, no dangerous renames -- > and probably automated rebuilds of dependency chains, regardless of > whether the results work). Well, I didn't wrote it but in my mind when we escalate to rel eng after the first TTL expiration, that's to decide if B, C, D should be poked harder, their packages dropped, or A should be asked to do a compat package since his stuff is obviously breaking too much stuff. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sun Nov 12 13:15:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Nov 2006 14:15:23 +0100 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163336961.6043.43.camel@rousalka.dyndns.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163238753.3520.15.camel@rousalka.dyndns.org> <604aa7910611110202td0853cch34758fd461d94b24@mail.gmail.com> <6280325c0611110305n3fe8342bh8c2ad592ef0f7a7c@mail.gmail.com> <604aa7910611111147k5054738do44a691a273ef7e2f@mail.gmail.com> <6280325c0611111628l6684b301r5e9623a09127cb64@mail.gmail.com> <1163324521.6043.21.camel@rousalka.dyndns.org> <20061112135650.05c86401.fedora@wir-sind-cool.org> <1163336961.6043.43.camel@rousalka.dyndns.org> Message-ID: <1163337327.6043.49.camel@rousalka.dyndns.org> Le dimanche 12 novembre 2006 ? 14:09 +0100, Nicolas Mailhot a ?crit : > Well, I didn't wrote it but in my mind when we escalate to rel eng after > the first TTL expiration, that's to decide if B, C, D should be poked > harder, their packages dropped, or A should be asked to do a compat > package since his stuff is obviously breaking too much stuff. Also you could have all sorts of interesting properties : use different policies for devel and updates to releases (never allow updates to break released repo), change the TTL values at FCTx time, have maintainers supersede broken submissions in the TTL period instead of asking to manually remove them from the push, etc -- Nicolas Mailhot From skvidal at linux.duke.edu Sun Nov 12 14:23:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 12 Nov 2006 09:23:19 -0500 Subject: Proposal - replace beagle with tracker In-Reply-To: <4556A7FD.3040001@fedoraproject.org> References: <4554AEB3.8010701@redhat.com> <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> <4556413E.8050406@redhat.com> <1163283737.9312.32.camel@cutter> <4556A7FD.3040001@fedoraproject.org> Message-ID: <1163341399.9312.34.camel@cutter> On Sun, 2006-11-12 at 10:20 +0530, Rahul Sundaram wrote: > seth vidal wrote: > > On Sat, 2006-11-11 at 16:31 -0500, Christopher Aillon wrote: > > > >>> > >> There are also problems with the code quality, or lack thereof. It's > >> dissected somewhere else in the thread. > > > > If we're not going to let packages in based on code quality "standards" > > then we're going to be kicking out a lot packages I think. > > What is going to be default generally has higher standards applied to > them. There already is a lot of packages discouraged for their code > quality. I know atleast phpbb and webmin were put up for review and left > off in the middle when people pointed out their security history and > need for constant vigilance. > There's a sharp distinction between: riddled with security holes and "code is not pretty enough" -sv From jkeating at redhat.com Sun Nov 12 15:06:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Nov 2006 10:06:16 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <20061112131854.5255bd88.fedora@wir-sind-cool.org> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <1163323357.6043.1.camel@rousalka.dyndns.org> <20061112131854.5255bd88.fedora@wir-sind-cool.org> Message-ID: <200611121006.17014.jkeating@redhat.com> On Sunday 12 November 2006 07:18, Michael Schwendt wrote: > This is the typical ?discuss-things-endlessly-before-even-trying ?type of > conversation. Meanwhile, the "Package EVR problems in FC+FE" report [1] > gets longer (even ".FC6" dist tags pop up in there - what the heck?!), and > Extras packagers don't rebuild their devel packages either. Even if they > managed to do so with a time-consuming mock build, they could not update > their rawhide machines (or upgrade FC6 to rawhide) without trying to hack a > long list of excludes. And extras people can't rebuild against packages that don't get published. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jfrieben at freesurf.fr Sun Nov 12 15:08:51 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sun, 12 Nov 2006 16:08:51 +0100 (CET) Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111757.45700.jkeating@redhat.com> References: <200611111757.45700.jkeating@redhat.com> Message-ID: <53192.194.94.224.254.1163344131.squirrel@arlette.freesurf.fr> > In fact, for this next development cycle, I'd like to > change how the boot.iso and such work for rawhide, in that it doesn't > KNOW about any packages, rather it just has core and extras as > preselected remote repositories. This way you can use a good > combination of kernel and anaconda to install day after day after day, > and rawhide becomes nothing more than a createrepo call. As a matter of fact, [for the time being] the "rescue" image and also the installation media of "FC6" do actually allow you to carry out an "http" install from the current "rawhide" tree. The difference to "boot.iso" is that "stage2.img" is already included which seems to avoid the standard tree date mismatch message. After a fresh "rawhide" install as of 2006-11-11 [IPV4 is broken right now in current "anaconda"], I also tried out the "FC5" image for this purpose, and even here, everything went smoothly up to the point where the final confirmation was required [I aborted the install procedure at this moment deliberately but I am confident that it would have proceeded successfully]. From gilboad at gmail.com Sun Nov 12 16:28:10 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 18:28:10 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111309.35147.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163258466.26941.146.camel@gilboa-home-dev.localhost> <200611111309.35147.jkeating@redhat.com> Message-ID: <1163348890.1615.85.camel@gilboa-work-dev> On Sat, 2006-11-11 at 13:09 -0500, Jesse Keating wrote: > On Saturday 11 November 2006 10:21, Gilboa Davara wrote: > > Question: Can pungi be used to auto-create the ISOs? > > Cron is your friend. > > Missing deps isn't the problem, its the actual functionality of the installer, > or of the packages being installed. These are harder to test automatically, > and harder to fix without a freeze in place. OK. I accept that spinning test releases once that tree build integrity is achieved is problematic. (Though I still call for -more- test releases and a logical naming scheme) By -design-, Anacnoda bombs out if anything is broken. If you maintain that there's no way to create/detect/exclude a stable tree image, Anaconda should be able to detect and remove missing deps -and- do graceful recovery (as opposed to graceful exit) when something is broken but was undetected during the initial scan. This should ensure that unless something is broken within Anaconda (which is interesting and worthwhile by itself), most install attempts will end with a bootable image - no matter which package configuration was selected. Missing stuff (or broken stuff) can always be installed using "yum --exclude XXX update" As it stands, at least in my own experience, getting rawhide installed from scratch is a matter of pure luck. I'm trying to find a way to replace dumb luck with better error handling. - Gilboa From rob at choralone.org Sun Nov 12 16:25:43 2006 From: rob at choralone.org (Rob Andrews) Date: Sun, 12 Nov 2006 16:25:43 +0000 Subject: wireless NICs, wpa In-Reply-To: <87ac2zupwf.fsf@arbol.wsrcc.com> References: <1163155515.17650.10.camel@fred.scooby.net> <20061110115759.GB6767@aphasia.badger.choralone.org> <87ac2zupwf.fsf@arbol.wsrcc.com> Message-ID: <20061112162543.GB5733@aphasia.badger.choralone.org> On 10-Nov-2006 18:18.08 (GMT), Wolfgang S. Rupprecht wrote: > > http://choralone.org/cruft/random/ns.diff > This is much more extensive than I use. (Not to say this is a bad > idea, but this is more intrusive than needed to get things working.) It is. What I'm going to aim for (ideal solution) is support for setting up 802.1x in system-config-network. The integration with the ifup/down scripts is intentional, so the supplicant is started and stopped when the interface is brought up or down. That way no external initscripts are required. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From wtogami at redhat.com Sun Nov 12 16:30:02 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 12 Nov 2006 11:30:02 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163322809.1615.6.camel@gilboa-work-dev> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> Message-ID: <45574C0A.1060309@redhat.com> Gilboa Davara wrote: > > This a nice solution - though I rather have a simple method of > overriding the selection without editing a configuration file and/or > making it system wide. > IMHO, adding a command line parameters seems like the obvious choice as > it gives the user additional means of controlling which version is > executed. > > I can combine your patch with mine - read, use the default > in /etc/sysconfig/firefox-arch unless the user specifically requested > something else. > Does it sound reasonable to you? > > - Gilboa I don't think there is much value to end-users to have a --32 or --64 switch, because command line is NOT how you should expect users to launch firefox. It wouldn't hurt to have the option though. Also keep in mind that due to xremote, you CAN'T run both 32bit and 64bit browsers at the same time without making further modifications to firefox to handle it. In any case, merging our patches would be a moot point, because it wont be accepted into Fedora. Warren Togami wtogami at redhat.com From gilboad at gmail.com Sun Nov 12 16:33:45 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 18:33:45 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <604aa7910611111336o4fd2c730r8ae16a72b81ffdb@mail.gmail.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163258466.26941.146.camel@gilboa-home-dev.localhost> <604aa7910611111336o4fd2c730r8ae16a72b81ffdb@mail.gmail.com> Message-ID: <1163349225.1615.92.camel@gilboa-work-dev> On Sat, 2006-11-11 at 12:36 -0900, Jeff Spaleta wrote: > On 11/11/06, Gilboa Davara wrote: > > On Sat, 2006-11-11 at 00:28 -0900, Jeff Spaleta wrote: > > > On 11/10/06, Gilboa Davara wrote: > > > > A. Create more mile-stone releases. Once the tree reaches build > > > > integrity (no missing packages), spin a test release. (Fixes P1, P2) > > > > > > Logic fault... we dont have enough testers right now... more > > > mile-stone releases will actually mean even fewer people will be > > > testing each of those releases. We don't magically gain more manhours > > > of testing by having 14 individual isosets in the wild. > > > > > > You've missed my point. > > Take Mozilla - each and every night they release a nightly build. > > First of all you can't respin all of rawhide in one night. Are you > seriously suggesting that we re-engineer rawhide in such a way that we > do a full respin of the entire codebase and then push the full tree as > one unit..everytime we make a public push? Let's keep the scale of > the problems in mind please. Rawhide has dependancy issues because > the codebase is so large that it can't be easily re-mastered in one > big push. Mass rebuilds when they are required are major multiday > efforts, and we can not rely on that left of churn as the primary way > to get individual component updates out and tested. OK. Bad selection of example on my part. It was not my intention to get a nightly ISO build. I am looking for a way to get a 1/1 install/boot ratio, which means, unless something is broken within Anaconda itself, for each install/upgrade attempt, I'd be getting a bootable image. > > > Point of reason: > > A. The biggest issue with any Linux distribution is the installer. > > I'm going to focus on this one item, since most of the others are > associated with the idea of getting better testing of the installer > specifically. I have an alternative proposal for installer testing > instead of attempting to force more structure into the rawhide > process. I agree that the installer itself is a very special case, a > case that rawhide's structure isn't well suited for. > > If we want to develop a regiment for testing the installer > functionality specifically... then we should be discussing nightly > builds of the installer against a simple to use and very static > package-payload that does not represent the full rawhide image. We > don't need full rawhide tree consistency to better test the installer. > > There's no reason that we need to make the full rawhide tree available > for people who want to continually test the installer functionality > and do regression testing for things like partition creation and > handling. All you need to do is to identify a basic set of payload > packages that is neceessary to test the installer.. make that payload > set semi-static.. and pump out test images of the installer as the > installer codebase gets updated using this cutdown package payload. > Update that cutdown package payload as it become self-consistent > regardless of the full state of the rawhide tree. We don't need > openoffice to be in a consistent state in the full rawhide tree to > test the installer for regressions. > > So let me recap for anyone who could make this happen. > > Problem statement: > Better testing of the installer functionality regardless of the state > of the full rawhide tree. > > Proposal: > creation of a semi-static payload tree that nightly builds of the > installer targets so testers can avoid depchain breakage at install > time, while still being able to test all installer based > functionality. Additionally the semi-static payload would provide a > test of the firstboot process as well. While there is no substitute > for bare metal, allow for a xen based testing process so testers > without dedicated hardware can chew on these nightly installer builds > to do some regression testing. > > Thoughts from the release-eng and installer people inside RedHat as to > the feasibility and usefulness of this proposal? > > -jef Good idea, but no go. If you create a static test case, upgrade can no longer be tested. In recent years I rarely seen a non-Rawhide Anaconda blowing up during fresh install. Anaconda/FC6 alone killed two upgrades. Gilboa "Just fresh-installed his laptop after a botched FC6 upgrade" Davara. From gilboad at gmail.com Sun Nov 12 16:41:31 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 18:41:31 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45574C0A.1060309@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> Message-ID: <1163349691.1615.99.camel@gilboa-work-dev> On Sun, 2006-11-12 at 11:30 -0500, Warren Togami wrote: > Gilboa Davara wrote: > > > > This a nice solution - though I rather have a simple method of > > overriding the selection without editing a configuration file and/or > > making it system wide. > > IMHO, adding a command line parameters seems like the obvious choice as > > it gives the user additional means of controlling which version is > > executed. > > > > I can combine your patch with mine - read, use the default > > in /etc/sysconfig/firefox-arch unless the user specifically requested > > something else. > > Does it sound reasonable to you? > > > > - Gilboa > > I don't think there is much value to end-users to have a --32 or --64 > switch, because command line is NOT how you should expect users to > launch firefox. It wouldn't hurt to have the option though. I can argue that we can add a second icon that adds the --32bit command line parameter. > > Also keep in mind that due to xremote, you CAN'T run both 32bit and > 64bit browsers at the same time without making further modifications to > firefox to handle it. Known problem. It's possible to disable xremote check if --32/--64 parameter is set, but it may create havoc in the .mozilla directory, making it less, err, useful. > > In any case, merging our patches would be a moot point, because it wont > be accepted into Fedora. Point taken. ...One question though, if there's no way to use it (32bit firefox), why the !@?#^?#^ are we installing it in the first place? - Gilboa From warren at togami.com Sun Nov 12 16:46:11 2006 From: warren at togami.com (Warren Togami) Date: Sun, 12 Nov 2006 11:46:11 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163349691.1615.99.camel@gilboa-work-dev> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> Message-ID: <45574FD3.5000305@togami.com> Gilboa Davara wrote: >> In any case, merging our patches would be a moot point, because it wont >> be accepted into Fedora. > > Point taken. > > ...One question though, if there's no way to use it (32bit firefox), why > the !@?#^?#^ are we installing it in the first place? > > - Gilboa > I'm pretty annoyed by this as well. So I am soon submitting an alternative short-term solution to Extras. The real solution is to make browser plugins run out-of-process. This would have tremendous benefits to us in the long-term. I am skeptical however that it will happen in a timely manner. Warren Togami wtogami at redhat.com From jkeating at redhat.com Sun Nov 12 16:53:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Nov 2006 11:53:54 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163348890.1615.85.camel@gilboa-work-dev> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111309.35147.jkeating@redhat.com> <1163348890.1615.85.camel@gilboa-work-dev> Message-ID: <200611121153.54407.jkeating@redhat.com> On Sunday 12 November 2006 11:28, Gilboa Davara wrote: > By -design-, Anacnoda bombs out if anything is broken. Actually I strongly question this. Anaconda seems perfectly happy to install packages with broken deps. its when things are missing for %post installs that things go haywire. > If you maintain that there's no way to create/detect/exclude a stable > tree image, Anaconda should be able to detect and remove missing deps > -and- do graceful recovery (as opposed to graceful exit) when something > is broken but was undetected during the initial scan. > This should ensure that unless something is broken within Anaconda > (which is interesting and worthwhile by itself), most install attempts > will end with a bootable image - no matter which package configuration > was selected. Missing stuff (or broken stuff) can always be installed > using "yum --exclude XXX update" But in my new world of rawhide, where anaconda knows nothing about packages until you start the install and it pulls the latest repodata from whatever repo this becomes a bit different. Anaconda doesn't know anything until you run it, not when the boot images were created. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Sun Nov 12 17:08:19 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 19:08:19 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45574FD3.5000305@togami.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> Message-ID: <1163351299.1615.114.camel@gilboa-work-dev> On Sun, 2006-11-12 at 11:46 -0500, Warren Togami wrote: > Gilboa Davara wrote: > >> In any case, merging our patches would be a moot point, because it wont > >> be accepted into Fedora. > > > > Point taken. > > > > ...One question though, if there's no way to use it (32bit firefox), why > > the !@?#^?#^ are we installing it in the first place? > > > > - Gilboa > > > > I'm pretty annoyed by this as well. So I am soon submitting an > alternative short-term solution to Extras. > > The real solution is to make browser plugins run out-of-process. This > would have tremendous benefits to us in the long-term. I am skeptical > however that it will happen in a timely manner. > You thinking about submitting nspluginwrapper? - Gilboa From gilboad at gmail.com Sun Nov 12 17:09:35 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 19:09:35 +0200 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611121153.54407.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111309.35147.jkeating@redhat.com> <1163348890.1615.85.camel@gilboa-work-dev> <200611121153.54407.jkeating@redhat.com> Message-ID: <1163351375.1615.116.camel@gilboa-work-dev> On Sun, 2006-11-12 at 11:53 -0500, Jesse Keating wrote: > On Sunday 12 November 2006 11:28, Gilboa Davara wrote: > > By -design-, Anacnoda bombs out if anything is broken. > > Actually I strongly question this. Anaconda seems perfectly happy to install > packages with broken deps. its when things are missing for %post installs > that things go haywire. > > > If you maintain that there's no way to create/detect/exclude a stable > > tree image, Anaconda should be able to detect and remove missing deps > > -and- do graceful recovery (as opposed to graceful exit) when something > > is broken but was undetected during the initial scan. > > This should ensure that unless something is broken within Anaconda > > (which is interesting and worthwhile by itself), most install attempts > > will end with a bootable image - no matter which package configuration > > was selected. Missing stuff (or broken stuff) can always be installed > > using "yum --exclude XXX update" > > But in my new world of rawhide, where anaconda knows nothing about packages > until you start the install and it pulls the latest repodata from whatever > repo this becomes a bit different. Anaconda doesn't know anything until you > run it, not when the boot images were created. Can it be fixed by pointing Anaconda to a second, automatically screened, repodata? - Gilboa From warren at togami.com Sun Nov 12 17:14:28 2006 From: warren at togami.com (Warren Togami) Date: Sun, 12 Nov 2006 12:14:28 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <1163351299.1615.114.camel@gilboa-work-dev> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> <1163351299.1615.114.camel@gilboa-work-dev> Message-ID: <45575674.2090208@togami.com> Gilboa Davara wrote: >> I'm pretty annoyed by this as well. So I am soon submitting an >> alternative short-term solution to Extras. >> >> The real solution is to make browser plugins run out-of-process. This >> would have tremendous benefits to us in the long-term. I am skeptical >> however that it will happen in a timely manner. >> > > You thinking about submitting nspluginwrapper? > > - Gilboa > No. It is broken and requires lots of work. You will see my submission soon. Warren Togami wtogami at redhat.com From gilboad at gmail.com Sun Nov 12 17:17:16 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 12 Nov 2006 19:17:16 +0200 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45575674.2090208@togami.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> <1163351299.1615.114.camel@gilboa-work-dev> <45575674.2090208@togami.com> Message-ID: <1163351836.1615.118.camel@gilboa-work-dev> On Sun, 2006-11-12 at 12:14 -0500, Warren Togami wrote: > Gilboa Davara wrote: > >> I'm pretty annoyed by this as well. So I am soon submitting an > >> alternative short-term solution to Extras. > >> > >> The real solution is to make browser plugins run out-of-process. This > >> would have tremendous benefits to us in the long-term. I am skeptical > >> however that it will happen in a timely manner. > >> > > > > You thinking about submitting nspluginwrapper? > > > > - Gilboa > > > > No. It is broken and requires lots of work. You will see my submission > soon. > > Warren Togami > wtogami at redhat.com OK. Thanks. - Gilboa From jkeating at redhat.com Sun Nov 12 18:03:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Nov 2006 13:03:55 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163351375.1615.116.camel@gilboa-work-dev> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611121153.54407.jkeating@redhat.com> <1163351375.1615.116.camel@gilboa-work-dev> Message-ID: <200611121303.58699.jkeating@redhat.com> On Sunday 12 November 2006 12:09, Gilboa Davara wrote: > Can it be fixed by pointing Anaconda to a second, automatically > screened, repodata? The possibilities are endless. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Sun Nov 12 20:21:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 12 Nov 2006 11:21:56 -0900 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <1163349225.1615.92.camel@gilboa-work-dev> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <604aa7910611110128n1fc27ed9hf998148b8954947c@mail.gmail.com> <1163258466.26941.146.camel@gilboa-home-dev.localhost> <604aa7910611111336o4fd2c730r8ae16a72b81ffdb@mail.gmail.com> <1163349225.1615.92.camel@gilboa-work-dev> Message-ID: <604aa7910611121221ob219f3at64ef60b3bfc7bce@mail.gmail.com> On 11/12/06, Gilboa Davara wrote: > Good idea, but no go. > If you create a static test case, upgrade can no longer be tested. It seems Jesse has the better solution already by fixing anaconda to work more generally. If I understand him correctly.. we will be able to eat nightly boot.iso images and point them to a previously existing test release package tree (or even our own local trees) instead of having to attempt a rawhide payload install. So we should be able to get daily testing of the installer codebase against a consistent payload tree without an overhaul of the entire rawhide build process and associated complications for Extras maintainers. I think Jesse's idea is going to solve the specific issue of installer testing quite well. And just as importantly it will also make it easier to serve the community with installer image updates post-release when they are needed to address specific hardware issues. I would encourage jesse or other release-eng people to give a nice big heads-up to this list when the necessary changes to anaconda and the boot.iso generation go live in rawhide. -jef From jspaleta at gmail.com Sun Nov 12 22:57:57 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 12 Nov 2006 13:57:57 -0900 Subject: Can we make readahead more robust to package updates? Message-ID: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> Okay its come to my attention that the readahead configs have a difficult time being kept in sync as package updates roll out. For fc6 right now for example readahead is out of sync with firefox libraries. Can we update readahead's implementation so we can get per package control of the default configs? Is a readahead.d/ structure appropriate here? I want to point out that we lose significant value with read-ahead if we can't ensure that the listings will be in-sync as package updates are issued. And re-spinning readahead updates periodically to attempt to sync a centralized config file is horrible inefficient and may never be perfectly in-sync considering the churn of updates during a release cycle. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203329 -jef From peter at thecodergeek.com Sun Nov 12 23:09:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 12 Nov 2006 15:09:27 -0800 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> Message-ID: <1163372968.8617.4.camel@tuxhugger> On Sun, 2006-11-12 at 13:57 -0900, Jeff Spaleta wrote: > Can we update readahead's implementation so we can get per package > control of the default configs? Is a readahead.d/ structure > appropriate here? I think this would be the Right Way(tm) to do it. Without native support for it, we could still at least cat all of those files into the proper readahead listing before running it. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sun Nov 12 23:15:57 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 12 Nov 2006 14:15:57 -0900 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> Message-ID: <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> On 11/12/06, Jeff Spaleta wrote: > Okay its come to my attention that the readahead configs have a > difficult time being kept in sync as package updates roll out. For fc6 > right now for example readahead is out of sync with firefox libraries. > > Can we update readahead's implementation so we can get per package > control of the default configs? Is a readahead.d/ structure > appropriate here? Sorry... i didnt look hard enough... the readahead.d structure was added for fc6.... the problem is package maintainers aren't using it yet. I guess what I need to do is parse the existing config file... identify individual packages that could drop files in readahead.d/ and poke the appropriate maintainers in the eye about dropping a file in there as part of package payloading. Anyone want to help me construct the list of packages that could make sure of readahead.d/ on a per package basis based on the default readahead configs we have right now? -jef"First up... the firefox maintainer... where's my eye poking stick"spaleta From wtogami at redhat.com Sun Nov 12 23:44:42 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 12 Nov 2006 18:44:42 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45575674.2090208@togami.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> <1163351299.1615.114.camel@gilboa-work-dev> <45575674.2090208@togami.com> Message-ID: <4557B1EA.1040109@redhat.com> Warren Togami wrote: > Gilboa Davara wrote: >>> I'm pretty annoyed by this as well. So I am soon submitting an >>> alternative short-term solution to Extras. >>> >>> The real solution is to make browser plugins run out-of-process. >>> This would have tremendous benefits to us in the long-term. I am >>> skeptical however that it will happen in a timely manner. >>> >> >> You thinking about submitting nspluginwrapper? >> >> - Gilboa >> > > No. It is broken and requires lots of work. You will see my submission > soon. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215256 Yes, this really sucks. Warren Togami wtogami at redhat.com From vonbrand at inf.utfsm.cl Sun Nov 12 16:27:26 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 12 Nov 2006 13:27:26 -0300 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: Message from Jesse Keating of "Sat, 11 Nov 2006 13:09:34 CDT." <200611111309.35147.jkeating@redhat.com> Message-ID: <200611121632.kACGRQK4007847@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Saturday 11 November 2006 10:21, Gilboa Davara wrote: > > Question: Can pungi be used to auto-create the ISOs? > > Cron is your friend. > Missing deps isn't the problem, its the actual functionality of the > installer, or of the packages being installed. These are harder to test > automatically, and harder to fix without a freeze in place. What about creating a "minimal daily (weekly, ...) rawhide CD", with just enough stuff to check that the installer (and the suchly installed system) works? I.e., kernel(s) and related stuff, perhaps up to X and Gnome? No fancy alternatives, etc. That way the risk of massive breakage is lower, and the result is easier on downloaders and testers. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From fedora at wir-sind-cool.org Mon Nov 13 01:06:38 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 13 Nov 2006 02:06:38 +0100 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <4557B1EA.1040109@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> <1163351299.1615.114.camel@gilboa-work-dev> <45575674.2090208@togami.com> <4557B1EA.1040109@redhat.com> Message-ID: <20061113020638.2ee0b964.fedora@wir-sind-cool.org> On Sun, 12 Nov 2006 18:44:42 -0500, Warren Togami wrote: > Warren Togami wrote: > > Gilboa Davara wrote: > >>> I'm pretty annoyed by this as well. So I am soon submitting an > >>> alternative short-term solution to Extras. > >>> > >>> The real solution is to make browser plugins run out-of-process. > >>> This would have tremendous benefits to us in the long-term. I am > >>> skeptical however that it will happen in a timely manner. > >>> > >> > >> You thinking about submitting nspluginwrapper? > >> > >> - Gilboa > >> > > > > No. It is broken and requires lots of work. You will see my submission > > soon. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215256 > Yes, this really sucks. Ugly indeed. Are you serious about building this as x86_64, ppc64 and s390x, but with a non-32-bit-specific dependency on "firefox"? You end up with an x86_64 package to be used for an i386 firefox, a ppc64 package for a ppc firefox, and so on. It's also possible to uninstall 32-bit firefox and keep this package including the trigger and the menu entry. With regard to the bottom half of the %description, there is one big question: *Why* isn't it done? From jkeating at redhat.com Mon Nov 13 04:09:44 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Nov 2006 23:09:44 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611121632.kACGRQK4007847@laptop13.inf.utfsm.cl> References: <200611121632.kACGRQK4007847@laptop13.inf.utfsm.cl> Message-ID: <200611122309.44686.jkeating@redhat.com> On Sunday 12 November 2006 11:27, Horst H. von Brand wrote: > What about creating a "minimal daily (weekly, ...) rawhide CD", with just > enough stuff to check that the installer (and the suchly installed system) > works? I.e., kernel(s) and related stuff, perhaps up to X and Gnome? No > fancy alternatives, etc. That way the risk of massive breakage is lower, > and the result is easier on downloaders and testers. Select less from the available repos. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon Nov 13 05:37:34 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 13 Nov 2006 00:37:34 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <20061113020638.2ee0b964.fedora@wir-sind-cool.org> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> <1163351299.1615.114.camel@gilboa-work-dev> <45575674.2090208@togami.com> <4557B1EA.1040109@redhat.com> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> Message-ID: <4558049E.9030706@redhat.com> Michael Schwendt wrote: > On Sun, 12 Nov 2006 18:44:42 -0500, Warren Togami wrote: > >> Warren Togami wrote: >>> Gilboa Davara wrote: >>>>> I'm pretty annoyed by this as well. So I am soon submitting an >>>>> alternative short-term solution to Extras. >>>>> >>>>> The real solution is to make browser plugins run out-of-process. >>>>> This would have tremendous benefits to us in the long-term. I am >>>>> skeptical however that it will happen in a timely manner. >>>>> >>>> You thinking about submitting nspluginwrapper? >>>> >>>> - Gilboa >>>> >>> No. It is broken and requires lots of work. You will see my submission >>> soon. >>> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215256 >> Yes, this really sucks. > > Ugly indeed. Are you serious about building this as x86_64, ppc64 and > s390x, but with a non-32-bit-specific dependency on "firefox"? You end up > with an x86_64 package to be used for an i386 firefox, a ppc64 package for > a ppc firefox, and so on. It's also possible to uninstall 32-bit firefox > and keep this package including the trigger and the menu entry. We don't build Extras packages for ppc64 and s390x, but for completeness this package would be buildable there too if anybody cared. Can you think of a way to make a firefox.i386 dependency specifically if this is a x86_64 arch package? I can't. > > With regard to the bottom half of the %description, there is one big > question: *Why* isn't it done? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214100 From jkeating at redhat.com Mon Nov 13 05:41:24 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 13 Nov 2006 00:41:24 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <4558049E.9030706@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> <4558049E.9030706@redhat.com> Message-ID: <200611130041.24557.jkeating@redhat.com> On Monday 13 November 2006 00:37, Warren Togami wrote: > Can you think of a way to make a firefox.i386 dependency specifically if > this is a x86_64 arch package? ?I can't. Have file requires on one of the 32bit libraries. Only the 32bit firefox would supply that library. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon Nov 13 05:46:03 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 13 Nov 2006 00:46:03 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <200611130041.24557.jkeating@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> <4558049E.9030706@redhat.com> <200611130041.24557.jkeating@redhat.com> Message-ID: <4558069B.60708@redhat.com> Jesse Keating wrote: > On Monday 13 November 2006 00:37, Warren Togami wrote: >> Can you think of a way to make a firefox.i386 dependency specifically if >> this is a x86_64 arch package? I can't. > > Have file requires on one of the 32bit libraries. Only the 32bit firefox > would supply that library. > > This doesn't exactly work in the case of firefox, because it uses versioned directories. And AFAIK none of the other things owned by the package is unique to firefox.i386. Warren Togami wtogami at redhat.com From jfrieben at freesurf.fr Mon Nov 13 07:28:17 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 13 Nov 2006 08:28:17 +0100 (CET) Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611121632.kACGRQK4007847@laptop13.inf.utfsm.cl> References: <200611121632.kACGRQK4007847@laptop13.inf.utfsm.cl> Message-ID: <58479.172.178.118.157.1163402897.squirrel@jose.freesurf.fr> > What about creating a "minimal daily (weekly, ...) rawhide CD", with > just enough stuff to check that the installer (and the suchly installed > system) works? I.e., kernel(s) and related stuff, perhaps up to X and > Gnome? No fancy alternatives, etc. That way the risk of massive > breakage is lower, and the result is easier on downloaders and testers. > -- > Dr. Horst H. von Brand User #22616 counter.li.org > Departamento de Informatica Fono: +56 32 2654431 > Universidad Tecnica Federico Santa Maria +56 32 2654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 You might want to have a look at my previous posting because the "rescue" disk already allows this to a [certain (?)] extent: https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00313.html From arjan at fenrus.demon.nl Mon Nov 13 08:06:20 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 13 Nov 2006 09:06:20 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> Message-ID: <1163405180.15249.105.camel@laptopd505.fenrus.org> On Sun, 2006-11-12 at 13:57 -0900, Jeff Spaleta wrote: > Okay its come to my attention that the readahead configs have a > difficult time being kept in sync as package updates roll out. For fc6 > right now for example readahead is out of sync with firefox libraries. > > Can we update readahead's implementation so we can get per package > control of the default configs? Is a readahead.d/ structure > appropriate here? maybe. the downside is that you now add extra costs (seeks :) which.. well readahead was trying to avoid. So if this is going to get used massively it's less certain things will gain as much as before... From jspaleta at gmail.com Mon Nov 13 09:48:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Nov 2006 00:48:24 -0900 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163405180.15249.105.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> Message-ID: <604aa7910611130148p60ea7ed7kf39d767798c40c8f@mail.gmail.com> On 11/12/06, Arjan van de Ven wrote: > the downside is that you now add extra costs (seeks :) which.. well > readahead was trying to avoid. So if this is going to get used massively > it's less certain things will gain as much as before... I'm not saying use it for everything.. im just saying lets make sure that the default items we have now in the readahead config actually stay in sync with the libraries on disk so users can derive consistent benefit from it over time. My current favorite example is firefox. The libraries are listed in the default readahead config..but now that firefox has seen an update, the listings are no longer in-sync with the files on disk.. because the library locations are in a versioned directory tree...so firefox won't get a readahead boost on an updated system. I understand the seek time issue associated with doing readahead willy-nilly, so if you can think of a way to centralize a default config and prevent out-of-sync conditions like we have with firefox at the moment I'm all ears. Please go ahead and take a lot at the listing in default.later and see if anything else besides firefox is currently out of sync on an updated fc6 install. -jef From fedora at camperquake.de Mon Nov 13 09:48:52 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 13 Nov 2006 10:48:52 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163405180.15249.105.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> Message-ID: <20061113104852.11ee30d8@yareena.int.addix.net> Hi. On Mon, 13 Nov 2006 09:06:20 +0100, Arjan van de Ven wrote: > the downside is that you now add extra costs (seeks :) which.. well > readahead was trying to avoid. So if this is going to get used > massively it's less certain things will gain as much as before... Maybe run a script on system shutdown which reads all the files under /etc/readahead.d and creates a single config file for readahead to read on the next boot? From arjan at fenrus.demon.nl Mon Nov 13 10:07:41 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 13 Nov 2006 11:07:41 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061113104852.11ee30d8@yareena.int.addix.net> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> Message-ID: <1163412461.15249.125.camel@laptopd505.fenrus.org> On Mon, 2006-11-13 at 10:48 +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 13 Nov 2006 09:06:20 +0100, Arjan van de Ven wrote: > > > the downside is that you now add extra costs (seeks :) which.. well > > readahead was trying to avoid. So if this is going to get used > > massively it's less certain things will gain as much as before... > > Maybe run a script on system shutdown which reads all the files under > /etc/readahead.d and creates a single config file for readahead to > read on the next boot? I really like this idea; it's a simple "cat" and it can be done at a time where latency doesn't matter... (even in cron.daily) Oh... this opens more options. This also allows the "sort by blocknumber" to be done at this point and taken out of the critical latency part...... great idea! From twoerner at redhat.com Mon Nov 13 13:09:12 2006 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 13 Nov 2006 14:09:12 +0100 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <4558069B.60708@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> <4558049E.9030706@redhat.com> <200611130041.24557.jkeating@redhat.com> <4558069B.60708@redhat.com> Message-ID: <45586E78.9080301@redhat.com> There is no arch support for requires in RPM. Therefore you have to add a virtual provide to the firefox package: Provides: %{name}.%{_arch} and add the requirement to the dependant package: Requires: firefox.i386 Warren Togami wrote: > Jesse Keating wrote: >> On Monday 13 November 2006 00:37, Warren Togami wrote: >>> Can you think of a way to make a firefox.i386 dependency specifically if >>> this is a x86_64 arch package? I can't. >> >> Have file requires on one of the 32bit libraries. Only the 32bit >> firefox would supply that library. >> >> > > This doesn't exactly work in the case of firefox, because it uses > versioned directories. And AFAIK none of the other things owned by the > package is unique to firefox.i386. > > Warren Togami > wtogami at redhat.com > -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From ajackson at redhat.com Mon Nov 13 13:17:28 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 13 Nov 2006 08:17:28 -0500 Subject: X in FC7 In-Reply-To: <200611101637.07377.jbarnes@virtuousgeek.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> Message-ID: <45587068.90508@redhat.com> Jesse Barnes wrote: > Well, I created an account but can't seem to edit the page. Anyway, I > like the idea of getting rid of xfs, it seems fairly useless. And to > quote mharris from awhile back: > >> Long term, what would be really nice, is if someone figured >> out a way to implement core fonts using fontconfig/Xft >> underneath so we have one font system, and it provides >> legacy compatibility to ancient applications that have not >> been updated to modern interfaces. That is something that >> would need to be spearheaded at the X.Org level rather than >> at a specific distribution however. So here's where I start to admit some font ignorance, but. I took a hack at this a while back, and it seemed to me like using fontconfig for matching was the wrong idea, since the properties available from fontconfig didn't quite match what you can select on with XLFD. As said on the wiki page, what problem is xfs trying to solve? If it's just about the ability to add fonts at runtime without having to do 'xset fp rehash', then that should be a very small amount of code to add to the X server. You need to watch for directories popping in and out of existance, but, okay, we know how to do that. > That said, which apps care about core fonts these days? Would it make > sense to just build-in a fixed font or something and let everything > else use fontconfig (as most decent apps do these days)? We do actually have a built-in fixed font now. And cursor. They've always been in the modular libXfont, we were just never telling the server to use them. In FC6 they're enabled by default. You can not remove core font functionality though, for the same reason you can't remove dashed wide arcs. > Also, which input drivers should we be using? Isn't synaptics much > better for laptops than the default mouse driver? What about evdev? > Should it be the default? We already detect synaptics via some anaconda voodoo. evdev should probably become the default once the input hotplug branch lands upstream and we start shipping that server; that's likely to be xserver 1.3, so that might not be ready in time for Fedora 7. That's sort of the pink elephant here. 1.3 will have a lot of really good stuff merged, but it's likely to be broken, guaranteedly for closed drivers but also internally. I'm hoping we can get dist-{hg,git} going soon so I can make packages available for both, 1.3 for the adventurous and 1.2 for the sane. Yes it's doable with CVS, but that's far more pain than I'm willing to take. Thanks all for the feedback, keep it coming. - ajax From wtogami at redhat.com Mon Nov 13 13:54:07 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 13 Nov 2006 08:54:07 -0500 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45586E78.9080301@redhat.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> <4558049E.9030706@redhat.com> <200611130041.24557.jkeating@redhat.com> <4558069B.60708@redhat.com> <45586E78.9080301@redhat.com> Message-ID: <455878FF.20607@redhat.com> Thomas Woerner wrote: > There is no arch support for requires in RPM. Therefore you have to add > a virtual provide to the firefox package: > > Provides: %{name}.%{_arch} > > and add the requirement to the dependant package: > > Requires: firefox.i386 The existence of this ugly hack in a side-package is due to unwillingness to do tiny changes in firefox itself. Warren Togami wtogami at redhat.com From ajackson at redhat.com Mon Nov 13 14:02:41 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 13 Nov 2006 09:02:41 -0500 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611111334.52442.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111304.14744.jkeating@redhat.com> <1163269570.7856.32.camel@rousalka.dyndns.org> <200611111334.52442.jkeating@redhat.com> Message-ID: <45587B01.1080501@redhat.com> Jesse Keating wrote: > On Saturday 11 November 2006 13:26, Nicolas Mailhot wrote: >> Not if we block only the broken parts. You know, instead of using >> testers to shame maintainers in fixing broken deps, have the buildsys do >> it, and only expose sane trees to users (with the "broken" packagesets >> being held where the buildsys can find them till they're complete) > > Thats quite the complexity to try spinning the tree, find broken deps, drop > out packages, try again, rather, rinse repeat. No, it's a do-while loop. If you start doing this from a working tree, you always have yesterday's known-good state to start from. On any given day, some subset of your packages will have changed EVR. Start with a compose that includes all updated packages, and walk it for broken deps. Define depgraph subtrees, rooted at and containing only components in a broken dep line (both sides) that have been updated since yesterday. Prune them from the candidate set for compose, and try again. Brief gedanken analysis tells me this is roughly O(n log m) on worst case behaviour, where one is the number of subtrees and the other is the number of updated packages. I suspect in practice we'll see a typical running time of 2. This does mean there will be a set of packages in a new limbo state, where they're built and published but not yet in a compose. Those packages simply go into the candidate set again in tomorrow's compose. Also the "both sides" part above might be aggressive, if we had done that for the rawhide leading to FC6 then the kernel would never have been updated because gnbd was always broken. Tough. Fix it, either by excluding broken crap from the compose, or - shock - fixing the broken packages. (Jesse, I suspect the model you're thinking of it "oh crap, the tree has broken deps, we can't publish _anything_". Which is wrong. You publish the bits that are at least guaranteed by RPM requirements to install. I mean, you want that for the updates stream for formal releases anyway, where 'yum update' should _never_ fail, and I suspect right now the releng team is doing that verification by hand. Trust the computer. Let it do the boring work.) > Look, rawhide is just a work in progress, a snapshot of what happened the day > before. We can't aways have a completely stable tree. Trying for that is > the road to insanity. Look, the kernel is just a work in progress, a snapshot of what happened the day before. We can't always have something that compiles. Trying for that is the road to insanity. Let's play spot the fallacy! Hint: only one sentence was wrong. Standard practice for rapid development environments is to require working daily builds. For a distribution, an installable package set is the definition of working. - ajax From buc at odusz.so-cdu.ru Mon Nov 13 14:41:22 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 13 Nov 2006 17:41:22 +0300 Subject: I think, rsh is quite obsolete In-Reply-To: <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> Message-ID: <45588412.40608@odu.neva.ru> Jeff Spaleta wrote: > On 11/9/06, Karel Zak wrote: > >> - around us are people who use non-Linux systems and rsh is very >> important for them >> >> >> Maybe we're already somewhere on the way between classic UNIX and >> Windows, but I think it's still to early to forget classic UNIX rule: >> >> The right tool for the job. > > > > Yes assuredly... there are situations to use things like rsh and even > telnet-server. > But the unanswered question here is.. can those situations be served > by moving this functionality into Extras and out of Core? I believe > that they can. Sometime in the future -- yes. But not now. A lot of people still buy Fedora on CDs (especially in third-world countries), and even have no on-line Internet to download something more. Removing of these "well-known" utilities (rsh and friends) will produce some kind of "culture shock" (the same as when mp3&friends was removed). And, actually, all such stuff takes just several megabytes of code. I am sure it even less than the total size of "gnome-games" included into Core... (You guess, I'm a "production envrionment" man :) ) > I also believe that continuing to narrow the focus of > Core and to keep Core technology-forward looking is important. It sounds like you want to *cause* people to switch to new technologies. It is similar to a unfair competition... ;) Seriously, the time to move this stuff to Extras is when the enterprise-level distros (RHEL etc.) will refuse it. That will mean that the market, the production environments and the real customers do not need such programs any more. > > -jef"I use rsh..but I don't need it in Core"spaleta But I need it in Core. ~buc From kevin.kofler at chello.at Mon Nov 13 15:39:49 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 13 Nov 2006 15:39:49 +0000 (UTC) Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <20061113020638.2ee0b964.fedora@wir-sind-cool.org> <4558049E.9030706@redhat.com> <200611130041.24557.jkeating@redhat.com> <4558069B.60708@redhat.com> Message-ID: Warren Togami redhat.com> writes: > Jesse Keating wrote: > > Have file requires on one of the 32bit libraries. Only the 32bit firefox > > would supply that library. > This doesn't exactly work in the case of firefox, because it uses > versioned directories. Can't you just do what all the Gecko-based apps (Galeon, Liferea et. al.) do and rebuild for each new Firefox? Kevin Kofler From kzak at redhat.com Mon Nov 13 16:00:29 2006 From: kzak at redhat.com (Karel Zak) Date: Mon, 13 Nov 2006 17:00:29 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163412461.15249.125.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> Message-ID: <20061113160029.GS4324@petra.dvoda.cz> On Mon, Nov 13, 2006 at 11:07:41AM +0100, Arjan van de Ven wrote: > On Mon, 2006-11-13 at 10:48 +0100, Ralf Ertzinger wrote: > > Hi. > > > > On Mon, 13 Nov 2006 09:06:20 +0100, Arjan van de Ven wrote: > > > > > the downside is that you now add extra costs (seeks :) which.. well > > > readahead was trying to avoid. So if this is going to get used > > > massively it's less certain things will gain as much as before... > > > > Maybe run a script on system shutdown which reads all the files under > > /etc/readahead.d and creates a single config file for readahead to > > read on the next boot? > > I really like this idea; it's a simple "cat" and it can be done at a > time where latency doesn't matter... (even in cron.daily) > > Oh... this opens more options. This also allows the "sort by > blocknumber" to be done at this point and taken out of the critical > latency part...... Good idea. Added to "TODO" list: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156442 Karel -- Karel Zak From otaylor at redhat.com Mon Nov 13 16:07:52 2006 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 13 Nov 2006 11:07:52 -0500 Subject: X in FC7 In-Reply-To: <45587068.90508@redhat.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> Message-ID: <1163434072.5123.6.camel@fresnel.dumbhippo.com> On Mon, 2006-11-13 at 08:17 -0500, Adam Jackson wrote: > Jesse Barnes wrote: > > > Well, I created an account but can't seem to edit the page. Anyway, I > > like the idea of getting rid of xfs, it seems fairly useless. And to > > quote mharris from awhile back: > > > >> Long term, what would be really nice, is if someone figured > >> out a way to implement core fonts using fontconfig/Xft > >> underneath so we have one font system, and it provides > >> legacy compatibility to ancient applications that have not > >> been updated to modern interfaces. That is something that > >> would need to be spearheaded at the X.Org level rather than > >> at a specific distribution however. > > So here's where I start to admit some font ignorance, but. I took a > hack at this a while back, and it seemed to me like using fontconfig for > matching was the wrong idea, since the properties available from > fontconfig didn't quite match what you can select on with XLFD. > > As said on the wiki page, what problem is xfs trying to solve? If it's > just about the ability to add fonts at runtime without having to do > 'xset fp rehash', then that should be a very small amount of code to add > to the X server. You need to watch for directories popping in and out > of existance, but, okay, we know how to do that. There's basically one reason why we switched to xfs years ago ... performance with large fonts; if you don't use xfs, then trying to load a large core font (for CHJK) can block all requests to the server for several seconds. Well, it could on machines of that day. Since core fonts are really fringe at this point, the main concern with a switch back to using in-server fonts would be configuration ... do you really want to change complicated %post scripts for a bunch of packages to do something new and different? That would be the possible advantage of a switch to locating fonts via fontconfig... there wouldn't be something new to add to the font packages. On the other there fair bit of new engineering and it also raises the question of what do you do to keep your set of core fonts and fontconfig font distinct? ... you don't want all the Adobe Helvetica bitmaps infecting your nice scalable fonts, and you don't want Indic/Arabic/etc fonts to show up when listing core fonts since they are useless within the core font system. - Owen From markmc at redhat.com Mon Nov 13 16:13:00 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 13 Nov 2006 11:13:00 -0500 Subject: AT_SPI_REGISTRY In-Reply-To: <20061111003550.GC21277@joshua.mesa.nl> References: <20061110234829.GB21277@joshua.mesa.nl> <1163204470.3033.8.camel@blaa> <20061111003550.GC21277@joshua.mesa.nl> Message-ID: <1163434380.3113.20.camel@blaa> On Sat, 2006-11-11 at 01:35 +0100, Marcel J.E. Mol wrote: > On Fri, Nov 10, 2006 at 07:21:10PM -0500, Mark McLoughlin wrote: > > On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > > > I'm running kde if that matters. > > > > That's probably the problem ... we've just updated to gnome-session > > 2.17.2 which includes this: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=345428 > > > > Basically, gnome-session starts at-registryd now ... > > > > Right. So this needs a bit tweaking in some scripts... > > % /usr/libexec/at-spi-registryd > Xlib: extension "XEVIE" missing on display ":0.0". > > > Suspended > % bg > [3] /usr/libexec/at-spi-registryd & > % gnumeric > Bonobo accessibility support initialized > GTK Accessibility Module initialized > > And gnumeric is happily running. You should log a Fedora/gnome-session bug on this, FWIW Cheers, Mark. From kzak at redhat.com Mon Nov 13 16:22:59 2006 From: kzak at redhat.com (Karel Zak) Date: Mon, 13 Nov 2006 17:22:59 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> Message-ID: <20061113162259.GT4324@petra.dvoda.cz> On Sun, Nov 12, 2006 at 02:15:57PM -0900, Jeff Spaleta wrote: > On 11/12/06, Jeff Spaleta wrote: > >Okay its come to my attention that the readahead configs have a > >difficult time being kept in sync as package updates roll out. For fc6 > >right now for example readahead is out of sync with firefox libraries. > > > >Can we update readahead's implementation so we can get per package > >control of the default configs? Is a readahead.d/ structure > >appropriate here? > > Sorry... i didnt look hard enough... the readahead.d structure was > added for fc6.... the problem is package maintainers aren't using it > yet. I guess what I need to do is parse the existing config file... > identify individual packages that could drop files in readahead.d/ > and poke the appropriate maintainers in the eye about dropping a file > in there as part of package payloading. > > Anyone want to help me construct the list of packages that could make > sure of readahead.d/ on a per package basis based on the default > readahead configs we have right now? I don't have machine with full FC6 installation, but you can create the list very easily by shell command: for f in `cat /etc/readahead.d/default.*`; do rpm -q --queryformat "%{NAME}\n" -f $f 2> /dev/null; done | sort -u > -jef"First up... the firefox maintainer... where's my eye poking > stick"spaleta The problem is not firefox only. It's pretty generic problem, because we have versions filenames for libraries: $ grep '/usr/lib/lib.*[0-9].*' /etc/readahead.d/default.* | wc -l 136 It's means almost all things in /etc/readahead.d/default.* could be obsolete after an update (except stable things like /bin/*). Karel -- Karel Zak From galibert at pobox.com Mon Nov 13 16:23:01 2006 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 13 Nov 2006 17:23:01 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> Message-ID: <20061113162301.GA59973@dspnet.fr.eu.org> On Sat, Nov 11, 2006 at 12:45:17AM -0900, Jeff Spaleta wrote: > How do we make it so we don't need to have all the legacy tools that > we need in Core to feel that our needs are being adequately met? How > does Extras need to be expanded so that we feel comfortable having > our critically important legacy tools live there? What is the current target of Core? Right now it looks like there is a push to limit it to the needs of the "home desktop/laptop, gnome-desktop only, office tools, no cli" crowd. The windows desktop crowd, in other words. Everybody else has to go hit extras. Is that by design, or does it just happen? Maybe the core/extras distinction should go away, to be replaced by a "make your own core" system. I have the starts of one, but it would require a lot of work still. There could be lists of packages for for instance: - base - gnome desktop - kde desktop - other wm/desktops - legagy X11 apps - TeX - parallel/distributed processing etc... And then you "just" need some tools to build a repository or an iso from a bunch of such lists. Fedora could easily promote a particular configuration of lists as a "release" and create isos for that one, or even give a number of choices (gnome desktop, kde desktop, server...). That would help remove the second class citizen stain that is currently plagueing extras. I suspect one big problem would be merging the mirroring for core and extras into something common, but larger. OG. From fedora-devel at tlarson.com Mon Nov 13 16:29:16 2006 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 13 Nov 2006 09:29:16 -0700 Subject: EPOLLRDHUP Message-ID: <45589D5C.2040906@tlarson.com> The man page for epoll_ctl lists an event flag, EPOLLRDHUP, functionally analogous to POLLRDHUP, used to detect a peer shutdown. However, does not define that symbol. (FC 6, BTW) The question is, which one's right? Is the symbol simply missing from epoll.h, but all other aspects of the implementation are in place? Or is epoll.h correct, and the man page incorrectly states that the flag should exist? Phrased differently, should a bug be filed against glibc-headers or man-pages? From sundaram at fedoraproject.org Mon Nov 13 16:30:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Nov 2006 22:00:55 +0530 Subject: I think, rsh is quite obsolete In-Reply-To: <20061113162301.GA59973@dspnet.fr.eu.org> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> <20061113162301.GA59973@dspnet.fr.eu.org> Message-ID: <45589DBF.5090209@fedoraproject.org> Olivier Galibert wrote: > > What is the current target of Core? Right now it looks like there is > a push to limit it to the needs of the "home desktop/laptop, > gnome-desktop only, office tools, no cli" crowd. The windows desktop > crowd, in other words. Everybody else has to go hit extras. Is that > by design, or does it just happen? See http://fedoraproject.org/wiki/Extras/CoreVsExtras for the original idea. > Maybe the core/extras distinction should go away, to be replaced by a > "make your own core" system. I have the starts of one, but it would > require a lot of work still. There could be lists of packages for for > instance: > - base > - gnome desktop > - kde desktop > - other wm/desktops > - legagy X11 apps > - TeX > - parallel/distributed processing > etc... > > And then you "just" need some tools to build a repository or an iso > from a bunch of such lists. Fedora could easily promote a particular > configuration of lists as a "release" and create isos for that one, or The distribution composing tool that is designed to do this is pungi http://jkeating.livejournal.com/32250.html > even give a number of choices (gnome desktop, kde desktop, server...). > That would help remove the second class citizen stain that is > currently plagueing extras. > > I suspect one big problem would be merging the mirroring for core and > extras into something common, but larger. See http://fedoraproject.org/wiki/FedoraSummit for the current plans. Rahul From chasd at silveroaks.com Mon Nov 13 16:55:41 2006 From: chasd at silveroaks.com (chasd) Date: Mon, 13 Nov 2006 10:55:41 -0600 Subject: db4 is now updated to 4.5.20 and compat-db to 4.3.29 In-Reply-To: <20061111043032.0F5BD733D6@hormel.redhat.com> References: <20061111043032.0F5BD733D6@hormel.redhat.com> Message-ID: <0D9B1433-E646-471D-987B-09C8A5A8B83D@silveroaks.com> > db4 is now updated to 4.5.20, so please if you are a maintainer of a > package listed below, which is dependent on it, consider rebuilding > ASAP > so that I don't break rawhide for too long ;-) > > If your package is for some *IMPORTANT* reason incompatible with > db4.5, > you can switch BuildRequires to compat-db, which now contains former > rawhide db4-3.29 including header files in %{_includedir}/db4.3.29 so > you might want to update your include paths as well. compat-db-4.3.29 > contains also db-4.2.52 libraries, db-4.1.25 was removed. > p: libdb-4.3.so <- > netatalk-2.0.3-7.fc6 [development] From the Netatalk home- > Netatalk makes use of sleepycats' Berkeley DB. At the time of > writing, the following versions are supported: > > 4.1.25 > 4.2.52 (recommended) At least one user is reporting .AppleDB corruption on FC6 in upstream mail lists. I personally have seen .AppleDB corruption when building netatalk against db4 packages older than 4.1.25. I will soon be migrating one of our more heavily used file servers that runs netatalk to FC6. I would recommend building development netatalk packages against db-4.2.52 to minimize end user .AppleDB corruption. Upstream moves slowly, so getting a fix there to be compatible with new db4 is not likely soon. Charles Dostale From ajackson at redhat.com Mon Nov 13 17:32:25 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 13 Nov 2006 12:32:25 -0500 Subject: X in FC7 In-Reply-To: <1163434072.5123.6.camel@fresnel.dumbhippo.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <1163434072.5123.6.camel@fresnel.dumbhippo.com> Message-ID: <4558AC29.9030107@redhat.com> Owen Taylor wrote: > On Mon, 2006-11-13 at 08:17 -0500, Adam Jackson wrote: >> Jesse Barnes wrote: >> >>> Well, I created an account but can't seem to edit the page. Anyway, I >>> like the idea of getting rid of xfs, it seems fairly useless. And to >>> quote mharris from awhile back: >>> >>>> Long term, what would be really nice, is if someone figured >>>> out a way to implement core fonts using fontconfig/Xft >>>> underneath so we have one font system, and it provides >>>> legacy compatibility to ancient applications that have not >>>> been updated to modern interfaces. That is something that >>>> would need to be spearheaded at the X.Org level rather than >>>> at a specific distribution however. >> So here's where I start to admit some font ignorance, but. I took a >> hack at this a while back, and it seemed to me like using fontconfig for >> matching was the wrong idea, since the properties available from >> fontconfig didn't quite match what you can select on with XLFD. >> >> As said on the wiki page, what problem is xfs trying to solve? If it's >> just about the ability to add fonts at runtime without having to do >> 'xset fp rehash', then that should be a very small amount of code to add >> to the X server. You need to watch for directories popping in and out >> of existance, but, okay, we know how to do that. > > There's basically one reason why we switched to xfs years ago ... > performance with large fonts; if you don't use xfs, then trying to > load a large core font (for CHJK) can block all requests to the server > for several seconds. Well, it could on machines of that day. > > Since core fonts are really fringe at this point, the main concern with > a switch back to using in-server fonts would be configuration ... do you > really want to change complicated %post scripts for a bunch of packages > to do something new and different? Would you even have to though? It looks like %post for the core subpackages of xorg-x11-fonts is just doing chkfontpath/mkfontscale/mkfontdir for the core stuff, and then fc-cache for fontconfig visibility. Okay, fine, you might have added a directory, great. The server (in the new world order) would just check directory mtimes at font open time and automatically rehash and so forth, so you're doing _more_ work than you need to at install time. Right? In which case, "fixing" font packages is a matter of requiring a sufficiently new server and deleting %post. I am totally okay with fix by deletion. - ajax From jspaleta at gmail.com Mon Nov 13 17:39:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Nov 2006 08:39:08 -0900 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061113162259.GT4324@petra.dvoda.cz> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20061113162259.GT4324@petra.dvoda.cz> Message-ID: <604aa7910611130939p2c73901o75ef43471ecfb79@mail.gmail.com> On 11/13/06, Karel Zak wrote: > It's means almost all things in /etc/readahead.d/default.* could be > obsolete after an update (except stable things like /bin/*). I agree... which is why i think its important to have this discussion in the list.. instead of just in the bugzilla report. The rpm query is a neat trick. If you want to pump up a few throwaway readahead packages to test new ideas to solve this issue, I'll be happy to offer my system up for inadvertent destruction testing them. -jef From jnovy at redhat.com Mon Nov 13 18:27:28 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 13 Nov 2006 19:27:28 +0100 Subject: db4 is now updated to 4.5.20 and compat-db to 4.3.29 In-Reply-To: <0D9B1433-E646-471D-987B-09C8A5A8B83D@silveroaks.com> References: <20061111043032.0F5BD733D6@hormel.redhat.com> <0D9B1433-E646-471D-987B-09C8A5A8B83D@silveroaks.com> Message-ID: <1163442448.29837.27.camel@redhat.usu> On Mon, 2006-11-13 at 10:55 -0600, chasd wrote: > > db4 is now updated to 4.5.20, so please if you are a maintainer of a > > package listed below, which is dependent on it, consider rebuilding > > ASAP > > so that I don't break rawhide for too long ;-) > > > > If your package is for some *IMPORTANT* reason incompatible with > > db4.5, > > you can switch BuildRequires to compat-db, which now contains former > > rawhide db4-3.29 including header files in %{_includedir}/db4.3.29 so > > you might want to update your include paths as well. compat-db-4.3.29 > > contains also db-4.2.52 libraries, db-4.1.25 was removed. > > > > > p: libdb-4.3.so <- > > netatalk-2.0.3-7.fc6 [development] > > From the Netatalk home- > > > Netatalk makes use of sleepycats' Berkeley DB. At the time of > > writing, the following versions are supported: > > > > 4.1.25 > > 4.2.52 (recommended) > installation.html#id2837734> > > At least one user is reporting .AppleDB corruption on FC6 in upstream > mail lists. > I personally have seen .AppleDB corruption when building netatalk > against db4 packages older than 4.1.25. > I will soon be migrating one of our more heavily used file servers > that runs netatalk to FC6. > > I would recommend building development netatalk packages against > db-4.2.52 to minimize end user .AppleDB corruption. > > Upstream moves slowly, so getting a fix there to be compatible with > new db4 is not likely soon. Charles, this is the case where you can rebuild your package against compat-db as it contains headers/libs for db4-2.52. But please don't rebuild it now as the new db4 is not yet in buildroots. Tomas needs some time to update pam's internal db4 first. If you are interested you can test these packages in the meantime: http://people.redhat.com/jnovy/files/compat-db-4.3.29-1.fc7.src.rpm http://people.redhat.com/jnovy/files/db4-4.5.20-1.fc7.src.rpm together with this version of pam with the conflict removed: http://people.redhat.com/jnovy/files/pam-0.99.6.2-3.noconf.fc7.src.rpm Jindrich From dragoran at feuerpokemon.de Mon Nov 13 18:42:38 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 13 Nov 2006 19:42:38 +0100 Subject: GPL2 Java? Message-ID: <4558BC9E.4060809@feuerpokemon.de> Sun is going to release java under the gpl2 license see: http://blogs.sun.com/dannycoward/entry/java_me,_se_and_ee how would this affect fedora? Will this be included and replace the gcj stuff? Can both be installed in parrallel? (using alternatives it should work like it does now) which would mean one of them have to go to extras... From wtogami at redhat.com Mon Nov 13 19:11:34 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 13 Nov 2006 14:11:34 -0500 Subject: GPL2 Java? In-Reply-To: <4558BC9E.4060809@feuerpokemon.de> References: <4558BC9E.4060809@feuerpokemon.de> Message-ID: <4558C366.4080907@redhat.com> dragoran wrote: > Sun is going to release java under the gpl2 license see: > http://blogs.sun.com/dannycoward/entry/java_me,_se_and_ee > how would this affect fedora? Will this be included and replace the gcj > stuff? > Can both be installed in parrallel? (using alternatives it should work > like it does now) > which would mean one of them have to go to extras... > Keep in mind that bits don't land until March 2007. Warren From florin at andrei.myip.org Mon Nov 13 19:38:24 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 13 Nov 2006 11:38:24 -0800 Subject: I think, rsh is quite obsolete In-Reply-To: <20061109024213.GE673446@hiwaay.net> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> Message-ID: <4558C9B0.9000203@andrei.myip.org> Chris Adams wrote: > Telnet and rsh can be used over networks that are secured in other ways. Exactly. I use telnet over OpenVPN tunnels (strictly between the ends of the tunnels, not beyond) and it's much faster than ssh, since telnet can be compressed by OpenVPN while ssh, being "randomized" (encrypted) already, does not compress too well, if at all. Also, we have a protected environment where encryption gives us no security advantage, while plain text protocols are much faster than ssh. With ssh we get transfer times that are unacceptable, while plain text transfers will hit the bandwidth ceiling and complete pretty quickly. Leave the cleartext protocols alone, they're good tools if you know what you are doing. -- Florin Andrei http://florin.myip.org/ From jspaleta at gmail.com Mon Nov 13 20:03:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Nov 2006 11:03:18 -0900 Subject: I think, rsh is quite obsolete In-Reply-To: <45588412.40608@odu.neva.ru> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> <45588412.40608@odu.neva.ru> Message-ID: <604aa7910611131203l48def8b8s94b2d55e1cf8aadc@mail.gmail.com> On 11/13/06, Dmitry Butskoy wrote: > Sometime in the future -- yes. But not now. What specifically would need to happen between then and now to make moving this to Extras a viable option. -jef"Difficult to see. Always in motion is future."spaleta From otto_rey at yahoo.com.ar Mon Nov 13 19:36:57 2006 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Mon, 13 Nov 2006 11:36:57 -0800 (PST) Subject: GPL2 Java? Message-ID: <20061113193657.28980.qmail@web52413.mail.yahoo.com> +1 Include Sun JDK in Fedora +1 Move Gcj to Extras ----- Original Message ---- From: Warren Togami To: Development discussions related to Fedora Core Sent: Monday, November 13, 2006 4:11:34 PM Subject: Re: GPL2 Java? dragoran wrote: > Sun is going to release java under the gpl2 license see: > http://blogs.sun.com/dannycoward/entry/java_me,_se_and_ee > how would this affect fedora? Will this be included and replace the gcj > stuff? > Can both be installed in parrallel? (using alternatives it should work > like it does now) > which would mean one of them have to go to extras... > Keep in mind that bits don't land until March 2007. Warren -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Mon Nov 13 20:13:31 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Nov 2006 11:13:31 -0900 Subject: GPL2 Java? In-Reply-To: <20061113193657.28980.qmail@web52413.mail.yahoo.com> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> Message-ID: <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> On 11/13/06, Otto Rey wrote: > > +1 Include Sun JDK in Fedora > +1 Move Gcj to Extras > > > From: Warren Togami > Keep in mind that bits don't land until March 2007. Keep in mind that any such actions will have to be in a post fc7 timeframe if Warren's statement is correct and the re-licensed code isn't publically available until March 2007. A detailed discussion as to what to do is a bit premature until we have the re-licensed code in hand. I really think it would be a bad idea to rely on a promise to re-license, to make technical decisions which could impact the fc7 release. Its enough to know everyone is aware about it and the timescales involved. Work on gcj can't stop if Sun's relicensed release isn't available soon enough for the fc7 testing timeframe. -jef"Dates slip...even if Sun is serious this time about open sourcing java...you can't count on them holding to a specific date of availability this far out in the process"spaleta From cmadams at hiwaay.net Mon Nov 13 20:22:48 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 13 Nov 2006 14:22:48 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <45588412.40608@odu.neva.ru> References: <1162983051.4459.6.camel@numenor> <20061109092658.GC4324@petra.dvoda.cz> <604aa7910611110145o2c934f69j79916ca95fc05dcb@mail.gmail.com> <45588412.40608@odu.neva.ru> Message-ID: <20061113202248.GE962784@hiwaay.net> Once upon a time, Dmitry Butskoy said: > And, actually, all such stuff takes just several megabytes of code. I am > sure it even less than the total size of "gnome-games" included into > Core... (You guess, I'm a "production envrionment" man :) ) Not even megabytes: telnet (client and server) SRPM: 119K rsh (client and server) SRPM: 279K telnet-server RPM: 36K telnet-client RPM: 58K rsh-server RPM: 40K rsh-client RPM: 44K total: 575K -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From j.w.r.degoede at hhs.nl Mon Nov 13 20:44:12 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 13 Nov 2006 21:44:12 +0100 Subject: GPL2 Java? In-Reply-To: <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> Message-ID: <4558D91C.2050308@hhs.nl> Jeff Spaleta wrote: > On 11/13/06, Otto Rey wrote: >> >> +1 Include Sun JDK in Fedora >> +1 Move Gcj to Extras >> >> >> From: Warren Togami >> Keep in mind that bits don't land until March 2007. > > Keep in mind that any such actions will have to be in a post fc7 > timeframe if Warren's statement is correct and the re-licensed code > isn't publically available until March 2007. A detailed discussion as > to what to do is a bit premature until we have the re-licensed code in > hand. I really think it would be a bad idea to rely on a promise to > re-license, to make technical decisions which could impact the fc7 > release. Its enough to know everyone is aware about it and the > timescales involved. Work on gcj can't stop if Sun's relicensed > release isn't available soon enough for the fc7 testing timeframe. > > -jef"Dates slip...even if Sun is serious this time about open sourcing > java...you can't count on them holding to a specific date of > availability this far out in the process"spaleta > Agreed, what is however very interesting is one of the parts released under the GPL NOW, the hotspot vm, which according to SUN's FAQ: "Q: What is the Java HotSpot virtual machine? What can developers do with this component? A: Java HotSpot is Sun's implementation of the Java virtual machine. The Java HotSpot VM includes the core execution engine for the Java platform, including: * dynamic compilers that convert Java bytecodes into optimized native machine code on supported hardware platforms * memory management and garbage collection subsystems * threads and synchronization * monitoring, debugging, and profiling telemetry * parts of the Java security architecture including the bytecode verifier" I'm especially hoping that the "parts of the Java security architecture including the bytecode verifier" will help us get a gcj-web-plugin for FC-7. Regards, Hans From thuforuk at yahoo.co.uk Mon Nov 13 20:32:40 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Mon, 13 Nov 2006 20:32:40 +0000 Subject: GPL2 Java? In-Reply-To: <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> Message-ID: <4558D668.7010701@yahoo.co.uk> On 11/13/2006 08:13 PM, Jeff Spaleta wrote: > On 11/13/06, Otto Rey wrote: >> >> +1 Include Sun JDK in Fedora >> +1 Move Gcj to Extras >> >> >> From: Warren Togami >> Keep in mind that bits don't land until March 2007. > > Keep in mind that any such actions will have to be in a post fc7 > timeframe if Warren's statement is correct and the re-licensed code > isn't publically available until March 2007. A detailed discussion as > to what to do is a bit premature until we have the re-licensed code in > hand. I really think it would be a bad idea to rely on a promise to > re-license, to make technical decisions which could impact the fc7 > release. Its enough to know everyone is aware about it and the > timescales involved. Work on gcj can't stop if Sun's relicensed > release isn't available soon enough for the fc7 testing timeframe. > > -jef"Dates slip...even if Sun is serious this time about open sourcing > java...you can't count on them holding to a specific date of > availability this far out in the process"spaleta I'm glad to dissapoint you -- seems that compiler and HotSpot VM are already in Subversion at https://openjdk.dev.java.net/source/browse/openjdk/ (Note: I haven't actually tried to check it out/compile, just browsed the repo... so I might be wrong assuming it's all you need to build these two ;-) Regards, Dariusz Send instant messages to your online friends http://uk.messenger.yahoo.com From vonbrand at inf.utfsm.cl Mon Nov 13 20:36:05 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 13 Nov 2006 17:36:05 -0300 Subject: GPL2 Java? In-Reply-To: Message from "Jeff Spaleta" of "Mon, 13 Nov 2006 11:13:31 -0900." <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> Message-ID: <200611132036.kADKa5Bn015399@laptop13.inf.utfsm.cl> Jeff Spaleta wrote: > On 11/13/06, Otto Rey wrote: > > > > +1 Include Sun JDK in Fedora > > +1 Move Gcj to Extras > > > > > > From: Warren Togami > > Keep in mind that bits don't land until March 2007. > Keep in mind that any such actions will have to be in a post fc7 > timeframe if Warren's statement is correct and the re-licensed code > isn't publically available until March 2007. A detailed discussion as > to what to do is a bit premature until we have the re-licensed code in > hand. I really think it would be a bad idea to rely on a promise to > re-license, to make technical decisions which could impact the fc7 > release. Its enough to know everyone is aware about it and the > timescales involved. Work on gcj can't stop if Sun's relicensed > release isn't available soon enough for the fc7 testing timeframe. Besides, at least to me it isn't clear (yet?) they are GPLing everything you'd need to /use/ Java in anger... Also, gcj is a native compiler too, it could very well be that filling in the rough spots from Sun's Java is the way to go in the end. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jspaleta at gmail.com Mon Nov 13 20:37:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Nov 2006 11:37:23 -0900 Subject: GPL2 Java? In-Reply-To: <4558D91C.2050308@hhs.nl> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> <4558D91C.2050308@hhs.nl> Message-ID: <604aa7910611131237t5f3ebeads58d26708a9db805b@mail.gmail.com> On 11/13/06, Hans de Goede wrote: > I'm especially hoping that the "parts of the Java security architecture > including the bytecode verifier" will help us get a gcj-web-plugin for > FC-7. Can we roll individual pieces of the stack in fe6 as they become available? It would make it much easier to make technical assessments as we move towards fc7 test releases if we know what pieces are available and already have them packaged in extras for fe6. -jef From dragoran at feuerpokemon.de Mon Nov 13 20:39:52 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 13 Nov 2006 21:39:52 +0100 Subject: GPL2 Java? In-Reply-To: <4558D668.7010701@yahoo.co.uk> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> <4558D668.7010701@yahoo.co.uk> Message-ID: <4558D818.1070703@feuerpokemon.de> Dariusz J. Garbowski wrote: > > I'm glad to dissapoint you -- seems that compiler and HotSpot VM are > already in Subversion at > https://openjdk.dev.java.net/source/browse/openjdk/ > > (Note: I haven't actually tried to check it out/compile, just browsed > the repo... so I might be wrong assuming it's all you need to build > these two ;-) > the compile should be working see http://community.java.net/openjdk/ (but I have not tested it yet too) From green at redhat.com Mon Nov 13 20:42:15 2006 From: green at redhat.com (Anthony Green) Date: Mon, 13 Nov 2006 12:42:15 -0800 Subject: GPL2 Java? In-Reply-To: <4558C366.4080907@redhat.com> References: <4558BC9E.4060809@feuerpokemon.de> <4558C366.4080907@redhat.com> Message-ID: <1163450535.3152.101.camel@localhost.localdomain> On Mon, 2006-11-13 at 14:11 -0500, Warren Togami wrote: > dragoran wrote: > > Sun is going to release java under the gpl2 license see: > > http://blogs.sun.com/dannycoward/entry/java_me,_se_and_ee > > how would this affect fedora? Will this be included and replace the gcj > > stuff? > > Can both be installed in parrallel? (using alternatives it should work > > like it does now) > > which would mean one of them have to go to extras... > > > > Keep in mind that bits don't land until March 2007. And there's no PowerPC port. I think it's more realistic to push OpenJDK through the Extras process in that time frame (assuming the Core/Extras distinction continues). AG From dragoran at feuerpokemon.de Mon Nov 13 20:52:56 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 13 Nov 2006 21:52:56 +0100 Subject: GPL2 Java? In-Reply-To: <4558D818.1070703@feuerpokemon.de> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <604aa7910611131213y6cbbc47emde1d33bbf2ad35b3@mail.gmail.com> <4558D668.7010701@yahoo.co.uk> <4558D818.1070703@feuerpokemon.de> Message-ID: <4558DB28.7090607@feuerpokemon.de> dragoran wrote: > Dariusz J. Garbowski wrote: >> >> I'm glad to dissapoint you -- seems that compiler and HotSpot VM are >> already in Subversion at >> https://openjdk.dev.java.net/source/browse/openjdk/ >> >> (Note: I haven't actually tried to check it out/compile, just browsed >> the repo... so I might be wrong assuming it's all you need to build >> these two ;-) >> > the compile should be working s/compile/compiler/ > see http://community.java.net/openjdk/ > (but I have not tested it yet too) From steve at silug.org Mon Nov 13 21:01:50 2006 From: steve at silug.org (Steven Pritchard) Date: Mon, 13 Nov 2006 15:01:50 -0600 Subject: I think, rsh is quite obsolete In-Reply-To: <4558C9B0.9000203@andrei.myip.org> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> Message-ID: <20061113210150.GA4681@osiris.silug.org> On Mon, Nov 13, 2006 at 11:38:24AM -0800, Florin Andrei wrote: > Leave the cleartext protocols alone, they're good tools if you know what > you are doing. I don't think anyone would argue that about telnet (well, other than it not being 8-bit clean), but have you ever really looked at rsh? It's just *evil*. Authentication is implemented entirely client-side. It won't work with firewalls. It has to be setuid root. It needs to be available no matter how evil it is, but it certainly doesn't need to be in Core. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From marcel at mesa.nl Mon Nov 13 21:24:45 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Mon, 13 Nov 2006 22:24:45 +0100 Subject: AT_SPI_REGISTRY In-Reply-To: <1163434380.3113.20.camel@blaa> References: <20061110234829.GB21277@joshua.mesa.nl> <1163204470.3033.8.camel@blaa> <20061111003550.GC21277@joshua.mesa.nl> <1163434380.3113.20.camel@blaa> Message-ID: <20061113212445.GD6499@joshua.mesa.nl> On Mon, Nov 13, 2006 at 11:13:00AM -0500, Mark McLoughlin wrote: > On Sat, 2006-11-11 at 01:35 +0100, Marcel J.E. Mol wrote: > > On Fri, Nov 10, 2006 at 07:21:10PM -0500, Mark McLoughlin wrote: > > > On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > > > > > I'm running kde if that matters. > > > > > > That's probably the problem ... we've just updated to gnome-session > > > 2.17.2 which includes this: > > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=345428 > > > > > > Basically, gnome-session starts at-registryd now ... > > > > > > > Right. So this needs a bit tweaking in some scripts... > > > > % /usr/libexec/at-spi-registryd > > Xlib: extension "XEVIE" missing on display ":0.0". > > > > > > Suspended > > % bg > > [3] /usr/libexec/at-spi-registryd & > > % gnumeric > > Bonobo accessibility support initialized > > GTK Accessibility Module initialized > > > > And gnumeric is happily running. > > You should log a Fedora/gnome-session bug on this, FWIW I thought you mentioning this in the obove gnome bugzilla would be enough. I just installed Fedore dev with mostly defaults but start the system in runlevel 3. I start X manually using startkde i my .Xclients file. I did not run gnome on this system yet, so never (manually) selected assistive technology as Bill Haneman suggested. I actually just saw the bugzilla was not the fedora bugzilla system. I'll file bug in fedora later on if that helps. -Marcel From giallu at gmail.com Mon Nov 13 22:05:51 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 13 Nov 2006 23:05:51 +0100 Subject: .fc6 kernel packages in developement Message-ID: I just noticed the development repo was updated with a new kernel (2.6.18-1.2849) but the pakcages have the .fc6 dist tag: this prevents me from building sysprof-kmod for development since the "make tag" fails because the tag is already used on the FC-6 branch. I there a reason for this .fc6 packages in devel? From kzak at redhat.com Mon Nov 13 23:25:19 2006 From: kzak at redhat.com (Karel Zak) Date: Tue, 14 Nov 2006 00:25:19 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <20061113210150.GA4681@osiris.silug.org> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> Message-ID: <20061113232519.GA12487@petra.dvoda.cz> On Mon, Nov 13, 2006 at 03:01:50PM -0600, Steven Pritchard wrote: > On Mon, Nov 13, 2006 at 11:38:24AM -0800, Florin Andrei wrote: > > Leave the cleartext protocols alone, they're good tools if you know what > > you are doing. > > I don't think anyone would argue that about telnet (well, other than > it not being 8-bit clean), but have you ever really looked at rsh? > It's just *evil*. Authentication is implemented entirely client-side. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do you mean PAM code on server-side, right? :-) Karel -- Karel Zak From jkeating at redhat.com Mon Nov 13 23:38:24 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 13 Nov 2006 18:38:24 -0500 Subject: .fc6 kernel packages in developement In-Reply-To: References: Message-ID: <200611131838.26806.jkeating@redhat.com> On Monday 13 November 2006 17:05, Gianluca Sforna wrote: > I there a reason for this .fc6 packages in devel? They're inherited from dist-fc6-updates. No kernel package has been built specifically for rawhide yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From khc at pm.waw.pl Mon Nov 13 23:40:10 2006 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 14 Nov 2006 00:40:10 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <20061113210150.GA4681@osiris.silug.org> (Steven Pritchard's message of "Mon, 13 Nov 2006 15:01:50 -0600") References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> Message-ID: Steven Pritchard writes: > I don't think anyone would argue that about telnet (well, other than > it not being 8-bit clean), but have you ever really looked at rsh? > It's just *evil*. Authentication is implemented entirely client-side. Just as with NFS for example. Is NFS evil too? > It won't work with firewalls. Of course it does. It can't work with dynamic NATs as it uses IP (and reserved TCP port) for access check but rsh is just a simple TCP connection to a well-known port. > It has to be setuid root. Sure, reserved TCP port. Still, there is no replacement. -- Krzysztof Halasa From davem at iabyn.com Tue Nov 14 00:56:30 2006 From: davem at iabyn.com (Dave Mitchell) Date: Tue, 14 Nov 2006 00:56:30 +0000 Subject: I think, rsh is quite obsolete In-Reply-To: References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> Message-ID: <20061114005630.GA768@iabyn.com> On Tue, Nov 14, 2006 at 12:40:10AM +0100, Krzysztof Halasa wrote: > Just as with NFS for example. Is NFS evil too? Basic NFS is pretty evil. Totally insecure. > > It won't work with firewalls. > > Of course it does. It can't work with dynamic NATs as it uses IP > (and reserved TCP port) for access check but rsh is just a simple > TCP connection to a well-known port. The rsh protocol requires the server to make a second TCP connection back to a low-numbered ephemeral port specified by the client, for the stderr channel. If you haven't got a stateful, inspecting firewall, you're hosed. -- The crew of the Enterprise encounter an alien life form which is suprisingly neither humanoid nor made from pure energy. -- Things That Never Happen in "Star Trek" #22 From janina at rednote.net Tue Nov 14 02:00:34 2006 From: janina at rednote.net (Janina Sajka) Date: Mon, 13 Nov 2006 21:00:34 -0500 Subject: AT_SPI_REGISTRY In-Reply-To: <20061110234829.GB21277@joshua.mesa.nl> References: <20061110234829.GB21277@joshua.mesa.nl> Message-ID: <20061114020034.GO30057@rednote.net> I'm not sure, but it seems to me that gnumeric shouldn't be looking for at-spi if accessibility isn't enabled. You could turn it on and restart X just to see if that clears things up. PS: If the meaning of this is that gnumeric is finally building in a11y support, that certainly makes me glad. But then I could be way off base on all of this. Janina Marcel J.E. Mol writes: > After installing rawhide(-extras) x86-64 on my laptop I get the following > when starting gnumeric: > > > % gnumeric > > Bonobo accessibility support initialized > GTK Accessibility Module initialized > > ** (gnumeric:17572): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. > > ** (gnumeric:17572): WARNING **: IOR not set. > > ** ERROR **: Could not locate registry > aborting... > Bonobo accessibility support initialized > GTK Accessibility Module initialized > > ** (gnome_segv2:17573): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. > > ** (gnome_segv2:17573): WARNING **: IOR not set. > > ** ERROR **: Could not locate registry > aborting... > Bonobo accessibility support initialized > GTK Accessibility Module initialized > > ** (gnome_segv2:17574): CRITICAL **: AT_SPI_REGISTRY was not started at session startup. > > ** (gnome_segv2:17574): WARNING **: IOR not set. > > ** ERROR **: Could not locate registry > aborting... > > and around another 100 more of these, ending with > > Xlib: connection to ":0.0" refused by server > Xlib: Maximum number of clients reached > > (gnome_segv2:17682): Gtk-WARNING **: cannot open display: > > And no gnumeric starting up. > Something similar happens when running the 32-bit firefox (to be able to > see some flash sites). 64-bit firefox strarts up fine. > Scanning google or lists did not give any clues... > > I'm running kde if that matters. > > Any idea? > > -Marcel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From janina at rednote.net Tue Nov 14 02:03:58 2006 From: janina at rednote.net (Janina Sajka) Date: Mon, 13 Nov 2006 21:03:58 -0500 Subject: Firefox 3 Message-ID: <20061114020358.GP30057@rednote.net> Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere near ready for prime time, but I have a compelling reason to start using ff3 fairly soon and would rather install from rpm, of course. BTW: My compelling reason is that FF3 will contain a11y support that should prove superior to any yet seen on any platform. Fingers crossed, etc ... Janina -- Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From notting at redhat.com Tue Nov 14 03:23:24 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Nov 2006 22:23:24 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163412461.15249.125.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> Message-ID: <20061114032324.GA26706@nostromo.devel.redhat.com> Arjan van de Ven (arjan at fenrus.demon.nl) said: > I really like this idea; it's a simple "cat" and it can be done at a > time where latency doesn't matter... (even in cron.daily) > > Oh... this opens more options. This also allows the "sort by > blocknumber" to be done at this point and taken out of the critical > latency part...... > > great idea! Of course, that then makes shutdown take twice as long. What do you do if you have a box where readahead makes boot slower? Bill From mattdm at mattdm.org Tue Nov 14 03:29:08 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Nov 2006 22:29:08 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061114032324.GA26706@nostromo.devel.redhat.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> Message-ID: <20061114032908.GA29126@jadzia.bu.edu> On Mon, Nov 13, 2006 at 10:23:24PM -0500, Bill Nottingham wrote: > What do you do if you have a box where readahead makes boot slower? rpm -e readahead? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Nov 14 03:33:14 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Nov 2006 22:33:14 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061114032908.GA29126@jadzia.bu.edu> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <20061114032908.GA29126@jadzia.bu.edu> Message-ID: <20061114033314.GA26878@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Mon, Nov 13, 2006 at 10:23:24PM -0500, Bill Nottingham wrote: > > What do you do if you have a box where readahead makes boot slower? > > rpm -e readahead? You can, but it does seem odd to install something tha makes the system less efficient. I should do more testing on laptops; I know at least on some it slows things down. Bill From jreiser at BitWagon.com Tue Nov 14 03:43:31 2006 From: jreiser at BitWagon.com (John Reiser) Date: Mon, 13 Nov 2006 19:43:31 -0800 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061114032324.GA26706@nostromo.devel.redhat.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> Message-ID: <45593B63.9090505@BitWagon.com> > Of course, that then makes shutdown take twice as long. In most cases (no changes to the files since last shutdown), then a 'make' can shorten the latency to just a 'stat()' of each file. The whole computation can run in parallel with all other activities during shutdown, until just before the unmounts. > What do you do if you have a box where readahead makes boot slower? Delete enough items from the list of filenames to be processed. -- From mattdm at mattdm.org Tue Nov 14 03:46:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Nov 2006 22:46:07 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061114033314.GA26878@nostromo.devel.redhat.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <20061114032908.GA29126@jadzia.bu.edu> <20061114033314.GA26878@nostromo.devel.redhat.com> Message-ID: <20061114034607.GA29864@jadzia.bu.edu> On Mon, Nov 13, 2006 at 10:33:14PM -0500, Bill Nottingham wrote: > > > What do you do if you have a box where readahead makes boot slower? > > rpm -e readahead? > You can, but it does seem odd to install something tha makes the > system less efficient. I should do more testing on laptops; I know > at least on some it slows things down. Okay, I admit I actually take the more drastic solution of removing it from comps.xml. I don't remember the numbers, but it was definitely making my FC4 laptop boot more slowly. I haven't given it another chance.... And on non-laptop systems that don't reboot often, it's basically pointless anyway. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwmw2 at infradead.org Tue Nov 14 04:01:47 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 14 Nov 2006 12:01:47 +0800 Subject: GPL2 Java? In-Reply-To: <20061113193657.28980.qmail@web52413.mail.yahoo.com> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> Message-ID: <1163476907.3396.9.camel@shinybook.infradead.org> On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: > +1 Include Sun JDK in Fedora Does Sun JDK build for PowerPC? -- dwmw2 From arjan at fenrus.demon.nl Tue Nov 14 07:15:26 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 14 Nov 2006 08:15:26 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20061114032324.GA26706@nostromo.devel.redhat.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> Message-ID: <1163488526.15249.230.camel@laptopd505.fenrus.org> On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote: > Arjan van de Ven (arjan at fenrus.demon.nl) said: > > I really like this idea; it's a simple "cat" and it can be done at a > > time where latency doesn't matter... (even in cron.daily) > > > > Oh... this opens more options. This also allows the "sort by > > blocknumber" to be done at this point and taken out of the critical > > latency part...... > > > > great idea! > > Of course, that then makes shutdown take twice as long. if you do it at shutdown, which is again a latency path :) cron.daily/weekly is less so ;) From thuforuk at yahoo.co.uk Tue Nov 14 07:35:15 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Tue, 14 Nov 2006 07:35:15 +0000 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163488526.15249.230.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> Message-ID: <455971B3.7080609@yahoo.co.uk> On 11/14/2006 07:15 AM, Arjan van de Ven wrote: > On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote: >> Arjan van de Ven (arjan at fenrus.demon.nl) said: >>> I really like this idea; it's a simple "cat" and it can be done at a >>> time where latency doesn't matter... (even in cron.daily) >>> >>> Oh... this opens more options. This also allows the "sort by >>> blocknumber" to be done at this point and taken out of the critical >>> latency part...... >>> >>> great idea! >> Of course, that then makes shutdown take twice as long. > > if you do it at shutdown, which is again a latency path :) > cron.daily/weekly is less so ;) +1 for cron -1 for shutdown -> what about boxens, which are shutdown only on kernel updates? (like mine) Regards, Dariusz Send instant messages to your online friends http://uk.messenger.yahoo.com From dwmw2 at infradead.org Tue Nov 14 09:12:58 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 14 Nov 2006 17:12:58 +0800 Subject: I think, rsh is quite obsolete In-Reply-To: <20061114005630.GA768@iabyn.com> References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> <20061114005630.GA768@iabyn.com> Message-ID: <1163495578.3396.39.camel@shinybook.infradead.org> On Tue, 2006-11-14 at 00:56 +0000, Dave Mitchell wrote: > > Of course it does. It can't work with dynamic NATs as it uses IP > > (and reserved TCP port) for access check but rsh is just a simple > > TCP connection to a well-known port. > > The rsh protocol requires the server to make a second TCP connection back > to a low-numbered ephemeral port specified by the client, for the stderr > channel. If you haven't got a stateful, inspecting firewall, you're hosed. Why do you say such a thing? I don't have a stateful, inspecting firewall -- but rsh seems to work fine. In fact, I don't have a firewall at all -- firewalls just break things. In general, firewalls are a band-aid to patch over broken software; a poor substitute for proper security. -- dwmw2 From sundaram at fedoraproject.org Tue Nov 14 10:50:31 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Nov 2006 16:20:31 +0530 Subject: GPL2 Java? In-Reply-To: <1163476907.3396.9.camel@shinybook.infradead.org> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> Message-ID: <45599F77.6080805@fedoraproject.org> David Woodhouse wrote: > On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: >> +1 Include Sun JDK in Fedora > > Does Sun JDK build for PowerPC? Nope but its potentially possible now. Rahul From buildsys at redhat.com Tue Nov 14 10:54:37 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 14 Nov 2006 05:54:37 -0500 Subject: rawhide report: 20061114 changes Message-ID: <200611141054.kAEAsbtr002481@hs20-bc2-6.build.redhat.com> Updated Packages: dbus-1.0.0-1.fc7 ---------------- * Mon Nov 13 2006 John (J5) Palmieir - 1.0.0-1 - update to D-Bus 1.0.0 "Blue Bird" - build with verbose mode on but tests and asserts off * Sun Nov 12 2006 Ray Strode - 0.95-3 - dont let dbus-launch session sitter crash in the non-autolaunch code path (bug 214649) * Mon Nov 06 2006 John (J5) Palmieri - 0.95-2 - Add /var/lib/dbus directory to %files dhcp-12:3.0.5-4.fc7 ------------------- * Mon Nov 13 2006 David Cantrell - 12:3.0.5-4 - Enable relinquish_timeouts() and cancel_all_timeouts() even when DEBUG_MEMORY_LEAKAGE_ON_EXIT is not defined - Add prototypes for b64_pton() and b64_ntop in dst/ - Move variable declarations and labels around in the fix-warnings patch - Expand the list of objects needed for libdhcp4client (#215328) - Use libres.a in libdhcp4client since it gives correct minires objects - Remove the dhcp options table in C, Perl, Python, and text format (these were reference files added to /usr/share/doc) * Mon Nov 13 2006 David Cantrell - 12:3.0.5-3 - Remove struct universe *universe from envadd_state in the client patch - Add struct universe *universe to envadd_state in the enoi patch - Add example dbusified dhclient-script in the enoi patch * Fri Nov 10 2006 David Cantrell - 12:3.0.5-2 - Change the way libdhcp4client is compiled (patch main source, create new Makefile rather than copy and patch code after main patches) - Fix up problems generating compiler warnings - Use 'gcc' for making dependencies - Pass -fPIC instead of -fpie/-fPIE in compiler flags - Combine the extended new option info changes in to one patch file (makes it easier for outside projects that want to use dhcdbd and NetworkManager) ed-0.3-1 -------- * Mon Nov 13 2006 Karsten Hopp 0.3-1 - update to ed-0.3 gnome-bluetooth-0.8.0-1.fc7 --------------------------- * Mon Nov 13 2006 Harald Hoyer - 0.8.0-1.fc7 - version 0.8.0 isdn4k-utils-3.2-52.fc7 ----------------------- * Mon Nov 13 2006 Than Ngo - 3.2-52.fc7 - fix #213233, require main package with %{version}-%{release} libbtctl-0.8.2-1.fc7 -------------------- * Mon Nov 13 2006 Harald Hoyer - 0.8.2-1.fc7 - version 0.8.2 - Resolves: rhbz#215230 libdhcp-1.17-2.fc7 ------------------ * Mon Nov 13 2006 David Cantrell - 1.17-2 - Rebuild libgpod-0.4.0-1.fc7 ------------------- * Mon Nov 13 2006 Matthias Clasen - 0.4.0-1 - Update to 0.4.0 - Include docs in the -devel package - Don't ship static libraries mailman-3:2.1.9-3 ----------------- * Thu Oct 05 2006 David Woodhouse - 3:2.1.9-3 - fix broken In-Reply-To: header in mailto: URL in archives (#123768) man-pages-fr-2.39-7.fc7 ----------------------- * Fri Oct 13 2006 Marcela Maslanova 2.39-7 - rebuilt nautilus-2.16.2-5.fc7 --------------------- * Mon Nov 13 2006 Alexander Larsson - 2.16.2-5.fc7 - Fix commonly reported NautilusDirectory crash * Wed Nov 08 2006 Alexander Larsson - 2.16.2-4.fc7 - Revert upstream icon placement patch as it seems broken * Tue Nov 07 2006 Alexander Larsson - 2.16.2-2.fc7 - Update to 2.16.2 pam-0.99.6.2-4.fc7 ------------------ * Mon Nov 13 2006 Tomas Mraz 0.99.6.2-4 - update internal db4 to 4.5.20 version - move setgid before setuid in pam_keyinit (#212329) - make username check in pam_unix consistent with useradd (#212153) * Tue Oct 24 2006 Tomas Mraz 0.99.6.2-3.3 - don't overflow a buffer in pam_namespace (#211989) * Mon Oct 16 2006 Tomas Mraz 0.99.6.2-3.2 - /var/log/faillog and tallylog must be %config(noreplace) python-urlgrabber-2.9.9-3 ------------------------- * Sat Nov 11 2006 Florian La Roche - add version/release to "Provides: urlgrabber" readline-5.2-1.fc7 ------------------ * Mon Nov 13 2006 Miroslav Lichvar 5.2-1 - update to 5.2 (#213795) - use CFLAGS when linking (#199374) - package docs and examples (#172497) - spec cleanup rhythmbox-0.9.6-2.fc7 --------------------- * Mon Nov 13 2006 Matthias Clasen - 0.9.6-2 - Rebuild selinux-policy-2.4.3-12 ----------------------- * Mon Nov 13 2006 Dan Walsh 2.4.3-12 - Fix for qemu, /dev/ * Mon Nov 13 2006 Dan Walsh 2.4.3-11 - Fix path to realplayer.bin sg3_utils-1.22-1.fc7 -------------------- * Mon Nov 13 2006 Phil Knirsch - 1.22-1 - Update to sg3_utils-1.22 system-config-httpd-5:1.4.1-1.fc7 --------------------------------- * Mon Nov 13 2006 Phil Knirsch 1.4.0-2.fc7 - Fixed missing buildrequires on gettext * Fri Nov 10 2006 Phil Knirsch 1.4.0-1.fc7 - Finished SSL related bugfixes finally, too - Fixed problem with s-c-h removing config and .pyc files after update * Wed Oct 25 2006 Phil Knirsch - Large update for system-config-httpd with lots of bugfixes system-config-printer-0.7.37-1.fc7 ---------------------------------- * Mon Nov 13 2006 Tim Waugh 0.7.37-1 - 0.7.37: - Allow cancellation of test pages (bug #215054). units-1.86-1 ------------ * Mon Nov 13 2006 Florian La Roche - 1.86-1 - 1.86 vim-2:7.0.162-2 --------------- * Mon Nov 13 2006 Karsten Hopp 7.0.162-2 - fix lang problem in spec file mode - use old g:packager variable when set Broken deps for i386 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.i386 requires libbtctl.so.2 Broken deps for ppc64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ppc64 requires libbtctl.so.2()(64bit) Broken deps for x86_64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.x86_64 requires libbtctl.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ppc requires libbtctl.so.2 Broken deps for ia64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ia64 requires libbtctl.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jakub at redhat.com Tue Nov 14 10:57:35 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 14 Nov 2006 05:57:35 -0500 Subject: GPL2 Java? In-Reply-To: <45599F77.6080805@fedoraproject.org> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> Message-ID: <20061114105735.GK6570@devserv.devel.redhat.com> On Tue, Nov 14, 2006 at 04:20:31PM +0530, Rahul Sundaram wrote: > David Woodhouse wrote: > >On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: > >>+1 Include Sun JDK in Fedora > > > >Does Sun JDK build for PowerPC? > > Nope but its potentially possible now. Well, only after the library bits are GPLed too. Jakub From davem at iabyn.com Tue Nov 14 11:28:55 2006 From: davem at iabyn.com (Dave Mitchell) Date: Tue, 14 Nov 2006 11:28:55 +0000 Subject: I think, rsh is quite obsolete In-Reply-To: <1163495578.3396.39.camel@shinybook.infradead.org> References: <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> <20061114005630.GA768@iabyn.com> <1163495578.3396.39.camel@shinybook.infradead.org> Message-ID: <20061114112855.GB768@iabyn.com> On Tue, Nov 14, 2006 at 05:12:58PM +0800, David Woodhouse wrote: > On Tue, 2006-11-14 at 00:56 +0000, Dave Mitchell wrote: > > > Of course it does. It can't work with dynamic NATs as it uses IP > > > (and reserved TCP port) for access check but rsh is just a simple > > > TCP connection to a well-known port. > > > > The rsh protocol requires the server to make a second TCP connection back > > to a low-numbered ephemeral port specified by the client, for the stderr > > channel. If you haven't got a stateful, inspecting firewall, you're hosed. > > Why do you say such a thing? I don't have a stateful, inspecting > firewall -- but rsh seems to work fine. > > In fact, I don't have a firewall at all -- firewalls just break things. > In general, firewalls are a band-aid to patch over broken software; a > poor substitute for proper security. The original point being made was that rsh won't work with a simple firewall. You either have to turn the firewall off, or install a complex firewall (that may then have its own security problems). -- In my day, we used to edit the inodes by hand. With magnets. From t.matsuu at gmail.com Tue Nov 14 11:49:41 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Tue, 14 Nov 2006 20:49:41 +0900 Subject: Firefox 3 Message-ID: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> Hi all, I put firefox-trunk SRPM based on current fedora rawhide one at http://homepage2.nifty.com/t-matsuu/install-memo/fc/ Notice: this package breaks the dependency against devhelp and yelp. Janina Sajka wrote: > Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere > near ready for prime time, but I have a compelling reason to start using > ff3 fairly soon and would rather install from rpm, of course. > > BTW: My compelling reason is that FF3 will contain a11y support that > should prove superior to any yet seen on any platform. Fingers crossed, > etc ... MATSUURA Takanori From pknirsch at redhat.com Tue Nov 14 14:07:38 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Tue, 14 Nov 2006 15:07:38 +0100 Subject: New system-config-httpd out for testing Message-ID: <4559CDAA.6070200@redhat.com> Hi folks. After a long time i've finally found some time to fix some long standing bugs and integrate some of the fundamental changes that were required to keep this tool usable and working. system-config-httpd-1.4.1-1.fc7 should be available now for development, an update version for FC6 and FC5 will follow in the next few days. Please let me know if something ain't working for you (via bugzilla ofc ;) . 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 steveo at syslang.net Tue Nov 14 14:07:20 2006 From: steveo at syslang.net (Steven W. Orr) Date: Tue, 14 Nov 2006 09:07:20 -0500 (EST) Subject: Welcome to the "fedora-devel-list" mailing list (fwd) Message-ID: Can someone please explain to me why I just got this in the mail? The headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t didn't do it. Are we in the habit of subscribing people without asking? Yes, I am capable of removing myself but do I have to add redhat lists on a cas by case basis to me whitelist? ---------- Forwarded message ---------- Date: Tue, 14 Nov 2006 00:08:57 -0500 From: fedora-devel-list-request at redhat.com To: steveo at syslang.net Subject: Welcome to the "fedora-devel-list" mailing list Welcome to the fedora-devel-list at redhat.com mailing list! To post to this list, send your email to: fedora-devel-list at redhat.com General information about the mailing list is at: https://www.redhat.com/mailman/listinfo/fedora-devel-list If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.redhat.com/mailman/options/fedora-devel-list/steveo%40syslang.net You can also make such adjustments via email by sending a message to: fedora-devel-list-request at redhat.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: mouse Normally, Mailman will remind you of your redhat.com mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From rbrausse at gmx.net Tue Nov 14 14:15:34 2006 From: rbrausse at gmx.net (Renke Brausse) Date: Tue, 14 Nov 2006 15:15:34 +0100 Subject: Welcome to the "fedora-devel-list" mailing list (fwd) In-Reply-To: References: Message-ID: <1163513734.2700.1.camel@localhost.localdomain> Good question - I didn't add myself to the list, too. A funny spam-bot? Greetings, Renke Am Dienstag, den 14.11.2006, 09:07 -0500 schrieb Steven W. Orr: > Can someone please explain to me why I just got this in the mail? The > headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t > didn't do it. Are we in the habit of subscribing people without asking? > > Yes, I am capable of removing myself but do I have to add redhat lists on > a cas by case basis to me whitelist? > > > ---------- Forwarded message ---------- > Date: Tue, 14 Nov 2006 00:08:57 -0500 > From: fedora-devel-list-request at redhat.com > To: steveo at syslang.net > Subject: Welcome to the "fedora-devel-list" mailing list > > Welcome to the fedora-devel-list at redhat.com mailing list! > > To post to this list, send your email to: > > fedora-devel-list at redhat.com > > General information about the mailing list is at: > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://www.redhat.com/mailman/options/fedora-devel-list/steveo%40syslang.net > > > You can also make such adjustments via email by sending a message to: > > fedora-devel-list-request at redhat.com > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > mouse > > Normally, Mailman will remind you of your redhat.com mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > From Matt_Domsch at dell.com Tue Nov 14 14:58:10 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Nov 2006 08:58:10 -0600 Subject: Driver disks for FC6 In-Reply-To: <20061026181840.GC22706@lists.us.dell.com> References: <20061024193820.GA3018@lists.us.dell.com> <20061024224815.GC9639@ranandlinuxbox.qlogic.org> <20061025140704.GA323@lists.us.dell.com> <20061025142531.GA29290@edu.joroinen.fi> <20061025143755.GB29290@edu.joroinen.fi> <20061025181617.GC8452@ranandlinuxbox.qlogic.org> <20061026181840.GC22706@lists.us.dell.com> Message-ID: <20061114145810.GC23849@lists.us.dell.com> On Thu, Oct 26, 2006 at 01:18:40PM -0500, Matt Domsch wrote: > On Wed, Oct 25, 2006 at 11:16:18AM -0700, ravianand wrote: > > >On Wed, 25 Oct 2006, Pasi K?rkk?inen wrote: > > > Reply-To: Development discussions related to Fedora Core > > > > > > On Wed, Oct 25, 2006 at 05:25:31PM +0300, Pasi K?rkk?inen wrote: > > > > On Wed, Oct 25, 2006 at 09:07:04AM -0500, Matt Domsch wrote: > > > > > On Tue, Oct 24, 2006 at 03:48:15PM -0700, ravianand wrote: > > > > > > Does DKMS looks for pcitable or it has been updated to package module.alias ? > > > > > > > > > > It uses pcitable for <= 2.0.13 (the current release). What's the module.alias change? > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195899#c18 > > > > > > > > FC6 and RHEL5 use the new format, and work properly with it.. > > DKMS patch below which creates the FC5+ driver disk format. It > auto-generates modules.alias. Please try this if you use this > feature. Any feedback? I've not received any... -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jeff at ocjtech.us Tue Nov 14 15:14:23 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 14 Nov 2006 09:14:23 -0600 Subject: Can we make readahead more robust to package updates? In-Reply-To: <455971B3.7080609@yahoo.co.uk> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> <455971B3.7080609@yahoo.co.uk> Message-ID: <1163517263.4352.11.camel@lt21223.campus.dmacc.edu> On Tue, 2006-11-14 at 07:35 +0000, Dariusz J. Garbowski wrote: > > what about boxens, which are shutdown only on kernel > updates? (like mine) Then you probably don't need readahead - readahead is primarily useful for those people that boot their systems frequently. Jeff -------------- 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 selinux at gmail.com Tue Nov 14 15:16:09 2006 From: selinux at gmail.com (Tom London) Date: Tue, 14 Nov 2006 07:16:09 -0800 Subject: rawhide report: 20061114 changes In-Reply-To: <200611141054.kAEAsbtr002481@hs20-bc2-6.build.redhat.com> References: <200611141054.kAEAsbtr002481@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530611140716u40ff993dg91be21ec9a6f214f@mail.gmail.com> > dbus-1.0.0-1.fc7 > ---------------- > * Mon Nov 13 2006 John (J5) Palmieir - 1.0.0-1 > - update to D-Bus 1.0.0 "Blue Bird" > - build with verbose mode on but tests and asserts off > > * Sun Nov 12 2006 Ray Strode - 0.95-3 > - dont let dbus-launch session sitter crash in the > non-autolaunch code path (bug 214649) > > * Mon Nov 06 2006 John (J5) Palmieri - 0.95-2 > - Add /var/lib/dbus directory to %files > dbus packages since 0.95-1 appear to crash g-p-m and haldaemon (#214090, #214749) Update to hal in the works? tom -- Tom London From khc at pm.waw.pl Tue Nov 14 15:32:47 2006 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 14 Nov 2006 16:32:47 +0100 Subject: I think, rsh is quite obsolete In-Reply-To: <20061114005630.GA768@iabyn.com> (Dave Mitchell's message of "Tue, 14 Nov 2006 00:56:30 +0000") References: <1162983051.4459.6.camel@numenor> <20061108235818.GM3309@redhat.com> <20061108172230.16a3d9b6.zaitcev@redhat.com> <20061109015324.GB805@redhat.com> <20061109020212.GC673446@hiwaay.net> <20061109023347.GB11430@redhat.com> <20061109024213.GE673446@hiwaay.net> <4558C9B0.9000203@andrei.myip.org> <20061113210150.GA4681@osiris.silug.org> <20061114005630.GA768@iabyn.com> Message-ID: Dave Mitchell writes: >> Just as with NFS for example. Is NFS evil too? > > Basic NFS is pretty evil. Totally insecure. Well, it looks like most local traffic here uses evil things :-) I imagine TFTP isn't less evil and perhaps only FTP is worse (cleartext passwords over the wire and firewall problems). And Samba (especially with unencrypted passwords) and X and... > The rsh protocol requires the server to make a second TCP connection back > to a low-numbered ephemeral port specified by the client, for the stderr > channel. Nope, that's optional. > If you haven't got a stateful, inspecting firewall, you're hosed. Even with stderr all you'd need is a simple helper. Anyway most people use rsh* over physically secure networks. Password-less privileged access with source IP access control over public network? No, thanks. -- Krzysztof Halasa From buc at odusz.so-cdu.ru Tue Nov 14 15:44:00 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 14 Nov 2006 18:44:00 +0300 Subject: HZ value changed from 250 to 1000 in the latest updated kernel Message-ID: <4559E440.7030307@odu.neva.ru> The latest updated kernel has another HZ value (1000 instead of 250), according to: > * Thu Nov 9 2006 Dave Jones > - Change HZ to 1000 for increased accuracy. > (Except in Xen, where it stays at 250 for now). Could someone point for me where it was discussed? (Just interested). Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From jkeating at redhat.com Tue Nov 14 15:51:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 10:51:21 -0500 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <4559E440.7030307@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> Message-ID: <200611141051.24839.jkeating@redhat.com> On Tuesday 14 November 2006 10:44, Dmitry Butskoy wrote: > Could someone point for me where it was discussed? (Just interested). I don't think it was discussed externally. The setting of 250 in the Fedora kernel was more of an accident/experiment that we forgot to remove. Dave finally reverted back to the tried and true 1000. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Tue Nov 14 16:21:07 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 14 Nov 2006 19:21:07 +0300 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <200611141051.24839.jkeating@redhat.com> References: <4559E440.7030307@odu.neva.ru> <200611141051.24839.jkeating@redhat.com> Message-ID: <4559ECF3.10807@odu.neva.ru> Jesse Keating wrote: >On Tuesday 14 November 2006 10:44, Dmitry Butskoy wrote: > > >>Could someone point for me where it was discussed? (Just interested). >> >> > >The setting of 250 in the Fedora >kernel was more of an accident/experiment that we forgot to remove. > Hmm... But it seems that vanilla kernel has default of 250, see kernel/Kconfig.hz ... "100 - servers, 1000 - desktops, 250 - compromise" ... I just doubt a little about my live smp-servers :) ~buc From zaitcev at redhat.com Tue Nov 14 16:42:42 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 14 Nov 2006 08:42:42 -0800 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <4559ECF3.10807@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> <200611141051.24839.jkeating@redhat.com> <4559ECF3.10807@odu.neva.ru> Message-ID: <20061114084242.81c29d20.zaitcev@redhat.com> On Tue, 14 Nov 2006 19:21:07 +0300, Dmitry Butskoy wrote: > >The setting of 250 in the Fedora > >kernel was more of an accident/experiment that we forgot to remove. > > But it seems that vanilla kernel has default of 250, see > kernel/Kconfig.hz ... > "100 - servers, 1000 - desktops, 250 - compromise" ... > > I just doubt a little about my live smp-servers :) We can't please everyone. People playing video at their systems noticed the difference (I did, for one). There's a solution (a palliative actually) on the horizon, called "HZ divider", which allows servers basically to turn their ticks down without affecting user seen HZ. So, Dave figured that setting this 1000 now will allow to introduce this patch later when it congeals. At least this is how I take his reasoning (please correct me - I didn't look into the actual patch). The right solution is the tickless kernel, but it was in the works for years. Who knows when that appears. -- Pete From jonathan.underwood at gmail.com Tue Nov 14 18:04:23 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 14 Nov 2006 18:04:23 +0000 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <20061114084242.81c29d20.zaitcev@redhat.com> References: <4559E440.7030307@odu.neva.ru> <200611141051.24839.jkeating@redhat.com> <4559ECF3.10807@odu.neva.ru> <20061114084242.81c29d20.zaitcev@redhat.com> Message-ID: <645d17210611141004h3efd0bbdk4456a7e642d96631@mail.gmail.com> On 14/11/06, Pete Zaitcev wrote: > The right solution is the tickless kernel, but it was in the works > for years. Who knows when that appears. > For the interested, a short, reasonably recent article on the tickless kernel patch is: http://kerneltrap.org/node/6750 From guineau at earthlink.net Tue Nov 14 18:25:43 2006 From: guineau at earthlink.net (W.John Guineau) Date: Tue, 14 Nov 2006 10:25:43 -0800 Subject: FC5 -> FC6 - is a clean install or upgrade the best path? In-Reply-To: <20061114145810.GC23849@lists.us.dell.com> Message-ID: <02fa01c7081a$4c231d10$0700a8c0@coyote> I know this is probebly not the most appropriate list, but probably the most informed... I've done an "upgrade" to a new major Fedora version in the past and it seems you are not left with all the new "bells and whistles" of the newer version. Is an upgrade from FC5->FC6 virtually the same result as a clean FC6 install (and reinstall/setup of my environment)? If clean install, how can I most easily preserve things like user accounts etc. when all are on the same disk? john From opensource at till.name Tue Nov 14 19:12:11 2006 From: opensource at till.name (Till Maas) Date: Tue, 14 Nov 2006 20:12:11 +0100 Subject: Welcome to the "fedora-devel-list" mailing list (fwd) In-Reply-To: References: Message-ID: <200611142012.15219.opensource@till.name> On Tuesday 14 November 2006 15:07, Steven W. Orr wrote: > Can someone please explain to me why I just got this in the mail? The > headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t > didn't do it. Are we in the habit of subscribing people without asking? Are you a fedora extras maintainer? Iirc it was decided by Fesco that it should be made sure that every maintainer is subscribed to the mailinglists that are described as mandatory for maintainers in the wiki. (devel, maintainer, extras, commit(iirc)) Maybe this is the reason. Regards, Till From p at uni-bielefeld.de Tue Nov 14 19:27:32 2006 From: p at uni-bielefeld.de (=?ISO-8859-1?Q?Peter_K=FChnlein?=) Date: Tue, 14 Nov 2006 20:27:32 +0100 Subject: Welcome to the "fedora-devel-list" mailing list (fwd) In-Reply-To: <200611142012.15219.opensource@till.name> References: <200611142012.15219.opensource@till.name> Message-ID: <455A18A4.6090504@uni-bielefeld.de> Till Maas wrote: >On Tuesday 14 November 2006 15:07, Steven W. Orr wrote: > > > >>Can someone please explain to me why I just got this in the mail? The >>headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t >>didn't do it. Are we in the habit of subscribing people without asking? >> >> > >Are you a fedora extras maintainer? Iirc it was decided by Fesco that it >should be made sure that every maintainer is subscribed to the mailinglists >that are described as mandatory for maintainers in the wiki. (devel, >maintainer, extras, commit(iirc)) Maybe this is the reason. > >Regards, >Till > > > > I'm no fc extra maintainer, but suddenly received the mails as well... i guess it's either a funny spambot or just an error in RH's database... can't decide what is more likely... anyway, my "unsubscribe" request hasn't been acknowledged up to now... Take care: Peter -- http://www.peter-kuehnlein.net "The Way of the Samurai is in desperateness. Ten men or more cannot kill such a man." (Hagakure) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclarke at wiredunderground.com Tue Nov 14 18:55:40 2006 From: jclarke at wiredunderground.com (Jim Clarke) Date: Tue, 14 Nov 2006 11:55:40 -0700 Subject: FC5 -> FC6 - is a clean install or upgrade the best path? In-Reply-To: <02fa01c7081a$4c231d10$0700a8c0@coyote> References: <20061114145810.GC23849@lists.us.dell.com> <02fa01c7081a$4c231d10$0700a8c0@coyote> Message-ID: <20061114184643.M51799@wiredunderground.com> Most recently on one of our servers I have upgraded from FC5 > FC6 and yes you do not get all the "bells and whistles". What it does is upgrade the core, and rpm modules installed to the FC6 corresponding rpm's. A re-install will definently be the best and give you all the bells and whistles. However on our one server that was upgraded to FC6 I have way to many custom scripts and configs to redo. Was looking forward to the eye candy provided from FC6. However manually installing some of these nice additions manually via yum should not be an issue? Anyone have a "yum install" list of what they have done to make use of the extra's from FC6 after an upgrade would be most beneficial. On another note I have noticed a nice OS speed increase and gui stability within Gnome which is very nice! cheers, Jim Clarke On Tue, 14 Nov 2006 10:25:43 -0800, W.John Guineau wrote > I know this is probebly not the most appropriate list, but probably > the most informed... > > I've done an "upgrade" to a new major Fedora version in the past and > it seems you are not left with all the new "bells and whistles" of > the newer version. > > Is an upgrade from FC5->FC6 virtually the same result as a clean FC6 > install > (and reinstall/setup of my environment)? > > If clean install, how can I most easily preserve things like user accounts > etc. when all are on the same disk? > > john > > -- -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ If you are not the CanIt administrator and you think this message is spam, please give the id 77108 and magic value 2893307b999b to jclarke at wiredunderground.com to be marked as spam. Teach CanIt if this mail (ID 77108) is spam: Spam: http://www.wiredunderground.com/CanIt/b.php?c=s&i=77108&m=2893307b999b Not spam: http://www.wiredunderground.com/CanIt/b.php?c=n&i=77108&m=2893307b999b Forget vote: http://www.wiredunderground.com/CanIt/b.php?c=f&i=77108&m=2893307b999b ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS From avi at argo.co.il Tue Nov 14 20:31:21 2006 From: avi at argo.co.il (Avi Kivity) Date: Tue, 14 Nov 2006 22:31:21 +0200 Subject: X in FC7 In-Reply-To: <45587068.90508@redhat.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> Message-ID: <455A2799.6010807@argo.co.il> Adam Jackson wrote: > > As said on the wiki page, what problem is xfs trying to solve? If > it's just about the ability to add fonts at runtime without having to > do 'xset fp rehash', then that should be a very small amount of code > to add to the X server. You need to watch for directories popping in > and out of existance, but, okay, we know how to do that. Wasn't the X font server designed for storageless X terminals? You'd just point the X server at the font server, and get the fonts you need, without needing to replace the terminal's ROM. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From bkoz at redhat.com Tue Nov 14 22:28:32 2006 From: bkoz at redhat.com (Benjamin Kosnik) Date: Tue, 14 Nov 2006 23:28:32 +0100 Subject: debuginfo issues Message-ID: <20061114232832.2d2d4c47.bkoz@redhat.com> Hey Jakub! I don't see any libstdc++-debuginfo packages, and am wondering... why? The /usr/lib shared lib is stripped. What am I missing? Is this debug info in another package (and not the obvious libstdc++-debuginfo package)? I usually just debug with my own toolchain so hadn't noticed this before. I'm trying to figure out what to do with boost's empty debuginfo package, so had looked around for other libs that were presumably doing this correctly. I'm not quite sure what's up: I get this in my build log when I do rpmbuild -ba boost.spec ... + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/boost_1_33_1 0 blocks find: /var/tmp/boost-1.33.1-root/usr/lib/debug: No such file or directory ... I'm looking for some documentation on this stuff and am coming up empty handed. I don't see any consensus in the kernel.spec or gcc41.spec files, and no trail of obvious tricks either. I see that the gmp-debuginfo package does what I'd expect it to do, but doesn't seem to resort to any trickery to do it. The build log for gmp looks like: ... + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/gmp-4.1.4 extracting debug info from /var/tmp/gmp-4.1.4-root/usr/lib/libgmpxx.so.3.0.5 extracting debug info from /var/tmp/gmp-4.1.4-root/usr/lib/libgmp.so.3.3.3 extracting debug info from /var/tmp/gmp-4.1.4-root/usr/lib/libmp.so.3.1.7 cpio: gmp-4.1.4/base/cxx/: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-add_n.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-addmul_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-copyd.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-copyi.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-dive_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-diveby3.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-divrem_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-lshift.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-mod_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-mod_34lsub1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-mul_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-mul_basecase.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-rshift.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-sub_n.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-submul_1.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-udiv.s: No such file or directory cpio: gmp-4.1.4/base/mpn/tmp-umul.s: No such file or directory 2702 blocks ... The boost build procedure unfortunately doesn't use the standard GNU make tools, so perhaps this is something related to build location, or something not done? -benjamin From nicolas.mailhot at laposte.net Tue Nov 14 22:40:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Nov 2006 23:40:42 +0100 Subject: X in FC7 In-Reply-To: <455A2799.6010807@argo.co.il> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> Message-ID: <1163544043.23070.11.camel@rousalka.dyndns.org> Le mardi 14 novembre 2006 ? 22:31 +0200, Avi Kivity a ?crit : > Wasn't the X font server designed for storageless X terminals? > > You'd just point the X server at the font server, and get the fonts you > need, without needing to replace the terminal's ROM. Very few entities are able to license fonts for use on this scale ; and if the fonts are freely redistributable, the font server part is useless nowadays. -- Nicolas Mailhot From aoriani at gmail.com Tue Nov 14 22:40:54 2006 From: aoriani at gmail.com (=?ISO-8859-1?Q?Andr=E9_Oriani?=) Date: Tue, 14 Nov 2006 20:40:54 -0200 Subject: Welcome to the "fedora-devel-list" mailing list (fwd) In-Reply-To: <455A18A4.6090504@uni-bielefeld.de> References: <200611142012.15219.opensource@till.name> <455A18A4.6090504@uni-bielefeld.de> Message-ID: <7f47da080611141440p218a6fedr5edbf85aa9355e72@mail.gmail.com> I subscribed once but not anymore and now I am back without having been subscribed again. Andr? Oriani 2006/11/14, Peter K?hnlein

: > > Till Maas wrote: > > On Tuesday 14 November 2006 15:07, Steven W. Orr wrote: > > > > Can someone please explain to me why I just got this in the mail? The > headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t > didn't do it. Are we in the habit of subscribing people without asking? > > > Are you a fedora extras maintainer? Iirc it was decided by Fesco that it > should be made sure that every maintainer is subscribed to the mailinglists > that are described as mandatory for maintainers in the wiki. (devel, > maintainer, extras, commit(iirc)) Maybe this is the reason. > > Regards, > Till > > > > > I'm no fc extra maintainer, but suddenly received the mails as well... i > guess it's either a funny spambot or just an error in RH's database... can't > decide what is more likely... anyway, my "unsubscribe" request hasn't been > acknowledged up to now... > > Take care: Peter > > -- http://www.peter-kuehnlein.net > > "The Way of the Samurai is in desperateness. Ten men or more cannot > kill such a man." > (Hagakure) > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at miketc.com Tue Nov 14 22:48:25 2006 From: mike at miketc.com (Mike Chambers) Date: Tue, 14 Nov 2006 16:48:25 -0600 Subject: Firefox 3 In-Reply-To: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> Message-ID: <1163544505.16827.2.camel@scrappy.miketc.com> On Tue, 2006-11-14 at 20:49 +0900, MATSUURA Takanori wrote: > Hi all, > > I put firefox-trunk SRPM based on current fedora rawhide one at > http://homepage2.nifty.com/t-matsuu/install-memo/fc/ > > Notice: this package breaks the dependency against devhelp and yelp. How stable is this version anyway? Are or you using it? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From p at uni-bielefeld.de Tue Nov 14 22:53:00 2006 From: p at uni-bielefeld.de (=?ISO-8859-1?Q?Peter_K=FChnlein?=) Date: Tue, 14 Nov 2006 23:53:00 +0100 Subject: unsubscribe In-Reply-To: <7f47da080611141440p218a6fedr5edbf85aa9355e72@mail.gmail.com> References: <200611142012.15219.opensource@till.name> <455A18A4.6090504@uni-bielefeld.de> <7f47da080611141440p218a6fedr5edbf85aa9355e72@mail.gmail.com> Message-ID: <455A48CC.7060903@uni-bielefeld.de> Andr? Oriani wrote: > I subscribed once but not anymore and now I am back without having > been subscribed again. > Andr? Oriani Fucking remove me from that list. -- http://www.peter-kuehnlein.net "The Way of the Samurai is in desperateness. Ten men or more cannot kill such a man." (Hagakure) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Tue Nov 14 23:02:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 18:02:46 -0500 Subject: New subscribers to the -devel list Message-ID: <200611141802.46970.jkeating@redhat.com> I'm trying to tack down why people are being added to the list. If you're new to this list, please let me know (in private) if you got 'welcome' email, or if you just started getting email. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sojeff62 at cox.net Tue Nov 14 23:13:36 2006 From: sojeff62 at cox.net (Steven Jeffries) Date: Tue, 14 Nov 2006 18:13:36 -0500 Subject: New subscribers to the -devel list In-Reply-To: <200611141802.46970.jkeating@redhat.com> Message-ID: <003601c70842$83773580$8901a8c0@Homeplate> I did just start getting e-mail from the list. I don't know why or how, but please unsubscribe me. Steve -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Jesse Keating Sent: Tuesday, November 14, 2006 6:03 PM To: Development discussions related to Fedora Core Subject: New subscribers to the -devel list I'm trying to tack down why people are being added to the list. If you're new to this list, please let me know (in private) if you got 'welcome' email, or if you just started getting email. -- Jesse Keating Release Engineer: Fedora From proclivity76 at yahoo.com Tue Nov 14 23:15:17 2006 From: proclivity76 at yahoo.com (Brian Neu) Date: Tue, 14 Nov 2006 15:15:17 -0800 (PST) Subject: New subscribers to the -devel list In-Reply-To: <200611141802.46970.jkeating@redhat.com> Message-ID: <20061114231517.35819.qmail@web51905.mail.yahoo.com> I was part of fedora-users Jesse Keating wrote: I'm trying to tack down why people are being added to the list. If you're new to this list, please let me know (in private) if you got 'welcome' email, or if you just started getting email. -- Jesse Keating Release Engineer: Fedora -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Tue Nov 14 23:30:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 15 Nov 2006 00:30:07 +0100 Subject: debuginfo issues In-Reply-To: <20061114232832.2d2d4c47.bkoz@redhat.com> References: <20061114232832.2d2d4c47.bkoz@redhat.com> Message-ID: <455A517F.3060608@hhs.nl> Benjamin Kosnik wrote: > > Hey Jakub! > > I don't see any libstdc++-debuginfo packages, and am wondering... why? > The /usr/lib shared lib is stripped. What am I missing? Is this debug > info in another package (and not the obvious libstdc++-debuginfo > package)? I usually just debug with my own toolchain so hadn't noticed > this before. > [hans at shalem devel]$ rpm -qi libstdc++ libstdc++-4.1.1-20.i386 Name : libstdc++ Relocations: (not relocatable) Version : 4.1.1 Vendor: Red Hat, Inc. Release : 20 Build Date: Tue 29 Aug 2006 12:24:58 AM CEST Install Date: Thu 14 Sep 2006 10:55:47 PM CEST Build Host: hs20-bc1-6.build.redhat.com Group : System Environment/Libraries Source RPM: gcc-4.1.1-20.src.rpm Size : 929584 License: GPL Signature : DSA/SHA1, Wed 13 Sep 2006 02:31:00 PM CEST, Key ID fd372689897da07a Packager : Red Hat, Inc. URL : http://gcc.gnu.org Summary : GNU Standard C++ Library Description : The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library. libstdc++-4.1.1-27.x86_64 Name : libstdc++ Relocations: (not relocatable) Version : 4.1.1 Vendor: Red Hat, Inc. Release : 27 Build Date: Fri 29 Sep 2006 12:48:17 AM CEST Install Date: Mon 02 Oct 2006 09:31:20 AM CEST Build Host: hs20-bc1-5.build.redhat.com Group : System Environment/Libraries Source RPM: gcc-4.1.1-27.src.rpm Size : 981840 License: GPL Signature : (none) Packager : Red Hat, Inc. URL : http://gcc.gnu.org Summary : GNU Standard C++ Library Description : The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library. [hans at shalem devel]$ Notice the "Source RPM: gcc-4.1.1-27.src.rpm", thus gcc-debuginfo is what you want. Regards, Hans From mike at miketc.com Tue Nov 14 23:27:14 2006 From: mike at miketc.com (Mike Chambers) Date: Tue, 14 Nov 2006 17:27:14 -0600 Subject: New subscribers to the -devel list In-Reply-To: <200611141802.46970.jkeating@redhat.com> References: <200611141802.46970.jkeating@redhat.com> Message-ID: <1163546834.1257.1.camel@scrappy.miketc.com> On Tue, 2006-11-14 at 18:02 -0500, Jesse Keating wrote: > I'm trying to tack down why people are being added to the list. If you're new > to this list, please let me know (in private) if you got 'welcome' email, or > if you just started getting email. For those that need help, please do as Jesse pointed out and let him know *IN PRIVATE* that you need off the list or why/how you were added, or whatever reason he pointed out above. No need to send the emails to the list itself. Thanks, -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From classicairchecks at gmail.com Wed Nov 15 00:03:53 2006 From: classicairchecks at gmail.com (Steve West) Date: Tue, 14 Nov 2006 18:03:53 -0600 Subject: GET ME OFF THIS DAMN LIST YOU'RE FILLING MY INBOX!!! References: <20061114231517.35819.qmail@web51905.mail.yahoo.com> Message-ID: <009501c70849$8c5d2d60$d5805c18@BACKROOM> I unsubscribed to this damn list a long time ago because it just clogs my inbox with crap I'm not interested in. PLEASE TAKE ME OFF THIS FRIGGIN LIST!!!! Steve Sawyer ----- Original Message ----- From: Brian Neu To: Development discussions related to Fedora Core Sent: Tuesday, November 14, 2006 5:15 PM Subject: Re: New subscribers to the -devel list I was part of fedora-users Jesse Keating wrote: I'm trying to tack down why people are being added to the list. If you're new to this list, please let me know (in private) if you got 'welcome' email, or if you just started getting email. -- Jesse Keating Release Engineer: Fedora -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list ------------------------------------------------------------------------------ -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilborn at uslec.com Wed Nov 15 00:06:36 2006 From: jwilborn at uslec.com (Wilborn, Jerry) Date: Tue, 14 Nov 2006 19:06:36 -0500 Subject: Welcome to the "fedora-devel-list" mailing list (fwd) Message-ID: Ditto. Jerry Wilborn, Systems Engineer US LEC 504-648-8078 www.uslec.com -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Andr? Oriani Sent: Tuesday, November 14, 2006 4:41 PM To: Development discussions related to Fedora Core Subject: Re: Welcome to the "fedora-devel-list" mailing list (fwd) I subscribed once but not anymore and now I am back without having been subscribed again. Andr? Oriani 2006/11/14, Peter K?hnlein

: Till Maas wrote: On Tuesday 14 November 2006 15:07, Steven W. Orr wrote: Can someone please explain to me why I just got this in the mail? The headers are not spoofed. I really am subscribed and I sure as sh[:vowel:]t didn't do it. Are we in the habit of subscribing people without asking? Are you a fedora extras maintainer? Iirc it was decided by Fesco that it should be made sure that every maintainer is subscribed to the mailinglists that are described as mandatory for maintainers in the wiki. (devel, maintainer, extras, commit(iirc)) Maybe this is the reason. Regards, Till I'm no fc extra maintainer, but suddenly received the mails as well... i guess it's either a funny spambot or just an error in RH's database... can't decide what is more likely... anyway, my "unsubscribe" request hasn't been acknowledged up to now... Take care: Peter -- http://www.peter-kuehnlein.net "The Way of the Samurai is in desperateness. Ten men or more cannot kill such a man." (Hagakure) -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario.danic at gmail.com Wed Nov 15 00:10:30 2006 From: mario.danic at gmail.com (=?ISO-8859-2?Q?Mario_=D0ani=E6?=) Date: Wed, 15 Nov 2006 01:10:30 +0100 Subject: GET ME OFF THIS DAMN LIST YOU'RE FILLING MY INBOX!!! In-Reply-To: <009501c70849$8c5d2d60$d5805c18@BACKROOM> References: <20061114231517.35819.qmail@web51905.mail.yahoo.com> <009501c70849$8c5d2d60$d5805c18@BACKROOM> Message-ID: <79957db20611141610hf3b01e9jca1f276a39836025@mail.gmail.com> On 11/15/06, Steve West wrote: > > > I unsubscribed to this damn list a long time ago because it just clogs my > inbox with crap I'm not interested in. PLEASE TAKE ME OFF THIS FRIGGIN > LIST!!!! > > Steve Sawyer Hello, please consider lowering your tone. People are already looking into the issue, and you are not the only one that have this problem. Thanks for understanding. Kind regards, Mario From ravi.anand at qlogic.com Wed Nov 15 00:14:12 2006 From: ravi.anand at qlogic.com (ravianand) Date: Tue, 14 Nov 2006 16:14:12 -0800 Subject: Driver disks for FC6 In-Reply-To: <20061114145810.GC23849@lists.us.dell.com> References: <20061024193820.GA3018@lists.us.dell.com> <20061024224815.GC9639@ranandlinuxbox.qlogic.org> <20061025140704.GA323@lists.us.dell.com> <20061025142531.GA29290@edu.joroinen.fi> <20061025143755.GB29290@edu.joroinen.fi> <20061025181617.GC8452@ranandlinuxbox.qlogic.org> <20061026181840.GC22706@lists.us.dell.com> <20061114145810.GC23849@lists.us.dell.com> Message-ID: <20061115001412.GD18719@ranandlinuxbox.qlogic.org> >On Tue, 14 Nov 2006, Matt Domsch wrote: > Reply-To: Development discussions related to Fedora Core > > On Thu, Oct 26, 2006 at 01:18:40PM -0500, Matt Domsch wrote: > > On Wed, Oct 25, 2006 at 11:16:18AM -0700, ravianand wrote: > > > >On Wed, 25 Oct 2006, Pasi K?rkk?inen wrote: > > > > Reply-To: Development discussions related to Fedora Core > > > > > > > > On Wed, Oct 25, 2006 at 05:25:31PM +0300, Pasi K?rkk?inen wrote: > > > > > On Wed, Oct 25, 2006 at 09:07:04AM -0500, Matt Domsch wrote: > > > > > > On Tue, Oct 24, 2006 at 03:48:15PM -0700, ravianand wrote: > > > > > > > Does DKMS looks for pcitable or it has been updated to package module.alias ? > > > > > > > > > > > > It uses pcitable for <= 2.0.13 (the current release). What's the module.alias change? > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195899#c18 > > > > > > > > > > FC6 and RHEL5 use the new format, and work properly with it.. > > > > DKMS patch below which creates the FC5+ driver disk format. It > > auto-generates modules.alias. Please try this if you use this > > feature. > > Any feedback? I've not received any... We will try it out and provide you an updated sometime next week. Just got busy with some of the other work. Thanx Ravi > > -- > Matt Domsch > Software Architect > Dell Linux Solutions linux.dell.com & www.dell.com/linux > Linux on Dell mailing lists @ http://lists.us.dell.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From dstewart at atl.lmco.com Wed Nov 15 00:38:39 2006 From: dstewart at atl.lmco.com (Doug Stewart) Date: Tue, 14 Nov 2006 19:38:39 -0500 Subject: GET ME OFF THIS DAMN LIST YOU'RE FILLING MY INBOX!!! In-Reply-To: <009501c70849$8c5d2d60$d5805c18@BACKROOM> References: <20061114231517.35819.qmail@web51905.mail.yahoo.com> <009501c70849$8c5d2d60$d5805c18@BACKROOM> Message-ID: <455A618F.5060605@atl.lmco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve West wrote: > I unsubscribed to this damn list a long time ago because it just clogs > my inbox with crap I'm not interested in. PLEASE TAKE ME OFF THIS > FRIGGIN LIST!!!! Thanks for filling my inbox instead of clicking on the link that's conveniently provided at the bottom of every. single. email. from this list that gets into your inbox. You have the power. Do it. - -- - ---------- Doug Stewart Senior Systems Administrator/Web Applications Developer Lockheed Martin Advanced Technology Labs dstewart at atl.lmco.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWmGPN50Q8DVvcvkRAl9AAJ98x5lsV556Y8fjx1MGZM2t6wl2NgCeNg8K aUVtcWp/Yci6MYb6yS7mHJs= =hy+Z -----END PGP SIGNATURE----- From ksnider at flarn.com Wed Nov 15 00:40:43 2006 From: ksnider at flarn.com (Ken Snider) Date: Tue, 14 Nov 2006 19:40:43 -0500 Subject: GET ME OFF THIS DAMN LIST YOU'RE FILLING MY INBOX!!! In-Reply-To: <455A618F.5060605@atl.lmco.com> References: <20061114231517.35819.qmail@web51905.mail.yahoo.com> <009501c70849$8c5d2d60$d5805c18@BACKROOM> <455A618F.5060605@atl.lmco.com> Message-ID: <455A620B.1050800@flarn.com> Doug Stewart wrote: > Thanks for filling my inbox instead of clicking on the link that's > conveniently provided at the bottom of every. single. email. from this > list that gets into your inbox. > > You have the power. Do it. 'cept the unsubscribe isn't working apparently, leading to people receiving unsolicited email without the ability to unsubscribe. Sound like another form of annoying email you may have heard of? ;) -- Ken Snider From midway04 at hotmail.com Wed Nov 15 01:39:49 2006 From: midway04 at hotmail.com (=?iso-8859-1?B?UGF0cmljayBC6WRhcmQ=?=) Date: Tue, 14 Nov 2006 20:39:49 -0500 Subject: EVERY BODY STOP REPLY!! In-Reply-To: <455A620B.1050800@flarn.com> Message-ID: An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Nov 15 03:01:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 22:01:25 -0500 Subject: New subscribers to the -devel list In-Reply-To: <200611141802.46970.jkeating@redhat.com> References: <200611141802.46970.jkeating@redhat.com> Message-ID: <200611142201.28578.jkeating@redhat.com> On Tuesday 14 November 2006 18:02, Jesse Keating wrote: > I'm trying to tack down why people are being added to the list. ?If > you're new to this list, please let me know (in private) if you got > ?'welcome' email, or if you just started getting email. Based on what people have been telling me, it seems that many (most?) of the new subscribers were already subscribed to some other Red Hat hosted mailing list. It would appear that these people somehow got added to the fedora-devel list without their concent. I am still looking into the issue, but may not have any resolutions until tomorrow when more IS is on staff. Please have patience with us. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Wed Nov 15 03:43:20 2006 From: warren at togami.com (Warren Togami) Date: Tue, 14 Nov 2006 22:43:20 -0500 Subject: Apologies for Fedora-Devel-List Mishap Message-ID: <455A8CD8.4060701@togami.com> Today a great many people were incorrectly subscribed today to fedora-devel-list due to a terrible error on our part. 929 people in total were subscribed by this unfortunate accident. In order to end this grief, we have decided to unsubscribe all new subscribers of today immediately after this message hits the list. We deeply regret any inconvenience this may have caused. https://www.redhat.com/mailman/listinfo/fedora-devel-list Some who intended to subscribe today might be accidentally removed. So please check on your subscription status tomorrow Warren Togami wtogami at redhat.com From Charles.Butterfield at nextcentury.com Wed Nov 15 04:05:17 2006 From: Charles.Butterfield at nextcentury.com (Charles Butterfield) Date: Tue, 14 Nov 2006 23:05:17 -0500 Subject: Kernel PCI Scan Bug - No feedback 8 days after bug submittal(reposted with newlines) References: <8EDBE3F4D9261F4A90677FB13B9CCEBC66A8E7@ws2.hq.nextcentury.com> <20061115031647.GR6591@redhat.com> Message-ID: "Dave Jones" wrote in message news:20061115031647.GR6591 at redhat.com... > On Tue, Nov 14, 2006 at 07:25:19PM -0500, Charles Butterfield wrote: > > I've had what seems like a fairly serious kernel bug related to PCI > > scanning open for over a week, with no hint that anybody has read it, > > triaged it, etc. > > chances are, that no-one has read it or triaged it. > There are currently 696 FC5 kernel bugs open, and 208 FC6 kernel bugs > open. > The number of people actively working through those bugs you can count > on one hand. > > > Some feedback would sure be nice. > > I'll get to it (unless someone else beats me to it) eventually. > > Dave Dave - Thanks for the feedback. 1) I was kind of worried that I had messed up the bugzilla posting with the initially incorrect subsystem diagnosis (Xorg vs kernel). 2) Is this something that can just be kicked upstream? I would (naively) think a discrepancy between /proc/bus/pci/devices and /proc/bus/pci/xx/* would be a clear "OOPS" for whoever maintains the pci part of procfs, which I wouldn't think would be Fedora specific. 3) Am I correct in assuming that the referral to the upstream kernel folks must be done by a distro developer? That seems to be the gist of a message on their website. - Charlie From caolanm at redhat.com Wed Nov 15 09:07:46 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 15 Nov 2006 09:07:46 +0000 Subject: debuginfo issues In-Reply-To: <20061114232832.2d2d4c47.bkoz@redhat.com> References: <20061114232832.2d2d4c47.bkoz@redhat.com> Message-ID: <1163581667.7640.18.camel@soulcrusher.caolan.org> On Tue, 2006-11-14 at 23:28 +0100, Benjamin Kosnik wrote: > I'm trying to figure out what to do with boost's empty debuginfo > package, so had looked around for other libs that were presumably doing > this correctly. I'm not quite sure what's up: I get this in my build > log when I do > > rpmbuild -ba boost.spec > > ... > + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/boost_1_33_1 > 0 blocks > find: /var/tmp/boost-1.33.1-root/usr/lib/debug: No such file or directory > The boost build procedure unfortunately doesn't use the standard GNU > make tools, so perhaps this is something related to build location, or > something not done? Any chance that the boost make install has a custom pre-strip which installs stripped .sos ? That would explain a worthless empty debuginfo package. C. From jakub at redhat.com Wed Nov 15 09:54:16 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 15 Nov 2006 04:54:16 -0500 Subject: debuginfo issues In-Reply-To: <20061114232832.2d2d4c47.bkoz@redhat.com> References: <20061114232832.2d2d4c47.bkoz@redhat.com> Message-ID: <20061115095415.GM6570@devserv.devel.redhat.com> On Tue, Nov 14, 2006 at 11:28:32PM +0100, Benjamin Kosnik wrote: > I don't see any libstdc++-debuginfo packages, and am wondering... why? gcc-debuginfo. > rpmbuild -ba boost.spec > > ... > + /usr/lib/rpm/find-debuginfo.sh /usr/src/redhat/BUILD/boost_1_33_1 > 0 blocks > find: /var/tmp/boost-1.33.1-root/usr/lib/debug: No such file or directory > ... Most probably your Makefiles or spec stripped everything before reaching debuginfo generation or wasn't even compiled with -g. Make sure you don't strip anything you want debuginfo generated for and that is has been compiled with debug enabled (-g is among RPM_OPT_FLAGS, so if the package honors that, it shouldn't be any extra effort). > I'm looking for some documentation on this stuff and am coming up empty > handed. I don't see any consensus in the kernel.spec or gcc41.spec > files, and no trail of obvious tricks either. I see that the Don't look at kernel.spec or glibc.spec for debuginfo details, these two packages build debuginfo specially on their own. But AFAIK all other packages use the standard thing. Jakub From dominik at greysector.net Wed Nov 15 10:24:39 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 15 Nov 2006 11:24:39 +0100 Subject: Apologies for Fedora-Devel-List Mishap In-Reply-To: <455A8CD8.4060701@togami.com> References: <455A8CD8.4060701@togami.com> Message-ID: <20061115102439.GB11319@rathann.pekin.waw.pl> On Wednesday, 15 November 2006 at 04:43, Warren Togami wrote: > Today a great many people were incorrectly subscribed today to > fedora-devel-list due to a terrible error on our part. 929 people in > total were subscribed by this unfortunate accident. That was nice and cryptic. If somebody wanted an explanation, they sure didn't get it. Now can you please tell us what really happened and how you intend to avoid something like that in the future? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buildsys at redhat.com Wed Nov 15 11:24:02 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 15 Nov 2006 06:24:02 -0500 Subject: rawhide report: 20061115 changes Message-ID: <200611151124.kAFBO2Zg026121@hs20-bc2-6.build.redhat.com> Updated Packages: arts-8:1.5.5-1.fc7 ------------------ * Tue Nov 14 2006 Than Ngo - 6:1.5.5-1.fc7 - rebuild at-3.1.10-6.fc7 --------------- * Fri Oct 27 2006 Marcela Maslanova - 3.1.10-6 - fix daylight-saving again - fix #214759 - problem with seteuid * Wed Oct 25 2006 Marcela Maslanova - 3.1.10-5 - daylight-saving * Tue Oct 24 2006 Marcela Maslanova - 3.1.10-3 - new version from upstream 3.1.10 checkpolicy-1.33.1-1 -------------------- * Tue Nov 14 2006 Dan Walsh - 1.33.1-1 - Latest update from NSA * Collapse user identifiers and identifiers together. dbus-1.0.0-2.fc7 ---------------- * Tue Nov 14 2006 John (J5) Palmieir - 1.0.0-2 - add patch to fix dbus_threads_init_default dhcp-12:3.0.5-5.fc7 ------------------- * Tue Nov 14 2006 David Cantrell - 12:3.0.5-5 - Do not link res_query.o in to libdhcp4client (#215501) * Mon Nov 13 2006 David Cantrell - 12:3.0.5-4 - Enable relinquish_timeouts() and cancel_all_timeouts() even when DEBUG_MEMORY_LEAKAGE_ON_EXIT is not defined - Add prototypes for b64_pton() and b64_ntop in dst/ - Move variable declarations and labels around in the fix-warnings patch - Expand the list of objects needed for libdhcp4client (#215328) - Use libres.a in libdhcp4client since it gives correct minires objects - Remove the dhcp options table in C, Perl, Python, and text format (these were reference files added to /usr/share/doc) * Mon Nov 13 2006 David Cantrell - 12:3.0.5-3 - Remove struct universe *universe from envadd_state in the client patch - Add struct universe *universe to envadd_state in the enoi patch - Add example dbusified dhclient-script in the enoi patch gnome-panel-2.16.1-4.fc7 ------------------------ * Tue Nov 14 2006 Matthias Clasen - 2.16.1-4 - Fix copying of launchers by DND, bug 214334 * Tue Nov 14 2006 Ray Strode - 2.16.1-3 - fix "Add this launcher to panel" chinese translation. Patch by Caius Chance (bug 211569) gnome-volume-manager-2.17.0-2.fc7 --------------------------------- * Tue Nov 07 2006 David Zeuthen - 2.17.0-2.fc7 - Refuse to automount when screensaver is running (#215057) hal-0.5.8.1-6.fc7 ----------------- * Tue Nov 14 2006 David Zeuthen - 0.5.8.1-6.fc7 - Rebuild * Tue Nov 14 2006 David Zeuthen - 0.5.8.1-5.fc7 - Alignment fixes on ia64; Add patch fixing to work with D-Bus 1.0 * Wed Oct 04 2006 David Zeuthen - 0.5.8.1-4.fc7 - Make a patch actually apply kdebindings-3.5.5-1.fc7 ----------------------- * Tue Nov 14 2006 Than Ngo - 3.5.5-1.fc7 - rebuild * Wed Nov 08 2006 Than Ngo 3.5.5-0.2.fc6 - fix #196311, should not own /usr/lib/python2.4 kdelibs-6:3.5.5-1.fc7 --------------------- * Tue Nov 14 2006 Than Ngo - 6:3.5.5-1.fc7 - rebuild m17n-db-1.3.3-38.fc7 -------------------- * Tue Nov 14 2006 Mayank Jain - Fixed Bug 177371: mapping of X and x in kn-kgp - Fixed Bug 215486: Mapped 0x0964 to shift(.) instead of . in as-inscript - Fixed Bug 215489: Mapped 0x0964 to shift(.) instead of . in bn-inscript nautilus-2.16.2-6.fc7 --------------------- * Tue Nov 14 2006 Matthias Clasen - 2.16.2-6 - Detect tracker dynamically, too policycoreutils-1.33.1-1 ------------------------ * Tue Nov 14 2006 Dan Walsh 1.33.1-3 - Update to upstream * Merged newrole patch set from Michael Thompson. - Add policycoreutils-gui scim-anthy-1.2.2-1.fc7 ---------------------- * Tue Nov 14 2006 Akira TAGOH - 1.2.2-1 - New upstream release. - removed unnecessary patches: - scim-anthy-libtool-export.patch - scim-anthy-fix-pending-state.patch - scim-anthy-dict-encoding.patch - scim-anthy-1.2.2-gettextize.patch: fix a build issue on the latest autotools. selinux-policy-2.4.3-13 ----------------------- * Mon Nov 13 2006 Dan Walsh 2.4.3-13 - Allow modstorage to edit /etc/fstab file shadow-utils-2:4.0.18.1-4.fc7 ----------------------------- * Tue Nov 14 2006 Peter Vrabec 2:4.0.18.1-4 - fix chpasswd and chgpasswd stack overflow (#213052) system-config-printer-0.7.38-1.fc7 ---------------------------------- * Tue Nov 14 2006 Tim Waugh 0.7.38-1 - Updated pycups to 1.9.15. - 0.7.38: - Fixed a bug in the 'ieee1284'/'ppd-device-id' parsing code. Broken deps for i386 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.i386 requires libbtctl.so.2 Broken deps for ppc64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ppc64 requires libbtctl.so.2()(64bit) Broken deps for x86_64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.x86_64 requires libbtctl.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ppc requires libbtctl.so.2 Broken deps for ia64 ---------------------------------------------------------- nautilus-sendto-bluetooth - 0.8-2.fc7.ia64 requires libbtctl.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From t.matsuu at gmail.com Wed Nov 15 11:52:32 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Wed, 15 Nov 2006 20:52:32 +0900 Subject: Firefox 3 Message-ID: <6f27515e0611150352s7ca05087l544ade135723af24@mail.gmail.com> I'm using it as a default browser on my Fedora Core box. Java, Flash, and AdobeReader plugins and some Add-ons I installed work fine. Basically I have no trouble with the trunk builds. But it is not always "stable" because it is the "trunk build" that is in the development process. So please use it at your own risk. 2006/11/14, Mike Chambers wrote: > How stable is this version anyway? Are or you using it? -- MATSUURA Takanori From jkeating at redhat.com Wed Nov 15 12:35:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 07:35:04 -0500 Subject: Apologies for Fedora-Devel-List Mishap In-Reply-To: <20061115102439.GB11319@rathann.pekin.waw.pl> References: <455A8CD8.4060701@togami.com> <20061115102439.GB11319@rathann.pekin.waw.pl> Message-ID: <200611150735.04743.jkeating@redhat.com> On Wednesday 15 November 2006 05:24, Dominik 'Rathann' Mierzejewski wrote: > That was nice and cryptic. If somebody wanted an explanation, they sure > didn't get it. Now can you please tell us what really happened and how you > intend to avoid something like that in the future? We closed down some lists: fedora-config-list fedora-patches-list fedora-tools-list The users of these lists accidentally got assigned to fedora-devel-list. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dragoran at feuerpokemon.de Wed Nov 15 12:47:04 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 15 Nov 2006 13:47:04 +0100 Subject: rawhide report: 20061115 changes In-Reply-To: <200611151124.kAFBO2Zg026121@hs20-bc2-6.build.redhat.com> References: <200611151124.kAFBO2Zg026121@hs20-bc2-6.build.redhat.com> Message-ID: <455B0C48.5060605@feuerpokemon.de> buildsys at redhat.com wrote: > > nautilus-2.16.2-6.fc7 > --------------------- > * Tue Nov 14 2006 Matthias Clasen - 2.16.2-6 > - Detect tracker dynamically, too > > what happens when tracker and beagle are installed and running? which one will nautilus use? From janina at rednote.net Wed Nov 15 14:51:03 2006 From: janina at rednote.net (Janina Sajka) Date: Wed, 15 Nov 2006 09:51:03 -0500 Subject: Firefox 3 In-Reply-To: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> Message-ID: <20061115145103.GQ30057@rednote.net> MATSUURA Takanori writes: > Hi all, > > I put firefox-trunk SRPM based on current fedora rawhide one at > http://homepage2.nifty.com/t-matsuu/install-memo/fc/ Wonderful! Thank you. Janina > > Notice: this package breaks the dependency against devhelp and yelp. > > Janina Sajka wrote: > >Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere > >near ready for prime time, but I have a compelling reason to start using > >ff3 fairly soon and would rather install from rpm, of course. > > > >BTW: My compelling reason is that FF3 will contain a11y support that > >should prove superior to any yet seen on any platform. Fingers crossed, > >etc ... > > > MATSUURA Takanori > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From ajackson at redhat.com Wed Nov 15 14:49:06 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 15 Nov 2006 09:49:06 -0500 Subject: X in FC7 In-Reply-To: <455A2799.6010807@argo.co.il> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> Message-ID: <455B28E2.4000701@redhat.com> Avi Kivity wrote: > Adam Jackson wrote: >> >> As said on the wiki page, what problem is xfs trying to solve? If >> it's just about the ability to add fonts at runtime without having to >> do 'xset fp rehash', then that should be a very small amount of code >> to add to the X server. You need to watch for directories popping in >> and out of existance, but, okay, we know how to do that. > > Wasn't the X font server designed for storageless X terminals? > > You'd just point the X server at the font server, and get the fonts you > need, without needing to replace the terminal's ROM. Sure, but that doesn't explain why we use it for local font access. Just to clarify, the font server will still be packaged and available, it just won't be used by default by the local X server. If you're building a diskless workstation out of Fedora you would probably be equally well served to just put the fonts on /usr on NFS anyway. - ajax From sundaram at fedoraproject.org Wed Nov 15 15:05:57 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Nov 2006 20:35:57 +0530 Subject: Apologies for Fedora-Devel-List Mishap In-Reply-To: <200611150735.04743.jkeating@redhat.com> References: <455A8CD8.4060701@togami.com> <20061115102439.GB11319@rathann.pekin.waw.pl> <200611150735.04743.jkeating@redhat.com> Message-ID: <455B2CD5.9060104@fedoraproject.org> Jesse Keating wrote: > On Wednesday 15 November 2006 05:24, Dominik 'Rathann' Mierzejewski wrote: >> That was nice and cryptic. If somebody wanted an explanation, they sure >> didn't get it. Now can you please tell us what really happened and how you >> intend to avoid something like that in the future? > > We closed down some lists: > > fedora-config-list > fedora-patches-list > fedora-tools-list > > The users of these lists accidentally got assigned to fedora-devel-list. Ah ok. I think the IT team misunderstood the mail I send to them to close down these unused lists and redirect users to fedora-devel list. I guess I should have been more explicit that I merely wanted a announcement and a notice to future subscribers to discuss things in fedora-devel list and not a mass resubscription. Rahul From mclasen at redhat.com Wed Nov 15 15:22:25 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 15 Nov 2006 10:22:25 -0500 Subject: rawhide report: 20061115 changes In-Reply-To: <455B0C48.5060605@feuerpokemon.de> References: <200611151124.kAFBO2Zg026121@hs20-bc2-6.build.redhat.com> <455B0C48.5060605@feuerpokemon.de> Message-ID: <1163604145.13021.4.camel@golem.boston.devel.redhat.com> On Wed, 2006-11-15 at 13:47 +0100, dragoran wrote: > buildsys at redhat.com wrote: > > > > nautilus-2.16.2-6.fc7 > > --------------------- > > * Tue Nov 14 2006 Matthias Clasen - 2.16.2-6 > > - Detect tracker dynamically, too > > > > > what happens when tracker and beagle are installed and running? > which one will nautilus use? > NautilusSearchEngine * nautilus_search_engine_new (void) { NautilusSearchEngine *engine; #ifdef HAVE_TRACKER engine = nautilus_search_engine_tracker_new (); if (engine) { return engine; } #endif #ifdef HAVE_BEAGLE engine = nautilus_search_engine_beagle_new (); if (engine) { return engine; } #endif engine = nautilus_search_engine_simple_new (); return engine; } So I assume it will prefer tracker, as long as it is installed. From my experiments, it looks like libtracker actually starts trackerd on demand, so you'll have to uninstall tracker to get back to beagle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at mesa.nl Wed Nov 15 21:48:41 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Wed, 15 Nov 2006 22:48:41 +0100 Subject: AT_SPI_REGISTRY In-Reply-To: <1163205176.32462.13.camel@soulcrusher.caolan.org> References: <20061110234829.GB21277@joshua.mesa.nl> <1163205176.32462.13.camel@soulcrusher.caolan.org> Message-ID: <20061115214841.GK11614@joshua.mesa.nl> On Sat, Nov 11, 2006 at 12:31:50AM +0000, Caolan McNamara wrote: > On Sat, 2006-11-11 at 00:48 +0100, Marcel J.E. Mol wrote: > > After installing rawhide(-extras) x86-64 on my laptop I get the following > > when starting gnumeric: > > > > > > % gnumeric > > > > Bonobo accessibility support initialized > > GTK Accessibility Module initialized > > > Yeah, something has one horribly wrong with rawhide a11y, probably > temporary. In the the meantime, something like > > > gconftool-2 -s "/desktop/gnome/interface/accessibility" false --type > bool > > unset GTK_MODULES > > might get you running gnome stuff without a11y enabled. Yes that does the job too. -Marcel From mike at miketc.com Wed Nov 15 22:48:35 2006 From: mike at miketc.com (Mike Chambers) Date: Wed, 15 Nov 2006 16:48:35 -0600 Subject: Firefox 3 In-Reply-To: <6f27515e0611150352s7ca05087l544ade135723af24@mail.gmail.com> References: <6f27515e0611150352s7ca05087l544ade135723af24@mail.gmail.com> Message-ID: <1163630915.15283.4.camel@scrappy.miketc.com> On Wed, 2006-11-15 at 20:52 +0900, MATSUURA Takanori wrote: > I'm using it as a default browser on my Fedora Core box. > Java, Flash, and AdobeReader plugins and some Add-ons I installed work fine. > > Basically I have no trouble with the trunk builds. But it is not > always "stable" because it is the "trunk build" that is in the > development process. So please use it at your own risk. > > 2006/11/14, Mike Chambers wrote: > > How stable is this version anyway? Are or you using it? I had a build error, during IMG_decoders or something, and it failed. Don't know how far into it that it was building, but it had gone a while before it finally errored. Guess you don't have an actual binary rpm for a rawhide system? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From jonesc at hep.phy.cam.ac.uk Wed Nov 15 23:54:13 2006 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Wed, 15 Nov 2006 23:54:13 +0000 Subject: compiz unresponsoive under heavy load Message-ID: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> Hi, I'm running compiz just fine on my FC6 system. However, I have noticed that under load (such as running make, yum update, my email client running a mail check or just my web browser running a heavy site) compiz becomes very unresponsive and thus also the desktop. I've also noticed that if I run the cpu heavy app. at an increased nice value, such as +15, compiz remains completely responsive whilst the apps runs pretty much at its usual speed. Unfortunately, its not easy to run everything at an increased nice value, so I wonder therefore, if it wouldn't be a good idea to something to run compiz (and Xorg or whatever it needs) at increased scheduling priority by default, to make use the user desktop always remains responsive ? cheers Chris From steve at silug.org Thu Nov 16 02:03:06 2006 From: steve at silug.org (Steven Pritchard) Date: Wed, 15 Nov 2006 20:03:06 -0600 Subject: X in FC7 In-Reply-To: <455B28E2.4000701@redhat.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455B28E2.4000701@redhat.com> Message-ID: <20061116020306.GA10309@osiris.silug.org> On Wed, Nov 15, 2006 at 09:49:06AM -0500, Adam Jackson wrote: > Sure, but that doesn't explain why we use it for local font access. Old (386/486-era) systems with no FPU would seem to hang for seconds at a time while the X server rendered fonts. Even on systems with an FPU, using the font server made X *much* more responsive/smooth. I know most people probably don't remember those days, but surely there are still smaller systems that benefit greatly from the font server... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From dominik at greysector.net Thu Nov 16 02:10:01 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 16 Nov 2006 03:10:01 +0100 Subject: Apologies for Fedora-Devel-List Mishap In-Reply-To: <455B2CD5.9060104@fedoraproject.org> References: <455A8CD8.4060701@togami.com> <20061115102439.GB11319@rathann.pekin.waw.pl> <200611150735.04743.jkeating@redhat.com> <455B2CD5.9060104@fedoraproject.org> Message-ID: <20061116021000.GA5145@rathann.pekin.waw.pl> On Wednesday, 15 November 2006 at 16:05, Rahul Sundaram wrote: > Jesse Keating wrote: > >On Wednesday 15 November 2006 05:24, Dominik 'Rathann' Mierzejewski wrote: > >>That was nice and cryptic. If somebody wanted an explanation, they sure > >>didn't get it. Now can you please tell us what really happened and how you > >>intend to avoid something like that in the future? > > > >We closed down some lists: > > > >fedora-config-list > >fedora-patches-list > >fedora-tools-list > > > >The users of these lists accidentally got assigned to fedora-devel-list. > > Ah ok. I think the IT team misunderstood the mail I send to them to > close down these unused lists and redirect users to fedora-devel list. I > guess I should have been more explicit that I merely wanted a > announcement and a notice to future subscribers to discuss things in > fedora-devel list and not a mass resubscription. Thank you both. Now it is clear. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From david at lovesunix.net Thu Nov 16 03:49:32 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 16 Nov 2006 04:49:32 +0100 Subject: Proposal - replace beagle with tracker In-Reply-To: <1163283737.9312.32.camel@cutter> References: <4554AEB3.8010701@redhat.com> <6280325c0611101822l14589953p638ad89503f48811@mail.gmail.com> <4556413E.8050406@redhat.com> <1163283737.9312.32.camel@cutter> Message-ID: <1163648972.2889.76.camel@dawkins> l?r, 11 11 2006 kl. 17:22 -0500, skrev seth vidal: > On Sat, 2006-11-11 at 16:31 -0500, Christopher Aillon wrote: > > n0dalus wrote: > > > On 11/11/06, Christopher Aillon wrote: > > >> > > >> Tracker has been proposed[1] to be included into GNOME and has been > > >> rejected for various reasons. See the thread for full details, but > > >> Joe's reply[2] lists some good reasons to not include tracker at this > > >> time. > > >> > > >> [1]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html > > >> > > >> [2]http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00211.html > > >> > > >> > > > > > > His main complaint seems to be that tracker hasn't had a lot of > > > testing. Maybe Fedora can help in that respect by putting it in devel > > > and getting the community using it. > > > > > > n0dalus. > > > > > > > There are also problems with the code quality, or lack thereof. It's > > dissected somewhere else in the thread. > > If we're not going to let packages in based on code quality "standards" > then we're going to be kicking out a lot packages I think. Okay, the lead developer Jamie McCracken has kindly offered to answer questions regarding Tracker. So ask your questions and get the answer straight from the horses mouth. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From j.rink at freenet.de Thu Nov 16 06:51:20 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Thu, 16 Nov 2006 07:51:20 +0100 Subject: compiz unresponsoive under heavy load In-Reply-To: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> References: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> Message-ID: <20061116075120.a60f08ad.j.rink@freenet.de> Am Wed, 15 Nov 2006 23:54:13 +0000 hat Chris Jones (Chris Jones) folgendes geschrieben: Hi, > Hi, > > I'm running compiz just fine on my FC6 system. However, I have > noticed that under load (such as running make, yum update, my email > client running a mail check or just my web browser running a heavy > site) compiz becomes very unresponsive and thus also the desktop. Same here, when i use sylpheed, i register hanging situations. I have the latest nvidia lvna driver, latest updates and a nforce 2 with barton mobile cpu. On the other hand, when i use googleearth here, no hanging. I think compiz has problems with high io on ide. -- Nine (not 9) Never trust a hippie From dwmw2 at infradead.org Thu Nov 16 07:19:58 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 16 Nov 2006 15:19:58 +0800 Subject: GPL2 Java? In-Reply-To: <45599F77.6080805@fedoraproject.org> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> Message-ID: <1163661598.21366.120.camel@shinybook.infradead.org> On Tue, 2006-11-14 at 16:20 +0530, Rahul Sundaram wrote: > David Woodhouse wrote: > > On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: > >> +1 Include Sun JDK in Fedora > > > > Does Sun JDK build for PowerPC? > > Nope but its potentially possible now. Of course, if Fedora wants to paint itself into a corner as an x86{,64}-only niche distribution, it could just switch to Sun JDK without caring about such issues.... but that's a different discussion :) -- dwmw2 From nicolas.mailhot at laposte.net Thu Nov 16 08:26:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 16 Nov 2006 09:26:46 +0100 (CET) Subject: X in FC7 In-Reply-To: <20061116020306.GA10309@osiris.silug.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455B28E2.4000701@redhat.com> <20061116020306.GA10309@osiris.silug.org> Message-ID: <51813.192.54.193.51.1163665606.squirrel@rousalka.dyndns.org> Le Jeu 16 novembre 2006 03:03, Steven Pritchard a ?crit : > I know most people probably don't remember those days, but surely > there are still smaller systems that benefit greatly from the font > server... OTOH, when adopting fontconfig was discussed x-side, people argued that modern (at that time!) use patterns made server-side fonts too slow. -- Nicolas Mailhot From aph at redhat.com Thu Nov 16 09:23:14 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Nov 2006 09:23:14 +0000 Subject: GPL2 Java? In-Reply-To: <45599F77.6080805@fedoraproject.org> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> Message-ID: <17756.11778.196984.294438@zebedee.pink> Rahul Sundaram writes: > David Woodhouse wrote: > > On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: > >> +1 Include Sun JDK in Fedora > > > > Does Sun JDK build for PowerPC? > > Nope but its potentially possible now. I don't really understand this remark. "Potentially possible?" What does this mean? That we can write a Java VM for the PowerPC? But, of course, that was always true. It's not as though we needs access to the source of a VM for some other arch before we can write one. Andrew. From k.georgiou at imperial.ac.uk Thu Nov 16 10:11:22 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 16 Nov 2006 10:11:22 +0000 Subject: X in FC7 In-Reply-To: <20061116020306.GA10309@osiris.silug.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455B28E2.4000701@redhat.com> <20061116020306.GA10309@osiris.silug.org> Message-ID: <20061116101122.GA32431@imperial.ac.uk> On Wed, Nov 15, 2006 at 08:03:06PM -0600, Steven Pritchard wrote: > On Wed, Nov 15, 2006 at 09:49:06AM -0500, Adam Jackson wrote: > > Sure, but that doesn't explain why we use it for local font access. > > Old (386/486-era) systems with no FPU would seem to hang for seconds > at a time while the X server rendered fonts. Even on systems with an > FPU, using the font server made X *much* more responsive/smooth. Another reason was that the XFree86 3.x server did not support truetype fonts but xfs (with the xfsft patches) did since RH6. It was the same time that RH switched to using xfs. You can read everything in a redhat white paper[1] for more details. Kostas Georgiou [1] http://www.redhat.net/support/wpapers/redhat/newfontsystem/index.html From dwmw2 at infradead.org Thu Nov 16 11:53:40 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 16 Nov 2006 19:53:40 +0800 Subject: GPL2 Java? In-Reply-To: <17756.11778.196984.294438@zebedee.pink> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> <17756.11778.196984.294438@zebedee.pink> Message-ID: <1163678020.21366.175.camel@shinybook.infradead.org> On Thu, 2006-11-16 at 09:23 +0000, Andrew Haley wrote: > Rahul Sundaram writes: > > David Woodhouse wrote: > > > On Mon, 2006-11-13 at 11:36 -0800, Otto Rey wrote: > > >> +1 Include Sun JDK in Fedora > > > > > > Does Sun JDK build for PowerPC? > > > > Nope but its potentially possible now. > > I don't really understand this remark. "Potentially possible?" What > does this mean? That we can write a Java VM for the PowerPC? But, of > course, that was always true. It's not as though we needs access to > the source of a VM for some other arch before we can write one. And indeed we already have one. At least two, in fact -- gcj and the IBM Java (which has a firefox plugin). -- dwmw2 From buildsys at redhat.com Thu Nov 16 11:53:43 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 16 Nov 2006 06:53:43 -0500 Subject: rawhide report: 20061116 changes Message-ID: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> Updated Packages: boost-1.33.1-9 -------------- * Wed Nov 15 2006 Benjamin Kosnik 1.33.1-9 - (#154784: boost-debuginfo package is empty) * Tue Nov 14 2006 Benjamin Kosnik 1.33.1-8 - (#205866: Revert scanner.hpp change.) * Mon Nov 13 2006 Benjamin Kosnik 1.33.1-7 - (#205866: boost::spirit generates warnings with -Wshadow) - (#205863: serialization lib generates warnings) - (#204326: boost RPM missing dependencies) - (#193465: [SIGNAL/BIND] Regressions with GCC 4.1) - BUILD_FLAGS, add, to see actual compile line. - REGEX_FLAGS, add, to compile regex with ICU support. busybox-1:1.2.2-1.fc7 --------------------- * Thu Nov 16 2006 Ivana Varekova - 1:1.2.2-1 - update to 1.2.2 cairo-1.3.2-1.fc7 ----------------- * Wed Nov 15 2006 Carl Worth 1.3.2-1 - Update to 1.3.2 * Sun Nov 05 2006 Matthias Clasen 1.2.6-1 - Update to 1.2.6 * Sun Aug 20 2006 Behdad Esfahbod 1.2.4-1 - Update to 1.2.4 - Drop libXt-devel BuildReq as it shouldn't need it anymore. compiz-0.3.2-2.fc7 ------------------ * Wed Nov 15 2006 Matthias Clasen - 0.3.2-2 - Use cow by default, bug 208044 gaim-2:2.0.0-0.20.beta4.fc7 --------------------------- * Wed Nov 15 2006 Warren Togami - 2:2.0.0-0.20.beta4 - #215704 Revert Yahoo protocol version identifier gdb-6.5-16.fc7 -------------- * Thu Nov 16 2006 Jan Kratochvil - 6.5-16 - Provide testcase for accessing the last address space byte. gnome-games-1:2.17.2-3.fc7 -------------------------- * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 - Add Provides/Obsoletes for gnuchess (#215110) irqbalance-1:1.13-8.fc7 ----------------------- * Wed Nov 15 2006 Neil Horman - 1.13-8 - Add ability to set default affinity mask (bz 211148) kdepim-6:3.5.5-0.2.fc6 ---------------------- * Fri Nov 10 2006 Than Ngo 6:3.5.5-0.2.fc6 - apply upstream patch to fix bz#215081 (kde#135513) libc-client-2004g-3 ------------------- * Wed Nov 15 2006 Joe Orton 2004g-3 - rebuild to fix debuginfo (#205339) libidn-0.6.8-4 -------------- * Wed Nov 15 2006 Joe Orton 0.6.8-4 - use non-GNU section in info directory (#209491) * Wed Nov 15 2006 Joe Orton 0.6.8-3 - update to 0.6.8 mlocate-0.15-1 -------------- * Thu Nov 16 2006 Miloslav Trmac - 0.15-1 - Update to mlocate-0.15 Resolves: #215763 nautilus-sendto-0.8-3.fc7 ------------------------- * Wed Nov 15 2006 Matthias Clasen - 0.8-3 - Rebuild against new libbtctl newt-perl-1.08-10 ----------------- * Wed Nov 15 2006 Joe Orton 1.08-10 - fix compiler warnings (#155977) nfs-utils-1:1.0.10-3.fc7 ------------------------ * Wed Nov 15 2006 Steve Dickson 1.0.10-3 - Removed some old mounting versioning code that was stopping tcp mount from working (bz 212471) * Tue Oct 31 2006 Steve Dickson 1.0.10-2 - Fixed -o remount (bz 210346) - fix memory leak in rpc.idmapd (bz 212547) - fix use after free bug in dirscancb (bz 212547) - Made no_subtree_check a default export option (bz 212218) * Wed Oct 25 2006 Steve Dickson 1.0.10-1 - Upgraded to 1.0.10 openldap-2.3.30-1.fc7 --------------------- * Wed Nov 15 2006 Jay Fenlason 2.3.30-1.fc7 - New upstream version php-5.2.0-4 ----------- * Wed Nov 15 2006 Joe Orton 5.2.0-4 - provide php-zend-abi (#212804) - add /etc/rpm/macros.php exporting interface versions - synch with upstream recommended php.ini * Wed Nov 15 2006 Joe Orton 5.2.0-3 - update to 5.2.0 (#213837) - php-xml provides php-domxml (#215656) - fix php-pdo-abi provide (#214281) policycoreutils-1.33.1-6 ------------------------ * Wed Nov 15 2006 Dan Walsh 1.33.1-6 - More fixes to gui * Wed Nov 15 2006 Dan Walsh 1.33.1-5 - Fix audit2allow to generate referene policy * Wed Nov 15 2006 Dan Walsh 1.33.1-4 - Add group sort for portsPage.py - Add enable/disableaudit to modules page screen-4.0.3-1.fc7 ------------------ * Sun Oct 15 2006 Marcela Maslanova - 4.0.3-1 - new version from upstream - ipv6 patch #198410 * Wed Aug 16 2006 Jesse Keating - 4.0.2-16 - Don't use %makeinstall, instead make install. - Change DDESTDIR to DESTDIR to do the right thing. - Comment out utf patch as it is no longer necessary. - Add dist tag - Change PreReq to correct Requires(pre), Requires(post), Requires(preun) - Don't use RPM_SOURCE_DIR, reference the source file directly - Do the compiling (make) in %build, not %install - Don't replace /etc/screenrc if the user has modified it - Ditto /etc/pam.d/screen - Change the buildroot to follow guidelines selinux-policy-2.4.4-2 ---------------------- * Wed Nov 15 2006 Dan Walsh 2.4.4-2 - Fixes for nvidia driver * Tue Nov 14 2006 Dan Walsh 2.4.4-2 - Allow semanage to signal mcstrans * Tue Nov 14 2006 Dan Walsh 2.4.4-1 - Update to upstream system-config-network-1.3.96-1.fc6 ---------------------------------- * Thu Nov 02 2006 Harald Hoyer - 1.3.96 - Resolves: rhbz #211980, rhbz #213181 * Wed Oct 04 2006 Harald Hoyer - 1.3.95 - translation update (bug #208886) - use rhpl.iwlib for wireless functions (bug #197954) - added perl-XML-Parser build requirement * Tue Aug 15 2006 Harald Hoyer - 1.3.94 - translation update (bug #182650) totem-2.17.3-1.fc7 ------------------ * Wed Nov 15 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 vnc-4.1.2-6.fc7 --------------- * Tue Nov 14 2006 Adam Tkac 4.1.2-6.fc7 - update to xorg-x11-server to version 1.1.1 - fixed OpenGL extensions (#213215) - fixed vnc-188169.patch (#213609) - fixed RENDER problems (#162304) - build requires libstdc++-devel and gcc-c++, autoconf213 and libselinux-devel * Wed Oct 25 2006 Adam Tkac 4.1.2-5 - added xorg-x11-fonts-base dependency - fixed vncconfig crash on x64 (#179635) * Tue Oct 17 2006 Adam Tkac 4.1.2-4 - IPv6 support to vncviewer has been added (#210617) - fixed conflict between "locate pointer" option in control-center and vncviewer (#188169) - fixed software group of vnc (#209229) - added support to get password from stdin (#102434) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From ch.nolte at fh-wolfenbuettel.de Thu Nov 16 12:34:40 2006 From: ch.nolte at fh-wolfenbuettel.de (Christian Nolte) Date: Thu, 16 Nov 2006 13:34:40 +0100 Subject: compiz unresponsoive under heavy load In-Reply-To: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> References: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> Message-ID: <455C5AE0.9060208@fh-wolfenbuettel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris! Chris Jones schrieb: > Hi, > > I'm running compiz just fine on my FC6 system. However, I have noticed that > under load (such as running make, yum update, my email client running a mail > check or just my web browser running a heavy site) compiz becomes very > unresponsive and thus also the desktop. > > I've also noticed that if I run the cpu heavy app. at an increased nice value, > such as +15, compiz remains completely responsive whilst the apps runs pretty > much at its usual speed. > > Unfortunately, its not easy to run everything at an increased nice value, so I > wonder therefore, if it wouldn't be a good idea to something to run compiz > (and Xorg or whatever it needs) at increased scheduling priority by default, > to make use the user desktop always remains responsive ? > > cheers Chris > Perhaps the information from this thread solves the unresponsiveness for you: http://www.redhat.com/archives/fedora-list/2006-October/msg03990.html http://www.redhat.com/archives/fedora-list/2006-November/msg00034.html Best regards! Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFXFrgCNjA0nfhW7wRAtZ+AJ9/UW1yKoqWBTNtNmhgMhCbocPa5gCeKzur gDGPRifJNz1wuRxRau2uMJY= =RE8J -----END PGP SIGNATURE----- From mharris at mharris.ca Thu Nov 16 13:47:37 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Nov 2006 08:47:37 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <200611021008.27113.jkeating@redhat.com> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> <200611021008.27113.jkeating@redhat.com> Message-ID: <455C6BF9.6000908@mharris.ca> Jesse Keating wrote: > On Thursday 02 November 2006 10:03, Arjan van de Ven wrote: >> are the src.rpm's also available somewhere? (you know, that open source >> thing ;) Also, are there plans to make expanded trees available? I tend >> to use those a lot more than isos.... > > The same srpms are used as the shipped FC6 ones. Unified srpms. Isn't the distributor of the binary rpms also the one responsible for distributing the source rpms? That's my understanding of the GPL, even if they are identical to ones shipped on the official Fedora sites. From mharris at mharris.ca Thu Nov 16 13:50:43 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Nov 2006 08:50:43 -0500 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <455C6BF9.6000908@mharris.ca> References: <454A0679.3080505@redhat.com> <1162479788.14530.43.camel@laptopd505.fenrus.org> <200611021008.27113.jkeating@redhat.com> <455C6BF9.6000908@mharris.ca> Message-ID: <455C6CB3.7070002@mharris.ca> Mike A. Harris wrote: > Jesse Keating wrote: >> On Thursday 02 November 2006 10:03, Arjan van de Ven wrote: >>> are the src.rpm's also available somewhere? (you know, that open source >>> thing ;) Also, are there plans to make expanded trees available? I tend >>> to use those a lot more than isos.... >> >> The same srpms are used as the shipped FC6 ones. Unified srpms. > > Isn't the distributor of the binary rpms also the one responsible for > distributing the source rpms? That's my understanding of the GPL, even > if they are identical to ones shipped on the official Fedora sites. Ugh.. my mailer had things sorted in non-date order and I didn't notice the date on this thread was old. Others already stated what I said, etc. Sorry for the noise... From mharris at mharris.ca Thu Nov 16 14:08:34 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Nov 2006 09:08:34 -0500 Subject: X in FC7 In-Reply-To: <20061111171950.62af0203@nausicaa.camperquake.de> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <20061111042704.GA847601@hiwaay.net> <20061111171950.62af0203@nausicaa.camperquake.de> Message-ID: <455C70E2.1040207@mharris.ca> Ralf Ertzinger wrote: > Hi. > > Chris Adams wrote: > >> There's only one xterm as well; for example, nobody else has Tek4014 >> emulation (useful for legacy apps). Also, xterm is lighter weight than >> gnome-terminal. > > And it works, which is more than could be said about gnome-terminal for > quite some time (I asmit that I do not know the current state of vte, > for lack of interest). I'd agree with that assessment, although I do prefer more advanced terminal emulation app than what xterm provides, so I use konsole (even when using GNOME). gnome-term could take some lessons from konsole IMHO, although konsole's pulldown menu structure and overall option UIs could use work. IMHO, konsole is the most functional and bug-free terminal, at least so far as my own usage cases. From mharris at mharris.ca Thu Nov 16 14:20:01 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Nov 2006 09:20:01 -0500 Subject: X in FC7 In-Reply-To: <455A2799.6010807@argo.co.il> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> Message-ID: <455C7391.3010605@mharris.ca> Avi Kivity wrote: > Adam Jackson wrote: >> >> As said on the wiki page, what problem is xfs trying to solve? If >> it's just about the ability to add fonts at runtime without having to >> do 'xset fp rehash', then that should be a very small amount of code >> to add to the X server. You need to watch for directories popping in >> and out of existance, but, okay, we know how to do that. > > Wasn't the X font server designed for storageless X terminals? Was that before or after NFS, Coda, SMB, and numerous other networked filesystems, etc. existed? ;o) Seriously, there are arguments for and against keeping/removing xfs, and I have some mixed feelings myself, but "diskless terminals" seems like a bad reason to keep xfs. I think Adam is on the right track about this personally. xfs was created to solve certain specific problems, and it was included and used by default in Red Hat Linux and derivatives for reasons Owen Taylor mentioned previously, however it doesn't hurt to keep re-evaluating which of the problems xfs addresses are still relevant, and to see whether or not they can be solved using other pre-existing methods, or to see what would be involved to implement desired functionality with a more modern approach. My personal feelings on xfs in Fedora Core, are that in an ideal world, it would be nice to get rid of xfs and use alternative methods to provide whatever functionality to users that xfs currently provides - however, that wont come free of cost, and someone needs to weigh the ups and downs of various potential solutions, and then decide whether or not any gains received by getting rid of xfs are worth the manpower, etc. that would need to be invested into doing so. IMHO it wouldn't make a lot of good sense to allocate limited resources to replacing xfs with something else, just to end up with solutions that do what xfs is already doing right now, unless there are other major gains that it provides on top of that which make it an overall worthwhile investment of time. > You'd just point the X server at the font server, and get the fonts you > need, without needing to replace the terminal's ROM. Or you could just mount the font directories over NFS to the diskless workstation. From selinux at gmail.com Thu Nov 16 15:02:14 2006 From: selinux at gmail.com (Tom London) Date: Thu, 16 Nov 2006 07:02:14 -0800 Subject: rawhide report: 20061116 changes In-Reply-To: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530611160702s351fa69ak217310e1e8f88ef8@mail.gmail.com> > compiz-0.3.2-2.fc7 > ------------------ > * Wed Nov 15 2006 Matthias Clasen - 0.3.2-2 > - Use cow by default, bug 208044 > This fixes some problems I had with previous version and my Thinkpad x60. But this version seems to have 'floating minimize/maximize/close' buttons on the window decorations. (This buttons seem to move around a bit in the decoration bar after various windows have been selected/raised/lowered/etc.) Anyone seeing this? Just me? tom -- Tom London From ajackson at redhat.com Thu Nov 16 15:46:45 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 16 Nov 2006 10:46:45 -0500 Subject: X in FC7 In-Reply-To: <20061116020306.GA10309@osiris.silug.org> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455B28E2.4000701@redhat.com> <20061116020306.GA10309@osiris.silug.org> Message-ID: <455C87E5.9040902@redhat.com> Steven Pritchard wrote: > On Wed, Nov 15, 2006 at 09:49:06AM -0500, Adam Jackson wrote: >> Sure, but that doesn't explain why we use it for local font access. > > Old (386/486-era) systems with no FPU would seem to hang for seconds > at a time while the X server rendered fonts. Even on systems with an > FPU, using the font server made X *much* more responsive/smooth. Numbers would be a fantastic thing to introduce to the discussion here, if anyone has them. I'm generally not fond of handwavey performance decisions in the name of low-end machines without some proof. I can personally attest that at least for the OLPC machine, which has a pretty crippled FPU, the performance problem for font rendering appeared to be the rendering itself, and not so much font load and metric time. But I don't have numbers immediately at hand to back that up. (And OLPC ended up dropping xfs for footprint reasons anyway.) - ajax From avi at argo.co.il Thu Nov 16 16:10:02 2006 From: avi at argo.co.il (Avi Kivity) Date: Thu, 16 Nov 2006 18:10:02 +0200 Subject: X in FC7 In-Reply-To: <455C7391.3010605@mharris.ca> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455C7391.3010605@mharris.ca> Message-ID: <455C8D5A.4010807@argo.co.il> Mike A. Harris wrote: > Avi Kivity wrote: >> Adam Jackson wrote: >>> >>> As said on the wiki page, what problem is xfs trying to solve? If >>> it's just about the ability to add fonts at runtime without having >>> to do 'xset fp rehash', then that should be a very small amount of >>> code to add to the X server. You need to watch for directories >>> popping in and out of existance, but, okay, we know how to do that. >> >> Wasn't the X font server designed for storageless X terminals? > > Was that before or after NFS, Coda, SMB, and numerous other networked > filesystems, etc. existed? ;o) > > Seriously, there are arguments for and against keeping/removing xfs, > and I have some mixed feelings myself, but "diskless terminals" seems > like a bad reason to keep xfs. > I'm not arguing that xfs should be kept for those NCD (sp?) terminals; just that xfs seems oriented towards those setups. Certainly, modern X terminals are usually Linux X servers and as such can easily mount any needed font. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From vismor.td at gmail.com Thu Nov 16 16:20:26 2006 From: vismor.td at gmail.com (Timothy Vismor) Date: Thu, 16 Nov 2006 11:20:26 -0500 Subject: rawhide report: 20061116 changes In-Reply-To: <4c4ba1530611160702s351fa69ak217310e1e8f88ef8@mail.gmail.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <4c4ba1530611160702s351fa69ak217310e1e8f88ef8@mail.gmail.com> Message-ID: <7946769f0611160820u35487315t77277a1efb82caf4@mail.gmail.com> Yes, I saw this in 3.2 (Thinkpad T43). The problem appears to be fixed in git. I downloaded a snapshot of git yesterday, rebuilt the rpms from the new snapshot, and the problem is gone (modifications to 3.2 redhat patches were necessary). On 11/16/06, Tom London wrote: > > > compiz-0.3.2-2.fc7 > > ------------------ > > * Wed Nov 15 2006 Matthias Clasen - 0.3.2-2 > > - Use cow by default, bug 208044 > > > This fixes some problems I had with previous version and my Thinkpad x60. > > But this version seems to have 'floating minimize/maximize/close' > buttons on the window decorations. (This buttons seem to move around a > bit in the decoration bar after various windows have been > selected/raised/lowered/etc.) > > Anyone seeing this? Just me? > > tom > -- > Tom London > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonesc at hep.phy.cam.ac.uk Thu Nov 16 18:14:10 2006 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Thu, 16 Nov 2006 18:14:10 +0000 Subject: compiz unresponsoive under heavy load In-Reply-To: <455C5AE0.9060208@fh-wolfenbuettel.de> References: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> <455C5AE0.9060208@fh-wolfenbuettel.de> Message-ID: <200611161814.10666.jonesc@hep.phy.cam.ac.uk> > > http://www.redhat.com/archives/fedora-list/2006-October/msg03990.html > http://www.redhat.com/archives/fedora-list/2006-November/msg00034.html Thanks. I thought I had search this list for info, but clearly not well enough as I didn't find that. I'll give what you suggest a shot. Chris > > Best regards! > Christian From j.w.r.degoede at hhs.nl Thu Nov 16 19:37:27 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Nov 2006 20:37:27 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> Message-ID: <455CBDF7.8040109@hhs.nl> > gnome-games-1:2.17.2-3.fc7 > -------------------------- > * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 > - Add Provides/Obsoletes for gnuchess (#215110) > Does this mean gnuchess has been absorbed into gnome-games now? Ifso will this impact other gnuchess frontends, as there are are a few in FE? Any chance gnuchess could be put in a subpackage gnome-games-gnuchess, so that people who only need gnuchess don't need to install all of gnome-games? Regards, Hans From j.w.r.degoede at hhs.nl Thu Nov 16 20:14:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Nov 2006 21:14:32 +0100 Subject: Progress reports of my students fixing bugs Message-ID: <455CC6A8.5060400@hhs.nl> Hi all, About a week ago I announced I wanted some relatively easy to fix bugs to use in a lab lesson for students to teach them / let them practice with systematical fault searching. Many thanks to those who posted bugs, although I did find the response a bit lacking. Since I want to continue with these lessons next week and need a few new bug here is a progress report on the bugs which I gave to my students: --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206873 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206874 Problem found and fix-patch attached to bug --- http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214745 Really 2 bugs, first ImageMagick creates a corrupt .ico and then it crashes reading it, debugging the crash reading it is in progress and I expect the students to come up with a fix next week. --- | -- CMakeLists.txt -- | include(foo.cmake) | foo() | | -- foo.cmake -- | macro(foo) | message(SEND_ERROR "foo") | endmacro(foo) | | $ cmake CMakeLists.txt | ... | Segmentation fault (core dumped) In progress, the segfault happens because the code tries to access element 0 / [0] of an empty STL vector, why its empty is not clear though. --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213212 This is really many bugs with mc ftpfs after the ipv6 support patch, my students have pinpointed the problems with passive ipv4 connections and also have figured out how to fix it, I expect them to write a fix for the passive problem this wednesday. --- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203336 Torcs segfaults after a short while when using "openal" for the sound, but not when using "plib". I just tried in 1.3.0 and there is still the same problem... either it's in torcs itself (which BTW exits when /dev/dsp is busy, not very user friendly!) or in openal, dunno. My Students failed to reproduce this on FC-6 and have requested the reporter to try to see if he can reproduce it. --- So as you can see my students are doing good work, and I / they need more relatively easy bugs to keep up there good work! So please send me more bugs. I need bugs (do I?) :) Regards, Hans From katzj at redhat.com Thu Nov 16 20:18:43 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Nov 2006 15:18:43 -0500 Subject: rawhide report: 20061116 changes In-Reply-To: <455CBDF7.8040109@hhs.nl> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> Message-ID: <1163708323.4032.14.camel@orodruin.boston.redhat.com> On Thu, 2006-11-16 at 20:37 +0100, Hans de Goede wrote: > > gnome-games-1:2.17.2-3.fc7 > > -------------------------- > > * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 > > - Add Provides/Obsoletes for gnuchess (#215110) > > > > Does this mean gnuchess has been absorbed into gnome-games now? > > Ifso will this impact other gnuchess frontends, as there are are a few > in FE? > > Any chance gnuchess could be put in a subpackage gnome-games-gnuchess, > so that people who only need gnuchess don't need to install all of > gnome-games? Or more preferably (IMHO), have gnome-games require gnuchess instead of trying to suck it up. gnuchess has its own upstream; gnome-games isn't it Jeremy From mihamina.rakotomandimby at etu.univ-orleans.fr Thu Nov 16 20:40:38 2006 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Mihamina Rakotomandimby) Date: Thu, 16 Nov 2006 21:40:38 +0100 Subject: howto package kernel-like Message-ID: <1163709638.4844.43.camel@r4000> Hi, I would like to make a package behaving like the kernel: When a new version is available, it installs near the old version, but it does not replace the old version. Has that kind of package a special name? What keyword or special mentions have I got to place in the spec file to get this behaviour? Of course, the install name/directory will be different as of the versions. Thank you. From rdieter at math.unl.edu Thu Nov 16 20:48:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 16 Nov 2006 14:48:53 -0600 Subject: howto package kernel-like References: <1163709638.4844.43.camel@r4000> Message-ID: Mihamina Rakotomandimby wrote: > Hi, > I would like to make a package behaving like the kernel: > When a new version is available, it installs near the old version, but > it does not replace the old version. Easy, 1. don't do it. or 2. For each new "version" use a new/different Name: -- Rex From mattdm at mattdm.org Thu Nov 16 20:49:43 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 16 Nov 2006 15:49:43 -0500 Subject: howto package kernel-like In-Reply-To: <1163709638.4844.43.camel@r4000> References: <1163709638.4844.43.camel@r4000> Message-ID: <20061116204943.GA26540@jadzia.bu.edu> On Thu, Nov 16, 2006 at 09:40:38PM +0100, Mihamina Rakotomandimby wrote: > I would like to make a package behaving like the kernel: > When a new version is available, it installs near the old version, but > it does not replace the old version. > Has that kind of package a special name? What keyword or special > mentions have I got to place in the spec file to get this behaviour? > Of course, the install name/directory will be different as of the > versions. Only one thing is special about the package -- the as you note, new version must contain nothing that conflicts with the old version. (To avoid such conflicts, any shared files must be exactly identical.) Other than that, the magic is done via a yum configuration option. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From zaitcev at redhat.com Thu Nov 16 22:04:22 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 16 Nov 2006 14:04:22 -0800 Subject: GPL2 Java? In-Reply-To: <17756.11778.196984.294438@zebedee.pink> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> <17756.11778.196984.294438@zebedee.pink> Message-ID: <20061116140422.c186390e.zaitcev@redhat.com> On Thu, 16 Nov 2006 09:23:14 +0000, Andrew Haley wrote: > > > Does Sun JDK build for PowerPC? > > > > Nope but its potentially possible now. > > I don't really understand this remark. "Potentially possible?" What > does this mean? That we can write a Java VM for the PowerPC? But, of > course, that was always true. It's not as though we needs access to > the source of a VM for some other arch before we can write one. So, if "we" "can" write one, why haven't we? I don't understand what your point is. Are you, personally, going to package JDK for PPC? Are you stenously object to someone else packaging JDK for PPC? If neither, what are you wasting the bandwidth about? So Rahul's wording was not perfect, big deal! By the way, surely you know that VMs are dime a dozen, and the libraries are the real problem. I am quite happy with my gcj and Classpath, which execute my critical Java applications today, but there are still people out there would would benefit from (compatibility with) all bugs in Sun JDK libraries. -- Pete From m.f.h at web.de Thu Nov 16 22:18:22 2006 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 16 Nov 2006 23:18:22 +0100 Subject: Scanning with XSANE not more working Message-ID: <455CE3AE.3060602@web.de> Hallo! What has been changed since FC5 (rawhide) and FC6 that I can not more use xsane to scan with my bearpaw ta1200 usb scanner? I've nothing changed... sane-find-scanner says: found USB scanner (vendor=0x055f, product=0x0212, chip=GT-6816?) at libusb:004:002 I've checked the configs from sane and see no changes. "Strace xsane" tells something about missing /dev/scanner and I made manually a link to the usb device. No success. xsane tells me: no devices found? :-( Regards, Marcus -- www.marcush.de From jkeating at redhat.com Thu Nov 16 22:46:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 17:46:41 -0500 Subject: bluez-pin In-Reply-To: <1162650195.5876.252.camel@shinybook.infradead.org> References: <20061104134349.GA14286@dudweiler.stuttgart.redhat.com> <1162650195.5876.252.camel@shinybook.infradead.org> Message-ID: <200611161746.41884.jkeating@redhat.com> On Saturday 04 November 2006 09:23, David Woodhouse wrote: > On Sat, 2006-11-04 at 14:43 +0100, Florian La Roche wrote: > > can bluez-pin be removed from FC-devel now? (It is > > obsoleted by bluez-gnome now.) > > Yes, it can go. Blocked. Sorry for not getting to this earlier. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Fri Nov 17 03:20:32 2006 From: steve at silug.org (Steven Pritchard) Date: Thu, 16 Nov 2006 21:20:32 -0600 Subject: X in FC7 In-Reply-To: <455C87E5.9040902@redhat.com> References: <4554A980.6060204@redhat.com> <200611101637.07377.jbarnes@virtuousgeek.org> <45587068.90508@redhat.com> <455A2799.6010807@argo.co.il> <455B28E2.4000701@redhat.com> <20061116020306.GA10309@osiris.silug.org> <455C87E5.9040902@redhat.com> Message-ID: <20061117032032.GA26039@osiris.silug.org> On Thu, Nov 16, 2006 at 10:46:45AM -0500, Adam Jackson wrote: > Numbers would be a fantastic thing to introduce to the discussion here, > if anyone has them. I'm generally not fond of handwavey performance > decisions in the name of low-end machines without some proof. That might be difficult. How many such systems are still alive, and are still capable of running X? :-) > I can personally attest that at least for the OLPC machine, which has a > pretty crippled FPU, the performance problem for font rendering appeared > to be the rendering itself, and not so much font load and metric time. > But I don't have numbers immediately at hand to back that up. (And OLPC > ended up dropping xfs for footprint reasons anyway.) Keep in mind that I was talking about 11-12 years ago, when nobody (I knew) had >100MHz systems. Why did (does?) font rendering block all other operations in the X server anyway? That was the real source of the problem. (For all I know, this could have been fixed a decade ago though. I had a FPU in all my systems, so I never cared that much. ;-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From j.rink at freenet.de Fri Nov 17 06:59:03 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Fri, 17 Nov 2006 07:59:03 +0100 Subject: compiz unresponsoive under heavy load In-Reply-To: <455C5AE0.9060208@fh-wolfenbuettel.de> References: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> <455C5AE0.9060208@fh-wolfenbuettel.de> Message-ID: <20061117075903.e1879d85.j.rink@freenet.de> Am Thu, 16 Nov 2006 13:34:40 +0100 hat Christian Nolte (Christian Nolte) folgendes geschrieben: Hi, > Perhaps the information from this thread solves the unresponsiveness > for you: > > http://www.redhat.com/archives/fedora-list/2006-October/msg03990.html > http://www.redhat.com/archives/fedora-list/2006-November/msg00034.html > thanks for your info, but recompiling the kernel is not a solution for me. In my office i have a 3.3 Ghz P IV with HT. When i copy from dvd to hd, X is not usable. It was ever a Problem for X, especially for openGL applications, to act smoothly when you have hd activity, but no reaction is a new feature. I do not want to solve it with recompiling a kernel. That things i do years ago. I thought fedora works from the box. So for me compiz is a nice gimmick, but not more. -- Nine (not 9) Never trust a hippie From pekkas at netcore.fi Fri Nov 17 07:54:37 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Nov 2006 09:54:37 +0200 (EET) Subject: After power-off booting halts Message-ID: Hi, A couple of weeks ago I started seeing the following with FC5 on Thinkpad X30: - if the laptop is powered off without graceful shutdown (e.g., power runs out), the first booting stops after 'recovering journal' somewhere around 'mounting filesystems read/write' (the specific place is difficult to find out as the boot messages overwrite each other). By 'stops' I mean that you the system responds to keys, but bootup process doesn't progress (the same as happens for example with ntpd start for a while if network isn't up). - powering off the system and rebooting again results in a successful startup. The system is up to date wrt updates and updates-testing. I've seen this at least with kernel-2.6.18-1.2239.fc5 and kernel-2.6.18-1.2224.fc5, possibly earlier as well. Anyone else started experiencing something like this? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Nov 17 09:44:55 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 17 Nov 2006 10:44:55 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <1163708323.4032.14.camel@orodruin.boston.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> Message-ID: <20061117104455.0f1a37fa@python3.es.egwn.lan> Jeremy Katz wrote : > On Thu, 2006-11-16 at 20:37 +0100, Hans de Goede wrote: > > > gnome-games-1:2.17.2-3.fc7 > > > -------------------------- > > > * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 > > > - Add Provides/Obsoletes for gnuchess (#215110) > > > > > > > Does this mean gnuchess has been absorbed into gnome-games now? > > > > Ifso will this impact other gnuchess frontends, as there are are a few > > in FE? > > > > Any chance gnuchess could be put in a subpackage gnome-games-gnuchess, > > so that people who only need gnuchess don't need to install all of > > gnome-games? > > Or more preferably (IMHO), have gnome-games require gnuchess instead of > trying to suck it up. gnuchess has its own upstream; gnome-games isn't > it And while we're doing requests : I'd like to NEVER see "Obsoletes:" like this one without a version, as it is simply asking for trouble. For instance, gnome-games still has : Provides: gnome-sudoku Obsoletes: gnome-sudoku Which means that if gnome-sudoku ever gets split back out, we're in trouble. Not to mention that it's a clear "loop" which modern tools have luckily been taught to break. Provides: gnome-sudoku = last_known_version-release+2 Obsoletes: gnome-sudoku <= last_known_version-release+1 Allows us to avoid all of these problems, making it possible to reintroduce gnome-sudoku at any higher version (the +1 and +2 tricks are because of disttags, it would be +0 and +1 otherwise). Packaging draft to the guidelines (not written by me) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 0.34 0.37 0.28 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Nov 17 09:56:47 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 17 Nov 2006 10:56:47 +0100 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CC6A8.5060400@hhs.nl> References: <455CC6A8.5060400@hhs.nl> Message-ID: <20061117105647.065263dc@python3.es.egwn.lan> Hans de Goede wrote : > [... bug reports, with fixes ...] Great work indeed! Maybe someone could quickly go through some open bugs and try to find some that are easily reproducible and which would involve the careful debugging you're looking for? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203336 > > Torcs segfaults after a short while when using "openal" for the sound, > but not when using "plib". I just tried in 1.3.0 and there is still the > same problem... either it's in torcs itself (which BTW exits > when /dev/dsp is busy, not very user friendly!) or in openal, dunno. > > My Students failed to reproduce this on FC-6 and have requested the > reporter to try to see if he can reproduce it. FWIW, I can reproduce this one very easily on my machine : rm -rf ~/.torcs/ torcs ... then press "enter" many times to start a "quick race" ... start driving and "bump" into anything (car or scenery) -> Segfault :-( On the machine I'm testing this on, the NVidia binary drivers are installed. I doubt it might have anything to do as this seems more related to sound, but who knows. My audio device is an integrated "Intel Corporation 631xESB/632xESB High Definition Audio Controller" Please have your students reply to the bug report if they need me to do any kind of testing for them, provide a core file etc. This can actually be interesting debugging, and good practice for the (not so uncommon) case where you need to guide someone who can reproduce the problem ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 0.62 0.46 0.34 From pertusus at free.fr Fri Nov 17 10:00:31 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 17 Nov 2006 11:00:31 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <20061117104455.0f1a37fa@python3.es.egwn.lan> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <20061117104455.0f1a37fa@python3.es.egwn.lan> Message-ID: <20061117100031.GB3290@free.fr> On Fri, Nov 17, 2006 at 10:44:55AM +0100, Matthias Saou wrote: > > Which means that if gnome-sudoku ever gets split back out, we're in > trouble. Not to mention that it's a clear "loop" which modern tools > have luckily been taught to break. > > Provides: gnome-sudoku = last_known_version-release+2 > Obsoletes: gnome-sudoku <= last_known_version-release+1 rpmlint warns about these, so package maintainers should be aware of these. At least no package should pass review with this issue. I hope that one day all the core package (and packages which entered extra a long time ago) pass a review, such that those kinds of issues are fixed once, instead of being fixed one by one. -- Pat From fedora at camperquake.de Fri Nov 17 10:08:15 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 17 Nov 2006 11:08:15 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <20061117100031.GB3290@free.fr> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <20061117104455.0f1a37fa@python3.es.egwn.lan> <20061117100031.GB3290@free.fr> Message-ID: <20061117110815.0c26ea8a@yareena.int.addix.net> Hi. On Fri, 17 Nov 2006 11:00:31 +0100, Patrice Dumas wrote: > rpmlint warns about these, so package maintainers should be aware of > these. At least no package should pass review with this issue. I hope > that one day all the core package (and packages which entered extra a > long time ago) pass a review, such that those kinds of issues are > fixed once, instead of being fixed one by one. I'd like to hear your opinion on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215165 From mcdavey at mrao.cam.ac.uk Fri Nov 17 10:18:30 2006 From: mcdavey at mrao.cam.ac.uk (Matt Davey) Date: Fri, 17 Nov 2006 10:18:30 +0000 Subject: Progress reports of my students fixing bugs In-Reply-To: <455CC6A8.5060400@hhs.nl> References: <455CC6A8.5060400@hhs.nl> Message-ID: <1163758710.16816.214.camel@sirocco.local.corvil.com> On Thu, 2006-11-16 at 21:14 +0100, Hans de Goede wrote: > Hi all, > > About a week ago I announced I wanted some relatively easy to fix bugs > to use in a lab lesson for students to teach them / let them practice > with systematical fault searching. > > Many thanks to those who posted bugs, although I did find the response a > bit lacking. Since I want to continue with these lessons next week and > need a few new bug here is a progress report on the bugs which I gave to > my students: What an excellent idea. I missed your original posting, but I think I'd have enjoyed being a student in your classes! You may be aware that gnome.bugzilla has a 'gnome love' keyword for bugs that should be tractable by newcomers. The idea is for maintainers to use the label for bugs that they're willing to help volunteers to fix. Matt Matt Davey Why is it difficult to find men who are sensitive, caring and mcdavey at mrao.cam.ac.uk good looking? - They've all got boyfriends already. From aph at redhat.com Fri Nov 17 10:31:54 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Nov 2006 10:31:54 +0000 Subject: GPL2 Java? In-Reply-To: <20061116140422.c186390e.zaitcev@redhat.com> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> <17756.11778.196984.294438@zebedee.pink> <20061116140422.c186390e.zaitcev@redhat.com> Message-ID: <17757.36762.780024.249601@zebedee.pink> Pete Zaitcev writes: > On Thu, 16 Nov 2006 09:23:14 +0000, Andrew Haley wrote: > > > > > Does Sun JDK build for PowerPC? > > > > > > Nope but its potentially possible now. > > > > I don't really understand this remark. "Potentially possible?" What > > does this mean? That we can write a Java VM for the PowerPC? But, of > > course, that was always true. It's not as though we needs access to > > the source of a VM for some other arch before we can write one. > > So, if "we" "can" write one, why haven't we? > > I don't understand what your point is. Are you, personally, going to > package JDK for PPC? Are you stenously object to someone else packaging > JDK for PPC? If neither, what are you wasting the bandwidth about? It's a question. I didn't understand Rahul's remark. I still don't. > So Rahul's wording was not perfect, big deal! > > By the way, surely you know that VMs are dime a dozen, and the > libraries are the real problem. I might have some knowledge of that. > I am quite happy with my gcj and Classpath, which execute my > critical Java applications today, but there are still people out > there would would benefit from (compatibility with) all bugs in Sun > JDK libraries. Excellent. Andrew. From sundaram at fedoraproject.org Fri Nov 17 11:13:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Nov 2006 16:43:44 +0530 Subject: GPL2 Java? In-Reply-To: <17757.36762.780024.249601@zebedee.pink> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> <17756.11778.196984.294438@zebedee.pink> <20061116140422.c186390e.zaitcev@redhat.com> <17757.36762.780024.249601@zebedee.pink> Message-ID: <455D9968.3010504@fedoraproject.org> Andrew Haley wrote: > Pete Zaitcev writes: > > On Thu, 16 Nov 2006 09:23:14 +0000, Andrew Haley wrote: > > > > > > > Does Sun JDK build for PowerPC? > > > > > > > > Nope but its potentially possible now. > > > > > > I don't really understand this remark. "Potentially possible?" What > > > does this mean? That we can write a Java VM for the PowerPC? But, of > > > course, that was always true. It's not as though we needs access to > > > the source of a VM for some other arch before we can write one. > > > > So, if "we" "can" write one, why haven't we? > > > > I don't understand what your point is. Are you, personally, going to > > package JDK for PPC? Are you stenously object to someone else packaging > > JDK for PPC? If neither, what are you wasting the bandwidth about? > > It's a question. I didn't understand Rahul's remark. I still don't. I meant that Since Sun has now indicated that it is putting Java under GPL, they might be interested in working with people to port it to more architectures. Rahul From sundaram at fedoraproject.org Fri Nov 17 11:14:24 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Nov 2006 16:44:24 +0530 Subject: GPL2 Java? In-Reply-To: <17757.36762.780024.249601@zebedee.pink> References: <20061113193657.28980.qmail@web52413.mail.yahoo.com> <1163476907.3396.9.camel@shinybook.infradead.org> <45599F77.6080805@fedoraproject.org> <17756.11778.196984.294438@zebedee.pink> <20061116140422.c186390e.zaitcev@redhat.com> <17757.36762.780024.249601@zebedee.pink> Message-ID: <455D9990.3000809@fedoraproject.org> Andrew Haley wrote: > Pete Zaitcev writes: > > On Thu, 16 Nov 2006 09:23:14 +0000, Andrew Haley wrote: > > > > > > > Does Sun JDK build for PowerPC? > > > > > > > > Nope but its potentially possible now. > > > > > > I don't really understand this remark. "Potentially possible?" What > > > does this mean? That we can write a Java VM for the PowerPC? But, of > > > course, that was always true. It's not as though we needs access to > > > the source of a VM for some other arch before we can write one. > > > > So, if "we" "can" write one, why haven't we? > > > > I don't understand what your point is. Are you, personally, going to > > package JDK for PPC? Are you stenously object to someone else packaging > > JDK for PPC? If neither, what are you wasting the bandwidth about? > > It's a question. I didn't understand Rahul's remark. I still don't. I meant that since Sun has now indicated that it is putting Java under GPL (+classpath exception), they might be interested in working with people to port it to more architectures. Rahul From ndbecker2 at gmail.com Fri Nov 17 11:37:53 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 17 Nov 2006 06:37:53 -0500 Subject: Make kde 1st class in fedora Message-ID: As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login? Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components. If a new desktop is setup with kde, it must have konqueror as the browser and kmail as the mail client. These are designed to work nicely together. In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop. From buildsys at redhat.com Fri Nov 17 11:45:37 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 17 Nov 2006 06:45:37 -0500 Subject: rawhide report: 20061117 changes Message-ID: <200611171145.kAHBjb2J008827@hs20-bc2-6.build.redhat.com> Removed package bluez-pin Updated Packages: cups-1:1.2.7-2.fc7 ------------------ * Thu Nov 16 2006 Tim Waugh 1:1.2.7-2 - 1.2.7. * Tue Nov 14 2006 Tim Waugh - Fixed LogFilePerm. * Mon Nov 13 2006 Tim Waugh - Don't use getpass() (bug #125133). dhcp-12:3.0.5-6.fc7 ------------------- * Thu Nov 16 2006 David Cantrell - 12:3.0.5-6 - Set permission of libdhcp4client.so.1 to 0755 (#215910) * Tue Nov 14 2006 David Cantrell - 12:3.0.5-5 - Do not link res_query.o in to libdhcp4client (#215501) * Mon Nov 13 2006 David Cantrell - 12:3.0.5-4 - Enable relinquish_timeouts() and cancel_all_timeouts() even when DEBUG_MEMORY_LEAKAGE_ON_EXIT is not defined - Add prototypes for b64_pton() and b64_ntop in dst/ - Move variable declarations and labels around in the fix-warnings patch - Expand the list of objects needed for libdhcp4client (#215328) - Use libres.a in libdhcp4client since it gives correct minires objects - Remove the dhcp options table in C, Perl, Python, and text format (these were reference files added to /usr/share/doc) dhcpv6-0.10-34.fc7 ------------------ * Thu Nov 16 2006 David Cantrell - 0.10-34 - Set permission of libdhcp6client.so.1 to 0755 (#215911) eclipse-1:3.2.1-19.fc7 ---------------------- * Thu Nov 16 2006 Andrew Overholt 3.2.1-19 - Add patch to look at gre64.conf on ppc64. * Fri Nov 10 2006 Ben Konrath 3.2.1-18 - Remove SWT ON_TOP patch as it is fixed in 3.2.1. * Thu Nov 09 2006 Ben Konrath 3.2.1-17 - Add file level requirement for swt fragment to rcp and platform packages. This is needed so that the rcp and platform packages pull in the swt package of the correct word size. eclipse-cdt-1:3.1.1-5.fc7 ------------------------- * Wed Nov 15 2006 Jeff Johnstont 3.1.1-5 - Add cppunit support. gcc-4.1.1-38 ------------ * Thu Nov 16 2006 Jakub Jelinek 4.1.1-38 - update from gcc-4_1-branch (-r118805:118891) - PRs rtl-optimization/29797 - fix forwprop switch optimization (PR middle-end/29584) - remove old *34* provides (#215839) * Tue Nov 14 2006 Jakub Jelinek 4.1.1-37 - fix up check_effective_target_fopenmp tcl test for the testsuite framework backport changes * Tue Nov 14 2006 Jakub Jelinek 4.1.1-36 - update from gcc-4_1-branch (-r118571:118805) - PRs c++/29106, c++/29518, fortran/24518, fortran/29216, fortran/29314, fortran/29371, fortran/29387, fortran/29392, fortran/29490, fortran/29565, fortran/29630, fortran/29679, fortran/29713, middle-end/21032, testsuite/28703, tree-opt/28545 - honor initial conditions and variable types in conversion to perfect nesting for -ftree-loop-linear optimizations (#209297, PR tree-optimization/29581) gd-2.0.33-10.fc7 ---------------- * Thu Nov 16 2006 Ivana Varekova 2.0.33-10 - added 'thick' - variable support for AA line (#198042) gdb-6.5-17.fc7 -------------- * Thu Nov 16 2006 Jan Kratochvil - 6.5-17 - Bugfix testcase typo of gdb-6.5-16. * Thu Nov 16 2006 Jan Kratochvil - 6.5-16 - Provide testcase for accessing the last address space byte. * Thu Nov 09 2006 Jan Kratochvil - 6.5-15 - Fix readline segfault on excessively long hand-typed lines. ghostscript-8.15.3-2.fc7 ------------------------ * Thu Nov 16 2006 Tim Waugh 8.15.3-2 - 8.15.3. No longer need gtk2, ps2epsi, badc, pagesize, use-external-freetype, split-font-configuration or cjkv patches. - Renumbered patches. * Tue Oct 03 2006 Tim Waugh 8.15.2-9 - Apply CJKV patch from svn164:165 plus the fix from svn173:174 (bug #194592, bug #203712, possibly bug #167596). * Wed Jul 12 2006 Jesse Keating - 8.15.2-8.1 - rebuild gnome-applets-1:2.16.1-5.fc7 ---------------------------- * Thu Nov 16 2006 Matthias Clasen - 1:2.16.1-5 - Fix muted icon in mixer again * Mon Nov 06 2006 Ray Strode - 1:2.16.1-4 - s/verion/version/ in dbus glib build requires * Fri Nov 03 2006 Matthias Clasen - 1:2.16.1-3 - Silence %pre gnome-games-1:2.17.2-4.fc7 -------------------------- * Thu Nov 16 2006 Matthias Clasen - 1:2.17.2-4 - Use Conflicts for gnuchess instead gnome-panel-2.16.1-5.fc7 ------------------------ * Thu Nov 16 2006 Matthias Clasen - 2.16.1-5 - Fix previous patch and also include the fix for gnome bug 359707 gtk2-2.10.6-2.fc7 ----------------- * Thu Nov 16 2006 Matthias Clasen - 2.10.6-2 - Avoid a possible segfault (#215933) gtk2-engines-2.8.2-1.fc7 ------------------------ * Thu Nov 16 2006 Matthias Clasen - 2.8.2-1 - Update to 2.8.2 iproute-2.6.18-3.fc7 -------------------- * Thu Nov 16 2006 Radek Vok??l - 2.6.18-3 - fix defective manpage for tc-pfifo (#215399) libwmf-0.2.8.4-11 ----------------- * Thu Nov 16 2006 Caolan McNamara 0.2.8.4-11 - Resolves: rhbz#215925 reduce exported symbols openoffice.org-1:2.1.0-3.1 -------------------------- * Wed Nov 15 2006 Caolan McNamara - 1:2.1.0-3.1 - next version - Resolves: rhbz#215694 add openoffice.org-2.0.4.ooo71562.svx.64bitcrash.patch - Resolves: rhbz#215582 add openoffice.org-2.0.4.ooo71570.psprint.noonecopy.patch - pt help translated - ta-IN help translated policycoreutils-1.33.1-8.fc7 ---------------------------- * Thu Nov 16 2006 Dan Walsh 1.33.1-8 - Fix display of gui * Thu Nov 16 2006 Dan Walsh 1.33.1-7 - Add patch by Joe Plans to make run_init use pam_acct_mgmt scim-1.4.5-2.fc7 ---------------- * Fri Nov 17 2006 Shawn Huang - 1.4.5-2 - add scim-fix-unload-segfault.patch to fix xim process segfaulting when already running (#206995) * Tue Nov 07 2006 Jens Petersen - 1.4.5-1 - update to 1.4.5 release - no longer need scim.pc-versioned-moduledir-179706.patch, scim_panel_gtk-systray-click-199187.patch, scim_panel_gtk-menu-recently-used-factories.patch, scim_backup-default-engine-2letter-locale-197058.patch, scim_utility-Assamese-locale-fix.patch, scim-gtkimm-underline-attrib-206397.patch, and scim_x11_frontend-underline-attrib-206397.patch - update scim-system-default-config.patch, scim_panel_gtk-icon-size-fixes.patch - add scim-1.4.5-panel-menu-fixes.patch to fix factory menu labelling - improve scim-restart script to also handle scim-bridge (#205547) - obsolete iiimf-csconv (#211875) * Thu Nov 02 2006 Jens Petersen - return scim-bridge-qt support to xinput script selinux-policy-2.4.4-3.fc7 -------------------------- setup-2.5.56-1 -------------- * Thu Nov 16 2006 Phil Knirsch 2.5.56-1 - Added an entry for samba and winbind_auth * Wed Oct 11 2006 Phil Knirsch 2.5.55-1 - Extended the protocols to include the missing hopopt (#209191) * Tue Oct 10 2006 Phil Knirsch 2.5.54-1 - Update /etc/protocols to latest officiall IANA version (#209191) yaboot-1.3.13-4.fc7 ------------------- * Thu Nov 16 2006 Paul Nasrat - 1.3.13-4 - Add support for usb/firewire from Alex Kanavin (#208768) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From sundaram at fedoraproject.org Fri Nov 17 11:55:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Nov 2006 17:25:36 +0530 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <455DA338.5080906@fedoraproject.org> Neal Becker wrote: > As a long time kde and fedora fan, I'd like to promote the idea of making > kde a 1st class part of fedora. What does this mean, you ask? Can't the > new user select kde at login? > > Yes, they can. But their desktop is setup with icons and menus that are > missing vital kde components. > > If a new desktop is setup with kde, it must have konqueror as the browser > and kmail as the mail client. These are designed to work nicely together. > > In my experience, most new linux users (as most new users on other OSs) > never bother to customize their menus and tool bars. I see my friends > desktops have kde as window manager, but never heard of kmail, knode, konq > because fedora by default doesn't show them on their menus and desktop. What you are describing is the symptom of a larger issue that different set of packages could use more attention that it current receives. This is something that we fix by merging core,extras and legacy and let everyone interested work on all of Fedora. See more details at http://fedoraproject.org/wiki/FedoraSummit Rahul From ch.nolte at fh-wolfenbuettel.de Fri Nov 17 12:16:28 2006 From: ch.nolte at fh-wolfenbuettel.de (Christian Nolte) Date: Fri, 17 Nov 2006 13:16:28 +0100 Subject: compiz unresponsoive under heavy load In-Reply-To: <20061117075903.e1879d85.j.rink@freenet.de> References: <200611152354.13799.jonesc@hep.phy.cam.ac.uk> <455C5AE0.9060208@fh-wolfenbuettel.de> <20061117075903.e1879d85.j.rink@freenet.de> Message-ID: <455DA81C.4000200@fh-wolfenbuettel.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 J?rn Rink schrieb: > Am Thu, 16 Nov 2006 13:34:40 +0100 > hat Christian Nolte (Christian Nolte) > folgendes geschrieben: > > Hi, > >> Perhaps the information from this thread solves the unresponsiveness >> for you: >> >> http://www.redhat.com/archives/fedora-list/2006-October/msg03990.html >> http://www.redhat.com/archives/fedora-list/2006-November/msg00034.html >> > > thanks for your info, > but recompiling the kernel is not a solution for me. In my office i > have a 3.3 Ghz P IV with HT. When i copy from dvd to hd, X is not > usable. > > [...] You do not have to recompile the kernel as the necessary scheduling policies come "out-of-the-box" scince 2.6.x. All you have to do is to use schedtool to give X real-time priority. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFXagcCNjA0nfhW7wRAvfWAKCL3QgpYKnHCw/8k/wRgt4Ws2BrRwCg+7S5 C9QlOKewn53qo2DWyj+PXno= =I4kL -----END PGP SIGNATURE----- From rdieter at math.unl.edu Fri Nov 17 13:49:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 17 Nov 2006 07:49:44 -0600 Subject: Make kde 1st class in fedora References: Message-ID: Neal Becker wrote: > In my experience, most new linux users (as most new users on other OSs) > never bother to customize their menus and tool bars. I see my friends > desktops have kde as window manager, but never heard of kmail, knode, konq > because fedora by default doesn't show them on their menus and desktop. kmail, knode, konq are all there on my box in the "Internet" menu, unless you're talking about something else... ? -- Rex From laurent.rineau__fedora_extras at normalesup.org Fri Nov 17 14:10:56 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 17 Nov 2006 15:10:56 +0100 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <200611171510.56805@rineau.schtroumpfette> On Friday 17 November 2006 14:49, Rex Dieter wrote: > Neal Becker wrote: > > In my experience, most new linux users (as most new users on other OSs) > > never bother to customize their menus and tool bars. I see my friends > > desktops have kde as window manager, but never heard of kmail, knode, > > konq because fedora by default doesn't show them on their menus and > > desktop. > > kmail, knode, konq are all there on my box in the "Internet" menu, unless > you're talking about something else... ? I imagine that he is talking about the default apps shortcuts in the panel. From pemboa at gmail.com Fri Nov 17 15:12:26 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 18 Nov 2006 09:12:26 +1800 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <16de708d0611170712n1e0ddf96we3aab21dc9094ae8@mail.gmail.com> On 11/18/06, Neal Becker wrote: > As a long time kde and fedora fan, I'd like to promote the idea of making > kde a 1st class part of fedora. What does this mean, you ask? Can't the > new user select kde at login? > > Yes, they can. But their desktop is setup with icons and menus that are > missing vital kde components. > > If a new desktop is setup with kde, it must have konqueror as the browser > and kmail as the mail client. These are designed to work nicely together. > > In my experience, most new linux users (as most new users on other OSs) > never bother to customize their menus and tool bars. I see my friends > desktops have kde as window manager, but never heard of kmail, knode, konq > because fedora by default doesn't show them on their menus and desktop. > Let it go dude. Trust me. I know what you mean. But I also know that it is going to be months before this changes. I think it will....in time. Peace -- Fedora Core 6 and proud From mmcgrath at fedoraproject.org Fri Nov 17 15:19:43 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 09:19:43 -0600 Subject: CVS is busted Message-ID: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> As of about 8:40 today the CVS box threw a SMART error regarding one of its drives. As a result most of the CVS box is presently mounted read only. We are working to correct this issue but expect CVS to be up and down today. -Mike From arjan at fenrus.demon.nl Fri Nov 17 15:52:49 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 17 Nov 2006 16:52:49 +0100 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <1163778769.31358.337.camel@laptopd505.fenrus.org> On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote: > As a long time kde and fedora fan, I'd like to promote the idea of making > kde a 1st class part of fedora. What does this mean, you ask? Can't the > new user select kde at login? > > Yes, they can. But their desktop is setup with icons and menus that are > missing vital kde components. > > If a new desktop is setup with kde, it must have konqueror as the browser The browser one is funny. I know MANY people who will be upset if it's not firefox, period. That has nothing to do with being pro, neutral or against KDE, but simple expectation that Firefox is the flag ship open source thing for many people (they met it first on Windows and started to take open source more serious, now they look at linux), and they expect it to be there at least as integrated as the Windows Firefox is. Firefox also isn't the gnome default browser, but still I think Fedora does the right thing to overrule BOTH desktops and give people what they want. From mclasen at redhat.com Fri Nov 17 16:02:07 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Nov 2006 11:02:07 -0500 Subject: rawhide report: 20061116 changes In-Reply-To: <1163708323.4032.14.camel@orodruin.boston.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> Message-ID: <1163779327.28284.20.camel@golem.boston.devel.redhat.com> On Thu, 2006-11-16 at 15:18 -0500, Jeremy Katz wrote: > On Thu, 2006-11-16 at 20:37 +0100, Hans de Goede wrote: > > > gnome-games-1:2.17.2-3.fc7 > > > -------------------------- > > > * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 > > > - Add Provides/Obsoletes for gnuchess (#215110) > > > > > > > Does this mean gnuchess has been absorbed into gnome-games now? > > > > Ifso will this impact other gnuchess frontends, as there are are a few > > in FE? > > > > Any chance gnuchess could be put in a subpackage gnome-games-gnuchess, > > so that people who only need gnuchess don't need to install all of > > gnome-games? > > Or more preferably (IMHO), have gnome-games require gnuchess instead of > trying to suck it up. gnuchess has its own upstream; gnome-games isn't > it I've changed the Obsoletes to a Conflicts for now. Can't do the right thing (Requires) as long as gnome-games is in core and gnuchess in extras... -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Fri Nov 17 16:16:17 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 17 Nov 2006 17:16:17 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <1163779327.28284.20.camel@golem.boston.devel.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <1163779327.28284.20.camel@golem.boston.devel.redhat.com> Message-ID: <455DE051.7090104@hhs.nl> Matthias Clasen wrote: > On Thu, 2006-11-16 at 15:18 -0500, Jeremy Katz wrote: >> On Thu, 2006-11-16 at 20:37 +0100, Hans de Goede wrote: >>>> gnome-games-1:2.17.2-3.fc7 >>>> -------------------------- >>>> * Wed Nov 15 2006 Matthias Clasen - 1:2.17.2-3 >>>> - Add Provides/Obsoletes for gnuchess (#215110) >>>> >>> Does this mean gnuchess has been absorbed into gnome-games now? >>> >>> Ifso will this impact other gnuchess frontends, as there are are a few >>> in FE? >>> >>> Any chance gnuchess could be put in a subpackage gnome-games-gnuchess, >>> so that people who only need gnuchess don't need to install all of >>> gnome-games? >> Or more preferably (IMHO), have gnome-games require gnuchess instead of >> trying to suck it up. gnuchess has its own upstream; gnome-games isn't >> it > > I've changed the Obsoletes to a Conflicts for now. Can't do the > right thing (Requires) as long as gnome-games is in core and gnuchess in > extras... > > Wouldn't it be better to move gnuchess to core for now then? That might also be a good test for some co-maintainance between FE contributers and a Core maintainer. Regards, Hans From david at lovesunix.net Fri Nov 17 16:04:09 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 17 Nov 2006 17:04:09 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163778769.31358.337.camel@laptopd505.fenrus.org> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> Message-ID: <1163779449.3112.7.camel@dawkins> fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven: > On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote: > > As a long time kde and fedora fan, I'd like to promote the idea of making > > kde a 1st class part of fedora. What does this mean, you ask? Can't the > > new user select kde at login? > > > > Yes, they can. But their desktop is setup with icons and menus that are > > missing vital kde components. > > > > If a new desktop is setup with kde, it must have konqueror as the browser > > The browser one is funny. I know MANY people who will be upset if it's > not firefox, period. That has nothing to do with being pro, neutral or > against KDE, but simple expectation that Firefox is the flag ship open > source thing for many people (they met it first on Windows and started > to take open source more serious, now they look at linux), and they > expect it to be there at least as integrated as the Windows Firefox is. > > Firefox also isn't the gnome default browser, but still I think Fedora > does the right thing to overrule BOTH desktops and give people what they > want. Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop. I strongly disagree with the argument that people move to Fedora thanks to Firefox since I see no hard evidence for that claim and there are advantages to be had by going for maximal integration. So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jeff at ocjtech.us Fri Nov 17 16:11:56 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2006 10:11:56 -0600 Subject: Make kde 1st class in fedora In-Reply-To: <1163779449.3112.7.camel@dawkins> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> Message-ID: <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> On Fri, 2006-11-17 at 17:04 +0100, David Nielsen wrote: > fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven: > > On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote: > > > > > If a new desktop is setup with kde, it must have konqueror as the browser > > > > Firefox also isn't the gnome default browser, but still I think Fedora > > does the right thing to overrule BOTH desktops and give people what they > > want. > > Funny as a GNOME user, the first thing I do is replace Firefox with > Epiphany as it integrates better with my desktop. I strongly disagree > with the argument that people move to Fedora thanks to Firefox since I > see no hard evidence for that claim and there are advantages to be had > by going for maximal integration. > > So I could definitely see why many KDE users would feel the same way > about Konqi. Luckily this one of those things that will naturally > resolve itself once Core and Extras gets merged, if the community by > then wants KDE to have Konqi as the default then that will happen. This might make a good candidate for firstboot - during firstboot the person installing the system could choose the default apps that newly created users would get. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Fri Nov 17 16:25:13 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 17 Nov 2006 17:25:13 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> Message-ID: <1163780713.3112.10.camel@dawkins> fre, 17 11 2006 kl. 10:11 -0600, skrev Jeffrey C. Ollie: > On Fri, 2006-11-17 at 17:04 +0100, David Nielsen wrote: > > fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven: > > > On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote: > > > > > > > If a new desktop is setup with kde, it must have konqueror as the browser > > > > > > Firefox also isn't the gnome default browser, but still I think Fedora > > > does the right thing to overrule BOTH desktops and give people what they > > > want. > > > > Funny as a GNOME user, the first thing I do is replace Firefox with > > Epiphany as it integrates better with my desktop. I strongly disagree > > with the argument that people move to Fedora thanks to Firefox since I > > see no hard evidence for that claim and there are advantages to be had > > by going for maximal integration. > > > > So I could definitely see why many KDE users would feel the same way > > about Konqi. Luckily this one of those things that will naturally > > resolve itself once Core and Extras gets merged, if the community by > > then wants KDE to have Konqi as the default then that will happen. > > This might make a good candidate for firstboot - during firstboot the > person installing the system could choose the default apps that newly > created users would get. Dear heavens no.. One of the strengths of the Fedora desktop is it's predefined standards. If you like me want a different set of applications there's the customize now/later option during install. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mmcgrath at fedoraproject.org Fri Nov 17 16:30:03 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 10:30:03 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> Message-ID: <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> On 11/17/06, Mike McGrath wrote: > As of about 8:40 today the CVS box threw a SMART error regarding one > of its drives. As a result most of the CVS box is presently mounted > read only. We are working to correct this issue but expect CVS to be > up and down today. > Dell has been dispatched and will arrive in 4 hours. CVS will be down until further notice. -Mike From mclasen at redhat.com Fri Nov 17 16:49:40 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Nov 2006 11:49:40 -0500 Subject: rawhide report: 20061116 changes In-Reply-To: <455DE051.7090104@hhs.nl> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <1163779327.28284.20.camel@golem.boston.devel.redhat.com> <455DE051.7090104@hhs.nl> Message-ID: <1163782180.28284.22.camel@golem.boston.devel.redhat.com> On Fri, 2006-11-17 at 17:16 +0100, Hans de Goede wrote: > Wouldn't it be better to move gnuchess to core for now then? That > might > also be a good test for some co-maintainance between FE contributers > and > a Core maintainer. > Seems silly to move things to core now, when everything will move in the opposite direction soon anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Fri Nov 17 17:14:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 17 Nov 2006 18:14:36 +0100 Subject: rawhide report: 20061116 changes In-Reply-To: <1163782180.28284.22.camel@golem.boston.devel.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <1163779327.28284.20.camel@golem.boston.devel.redhat.com> <455DE051.7090104@hhs.nl> <1163782180.28284.22.camel@golem.boston.devel.redhat.com> Message-ID: <455DEDFC.7060605@hhs.nl> Matthias Clasen wrote: > On Fri, 2006-11-17 at 17:16 +0100, Hans de Goede wrote: >> Wouldn't it be better to move gnuchess to core for now then? That >> might >> also be a good test for some co-maintainance between FE contributers >> and >> a Core maintainer. >> > > Seems silly to move things to core now, when everything will move in the > opposite direction soon anyway. > > Not sillier then having a Conflicts in a core package conflicting with a package available in the current FE tree. With this conflicts you are essentially making the FE package worthless. Regards, Hans From dennis at ausil.us Fri Nov 17 17:02:50 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 17 Nov 2006 11:02:50 -0600 Subject: rawhide report: 20061116 changes In-Reply-To: <1163782180.28284.22.camel@golem.boston.devel.redhat.com> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455DE051.7090104@hhs.nl> <1163782180.28284.22.camel@golem.boston.devel.redhat.com> Message-ID: <200611171102.51234.dennis@ausil.us> On Friday 17 November 2006 10:49, Matthias Clasen wrote: > On Fri, 2006-11-17 at 17:16 +0100, Hans de Goede wrote: > > Wouldn't it be better to move gnuchess to core for now then? That > > might > > also be a good test for some co-maintainance between FE contributers > > and > > a Core maintainer. > > Seems silly to move things to core now, when everything will move in the > opposite direction soon anyway. Lets move gnome-games to extras and do the right thing, -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From mclasen at redhat.com Fri Nov 17 17:11:29 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Nov 2006 12:11:29 -0500 Subject: rawhide report: 20061116 changes In-Reply-To: <455DEDFC.7060605@hhs.nl> References: <200611161153.kAGBrhJW019091@hs20-bc2-6.build.redhat.com> <455CBDF7.8040109@hhs.nl> <1163708323.4032.14.camel@orodruin.boston.redhat.com> <1163779327.28284.20.camel@golem.boston.devel.redhat.com> <455DE051.7090104@hhs.nl> <1163782180.28284.22.camel@golem.boston.devel.redhat.com> <455DEDFC.7060605@hhs.nl> Message-ID: <1163783489.28284.24.camel@golem.boston.devel.redhat.com> On Fri, 2006-11-17 at 18:14 +0100, Hans de Goede wrote: > > Matthias Clasen wrote: > > On Fri, 2006-11-17 at 17:16 +0100, Hans de Goede wrote: > >> Wouldn't it be better to move gnuchess to core for now then? That > >> might > >> also be a good test for some co-maintainance between FE contributers > >> and > >> a Core maintainer. > >> > > > > Seems silly to move things to core now, when everything will move in the > > opposite direction soon anyway. > > > > > > Not sillier then having a Conflicts in a core package conflicting with a > package available in the current FE tree. With this conflicts you are > essentially making the FE package worthless. > No, the Obsoletes that I put in first made the extras package worthless. The conflict gives people the option to not install gnome-games and enjoy gnuchess instead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Fri Nov 17 18:04:54 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 17 Nov 2006 18:04:54 +0000 (UTC) Subject: Make kde 1st class in fedora References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> Message-ID: David Nielsen lovesunix.net> writes: > Funny as a GNOME user, the first thing I do is replace Firefox with > Epiphany as it integrates better with my desktop. And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror? Kevin Kofler From david at fubar.dk Fri Nov 17 18:08:59 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 17 Nov 2006 13:08:59 -0500 Subject: Plans for Fast User Switching Message-ID: <455DFABB.7090205@fubar.dk> Hi, I've created a Wiki page with some of the plans that the desktop team at Red Hat got wrt. making Fast User Switching just work http://fedoraproject.org/wiki/Desktop/FastUserSwitching Feel free to edit the page with ideas / questions (probably better than asking on the mailing lists). Thanks. David From pemboa at gmail.com Fri Nov 17 19:08:40 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 17 Nov 2006 13:08:40 -0600 Subject: Make kde 1st class in fedora In-Reply-To: References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> Message-ID: <16de708d0611171108o2de43165gd271e0826fdf74bc@mail.gmail.com> On 11/17/06, Kevin Kofler wrote: > David Nielsen lovesunix.net> writes: > > Funny as a GNOME user, the first thing I do is replace Firefox with > > Epiphany as it integrates better with my desktop. > > And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox > altogether (considering all that trademark crap) and default GNOME to Epiphany > (built against xulrunner - firefox-devel is only a temporary hack anyway) and > KDE to Konqueror? > > Kevin Kofler I only use Firefox on my Fedora install to check Gmail (these mailing lists) - I use Seamonkey the rest of the time. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Fedora Core 6 and proud From jfrieben at freesurf.fr Fri Nov 17 20:11:42 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Fri, 17 Nov 2006 21:11:42 +0100 (CET) Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> > And as a KDE user, I do the same with Konqueror. Heck, why not drop > Firefox altogether (considering all that trademark crap) and default > GNOME to Epiphany (built against xulrunner - firefox-devel is only a > temporary hack anyway) and KDE to Konqueror? > > Kevin Kofler Be gentle, moving "firefox" to "Extras" would already be a great thing ;) From hughsient at gmail.com Fri Nov 17 20:01:30 2006 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 17 Nov 2006 20:01:30 +0000 Subject: Plans for Fast User Switching In-Reply-To: <455DFABB.7090205@fubar.dk> References: <455DFABB.7090205@fubar.dk> Message-ID: <1163793690.3333.8.camel@localhost.localdomain> On Fri, 2006-11-17 at 13:08 -0500, David Zeuthen wrote: > Hi, > > I've created a Wiki page with some of the plans that the desktop team at > Red Hat got wrt. making Fast User Switching just work Looks fantastic. I can roll daily git rpm's of ConsoleKit in the (really hardcore) utopia repo if you wish - I'm already doing that for PolicyKit and HAL. Richard. From sundaram at fedoraproject.org Fri Nov 17 21:32:53 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Nov 2006 03:02:53 +0530 Subject: Make kde 1st class in fedora In-Reply-To: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> Message-ID: <455E2A85.1040307@fedoraproject.org> Joachim Frieben wrote: >> And as a KDE user, I do the same with Konqueror. Heck, why not drop >> Firefox altogether (considering all that trademark crap) and default >> GNOME to Epiphany (built against xulrunner - firefox-devel is only a >> temporary hack anyway) and KDE to Konqueror? >> >> Kevin Kofler > > Be gentle, moving "firefox" to "Extras" would already be a great thing ;) > If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit. If you want to seriously suggest changing the default, write up more solid proposals that has just more than personal preferences in it and start a new thread. Rahul From jkeating at redhat.com Fri Nov 17 21:46:06 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Nov 2006 16:46:06 -0500 Subject: Make kde 1st class in fedora In-Reply-To: <455E2A85.1040307@fedoraproject.org> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> <455E2A85.1040307@fedoraproject.org> Message-ID: <200611171646.06276.jkeating@redhat.com> On Friday 17 November 2006 16:32, Rahul Sundaram wrote: > If you havent received the memo yet, there is no core/extras/legacy > starting from the next release. > http://fedoraproject.org/wiki/FedoraSummit. Please remember that this is just proposed, and by no means set in stone. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora-devel at tlarson.com Fri Nov 17 21:53:21 2006 From: fedora-devel at tlarson.com (Tyler Larson) Date: Fri, 17 Nov 2006 14:53:21 -0700 Subject: Core + Extras In-Reply-To: <455E2A85.1040307@fedoraproject.org> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> <455E2A85.1040307@fedoraproject.org> Message-ID: <455E2F51.4040909@tlarson.com> Rahul Sundaram wrote: > If you havent received the memo yet, there is no core/extras/legacy > starting from the next release. > http://fedoraproject.org/wiki/FedoraSummit. > Rahul > Indeed, I didn't get that memo. The site you linked to didn't so much describe the merger between Core and Extras as much as it did simply hint at at. I would very much appreciate it if you could point us to where we can find information on what this will all mean, and how it will work out. From sundaram at fedoraproject.org Fri Nov 17 22:02:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Nov 2006 03:32:18 +0530 Subject: Core + Extras In-Reply-To: <455E2F51.4040909@tlarson.com> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> <455E2A85.1040307@fedoraproject.org> <455E2F51.4040909@tlarson.com> Message-ID: <455E316A.8050103@fedoraproject.org> Tyler Larson wrote: > Rahul Sundaram wrote: >> If you havent received the memo yet, there is no core/extras/legacy >> starting from the next release. >> http://fedoraproject.org/wiki/FedoraSummit. >> Rahul >> > > Indeed, I didn't get that memo. The site you linked to didn't so much > describe the merger between Core and Extras as much as it did simply > hint at at. I would very much appreciate it if you could point us to > where we can find information on what this will all mean, and how it > will work out. There are links in that page. You probably missed that. http://fedoraproject.org/wiki/FedoraSummit/OpeningCore http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess Rahul From bernie at develer.com Fri Nov 17 22:41:25 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 17 Nov 2006 23:41:25 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163780713.3112.10.camel@dawkins> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> Message-ID: <455E3A95.9070003@develer.com> David Nielsen wrote: >>> So I could definitely see why many KDE users would feel the same way >>> about Konqi. Luckily this one of those things that will naturally >>> resolve itself once Core and Extras gets merged, if the community by >>> then wants KDE to have Konqi as the default then that will happen. >> This might make a good candidate for firstboot - during firstboot the >> person installing the system could choose the default apps that newly >> created users would get. > > Dear heavens no.. One of the strengths of the Fedora desktop is it's > predefined standards. If you like me want a different set of > applications there's the customize now/later option during install. Besides, choosing a web browser and a MUA is a per-user action; It doesn't belong to firstboot, which is a system-wide thing. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Fri Nov 17 23:01:23 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Nov 2006 00:01:23 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163778769.31358.337.camel@laptopd505.fenrus.org> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> Message-ID: <455E3F43.7030202@develer.com> Arjan van de Ven wrote: > The browser one is funny. I know MANY people who will be upset if it's > not firefox, period. That has nothing to do with being pro, neutral or > against KDE, but simple expectation that Firefox is the flag ship open > source thing for many people (they met it first on Windows and started > to take open source more serious, now they look at linux), and they > expect it to be there at least as integrated as the Windows Firefox is. Of course it's just a matter of opinions, but am I the only one considering Firefox (or Thunderbird, and even OpenOffice...) very bad examples of how to design a good open source program? The fact that these applications originated as proprietary software is still very recognizable today. They still are very monolithic in nature, built on their own custom portability and GUI frameworks. They make heavy use of binary or opaque file formats for storing settings and other metadata. And they generally (ab)use threading, or custom plugin, upgrade, and installation systems. I use all these apps daily, but I still feel somewhat uncomfortable with them. Just my 2 cents. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From ndbecker2 at gmail.com Sat Nov 18 00:58:12 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 17 Nov 2006 19:58:12 -0500 Subject: Make kde 1st class in fedora References: Message-ID: I believe most linux advocates would agree that one of linux main strengths is choice. But, user's don't really have choice if they don't know they have choice. I don't want to remove firefox. Firefox is great. I just believe we need a more effective way to alert new users that they have a choice. From mmcgrath at fedoraproject.org Sat Nov 18 01:55:14 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 17 Nov 2006 19:55:14 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> Message-ID: <3237e4410611171755pb39e43ay9c80e9d6e01d1570@mail.gmail.com> On 11/17/06, Mike McGrath wrote: > On 11/17/06, Mike McGrath wrote: > > As of about 8:40 today the CVS box threw a SMART error regarding one > > of its drives. As a result most of the CVS box is presently mounted > > read only. We are working to correct this issue but expect CVS to be > > up and down today. > > > > > Dell has been dispatched and will arrive in 4 hours. CVS will be down > until further notice. Further notice will go well into tonight and probably into tomorow. The drives are pretty messed up and mgalgoci has done great work to get the array's rebuilt but we aren't confident the filesystem will be in working order, we may have to restore from backup. -Mike From pemboa at gmail.com Sat Nov 18 04:26:53 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 18 Nov 2006 22:26:53 +1800 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <16de708d0611172026w65c7f84x3ab490337922e3ab@mail.gmail.com> On 11/18/06, Neal Becker wrote: > I believe most linux advocates would agree that one of linux main strengths > is choice. But, user's don't really have choice if they don't know they > have choice. If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice. Frankly...I think there need to be a 'Dr. Fedora. type app which help a users make (or ignore) the many choices which are available to them. -- Fedora Core 6 and proud From jeff at ocjtech.us Sat Nov 18 05:15:10 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2006 23:15:10 -0600 Subject: Make kde 1st class in fedora In-Reply-To: <455E3A95.9070003@develer.com> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> Message-ID: <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> On Fri, 2006-11-17 at 23:41 +0100, Bernardo Innocenti wrote: > David Nielsen wrote: > > >>> So I could definitely see why many KDE users would feel the same way > >>> about Konqi. Luckily this one of those things that will naturally > >>> resolve itself once Core and Extras gets merged, if the community by > >>> then wants KDE to have Konqi as the default then that will happen. > >> This might make a good candidate for firstboot - during firstboot the > >> person installing the system could choose the default apps that newly > >> created users would get. > > > > Dear heavens no.. One of the strengths of the Fedora desktop is it's > > predefined standards. If you like me want a different set of > > applications there's the customize now/later option during install. > > Besides, choosing a web browser and a MUA is a per-user action; > It doesn't belong to firstboot, which is a system-wide thing. In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis. Jeff -------------- 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 mclasen at redhat.com Sat Nov 18 05:23:36 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 18 Nov 2006 00:23:36 -0500 Subject: Make kde 1st class in fedora In-Reply-To: <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> Message-ID: <1163827416.3141.0.camel@localhost.localdomain> On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > In firstboot, you would be setting the system-wide default. Users would > be able to change their browser on an individual basis. > Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet. From rc040203 at freenet.de Sat Nov 18 05:27:41 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 18 Nov 2006 06:27:41 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163827416.3141.0.camel@localhost.localdomain> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> <1163827416.3141.0.camel@localhost.localdomain> Message-ID: <1163827661.7059.83.camel@mccallum.corsepiu.local> On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote: > On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > > > In firstboot, you would be setting the system-wide default. Users would > > be able to change their browser on an individual basis. > > > > Surprise, users are already able to change their browser on an > individual basis. Try the "Preferred Applications" capplet. Correct me if I'm wrong, but AFAICT, there aren't any means to setup a "machine-wide" or "network-wide" defaults? Ralf From mclasen at redhat.com Sat Nov 18 05:45:29 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 18 Nov 2006 00:45:29 -0500 Subject: Make kde 1st class in fedora In-Reply-To: <1163827661.7059.83.camel@mccallum.corsepiu.local> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> <1163827416.3141.0.camel@localhost.localdomain> <1163827661.7059.83.camel@mccallum.corsepiu.local> Message-ID: <1163828729.3141.3.camel@localhost.localdomain> On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote: > On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote: > > On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > > > > > In firstboot, you would be setting the system-wide default. Users would > > > be able to change their browser on an individual basis. > > > > > > > Surprise, users are already able to change their browser on an > > individual basis. Try the "Preferred Applications" capplet. > Correct me if I'm wrong, but AFAICT, there aren't any means to setup a > "machine-wide" or "network-wide" defaults? > The preferred applications capplet stores its values in gconf. gconf does have system-wide defaults, and you can set them with gconftool-2. From jeff at ocjtech.us Sat Nov 18 05:47:07 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 17 Nov 2006 23:47:07 -0600 Subject: Make kde 1st class in fedora In-Reply-To: <1163827416.3141.0.camel@localhost.localdomain> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> <1163827416.3141.0.camel@localhost.localdomain> Message-ID: <1163828827.3387.9.camel@lt21223.campus.dmacc.edu> On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote: > On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > > > In firstboot, you would be setting the system-wide default. Users would > > be able to change their browser on an individual basis. > > > > Surprise, users are already able to change their browser on an > individual basis. Yes, I should have said, users would *still* be able to change their browser on an individual basis. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Sat Nov 18 06:02:11 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 19 Nov 2006 00:02:11 +1800 Subject: Make kde 1st class in fedora In-Reply-To: <1163828729.3141.3.camel@localhost.localdomain> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> <1163827416.3141.0.camel@localhost.localdomain> <1163827661.7059.83.camel@mccallum.corsepiu.local> <1163828729.3141.3.camel@localhost.localdomain> Message-ID: <16de708d0611172202u5dcf240bw6b319123428d4e0a@mail.gmail.com> On 11/18/06, Matthias Clasen wrote: > On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote: > > On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote: > > > On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > > > > > > > In firstboot, you would be setting the system-wide default. Users would > > > > be able to change their browser on an individual basis. > > > > > > > > > > Surprise, users are already able to change their browser on an > > > individual basis. Try the "Preferred Applications" capplet. > > Correct me if I'm wrong, but AFAICT, there aren't any means to setup a > > "machine-wide" or "network-wide" defaults? > > > > The preferred applications capplet stores its values in gconf. gconf > does have system-wide defaults, and you can set them with gconftool-2. Does KDE touch Gconf? I'd hate to believe a Gnome speicifc solution is beign suggest in a thread abotu KDE. -- Fedora Core 6 and proud From avi at argo.co.il Sat Nov 18 06:37:16 2006 From: avi at argo.co.il (Avi Kivity) Date: Sat, 18 Nov 2006 08:37:16 +0200 Subject: Make kde 1st class in fedora In-Reply-To: <455E3F43.7030202@develer.com> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> Message-ID: <455EAA1C.3040105@argo.co.il> Bernardo Innocenti wrote: Nice troll, but there's a point that can be made out of it: > The fact that these applications originated as proprietary software is > still very recognizable today. What's recognizable is that they're user-oriented instead of developer oriented. > They still are very monolithic in nature, Users like one interface to handle all their needs. Developers | want | to | connect | orthogonal > tools. > built on their own custom portability and GUI frameworks. Most users don't use GTK (and where most of these apps are deployed, GTK would be considered a custom portability framework). > They make heavy use of binary or opaque file formats for storing > settings and other metadata. Users want to configure using a gui. That means a program reads and writes the configuration, so a binary format makes sense. Developers like to vi/emacs the configuration file; most developer-oriented programs never write their configuration file. > And they generally (ab)use threading, Users want the program to be responsive. Developers want purity of design. > or > custom plugin, upgrade, and installation systems. To reach actual users (not developers) you need more than rpm and yum. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From giallu at gmail.com Sat Nov 18 06:58:04 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 18 Nov 2006 07:58:04 +0100 Subject: CVS is busted In-Reply-To: <3237e4410611171755pb39e43ay9c80e9d6e01d1570@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> <3237e4410611171755pb39e43ay9c80e9d6e01d1570@mail.gmail.com> Message-ID: On 11/18/06, Mike McGrath wrote: > On 11/17/06, Mike McGrath wrote: > > On 11/17/06, Mike McGrath wrote: > > > As of about 8:40 today the CVS box threw a SMART error regarding one > > > of its drives. As a result most of the CVS box is presently mounted > > > read only. We are working to correct this issue but expect CVS to be > > > up and down today. > > > > > > > > > Dell has been dispatched and will arrive in 4 hours. CVS will be down > > until further notice. > > > Further notice will go well into tonight and probably into tomorow. > The drives are pretty messed up and mgalgoci has done great work to > get the array's rebuilt but we aren't confident the filesystem will be > in working order, we may have to restore from backup. > Thanks for keeping us informed. Just for information, what backup type/program are you using? How easy is it to recover from bare metal? From nickisgod1 at gmail.com Sat Nov 18 07:19:47 2006 From: nickisgod1 at gmail.com (nick stumpos) Date: Sat, 18 Nov 2006 02:19:47 -0500 Subject: Core + Extras In-Reply-To: <455E316A.8050103@fedoraproject.org> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> <455E2A85.1040307@fedoraproject.org> <455E2F51.4040909@tlarson.com> <455E316A.8050103@fedoraproject.org> Message-ID: <5a89bf30611172319rbbbfbffh13ee2cfb35aed52b@mail.gmail.com> so just to be clear fedora is indeed combining core and extras? On 11/17/06, Rahul Sundaram wrote: > > Tyler Larson wrote: > > Rahul Sundaram wrote: > >> If you havent received the memo yet, there is no core/extras/legacy > >> starting from the next release. > >> http://fedoraproject.org/wiki/FedoraSummit. > >> Rahul > >> > > > > Indeed, I didn't get that memo. The site you linked to didn't so much > > describe the merger between Core and Extras as much as it did simply > > hint at at. I would very much appreciate it if you could point us to > > where we can find information on what this will all mean, and how it > > will work out. > > There are links in that page. You probably missed that. > > http://fedoraproject.org/wiki/FedoraSummit/OpeningCore > http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi at argo.co.il Sat Nov 18 08:09:11 2006 From: avi at argo.co.il (Avi Kivity) Date: Sat, 18 Nov 2006 10:09:11 +0200 Subject: CVS is busted In-Reply-To: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> Message-ID: <455EBFA7.3070400@argo.co.il> Mike McGrath wrote: > As of about 8:40 today the CVS box threw a SMART error regarding one > of its drives. As a result most of the CVS box is presently mounted > read only. We are working to correct this issue but expect CVS to be > up and down today. > Just curious: why the read-only mount? shouldn't the RAID have continued in degraded mode? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From kms at passback.co.uk Sat Nov 18 09:49:56 2006 From: kms at passback.co.uk (Keith Sharp) Date: Sat, 18 Nov 2006 09:49:56 +0000 Subject: Make kde 1st class in fedora In-Reply-To: <1163828729.3141.3.camel@localhost.localdomain> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163779916.3320.12.camel@lt21223.campus.dmacc.edu> <1163780713.3112.10.camel@dawkins> <455E3A95.9070003@develer.com> <1163826910.3387.6.camel@lt21223.campus.dmacc.edu> <1163827416.3141.0.camel@localhost.localdomain> <1163827661.7059.83.camel@mccallum.corsepiu.local> <1163828729.3141.3.camel@localhost.localdomain> Message-ID: <1163843396.10988.10.camel@animal.passback.co.uk> On Sat, 2006-11-18 at 00:45 -0500, Matthias Clasen wrote: > On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote: > > On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote: > > > On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote: > > > > > > > In firstboot, you would be setting the system-wide default. Users would > > > > be able to change their browser on an individual basis. > > > > > > > > > > Surprise, users are already able to change their browser on an > > > individual basis. Try the "Preferred Applications" capplet. > > Correct me if I'm wrong, but AFAICT, there aren't any means to setup a > > "machine-wide" or "network-wide" defaults? > > > > The preferred applications capplet stores its values in gconf. gconf > does have system-wide defaults, and you can set them with gconftool-2. Or you can use Sabayon[1][2] to administer GNOME desktop settings across multiple user accounts. Keith. [1] http://www.gnome.org/projects/sabayon/ [2] http://fedoraproject.org/extras/6/i386/repodata/repoview/sabayon-0-2.12.4-4.fc6.html From galibert at pobox.com Sat Nov 18 10:48:35 2006 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 18 Nov 2006 11:48:35 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <455EAA1C.3040105@argo.co.il> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> Message-ID: <20061118104835.GA55868@dspnet.fr.eu.org> On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote: > Users want to configure using a gui. That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because: - it's easier to find a file in a specific place than to find the configuration-application-of-the-day - it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up. - you can google using its contents - you often have useful comments in them, where the GUI equivalent requires a number of manipulations to access - you can grep a bunch of files to help finding where is the configuration concerning - it's way easier to talk about it in email - you don't need to leave the keyboard for all your configuration and you can see all the configuration options on one screen Of course, that breaks down if your "text" file is actually computer-oriented xml crap with a randomly generated name hidden 3 levels down in a dot-directory. Debutant users don't want to configure, period. Advanced users want efficiency. Efficient GUI configuration tools are extremely rare. OG. From avi at argo.co.il Sat Nov 18 11:11:20 2006 From: avi at argo.co.il (Avi Kivity) Date: Sat, 18 Nov 2006 13:11:20 +0200 Subject: Make kde 1st class in fedora In-Reply-To: <20061118104835.GA55868@dspnet.fr.eu.org> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> Message-ID: <455EEA58.4040306@argo.co.il> Olivier Galibert wrote: > On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote: > >> Users want to configure using a gui. >> > > That's a common misconception. Lots of users are perfectly ok with > text configuration files, and even often like them more, because: > > How many of these users are IT workers or computer enthusiasts? > - it's easier to find a file in a specific place than to find the > configuration-application-of-the-day > It's only easier for developers. Users know how to open Tools|Options. They have no idea where the config file sits. > - it's easier to find what you want in it, especially when your setup > is nonstandard in any slight way. Things hidden in the new tab of the > day which appears only when you click on allow advanced in a dialog > box coming from a menu can be quite frustrating. In other words, the > interface part of a text configuration file is much harder to fuck up. > If the configuration file is of any size at all (postfix, apache) you have to read a huge text file to find something. If the configuration file omits some of the options, you have to read the manual page. > - you can google using its contents > Shouldn't you try the application's help first? > - you often have useful comments in them, where the GUI equivalent > requires a number of manipulations to access > Context-sensitive help? > - you can grep a bunch of files to help finding where is the > configuration concerning > I'm a user. What's grep again? > - it's way easier to talk about it in email > > Especially for developers who dislike html mail. Users don't want to talk about options, they want to change them. > - you don't need to leave the keyboard for all your configuration and > A good GUI will allow you to do everything through the keyboard (yes, I've used one that does). > you can see all the configuration options on one screen > Again, assuming a short file, in which case the options dialog will be short as well. > Of course, that breaks down if your "text" file is actually > computer-oriented xml crap with a randomly generated name hidden 3 > levels down in a dot-directory. > In that case it's probably designed for machine writing. Hopefully there's a GUI for it. > Debutant users don't want to configure, period. Advanced users want > efficiency. Efficient GUI configuration tools are extremely rare. > Efficieny for configuration? Do you measure it in configs/sec? A configuration task is usually one for which you don't know all the details, since it is rare. In that case the most efficient interface is one that has visible hierarchical grouping so you can learn your way through it. An example: Thunderbird's Edit|Preferences|Display, "Plain Text Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js mail.wrap_long_lines (it isn't there, you have to google for it or look in Thunderbird's config editor) [yes, it's easier to type in an email. but you'd get unwrapped text much. much sooner with the GUI] For system administrators and developers, text files are fine. For normal users, let them have their GUI. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From mark at borkware.net Sat Nov 18 11:12:25 2006 From: mark at borkware.net (Mark Rosenstand) Date: Sat, 18 Nov 2006 12:12:25 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163488526.15249.230.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> Message-ID: <1163848345.7866.12.camel@mjollnir.borkware.net> On Tue, 2006-11-14 at 08:15 +0100, Arjan van de Ven wrote: > On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote: > > Arjan van de Ven (arjan at fenrus.demon.nl) said: > > > I really like this idea; it's a simple "cat" and it can be done at a > > > time where latency doesn't matter... (even in cron.daily) > > > > > > Oh... this opens more options. This also allows the "sort by > > > blocknumber" to be done at this point and taken out of the critical > > > latency part...... > > > > > > great idea! > > > > Of course, that then makes shutdown take twice as long. > > if you do it at shutdown, which is again a latency path :) > cron.daily/weekly is less so ;) Or post-{install,remove} of the packages that put files in readahead.d. There's no need to run the script if nothing has changed, and if you upgrade affected packages and reboot before the next day, the libs and config will be out of sync. From buildsys at redhat.com Sat Nov 18 11:16:39 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 18 Nov 2006 06:16:39 -0500 Subject: rawhide report: 20061118 changes Message-ID: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> Updated Packages: booty-0.81-1 ------------ * Fri Nov 17 2006 Peter Jones - 0.81-1 - Use "--stage2=" in the script we pass to grub to install the bootloader, so it won't write to the disk's device node. - Use isys's drive cache instead of creating our own, so we get dm device splitting/combining correctly. - Use a sorted drive order so we don't clobber kickstart's bootloader config (clumens, #214881). control-center-1:2.17.1-5.fc7 ----------------------------- * Fri Nov 17 2006 Ray Strode - 2.17.1-5 - apply aforementioned thumbnail fixups * Fri Nov 17 2006 Ray Strode - 2.17.1-4 - Drop unused/bogus patches - Try to fix up background capplet thumbnail code again (better this time) - rearrange patches so that vendor patches end up at the end eclipse-1:3.2.1-21.fc7 ---------------------- * Fri Nov 17 2006 Ben Konrath 3.2.1-21 - Add patch to workaround an xml parsing bug in libgcj (gcc bug #29853). - Resolves: #209393. * Fri Nov 17 2006 Andrew Overholt 3.2.1-20 - Revise gre64 patch to just do ppc64 addition and not ordering change. evolution-sharp-0.12.0-1.fc7 ---------------------------- * Fri Nov 17 2006 Matthew Barnes - 0.12.0-1.fc7 - Update to 0.12.0 - Don't ship unused patches. - Remove evolution-sharp-evo26.patch (fixed upstream). - Remove evolution-sharp-0.11.1-evo28.patch (fixed upstream). gnome-python2-2.16.2-2.fc7 -------------------------- * Fri Nov 17 2006 Matthew Barnes - 2.16.2-2.fc7 - Fix some minor packaging bugs (RH bug #203532). gnome-system-monitor-2.17.2.1-2.fc7 ----------------------------------- * Sat Nov 18 2006 Matthias Clasen - 2.17.2.1-2 - Add disto info gtk2-2.10.6-3.fc7 ----------------- * Fri Nov 17 2006 Matthias Clasen - 2.10.6-3 - Rework the filechooser search to support tracker, too kudzu-1.2.61-1 -------------- * Fri Nov 17 2006 Bill Nottingham - 1.2.61-1 - fix crash on powermac (#216173) - fix network configuration for devices that have firmware (#214235) - fix ibmveth for anaconda (#215578) libdrm-2.3.0-1.fc7 ------------------ * Fri Nov 17 2006 Adam Jackson 2.3.0-1.fc7 - Update to 2.3.0 from upstream. - Add nouveau userspace header. * Wed Jul 26 2006 Kristian H??gsberg - 2.0.2-3.fc6 - Build for rawhide. * Wed Jul 26 2006 Kristian H??gsberg - 2.0.2-2.fc5.aiglx - Build for fc5 aiglx repo. libsoup-2.2.97-2.fc7 -------------------- * Fri Nov 17 2006 Matthias Clasen - 2.2.97-2 - Avoid accidentally exported symbols (#215919) parted-1.8.0-1.fc7 ------------------ * Fri Nov 17 2006 David Cantrell - 1.8.0-1 - Upgrad to GNU parted-1.8.0 policycoreutils-1.33.1-9.fc7 ---------------------------- * Fri Nov 17 2006 Dan Walsh 1.33.1-9 - Add Amy Grifis Patch to preserve newrole exit status pwlib-1.10.2-3.fc7 ------------------ * Fri Nov 17 2006 Daniel Veillard - 1.10.2-3 - fix library permissions - Resolves: rhbz#215916 pyparted-1.8.0-1.fc7 -------------------- * Fri Nov 17 2006 David Cantrell - 1.8.0-1 - Bump version to 1.8.0 and require parted >= 1.8.0 - Remove python-abi Requires line since rpm handles that automatically * Wed Aug 30 2006 David Cantrell - 1.7.3-1 - Include parted/constraint.h in required header files * Wed Aug 30 2006 David Cantrell - 1.7.2-2 - Require parted-1.7.1 or higher scim-1.4.5-3.fc7 ---------------- * Fri Nov 17 2006 Jens Petersen - 1.4.5-3 - add scim-panel-observe-workarea-xprop.patch to make toolbar respect desktop work area (Takuro Ashie, #204442) - add scim_x11_frontend-ic-focus-LTC27940-215953.patch from cvs to fix XIM focus preedit commit issue (#215953) - add scim_panel_gtk-emacs-cc-style.patch to set emacs cc-mode style for panel - reduce systray icon size even more to 11 selinux-policy-2.4.5-1.fc7 -------------------------- * Wed Nov 15 2006 Dan Walsh 2.4.5-1 - Move to upstream version which accepted my patches tcpdump-14:3.9.4-9.fc7 ---------------------- * Fri Nov 17 2006 Miroslav Lichvar - 14:3.9.4-9 - fix processing of Prism and AVS headers (#206686) - fix arp2ethers script - update ethercodes.dat - move pcap man page to devel package tix-1:8.4.2-1 ------------- * Sat Nov 18 2006 Miloslav Trmac - 1:8.4.2-1 - Update to tix-8.4.2 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From hughsient at gmail.com Sat Nov 18 11:28:33 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 18 Nov 2006 11:28:33 +0000 Subject: rawhide report: 20061118 changes In-Reply-To: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> Message-ID: <1163849313.3566.2.camel@localhost.localdomain> On Sat, 2006-11-18 at 06:16 -0500, buildsys at redhat.com wrote: > * Fri Nov 17 2006 Adam Jackson 2.3.0-1.fc7 > - Update to 2.3.0 from upstream. > - Add nouveau userspace header. Hey, looking good. What's the consequence of this? We can start hacking nouveau[1] easily? Or am I getting excited over nothing? Richard. [1] http://nouveau.freedesktop.org/wiki From david at lovesunix.net Sat Nov 18 11:29:38 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 18 Nov 2006 12:29:38 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <20061118104835.GA55868@dspnet.fr.eu.org> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> Message-ID: <1163849378.11262.15.camel@dawkins> l?r, 18 11 2006 kl. 11:48 +0100, skrev Olivier Galibert: > On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote: > > Users want to configure using a gui. That displays the fallacy that users want to configure stuff. They might want the option to tune an application but generally users just want applications to work and will as a rule rather live with a suboptimal default configuration for their soecific job than dig through options and confusing tools/dialogs. The lesson we have to take away from this is to strive for good default but remain configurable through a nice uniform interface. This is exactly why gconf is so cool, translatable decriptor strings explain what every key does for the user who likes to tweak the more exoteric parts of their applications and the rest get a nice clean interface with good defaults and the bare essencesial options. Please don't assume that users _want_ to configure, it's not an end goal, it's a means to get work done. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From nicolas.mailhot at laposte.net Sat Nov 18 11:37:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Nov 2006 12:37:47 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <455EEA58.4040306@argo.co.il> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> <455EEA58.4040306@argo.co.il> Message-ID: <1163849868.8380.38.camel@rousalka.dyndns.org> Le samedi 18 novembre 2006 ? 13:11 +0200, Avi Kivity a ?crit : > Olivier Galibert wrote: > > On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote: > > > >> Users want to configure using a gui. > >> > > > > That's a common misconception. Lots of users are perfectly ok with > > text configuration files, and even often like them more, because: > How many of these users are IT workers or computer enthusiasts? Yea, right, ever tried to explain a GUI procedure to someone over 40 (aggravating factor : over the telephone) ? They don't know what right-click is, they don't know conventions, they get hopelessly confused by renamed menu entries or new themes that change icons they're used to. GUI power is massively overrated (even when it's designed properly in the first place, which is the exception, especially for big proprietary offerings) (and that's not musch easier for younger people) Nobody but computer enthusiasts has the time to browse all the app menus and screens to find the place where the developper moved the magic button designed to help him not writing a text file > > - it's easier to find a file in a specific place than to find the > > configuration-application-of-the-day > > > > It's only easier for developers. Users know how to open Tools|Options. 1. No they don't 2. when they do they recoil in horror before the mass of badly qualified checkboxes > They have no idea where the config file sits. Unlike the GUI, the config file location is usually stable. They can note it down. Mapping a GUI route OTOH is a disaster > > - it's easier to find what you want in it, especially when your setup > > is nonstandard in any slight way. Things hidden in the new tab of the > > day which appears only when you click on allow advanced in a dialog > > box coming from a menu can be quite frustrating. In other words, the > > interface part of a text configuration file is much harder to fuck up. > > > > If the configuration file is of any size at all (postfix, apache) you > have to read a huge text file to find something. And usually you have the text explanation right next to the config option. With examples even. You don't realise what a godsend it is after the 3-word explanation you have next to a gui checkbox > If the configuration file omits some of the options, you have to read > the manual page. Hint : do you actually think people grok GUIs without manuals or helpful power users to explain them what the heck the convoluted label language means ? > > - you can google using its contents > > > > Shouldn't you try the application's help first? ROTFL you're hopeless > > - you often have useful comments in them, where the GUI equivalent > > requires a number of manipulations to access > Context-sensitive help? Right-click, what's a right click ? What's a right-clickable object ? Why do you think apple gets by with a single button mouse ? > > - it's way easier to talk about it in email > Especially for developers who dislike html mail. Users don't want to > talk about options, they want to change them. No. Users don't want to talk about options period. They don't want to change them be it in the config file or in the GUI > > An example: Thunderbird's Edit|Preferences|Display, "Plain Text > Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js > mail.wrap_long_lines (it isn't there, you have to google for it or look > in Thunderbird's config editor) > > [yes, it's easier to type in an email. but you'd get unwrapped text > much. much sooner with the GUI] That's remain to be proven. Comparing speed once users have learnt the GUI is cheating. > For system administrators and developers, text files are fine. For > normal users, let them have their GUI. If only it was their GUI and not some monstruosity designed to show of everything is GUI-accessible? -- Nicolas Mailhot From gajownik at gmail.com Sat Nov 18 11:52:59 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Sat, 18 Nov 2006 12:52:59 +0100 Subject: rawhide report: 20061118 changes In-Reply-To: <1163849313.3566.2.camel@localhost.localdomain> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> Message-ID: <455EF41B.4090707@gmail.com> Dnia 11/18/2006 12:30 PM, U?ytkownik Richard Hughes napisa?: > Hey, looking good. What's the consequence of this? We can start hacking > nouveau[1] easily? Or am I getting excited over nothing? Adam Jackson is incorporating nouveau driver into xorg-x11-drv-nv (like with modeseting intel driver and xorg-x11-drv-i810) :) Regards, Dawid -- ^_* From nicolas.mailhot at laposte.net Sat Nov 18 11:13:11 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 18 Nov 2006 12:13:11 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <455EAA1C.3040105@argo.co.il> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> Message-ID: <1163848396.8380.21.camel@rousalka.dyndns.org> Le samedi 18 novembre 2006 ? 08:37 +0200, Avi Kivity a ?crit : > Bernardo Innocenti wrote: > > Nice troll, but there's a point that can be made out of it: > > > The fact that these applications originated as proprietary software is > > still very recognizable today. > > What's recognizable is that they're user-oriented instead of developer > oriented. No, what's recognizable is they're PHB-oriented, PHB asked for a single tool, PHB got delivered a single tool, even at the cost of tying vastly different pieces of code with bandaids > > They still are very monolithic in nature, > > Users like one interface to handle all their needs. Developers | want | > to | connect | orthogonal > tools. In my experience users are quite happy with several interfaces as long as they're consistent and not overlapping. It's developers that insist on making private copies and forks of uncounted libs, then slap an "unifying" GUI over the mess (in a FLOSS context they get reminded of proper practices by distributions which hate having to ship and qualify multiple versions of the same thing; in a proprietary context they're given free run). The "users like one interface" is a myth, firefox succeeded because it broke the old mozilla in multiple interfaces, and before that moz was eating the netscape-branded version which had welded yet more stuff in the single interface. > > built on their own custom portability and GUI frameworks. > > Most users don't use GTK That's why using one-of-a-kind proprietary framework is better ? One of the clearest and most appreciated changes in OO.o 2 was to expose native widgets to users instead of the old SO thing. Mac users BTW complain because they were forgotten in this change. > > They make heavy use of binary or opaque file formats for storing > > settings and other metadata. > > Users want to configure using a gui. That means a program reads and > writes the configuration, so a binary format makes sense. There are many ways to have program-writeable text format (netscape/mozilla to name a big GUI app has been doing it for as long as I can remember), so again it's not a user wish but programming laziness the proprietary context allowed > > And they generally (ab)use threading, > > Users want the program to be responsive. Developers want purity of design. Yeah, right, that's why every "liberated" program is described as a pig compared to the FLOSS alternatives. Hint : purity of design translates in perf wins, hacks translate in microbenchmark wins for the first version (and then no one dares updating them for the next ones so all the clever ugly code rots) > > or > > custom plugin, upgrade, and installation systems. > > To reach actual users (not developers) you need more than rpm and yum. Wrong. The percentage of users willing to go the specific update route is vanishingly small, only enthousiasts are willing to spend the time learning an update system per app. Developers will want source tarballs Enthousiasts will want a way to update everything on their system to the latest bling, and are willing to jump through hoops and custom updaters for this. Everyone else (99% of users) just want the stuff to be pre-installed and transparently updated with the rest of the system using the system tools. For all its faults windows update showed pretty conclusively even in the windows world the power of a single unified update service. Regards, -- Nicolas Mailhot From ddmbox2 at yahoo.co.uk Sat Nov 18 13:31:06 2006 From: ddmbox2 at yahoo.co.uk (dexter) Date: Sat, 18 Nov 2006 13:31:06 +0000 Subject: rawhide report: 20061118 changes In-Reply-To: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> Message-ID: <200611181331.06921.ddmbox2@yahoo.co.uk> On Sat November 18 2006 11:16, buildsys at redhat.com wrote: > control-center-1:2.17.1-5.fc7 > ----------------------------- > * Fri Nov 17 2006 Ray Strode - 2.17.1-5 > - apply aforementioned thumbnail fixups > > * Fri Nov 17 2006 Ray Strode - 2.17.1-4 > - Drop unused/bogus patches > - Try to fix up background capplet thumbnail code again (better this time) > - rearrange patches so that vendor patches end up at the end error: %pre(control-center-2.17.1-5.fc7.i386) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping control-center-2.17.1-5.fc7 and --> Running transaction check --> Processing Dependency: libparted-1.7.so.1 for package: gparted --> Finished Dependency Resolution Error: Missing Dependency: libparted-1.7.so.1 is needed by package gparted ...dex Send instant messages to your online friends http://uk.messenger.yahoo.com From bernie at develer.com Sat Nov 18 14:31:47 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Nov 2006 15:31:47 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <455EAA1C.3040105@argo.co.il> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> Message-ID: <455F1953.3010705@develer.com> Avi Kivity wrote: >> The fact that these applications originated as proprietary software is >> still very recognizable today. > > What's recognizable is that they're user-oriented instead of developer > oriented. > [...] I can hardly disagree with all your arguments. After all, the programs I've been whining about are top-rated killer applications, and very appreciated in the Windows world too. As you pointed out, maybe my perspective is not user-oriented, because I'm actually a developer (or should I say a mature UNIX diehard?) with distinct habits and usage patterns. To us UNIX geeks, a good text editor is a much better configuration tool than any dialog box exactly because it's orthogonal with the application and provides powerful tools such as search, infinite undo and the ability to keep copies of different configurations etc. When we, the minority, choose an application for our own *personal* use, we don't care about the rest of the world and shouldn't need to. If an application design is unable to satisfy both the needs of regular users and people with "special requirements" like us, we are left behind. As Spok told us, the needs of the many outweigh the needs of the few, but many of us have been using Linux and other UNIX flavours because they were designed by our ancestors with our unusual behavioral patterns in mind. Where should we turn to if the usability of our platform gets compromised for the sake of a few billion lusers? ;-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From jkeating at redhat.com Sat Nov 18 15:10:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 18 Nov 2006 10:10:18 -0500 Subject: Make kde 1st class in fedora In-Reply-To: <1163827661.7059.83.camel@mccallum.corsepiu.local> References: <1163827416.3141.0.camel@localhost.localdomain> <1163827661.7059.83.camel@mccallum.corsepiu.local> Message-ID: <200611181010.18618.jkeating@redhat.com> On Saturday 18 November 2006 00:27, Ralf Corsepius wrote: > Correct me if I'm wrong, but AFAICT, there aren't any means to setup a > "machine-wide" or "network-wide" defaults? saybian I think is that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Nov 18 15:11:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 18 Nov 2006 10:11:13 -0500 Subject: Core + Extras In-Reply-To: <5a89bf30611172319rbbbfbffh13ee2cfb35aed52b@mail.gmail.com> References: <455E316A.8050103@fedoraproject.org> <5a89bf30611172319rbbbfbffh13ee2cfb35aed52b@mail.gmail.com> Message-ID: <200611181011.13773.jkeating@redhat.com> On Saturday 18 November 2006 02:19, nick stumpos wrote: > so just to be clear fedora is indeed combining core and extras? That is our intent. We still need to get approval from folks like the Fedora Extras leaders, the Fedora Legacy leaders, Red Hat engineering management, etc... -- Jesse Keating Release Engineer: Fedora -------------- 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 Sat Nov 18 15:22:03 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 18 Nov 2006 16:22:03 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163848345.7866.12.camel@mjollnir.borkware.net> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> <1163848345.7866.12.camel@mjollnir.borkware.net> Message-ID: <455F251B.9070409@volny.cz> Mark Rosenstand napsal(a): > On Tue, 2006-11-14 at 08:15 +0100, Arjan van de Ven wrote: >> On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote: >>> Arjan van de Ven (arjan at fenrus.demon.nl) said: >>>> I really like this idea; it's a simple "cat" and it can be done at a >>>> time where latency doesn't matter... (even in cron.daily) >>>> >>>> Oh... this opens more options. This also allows the "sort by >>>> blocknumber" to be done at this point and taken out of the critical >>>> latency part...... >>>> >>>> great idea! >>> Of course, that then makes shutdown take twice as long. >> if you do it at shutdown, which is again a latency path :) >> cron.daily/weekly is less so ;) > > Or post-{install,remove} of the packages that put files in readahead.d. > > There's no need to run the script if nothing has changed, Does prelink overwrite the modified files in place, or does it create new versions as separate files and rename()s them? Mirek From tibbs at math.uh.edu Sat Nov 18 15:31:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Nov 2006 09:31:26 -0600 Subject: CVS is busted In-Reply-To: <455EBFA7.3070400@argo.co.il> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> Message-ID: >>>>> "AK" == Avi Kivity writes: AK> Just curious: why the read-only mount? shouldn't the RAID have AK> continued in degraded mode? Probably because something else bad happened that just completely screwed up the SCSI bus and corrupted data on multiple disks. - J< From Dax at gurulabs.com Sat Nov 18 15:50:57 2006 From: Dax at gurulabs.com (Dax Kelson) Date: Sat, 18 Nov 2006 8:50:57 -0700 Subject: Core + Extras In-Reply-To: <200611181011.13773.jkeating@redhat.com> References: <455E316A.8050103@fedoraproject.org> <5a89bf30611172319rbbbfbffh13ee2cfb35aed52b@mail.gmail.com> <200611181011.13773.jkeating@redhat.com> Message-ID: <3239-SnapperMsg827D11E1C184DC68@[68.26.216.186]> ...... Original Message ....... On Sat, 18 Nov 2006 10:11:13 -0500 "Jesse Keating" wrote: >On Saturday 18 November 2006 02:19, nick stumpos wrote: >> so just to be clear fedora is indeed combining core and extras? > >That is our intent. We still need to get approval from folks like the Fedora >Extras leaders, the Fedora Legacy leaders, Red Hat engineering management, >etc... > So far each RHEL version has had a corresponding FC version that was extremely close in initially shipped package versions. For example: RHL7.2 - RHEL2.1 FC1 - RHEL3 FC3 - RHEL4 FC6 - RHEL5 (?) Will this new Fedora development model change this? ___ Dax Kelson Sent with my Treo (please pardon any brevity) From kevin.kofler at chello.at Sat Nov 18 16:17:32 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 18 Nov 2006 16:17:32 +0000 (UTC) Subject: Make kde 1st class in fedora References: <16de708d0611172026w65c7f84x3ab490337922e3ab@mail.gmail.com> Message-ID: Arthur Pemberton gmail.com> writes: > If you don't believe the quoted statement install Windows......you can > install several other browsers, text editors, media players > etc.....but if the link to the 'default' browser says Internet (or in > the case of gaim, 'Instant Messenger') then a large percentage of > users will _not_ benifit from having a choice. I must say I hate that too. This stuff belongs into the GenericName field, not the Name field. Of course, this means GNOME would have to be fixed to display both Name and GenericName as KDE has done for years. (And KDE allows you to configure it, so if you want just the name or just the GenericName, you can have that.) Kevin Kofler From jkeating at redhat.com Sat Nov 18 16:27:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 18 Nov 2006 11:27:50 -0500 Subject: Core + Extras In-Reply-To: <3239-SnapperMsg827D11E1C184DC68@[68.26.216.186]> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@[68.26.216.186]> Message-ID: <200611181127.50995.jkeating@redhat.com> On Saturday 18 November 2006 10:50, Dax Kelson wrote: > Will this new Fedora development model change this? Most likely no. We're still planning on sticking to the 6 month cycle, and RHEL could pick up a release and run with it. Whether or not RHEL uses the exact binaries is up for discussion, but most likely not, just the same srpms. Some of the software in Core may not find any real community users, some stuff that is RHEL only, and may not be carried forward, but it may, we're really not sure until we move everything and see how things shake out. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Sat Nov 18 16:38:22 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 18 Nov 2006 16:38:22 +0000 Subject: Make kde 1st class in fedora In-Reply-To: References: <16de708d0611172026w65c7f84x3ab490337922e3ab@mail.gmail.com> Message-ID: <1163867902.3529.3.camel@localhost.localdomain> On Sat, 2006-11-18 at 16:17 +0000, Kevin Kofler wrote: > Arthur Pemberton gmail.com> writes: > > If you don't believe the quoted statement install Windows......you can > > install several other browsers, text editors, media players > > etc.....but if the link to the 'default' browser says Internet (or in > > the case of gaim, 'Instant Messenger') then a large percentage of > > users will _not_ benifit from having a choice. > > I must say I hate that too. This stuff belongs into the GenericName field, not > the Name field. Of course, this means GNOME would have to be fixed to display > both Name and GenericName as KDE has done for years. (And KDE allows you to > configure it, so if you want just the name or just the GenericName, you can > have that.) This also bothers me greatly. If GNOME was fixed to use both names (or set to use the GenericName for RHEL and Name for Fedora) should we start using "Firefox" rather than "Web browser"? Richard. From david at lovesunix.net Sat Nov 18 17:02:22 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 18 Nov 2006 18:02:22 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <1163867902.3529.3.camel@localhost.localdomain> References: <16de708d0611172026w65c7f84x3ab490337922e3ab@mail.gmail.com> <1163867902.3529.3.camel@localhost.localdomain> Message-ID: <1163869342.11262.27.camel@dawkins> l?r, 18 11 2006 kl. 16:38 +0000, skrev Richard Hughes: > On Sat, 2006-11-18 at 16:17 +0000, Kevin Kofler wrote: > > Arthur Pemberton gmail.com> writes: > > > If you don't believe the quoted statement install Windows......you can > > > install several other browsers, text editors, media players > > > etc.....but if the link to the 'default' browser says Internet (or in > > > the case of gaim, 'Instant Messenger') then a large percentage of > > > users will _not_ benifit from having a choice. > > > > I must say I hate that too. This stuff belongs into the GenericName field, not > > the Name field. Of course, this means GNOME would have to be fixed to display > > both Name and GenericName as KDE has done for years. (And KDE allows you to > > configure it, so if you want just the name or just the GenericName, you can > > have that.) > > This also bothers me greatly. If GNOME was fixed to use both names (or > set to use the GenericName for RHEL and Name for Fedora) should we start > using "Firefox" rather than "Web browser"? I'd strongly object to using Name over GenericName just because we are Fedora. It has a significant discoverablity advantage for users to use GenericName which we would be throwing out. Users who want to change their application setup should also have the option to change the naming scheme, maybe in a TweakUI type thing or as part of the menu configuration/editing. . David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mmcgrath at fedoraproject.org Sat Nov 18 17:17:11 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 18 Nov 2006 11:17:11 -0600 Subject: CVS is busted In-Reply-To: References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <3237e4410611170830l6d2d2edn45db8323c133825a@mail.gmail.com> <3237e4410611171755pb39e43ay9c80e9d6e01d1570@mail.gmail.com> Message-ID: <3237e4410611180917m34f70640j338c9a0905c2e6e6@mail.gmail.com> On 11/18/06, Gianluca Sforna wrote: > On 11/18/06, Mike McGrath wrote: > > On 11/17/06, Mike McGrath wrote: > > > On 11/17/06, Mike McGrath wrote: > > > > As of about 8:40 today the CVS box threw a SMART error regarding one > > > > of its drives. As a result most of the CVS box is presently mounted > > > > read only. We are working to correct this issue but expect CVS to be > > > > up and down today. > > > > > > > > > > > > > Dell has been dispatched and will arrive in 4 hours. CVS will be down > > > until further notice. > > > > > > Further notice will go well into tonight and probably into tomorow. > > The drives are pretty messed up and mgalgoci has done great work to > > get the array's rebuilt but we aren't confident the filesystem will be > > in working order, we may have to restore from backup. > > > > Thanks for keeping us informed. > > Just for information, what backup type/program are you using? > How easy is it to recover from bare metal? > We're using BackupPC. At present we can't backup everything on every box so we're only getting whats important (that will change with the new backup server). Bare metal for the cvs box though shouldn't be to bad once we get the OS back on it. -Mike From mmcgrath at fedoraproject.org Sat Nov 18 17:28:17 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 18 Nov 2006 11:28:17 -0600 Subject: CVS is busted In-Reply-To: References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> Message-ID: <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> On 18 Nov 2006 09:31:26 -0600, Jason L Tibbitts III wrote: > >>>>> "AK" == Avi Kivity writes: > > AK> Just curious: why the read-only mount? shouldn't the RAID have > AK> continued in degraded mode? > > Probably because something else bad happened that just completely > screwed up the SCSI bus and corrupted data on multiple disks. > > - J< > We're talking about multiple failures across multiple drives, possibly a backplane. Here's the current plan. 1) Move proxy 3-4 into the f.rh.c cluster so we can take our new dells back. 2) Grab one of the new Dells and build the new cvs box. This will allow us to A) trust the hardware (we're all a little wary about the current cvs box) and B) build a new box with atleast access to the old box if we're missing something. It will also allow us greater capacity with regards to future growth and the whole FC+FC=Fedora thing. 3) Restore backups to the new cvs box. 4) test test test 5) Release to the wild and fix bugs as needed. 6) Take the old cvs box and run full diagnostics before we rebuild it (it'll be come one of our db servers, either primary or backup) Right now mgalgoci is working working on steps 1 and 2. When they are done I'll be on step 3 and we'll need a few people for 4. We'll probably discuss in #fedora-extras when the time comes. Bottom line, this sucks but we're working on it. Should be up and better than ever by Monday. -Mike From mrsam at courier-mta.com Sat Nov 18 18:19:50 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 18 Nov 2006 13:19:50 -0500 Subject: Perl bindings for RPM in FC6 Message-ID: What's the deal with RPM2.pm, it's not in FC6, nor in Extras? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kloczek at zie.pg.gda.pl Sat Nov 18 18:42:51 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Sat, 18 Nov 2006 19:42:51 +0100 Subject: rawhide report: 20061118 changes In-Reply-To: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> Message-ID: <1163875371.3723.2.camel@kloczek01.pracownicy.zie> Dnia 18-11-2006, sob o godzinie 06:16 -0500, buildsys at redhat.com napisa?(a): [..] > libdrm-2.3.0-1.fc7 > ------------------ > * Fri Nov 17 2006 Adam Jackson 2.3.0-1.fc7 > - Update to 2.3.0 from upstream. > - Add nouveau userspace header. Without new mesa (IIRC not yet released) and new X server it is piece of crap. Current mesa does not build on libdrm 2.3.0. kloczek From gilboad at gmail.com Sat Nov 18 19:20:33 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 18 Nov 2006 21:20:33 +0200 Subject: Make kde 1st class in fedora In-Reply-To: References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> Message-ID: <1163877633.15370.4.camel@gilboa-home-dev.localhost> On Fri, 2006-11-17 at 18:04 +0000, Kevin Kofler wrote: > David Nielsen lovesunix.net> writes: > > Funny as a GNOME user, the first thing I do is replace Firefox with > > Epiphany as it integrates better with my desktop. > > And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox > altogether (considering all that trademark crap) and default GNOME to Epiphany > (built against xulrunner - firefox-devel is only a temporary hack anyway) and > KDE to Konqueror? > > Kevin Kofler > Because konq is -years- behind firefox when it comes to supporting non-English sites and has superior extensions. Nothing stops you from configuring -your- installation as -you- like it. Screwing -my- setup just because -you're- too lazy to waste 2 minutes on customization is absurd. - Gilboa From gilboad at gmail.com Sat Nov 18 19:22:38 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 18 Nov 2006 21:22:38 +0200 Subject: Make kde 1st class in fedora In-Reply-To: <1163877633.15370.4.camel@gilboa-home-dev.localhost> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <1163779449.3112.7.camel@dawkins> <1163877633.15370.4.camel@gilboa-home-dev.localhost> Message-ID: <1163877758.15370.7.camel@gilboa-home-dev.localhost> On Sat, 2006-11-18 at 21:20 +0200, Gilboa Davara wrote: > On Fri, 2006-11-17 at 18:04 +0000, Kevin Kofler wrote: > > David Nielsen lovesunix.net> writes: > > > Funny as a GNOME user, the first thing I do is replace Firefox with > > > Epiphany as it integrates better with my desktop. > > > > And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox > > altogether (considering all that trademark crap) and default GNOME to Epiphany > > (built against xulrunner - firefox-devel is only a temporary hack anyway) and > > KDE to Konqueror? > > > > Kevin Kofler > > > > Because konq is -years- behind firefox when it comes to supporting > non-English sites and has superior extensions. > Nothing stops you from configuring -your- installation as -you- like it. > Screwing -my- setup just because -you're- too lazy to waste 2 minutes on > customization is absurd. > > - Gilboa > > FYI, I use KDE as main DE. (But I use non-KDE applications when they suite my needs - OO, Evolution, Firefox, Gimp, gvim, etc) - Gilboa From fedora at camperquake.de Sat Nov 18 19:32:22 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 18 Nov 2006 20:32:22 +0100 Subject: rawhide report: 20061118 changes In-Reply-To: <455EF41B.4090707@gmail.com> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> <455EF41B.4090707@gmail.com> Message-ID: <20061118203222.6f477ad0@nausicaa.camperquake.de> Hi. Dawid Gajownik wrote: > Adam Jackson is incorporating nouveau driver into xorg-x11-drv-nv (like > with modeseting intel driver and xorg-x11-drv-i810) :) Was that supposed to be a joke? I thought that the nouveau project had not produced anything close to usable code up to now, bot I may be mistaken, of course. -- My Uncle Larry has a saying, "Never play proctologist with an unwilling goose." Okay, so Uncle Larry drinks a bit. -- Yobaval From david at lovesunix.net Sat Nov 18 19:46:11 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 18 Nov 2006 20:46:11 +0100 Subject: rawhide report: 20061118 changes In-Reply-To: <20061118203222.6f477ad0@nausicaa.camperquake.de> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> <455EF41B.4090707@gmail.com> <20061118203222.6f477ad0@nausicaa.camperquake.de> Message-ID: <1163879171.11262.31.camel@dawkins> l?r, 18 11 2006 kl. 20:32 +0100, skrev Ralf Ertzinger: > Hi. > > Dawid Gajownik wrote: > > > Adam Jackson is incorporating nouveau driver into xorg-x11-drv-nv (like > > with modeseting intel driver and xorg-x11-drv-i810) :) > > Was that supposed to be a joke? > I thought that the nouveau project had not produced anything close to > usable code up to now, bot I may be mistaken, of course. It's probably in there for testing purposes. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From rdieter at math.unl.edu Sat Nov 18 20:09:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 18 Nov 2006 14:09:21 -0600 Subject: Make kde 1st class in fedora In-Reply-To: References: <16de708d0611172026w65c7f84x3ab490337922e3ab@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Arthur Pemberton gmail.com> writes: >> If you don't believe the quoted statement install Windows......you can >> install several other browsers, text editors, media players >> etc.....but if the link to the 'default' browser says Internet (or in >> the case of gaim, 'Instant Messenger') then a large percentage of >> users will _not_ benifit from having a choice. > > I must say I hate that too. This stuff belongs into the GenericName field, not > the Name field. Of course, this means GNOME would have to be fixed to display > both Name and GenericName as KDE has done for years. (And KDE allows you to > configure it, so if you want just the name or just the GenericName, you can > have that.) Amen to that. As a matter of fact, I plan on bringing .desktop file issues (like properly following the spec and respecting Name vs GenericName) to the Fedora Packaging committee to get such nonsense stopped. -- Rex From tibbs at math.uh.edu Sat Nov 18 19:55:53 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Nov 2006 13:55:53 -0600 Subject: rawhide report: 20061118 changes In-Reply-To: <20061118203222.6f477ad0@nausicaa.camperquake.de> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> <455EF41B.4090707@gmail.com> <20061118203222.6f477ad0@nausicaa.camperquake.de> Message-ID: >>>>> "RE" == Ralf Ertzinger writes: RE> Was that supposed to be a joke? I thought that the nouveau project RE> had not produced anything close to usable code up to now, bot I RE> may be mistaken, of course. There seem to be a couple of misconceptions. First, from what I've gathered watching the IRC traffic, ajax intends to provide nouveau as a parallel-installable module. The existing nv module will still be there and will still be the default. Second, the nouveau project has produced a 2D driver which is in many ways superior to the existing nv driver: the code has been somewhat de-obfuscated, EXA is supported, etc. It still has many bugs, of course. A significant portion of the information necessary to start work on 3D has already been gathered and work is being done towards that end. - J< From cweyl at alumni.drew.edu Sat Nov 18 20:02:52 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 18 Nov 2006 12:02:52 -0800 Subject: Perl bindings for RPM in FC6 In-Reply-To: References: Message-ID: <7dd7ab490611181202q17f49d7ctcada79762125b369@mail.gmail.com> On 11/18/06, Sam Varshavchik wrote: > What's the deal with RPM2.pm, it's not in FC6, nor in Extras? It has a long and storied history, but now appears to just be stalled in review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 -Chris -- Chris Weyl Ex astris, scientia From gajownik at gmail.com Sat Nov 18 20:04:48 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Sat, 18 Nov 2006 21:04:48 +0100 Subject: rawhide report: 20061118 changes In-Reply-To: <20061118203222.6f477ad0@nausicaa.camperquake.de> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> <455EF41B.4090707@gmail.com> <20061118203222.6f477ad0@nausicaa.camperquake.de> Message-ID: <455F6760.3040007@gmail.com> Dnia 11/18/2006 08:33 PM, U?ytkownik Ralf Ertzinger napisa?: > Was that supposed to be a joke? Well, no :-) If you don't believe me you can alway check #nouveau irc logs: http://lattice.u-strasbg.fr/irclogs/nouveau-2006-11-16 http://lattice.u-strasbg.fr/irclogs/nouveau-2006-11-17 (grep for "ajax") > I thought that the nouveau project had not produced anything close to > usable code up to now, bot I may be mistaken, of course. I presume that you have been misled by this sentence: "What is the current state of things ? Currently, nothing works. If you're not a developer, you're not interested in this at all." from nouveau main page ;) It was only written to scare normal users. nouveau driver was based on nv one so 2D works fine. Code is being deobfuscated and EXA acceleration was added. Reverse engineering part is almost finished so 3D driver should be available in the near future :) Dual head support will be added after RandR 1.2 merging into X server. Maybe driver is still rough but Fedora's 5th objective is: "Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades." Regards, Dawid -- ^_* From arjan at fenrus.demon.nl Sat Nov 18 23:01:01 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 19 Nov 2006 00:01:01 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <455F251B.9070409@volny.cz> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> <1163848345.7866.12.camel@mjollnir.borkware.net> <455F251B.9070409@volny.cz> Message-ID: <1163890861.31358.449.camel@laptopd505.fenrus.org> > > There's no need to run the script if nothing has changed, > Does prelink overwrite the modified files in place, or does it create > new versions as separate files and rename()s them? the later, so the resort needs to happen after a biweekly prelink as well From rstrode at redhat.com Sun Nov 19 01:18:49 2006 From: rstrode at redhat.com (Ray Strode) Date: Sat, 18 Nov 2006 20:18:49 -0500 Subject: rawhide report: 20061118 changes In-Reply-To: <200611181331.06921.ddmbox2@yahoo.co.uk> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <200611181331.06921.ddmbox2@yahoo.co.uk> Message-ID: <1163899129.30316.1.camel@halflap.boston.devel.redhat.com> Hi, > error: %pre(control-center-2.17.1-5.fc7.i386) scriptlet failed, exit status 1 > error: install: %pre scriptlet failed (2), skipping > control-center-2.17.1-5.fc7 > and > --> Running transaction check > --> Processing Dependency: libparted-1.7.so.1 for package: gparted > --> Finished Dependency Resolution > Error: Missing Dependency: libparted-1.7.so.1 is needed by package gparted > > ...dex Thanks, it looks like some schema files got dropped. --Ray From jspaleta at gmail.com Sun Nov 19 02:23:35 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 18 Nov 2006 17:23:35 -0900 Subject: Make kde 1st class in fedora In-Reply-To: References: Message-ID: <604aa7910611181823x756a7e4dtad28a64ae5a09613@mail.gmail.com> On 11/17/06, Neal Becker wrote: > I believe most linux advocates would agree that one of linux main strengths > is choice. But, user's don't really have choice if they don't know they > have choice. > > I don't want to remove firefox. Firefox is great. I just believe we need a > more effective way to alert new users that they have a choice. Effective.. sure we'd all like a pony. Uninformed choice is no better and in many cases worse than no choicee. First and foremost informed choices require the individuals to care. How do you make new users care, if they have not in fact experiencecd the pros and cons of each software choice for themselves? It's a catch-22. You can't pack enough information into the installer or into firstboot to help new users make informed choices. This is the role of detailed documentation... and you sure as hell aren't going to get new users to read through 4 pages of a detailed comparison of just the available browser advantages at install time. At best you can do is attempt to make them aware that Fedora contains multple application choicees across a wide array of functionality and ask them to explore the packagespace after install time. If the default is a bad choice for new users, there is no garuntee that any other choice you could give new users at install time would lead to consistently better experiences on average, because such choices at install time are inherently uninformed unless users have previous knowledge. And if they have previous knowledge as to what applications they prefer.. they don't need install time walk-throughs. If you want to fight about changing the default applications, feel free. But to pack a series of nagware like dialogs into the installer or into firstboot to enforce that users make a series of inherently uninformed choices is not going to make anything better for anyone. You might as well just write in a randomizing function so every user gets a random set of default apps. In fact.. from a testing point of view.. a random set of default apps would make for good testing coverage during pre-release testing. -jef"best is the enemy of good"spaleta From avi at argo.co.il Sun Nov 19 08:33:56 2006 From: avi at argo.co.il (Avi Kivity) Date: Sun, 19 Nov 2006 10:33:56 +0200 Subject: Make kde 1st class in fedora In-Reply-To: <1163849378.11262.15.camel@dawkins> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> <1163849378.11262.15.camel@dawkins> Message-ID: <456016F4.7080708@argo.co.il> David Nielsen wrote: > l?r, 18 11 2006 kl. 11:48 +0100, skrev Olivier Galibert: > >> On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote: >> >>> Users want to configure using a gui. >>> > > That displays the fallacy that users want to configure stuff. > > Users don't want to configure. But they do have habits and preferences. Some like bigger fonts, others like animation. Some want (*gasp*) to change their wallpaper. I've been known to enter my name and email address into my mailer. An unconfigurable application will probably be suitable for one user (its developer). > They might want the option to tune an application but generally users > just want applications to work and will as a rule rather live with a > suboptimal default configuration for their soecific job than dig through > options and confusing tools/dialogs. > > The lesson we have to take away from this is to strive for good default > but remain configurable through a nice uniform interface. This is > exactly why gconf is so cool, translatable decriptor strings explain > what every key does for the user who likes to tweak the more exoteric > parts of their applications and the rest get a nice clean interface with > good defaults and the bare essencesial options. > > gconftool is way better than configuration files (and you raise a good point -- localization -- that is missing from good old config files). However an application specific UI can (and should) be much better organized than gconf. > Please don't assume that users _want_ to configure, it's not an end > goal, it's a means to get work done. > That was my point exactly. Putting things in configuration files _prevents_ users from getting that work done. Putting things in gconf is better, but still user-unfriendly (open an external application, find the root of the configured application's tree, start hacking things in a generic interface rather than one tailored to the task). -- error compiling committee.c: too many arguments to function From avi at argo.co.il Sun Nov 19 08:53:13 2006 From: avi at argo.co.il (Avi Kivity) Date: Sun, 19 Nov 2006 10:53:13 +0200 Subject: Make kde 1st class in fedora In-Reply-To: <1163849868.8380.38.camel@rousalka.dyndns.org> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> <455EEA58.4040306@argo.co.il> <1163849868.8380.38.camel@rousalka.dyndns.org> Message-ID: <45601B79.2010008@argo.co.il> Nicolas Mailhot wrote: >>> That's a common misconception. Lots of users are perfectly ok with >>> text configuration files, and even often like them more, because: >>> > > >> How many of these users are IT workers or computer enthusiasts? >> > > Yea, right, ever tried to explain a GUI procedure to someone over 40 > (aggravating factor : over the telephone) ? They don't know what > right-click is, That's their first week on the computer, right? But they've already mastered vi. > they don't know conventions, they get hopelessly > confused by renamed menu entries or new themes that change icons they're > used to. Sure, an application upgrade can be confusing. But at least the applications can be upgraded. With configuration files, it's impossible (try to imagine a user diffing /etc/blah.conf with /etc/blah.conf.rpmnew to get their machine to work). (and it seems you're advocating that applications should never change rather than they should use config files). > GUI power is massively overrated (even when it's designed > properly in the first place, which is the exception, especially for big > proprietary offerings) > > (and that's not musch easier for younger people) > > Nobody but computer enthusiasts has the time to browse all the app menus > and screens to find the place where the developper moved the magic > button designed to help him not writing a text file > > Please try to watch some real users. They can get by with menus just fine. >>> - it's easier to find a file in a specific place than to find the >>> configuration-application-of-the-day >>> >>> >> It's only easier for developers. Users know how to open Tools|Options. >> > > 1. No they don't > 2. when they do they recoil in horror before the mass of badly qualified > checkboxes > Sigh. A badly designed UI is certainly worse than a good UI. A configuration file is a badly designed UI. > > >> They have no idea where the config file sits. >> > > Unlike the GUI, the config file location is usually stable. Where is it? My file browser doesn't show it. It doesn't matter if its stable if I can't find it. > They can > note it down. Mapping a GUI route OTOH is a disaster > > Screenshot. >>> - it's easier to find what you want in it, especially when your setup >>> is nonstandard in any slight way. Things hidden in the new tab of the >>> day which appears only when you click on allow advanced in a dialog >>> box coming from a menu can be quite frustrating. In other words, the >>> interface part of a text configuration file is much harder to fuck up. >>> >>> >> If the configuration file is of any size at all (postfix, apache) you >> have to read a huge text file to find something. >> > > And usually you have the text explanation right next to the config > option. With examples even. You don't realise what a godsend it is after > the 3-word explanation you have next to a gui checkbox > > Again you seem to think that a voyage into the application's design is more suitable for the user's attention span than clicking '[x] Beep when new mail arrives'. >> If the configuration file omits some of the options, you have to read >> the manual page. >> > > Hint : do you actually think people grok GUIs without manuals or helpful > power users to explain them what the heck the convoluted label language > means ? > > Convoluted label language is no different than config_file_keys. If the UI is bad, fix it. >>> - you can google using its contents >>> >>> >> Shouldn't you try the application's help first? >> > > ROTFL you're hopeless > > You mean, googling a database of all web pages, including other versions of the same program, other programs, to find a poor user that experienced the same desire as you and went to the trouble of posting to a mailing list is better than consulting an authoritative text that comes with the application? If so, hopelessness is indeed in order. For desktop Linux. >>> - you often have useful comments in them, where the GUI equivalent >>> requires a number of manipulations to access >>> > > >> Context-sensitive help? >> > > Right-click, what's a right click ? What's a right-clickable object ? > You seem to be against GUIs in general, not just for configuration. People do know how to right click (or do the equivalent on Apple). > Why do you think apple gets by with a single button mouse ? > > The option key? >>> - it's way easier to talk about it in email >>> > > >> Especially for developers who dislike html mail. Users don't want to >> talk about options, they want to change them. >> > > No. Users don't want to talk about options period. They don't want to > change them be it in the config file or in the GUI > > How do I add an e-mail account? The beep on a new mail message is annoying, can I disable it? All my friends have kittens on their desktop background. I want one too! Users want different things. That's why there are configuration options. >> An example: Thunderbird's Edit|Preferences|Display, "Plain Text >> Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js >> mail.wrap_long_lines (it isn't there, you have to google for it or look >> in Thunderbird's config editor) >> >> [yes, it's easier to type in an email. but you'd get unwrapped text >> much. much sooner with the GUI] >> > > That's remain to be proven. Comparing speed once users have learnt the > GUI is cheating. > With a GUI, you need a basic skill set (navigating menus) and no more. With a configuration file, you need a lot more knowledge and time. > >> For system administrators and developers, text files are fine. For >> normal users, let them have their GUI. >> > > If only it was their GUI and not some monstruosity designed to show of > everything is GUI-accessible? > I don't understand this remark. -- error compiling committee.c: too many arguments to function From buildsys at redhat.com Sun Nov 19 11:01:24 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 19 Nov 2006 06:01:24 -0500 Subject: rawhide report: 20061119 changes Message-ID: <200611191101.kAJB1O92012974@hs20-bc2-6.build.redhat.com> Updated Packages: control-center-1:2.17.1-6.fc7 ----------------------------- * Sat Nov 18 2006 Ray Strode - 2.17.1-6 - update file list to explicitly mention schema files - fix %pre scriplet gnome-themes-2.17.2-2.fc7 ------------------------- * Sun Nov 19 2006 Matthias Clasen - 2.17.2-2 - Drop Clearlooks variants (#215114) pygobject2-2.12.3-1.fc7 ----------------------- * Sat Nov 18 2006 Matthew Barnes - 2.12.3-1.fc7 - Update to 2.12.3 rdesktop-1.5.0-1.fc7 -------------------- * Sun Nov 19 2006 Matthias Clasen - 1.5.0-1 - Update to 1.5.0 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From gilboad at gmail.com Sun Nov 19 11:10:28 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 19 Nov 2006 13:10:28 +0200 Subject: rawhide report: 20061119 changes In-Reply-To: <200611191101.kAJB1O92012974@hs20-bc2-6.build.redhat.com> References: <200611191101.kAJB1O92012974@hs20-bc2-6.build.redhat.com> Message-ID: <1163934628.15622.4.camel@gilboa-work-dev> On Sun, 2006-11-19 at 06:01 -0500, buildsys at redhat.com wrote: > > > Updated Packages: > > rdesktop-1.5.0-1.fc7 > -------------------- > * Sun Nov 19 2006 Matthias Clasen - 1.5.0-1 > - Update to 1.5.0 > Two questions: First, will it be pushed down stream to FC6 (or maybe FC5)? Second, does it include the "new" Alsa layer? Thanks, - Gilboa From nicolas.mailhot at laposte.net Sun Nov 19 11:55:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Nov 2006 12:55:41 +0100 Subject: Make kde 1st class in fedora In-Reply-To: <45601B79.2010008@argo.co.il> References: <1163778769.31358.337.camel@laptopd505.fenrus.org> <455E3F43.7030202@develer.com> <455EAA1C.3040105@argo.co.il> <20061118104835.GA55868@dspnet.fr.eu.org> <455EEA58.4040306@argo.co.il> <1163849868.8380.38.camel@rousalka.dyndns.org> <45601B79.2010008@argo.co.il> Message-ID: <1163937342.8380.74.camel@rousalka.dyndns.org> Le dimanche 19 novembre 2006 ? 10:53 +0200, Avi Kivity a ?crit : > Nicolas Mailhot wrote: > >>> That's a common misconception. Lots of users are perfectly ok with > >>> text configuration files, and even often like them more, because: > >>> > > > > > >> How many of these users are IT workers or computer enthusiasts? > >> > > > > Yea, right, ever tried to explain a GUI procedure to someone over 40 > > (aggravating factor : over the telephone) ? They don't know what > > right-click is, > > That's their first week on the computer, right? But they've already > mastered vi. They can use gedit which is actually not too difficult to explain compared to some "user-oriented" monstruosities > > they don't know conventions, they get hopelessly > > confused by renamed menu entries or new themes that change icons they're > > used to. > > Sure, an application upgrade can be confusing. But at least the > applications can be upgraded. Very often the "GUI applications can be upgraded" means old settings are 100% lost. They even provide registry cleaners in case the upograde process forgot to kill some settings. > (and it seems you're advocating that applications should never change > rather than they should use config files). No, I'm saying being GUI is *not* the magical bullet you're saying it is. Like the rest of the software it can be massively abused, and in fact when a proprietary offering abuses threading and other plumbing aspects it ususally abuses the GUI too. > > GUI power is massively overrated (even when it's designed > > properly in the first place, which is the exception, especially for big > > proprietary offerings) > > > > (and that's not musch easier for younger people) > > > > Nobody but computer enthusiasts has the time to browse all the app menus > > and screens to find the place where the developper moved the magic > > button designed to help him not writing a text file > Please try to watch some real users. They can get by with menus just fine. Thank you but no. I've done enough helpdesk (both familial and professional) in my life not to need another confirmation. > >>> - it's easier to find a file in a specific place than to find the > >>> configuration-application-of-the-day > >>> > >> It's only easier for developers. Users know how to open Tools|Options. > > > > 1. No they don't > > 2. when they do they recoil in horror before the mass of badly qualified > > checkboxes > > Sigh. A badly designed UI is certainly worse than a good UI. A > configuration file is a badly designed UI. Again, you're generalising a manichean "GUI is good" "config files is bad" without providing any supporting evidence. > >> They have no idea where the config file sits. > >> > > > > Unlike the GUI, the config file location is usually stable. > > Where is it? My file browser doesn't show it. google is your friend > It doesn't matter if its stable if I can't find it. > > > They can > > note it down. Mapping a GUI route OTOH is a disaster > Screenshot. ROTFL # 2 It requires : 1. you have the very same app version as the user, with the same locale and theme settings 2. that you mount a screencast-film to explain every change It's not practical (and despite what you may seem to think yes I've already done it and it was massively time consuming, needed to be updated every release, and was not practical but for 1-2 core settings) > >>> - it's easier to find what you want in it, especially when your setup > >>> is nonstandard in any slight way. Things hidden in the new tab of the > >>> day which appears only when you click on allow advanced in a dialog > >>> box coming from a menu can be quite frustrating. In other words, the > >>> interface part of a text configuration file is much harder to fuck up. > >>> > >> If the configuration file is of any size at all (postfix, apache) you > >> have to read a huge text file to find something. > > > > And usually you have the text explanation right next to the config > > option. With examples even. You don't realise what a godsend it is after > > the 3-word explanation you have next to a gui checkbox > > Again you seem to think that a voyage into the application's design is > more suitable for the user's attention span than clicking '[x] Beep when > new mail arrives'. And again you seem to think checkboxes are logically labelled or logically placed. Very often a GUI settings *requires* you to understand the application design to find it/set it correctly. You really need to sit with a basic non-computer-oriented user someday to understand the *mass* of assumptions that make a GUI setting useable. (And I'm not adding localisation by people with zero idea of what the app does to the mix) > >> If the configuration file omits some of the options, you have to read > >> the manual page. > > Hint : do you actually think people grok GUIs without manuals or helpful > > power users to explain them what the heck the convoluted label language > > means ? > Convoluted label language is no different than config_file_keys. If the > UI is bad, fix it. The difference being that GUI real-estate is scarse, so you get a condensed convoluted and confused langage and settings placed hasaphardly because there was no dedicated tab/section for them and they were regrouped on the screen with some space left. > >>> - you can google using its contents > > >> Shouldn't you try the application's help first? > > > > ROTFL you're hopeless > > You mean, googling a database of all web pages, including other versions > of the same program, other programs, to find a poor user that > experienced the same desire as you and went to the trouble of posting to > a mailing list is better than consulting an authoritative text that > comes with the application? > > If so, hopelessness is indeed in order. For desktop Linux. It's the same for desktop windows. I've never encountered one person actively using application help. Even some who "did" find one answer there once upon a time only use it at last resort when googling fails. Application help is a need-to-have thing required in the function matrix corps use before buying software, but the way it's structured makes it rather useless (and no I've got no magic bullet either) > You seem to be against GUIs in general, not just for configuration. > People do know how to right click (or do the equivalent on Apple). I'm not against GUI. I love GUI. I use GUI every day. But there is a difference between being for GUI and stating that because it's GUI it's user-friendly and because it's not it's user-unfriendly. A GUI can be good or bad. Most GUI programs have the same strengths and weaknesses. A common GUI weakness is configuration settings. Another is the help system. That does not mean for other everyday operations the GUI is not a good choice. Just that on average, users choose not to use the GUI config or help system because on average it's hopelessly botched. > >> Especially for developers who dislike html mail. Users don't want to > >> talk about options, they want to change them. > >> > > > > No. Users don't want to talk about options period. They don't want to > > change them be it in the config file or in the GUI > How do I add an e-mail account? The beep on a new mail message is > annoying, can I disable it? You cope with it, you ask a friend, you ask helpdesk, you google for it and when all is lost you may wander in the config menu or the help system. > All my friends have kittens on their desktop background. I want one too! Ever noticed the "put picture on background" shortcut is duplicated everywhere because users could not find it in the central "logical" place ? Do you actually think it's possible to duplicate every setting twenty times in the hope users will find it ? > Users want different things. That's why there are configuration options. For power users to use or helpdesk to set corp-wide. The existence of GUI settings do not imply their wide use, in fact every single user study points users do not use them, or only for 1-2 apps they can't avoid. > >> An example: Thunderbird's Edit|Preferences|Display, "Plain Text > >> Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js > >> mail.wrap_long_lines (it isn't there, you have to google for it or look > >> in Thunderbird's config editor) > >> > >> [yes, it's easier to type in an email. but you'd get unwrapped text > >> much. much sooner with the GUI] > >> > > > > That's remain to be proven. Comparing speed once users have learnt the > > GUI is cheating. > With a GUI, you need a basic skill set (navigating menus) and no more. This basic skill set is les basic than you seem to think > With a configuration file, you need a lot more knowledge and time. Again I disagree so that's your opinion against mine without any hard fact between. > >> For system administrators and developers, text files are fine. For > >> normal users, let them have their GUI. > > If only it was their GUI and not some monstruosity designed to show of > > everything is GUI-accessible? > I don't understand this remark. Then you don't understand average users. -- Nicolas Mailhot From dwmw2 at infradead.org Sun Nov 19 11:58:36 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 19 Nov 2006 11:58:36 +0000 Subject: Make kde 1st class in fedora In-Reply-To: <200611171646.06276.jkeating@redhat.com> References: <48640.194.94.224.254.1163794302.squirrel@jose.freesurf.fr> <455E2A85.1040307@fedoraproject.org> <200611171646.06276.jkeating@redhat.com> Message-ID: <1163937516.22022.14.camel@pmac.infradead.org> On Fri, 2006-11-17 at 16:46 -0500, Jesse Keating wrote: > On Friday 17 November 2006 16:32, Rahul Sundaram wrote: > > If you havent received the memo yet, there is no core/extras/legacy > > starting from the next release. > > http://fedoraproject.org/wiki/FedoraSummit. > > Please remember that this is just proposed, and by no means set in > stone. It is a very good idea though, so fairly likely to go ahead. We have realised that having 'second class citizens' in Fedora doesn't make much sense and doesn't work very well. Having a separate build and release process for Fedora Extras was never particularly workable -- combining Core and Extras is obviously the right thing to do. Now, where else could we apply that same hard-earned knowledge? -- dwmw2 From vonbrand at inf.utfsm.cl Sun Nov 19 15:38:54 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 19 Nov 2006 12:38:54 -0300 Subject: Make kde 1st class in fedora In-Reply-To: Your message of "Sun, 19 Nov 2006 12:55:41 BST." <1163937342.8380.74.camel@rousalka.dyndns.org> Message-ID: <200611191538.kAJFcsDv002742@laptop13.inf.utfsm.cl> Nicolas Mailhot wrote: > Le dimanche 19 novembre 2006 ?? 10:53 +0200, Avi Kivity a ??crit : > > Nicolas Mailhot wrote: [...] > I've never encountered one person actively using application help. Even > some who "did" find one answer there once upon a time only use it at > last resort when googling fails. That is because the application help is usually completely unsearchable (or you want to search for "change background color" while it is documented under "reconfigure wallpaper" or "define theme", or it has a list of functions and you want to know how to compute something specific). "Help" is (as anyone who as taught somewhen) first about understanding what the user wants, finding out what their misconceptions are, and then pointing them in the right direction. As long as AI remains as primitive as it is today, you'll at best get Clippy. > Application help is a need-to-have thing required in the function matrix > corps use before buying software, but the way it's structured makes it > rather useless (and no I've got no magic bullet either) Problem is that it requires /thousands/ of different organizations, each tailored for a morass of different tasks. [...] > A GUI can be good or bad. Most GUI programs have the same strengths and > weaknesses. A common GUI weakness is configuration settings. Another is > the help system. That does not mean for other everyday operations the > GUI is not a good choice. Just that on average, users choose not to use > the GUI config or help system because on average it's hopelessly > botched. GUIs are usually easier to learn and use for simple tasks, for complex tasks they are hopeless. And the help system for CLI is usually also very bad, but CLI user expectations are normally lower. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From philipp_subx at redfish-solutions.com Sun Nov 19 21:10:21 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sun, 19 Nov 2006 14:10:21 -0700 Subject: Incorrect timestamp logging in gssftpd (krb5-workstation) Message-ID: <4560C83D.9000506@redfish-solutions.com> I found a situation (fairly common, actually) under which gssftpd generates incorrect timestamps as a result of chroot()ing and losing access to the /etc/localtime file (it surprises me that localtime(3) doesn't cache the file's contents in glibc... oh, well). I came up with a work-around for this which is fairly simple. Can someone else code review it? And if the Kerberos folks (krbdev) don't want to include the fix (I sent it to them, but didn't hear back) what's the criteria for it being included in the Redhat/ Fedora packaging instead? Here's the bug report (fix included): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216356 -Philip From mmcgrath at fedoraproject.org Mon Nov 20 02:26:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 19 Nov 2006 20:26:54 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> Message-ID: <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> On 11/18/06, Mike McGrath wrote: > Bottom line, this sucks but we're working on it. Should be up and > better than ever by Monday. > Buhhh, late monday. -Mike From tonynelson at georgeanelson.com Mon Nov 20 02:42:17 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sun, 19 Nov 2006 21:42:17 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda Message-ID: The RPM database should be verified more often than it is now. With FC6 there has been a spate of RPM database corruption. It happened to me: though there may have been incipient corruption in my FC5, after --rebuilddb and upgrading successfully I found more corruption later. This brings up that the RPM database is just assumed to work, but isn't being checked until it falls over. I propose that there should be a nightly cron task to check the RPM database with --verifydb, which would also attempt automatic repair (if the Packages file is OK). I am developing and testing a shell script to do this. Currently it seems to work when run manually; we'll see what happens tonight. It logs its actions in syslog via logger. I expect that logwatch will inform root by email. I propose that Anaconda should check the RPM database before starting an upgrade to an existing installation. Checking takes under a minute on my system, so it should not be objectionable. Anaconda should offer to repair a damaged RPM database (if the Package file is OK) before proceeding with the installation. I suggest that the --verifydb command should not be undocumented in RPM and its manpage. This seems to be on purpose, but I think it is a mistake. I would like some feedback about these proposals. If they are acceptable I will file RFE bugs on them. My knowlege of things RPM is superficial. It would be a good idea to have the proposed verification and repair methods criticised by authentic RPM developers, but I'm not sure where they hang out -- the Redhat Rpm-list appears to be for RPM users. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From mrsam at courier-mta.com Mon Nov 20 02:50:09 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 19 Nov 2006 21:50:09 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda References: Message-ID: Tony Nelson writes: > I propose that there should be a nightly cron task to check the RPM I proposed this several years ago, and got poo-poohed. I now just have a cron.daily script that just makes a copy of /var/lib/rpm on a five day rotation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Nov 20 09:24:03 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Nov 2006 09:24:03 +0000 Subject: Fedora/PowerPC on PlayStation 3 Message-ID: <1164014643.6925.85.camel@pmac.infradead.org> Go Fedora/PPC .... http://www.engadget.com/2006/11/19/fedora-linux-up-and-running-on-playstation-3-with-video/ Not officially supported yet but we should have a build of FC6+updates to install on it some time soon just as we did FC4+updates for the Pegasos II, and of course we intend FC7 to support it out of the box. There are other new PowerPC machines in the works too. Who needs Apple? :) -- dwmw2 From jeroen.janssen at gmail.com Mon Nov 20 09:26:19 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Mon, 20 Nov 2006 10:26:19 +0100 Subject: Fedora and cvs 1.12.x? In-Reply-To: References: Message-ID: Hello, (I'm hoping this is the correct mailinglist, if not then please let me know where to send this to) I was wondering if/when Fedora is going to ship CVS 1.12.x (the current is 1.11-22 in Fedora Core 6). I am really interested in using the new http proxy functionality in cvs 1.12.7 since it is the only way I am able to use cvs with the proxy server at work. Note for comparison that CVS 1.12.9 is present in the SuSe Linux 9.2 (build on Thu 07 Apr 2005 06:05:46 PM CEST). Best regards, Jeroen Janssen From alexl at redhat.com Mon Nov 20 08:32:42 2006 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 20 Nov 2006 09:32:42 +0100 Subject: rawhide report: 20061115 changes In-Reply-To: <1163604145.13021.4.camel@golem.boston.devel.redhat.com> References: <200611151124.kAFBO2Zg026121@hs20-bc2-6.build.redhat.com> <455B0C48.5060605@feuerpokemon.de> <1163604145.13021.4.camel@golem.boston.devel.redhat.com> Message-ID: <1164011562.2776.11.camel@greebo> On Wed, 2006-11-15 at 10:22 -0500, Matthias Clasen wrote: > So I assume it will prefer tracker, as long as it is installed. From > my > experiments, it looks like libtracker actually starts trackerd on > demand, so you'll have to uninstall tracker to get back to beagle. Maybe we should reverse the order, because the beagle version checks for the daemon at runtime and doesn't auto-start. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a one-legged bohemian inventor who hides his scarred face behind a mask. She's a hard-bitten out-of-work soap star who don't take no shit from nobody. They fight crime! From t.matsuu at gmail.com Mon Nov 20 09:54:18 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Mon, 20 Nov 2006 18:54:18 +0900 Subject: Firefox 3 Message-ID: <6f27515e0611200154y2f930b20i26e6d42bd7c5b7bb@mail.gmail.com> 16:48:35 -0600 > From: Mike Chambers > Subject: Re: Firefox 3 > Message-ID: <1163630915.15283.4.camel at scrappy.miketc.com> > > I had a build error, during IMG_decoders or something, and it failed. > Don't know how far into it that it was building, but it had gone a while > before it finally errored. > > Guess you don't have an actual binary rpm for a rawhide system? As I wrote in my webpage for firefox, my SRPM adds the experimental MNG support. http://mngzilla.sourceforge.net/ https://bugzilla.mozilla.org/show_bug.cgi?id=18574 Build may succeed if you install libmng-devel package. ---- MATSUURA Takanori From rodd at clarkson.id.au Mon Nov 20 10:21:15 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 20 Nov 2006 21:21:15 +1100 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164014643.6925.85.camel@pmac.infradead.org> References: <1164014643.6925.85.camel@pmac.infradead.org> Message-ID: <1164018075.27395.29.camel@localhost.localdomain> On Mon, 2006-11-20 at 09:24 +0000, David Woodhouse wrote: > Go Fedora/PPC .... > > http://www.engadget.com/2006/11/19/fedora-linux-up-and-running-on-playstation-3-with-video/ > > Not officially supported yet but we should have a build of FC6+updates > to install on it some time soon just as we did FC4+updates for the > Pegasos II, and of course we intend FC7 to support it out of the box. > > There are other new PowerPC machines in the works too. > Who needs Apple? :) I know this is not really fedora related, but I thought the PS4 used the cell processor, not a PowerPC processor, and that the cell processors were dramatically different to the PPC. What gives? R. -- "It's a fine line between denial and faith. It's much better on my side" From fedora at camperquake.de Mon Nov 20 10:27:29 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 20 Nov 2006 11:27:29 +0100 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164018075.27395.29.camel@localhost.localdomain> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> Message-ID: <20061120112729.672f4577@yareena.int.addix.net> Hi. On Mon, 20 Nov 2006 21:21:15 +1100, Rodd Clarkson wrote: > I know this is not really fedora related, but I thought the PS4 used > the cell processor, not a PowerPC processor, and that the cell > processors were dramatically different to the PPC. A Cell processor consists of a main processor (which is PPC) and a number of simple subprocessors, which can be assigned tasks by the main processor. The subprocessors are not PPC, as far as I know. The PS3 has 8 subprocessors, but this number can vary. From pbrobinson at gmail.com Mon Nov 20 10:29:04 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 20 Nov 2006 10:29:04 +0000 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164018075.27395.29.camel@localhost.localdomain> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> Message-ID: <5256d0b0611200229t45fcdc14t8d2dc0e6619a7f31@mail.gmail.com> On 11/20/06, Rodd Clarkson wrote: > On Mon, 2006-11-20 at 09:24 +0000, David Woodhouse wrote: > > Go Fedora/PPC .... > > > > http://www.engadget.com/2006/11/19/fedora-linux-up-and-running-on-playstation-3-with-video/ > > > > Not officially supported yet but we should have a build of FC6+updates > > to install on it some time soon just as we did FC4+updates for the > > Pegasos II, and of course we intend FC7 to support it out of the box. > > > > There are other new PowerPC machines in the works too. > > Who needs Apple? :) > > I know this is not really fedora related, but I thought the PS4 used the > cell processor, not a PowerPC processor, and that the cell processors > were dramatically different to the PPC. > > What gives? It does use a Cell processor, which is a variant of the PowerPC processor. The Cell was developed by IBM for Sony. IBM are now shipping Cell processors in Blades and already support Linux on those blades. Some details here http://www.itjungle.com/tlb/tlb091906-story02.html This will be interesting to see, the XBox 360 also runs on a variant of the PowerPC processor from a similar base to that of the Cell processor, and the Wii also sports some other variant of the PowerPC processor too. Peter From dwmw2 at infradead.org Mon Nov 20 10:35:06 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Nov 2006 10:35:06 +0000 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164018075.27395.29.camel@localhost.localdomain> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> Message-ID: <1164018906.6925.93.camel@pmac.infradead.org> On Mon, 2006-11-20 at 21:21 +1100, Rodd Clarkson wrote: > I know this is not really fedora related, but I thought the PS4 used the > cell processor, not a PowerPC processor, and that the cell processors > were dramatically different to the PPC. > > What gives? Cell is PowerPC with extra processing units. For more details, see Google or http://arstechnica.com/articles/paedia/cpu/cell-1.ars Fedora has supported the Cell processor since Fedora Core 5 -- I believe that Fedora is still the only OS which IBM ships on their Cell blades. -- dwmw2 From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From paul at city-fan.org Mon Nov 20 11:53:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 20 Nov 2006 11:53:27 +0000 Subject: Perl bindings for RPM in FC6 In-Reply-To: <7dd7ab490611181202q17f49d7ctcada79762125b369@mail.gmail.com> References: <7dd7ab490611181202q17f49d7ctcada79762125b369@mail.gmail.com> Message-ID: <45619737.5050105@city-fan.org> Chris Weyl wrote: > On 11/18/06, Sam Varshavchik wrote: >> What's the deal with RPM2.pm, it's not in FC6, nor in Extras? > > It has a long and storied history, but now appears to just be stalled in > review: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 The package is actually approved but the original submitter is no longer around and nobody else has volunteered to pick it up yet. Well actually Robin (the current Core perl maintainer) did say he'd do it if nobody else was interested, but that was back in September. Paul. From sdl.web at gmail.com Mon Nov 20 12:20:39 2006 From: sdl.web at gmail.com (Leo) Date: Mon, 20 Nov 2006 12:20:39 +0000 Subject: Fedora and cvs 1.12.x? References: Message-ID: On Mon, 20/11/06, Jeroen Janssen wrote: > Hello, > > (I'm hoping this is the correct mailinglist, if not then please let me > know where to send this to) > > I was wondering if/when Fedora is going to ship CVS 1.12.x (the > current is 1.11-22 in Fedora Core 6). > > I am really interested in using the new http proxy functionality in > cvs 1.12.7 since it is the only way I am able to use cvs with the > proxy server at work. > > Note for comparison that CVS 1.12.9 is present in the SuSe Linux 9.2 > (build on Thu 07 Apr 2005 06:05:46 PM CEST). > > Best regards, > > Jeroen Janssen Didn't realize CVS is this old in Fedora. I'd also like to see an update. Thanks. -- Leo From otto_rey at yahoo.com.ar Mon Nov 20 12:38:23 2006 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Mon, 20 Nov 2006 04:38:23 -0800 (PST) Subject: SUG: RPM database verification / repair, nightly and in Anaconda Message-ID: <20061120123823.90928.qmail@web52404.mail.yahoo.com> This sound good, but first we need to detect why rpms database got corrupted. ----- Original Message ---- From: Sam Varshavchik To: Development discussions related to Fedora Core Sent: Sunday, November 19, 2006 11:50:09 PM Subject: Re: SUG: RPM database verification / repair, nightly and in Anaconda Tony Nelson writes: > I propose that there should be a nightly cron task to check the RPM I proposed this several years ago, and got poo-poohed. I now just have a cron.daily script that just makes a copy of /var/lib/rpm on a five day rotation. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithishere2004 at gmail.com Mon Nov 20 12:56:57 2006 From: keithishere2004 at gmail.com (Keith G) Date: Mon, 20 Nov 2006 12:56:57 +0000 Subject: Core + Extras In-Reply-To: <200611181127.50995.jkeating@redhat.com> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> Message-ID: <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)? From arjan at fenrus.demon.nl Mon Nov 20 13:02:18 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 20 Nov 2006 14:02:18 +0100 Subject: Core + Extras In-Reply-To: <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> Message-ID: <1164027739.31358.594.camel@laptopd505.fenrus.org> On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote: > How will future decisions be made on which packages constitute the > official release (included in the release CDs and DVD)? I think at some point the "CD" needs to shrink down; it's an online world after all, and 5 cd's is just "too much" for people to look up against. In addition to making "the cd set" smaller, another option is to make groups of packages and then have special cds for them like fedora-base (1 or 2 cds with basic OS) fedora-server (all "server only" things such as apache) fedora-gnome (the gnome desktop packages) fedora-kde (the kde desktop packages) fedora-openoffice (the lot of openoffice.org) that way if you don't use kde (or gnome) you don't need to download&burn that CD. Same for openoffice... or you can elect to get that part of the upgrade via the network From keithishere2004 at gmail.com Mon Nov 20 13:02:43 2006 From: keithishere2004 at gmail.com (Keith G) Date: Mon, 20 Nov 2006 13:02:43 +0000 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164018906.6925.93.camel@pmac.infradead.org> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> <1164018906.6925.93.camel@pmac.infradead.org> Message-ID: <667750500611200502v615a5478sab20b75131e734ae@mail.gmail.com> Forgive my ignorance, but will this actually allow a linux game to take full advantage of the graphical capabilities of the PS3? Or are there restrictions preventing this? Keith. From sundaram at fedoraproject.org Mon Nov 20 13:14:21 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 18:44:21 +0530 Subject: Core + Extras In-Reply-To: <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> Message-ID: <4561AA2D.9070109@fedoraproject.org> Keith G wrote: > How will future decisions be made on which packages constitute the > official release (included in the release CDs and DVD)? > See http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess Rahul From jkeating at redhat.com Mon Nov 20 13:14:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 08:14:54 -0500 Subject: Core + Extras In-Reply-To: <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> References: <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> Message-ID: <200611200814.54177.jkeating@redhat.com> On Monday 20 November 2006 07:56, Keith G wrote: > How will future decisions be made on which packages constitute the > official release (included in the release CDs and DVD)? Probably a function of the release team, with input from various SIGs and RH Engineering management, with final approval by the board perhaps? Note that there is plenty of opportunity for community input in this stack. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From keithishere2004 at gmail.com Mon Nov 20 13:21:11 2006 From: keithishere2004 at gmail.com (Keith G) Date: Mon, 20 Nov 2006 13:21:11 +0000 Subject: Core + Extras In-Reply-To: <1164027739.31358.594.camel@laptopd505.fenrus.org> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> Message-ID: <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> I like the idea of separate fedora-server, fedora-gnome and fedora-kde CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus: * fedora-gnome = basic OS + Gnome + main essential applications * fedora-kde = basic OS + KDE + main essential applications * fedora-server = basic OS + server packages * fedora-extras = other popular packages and applications * fedora-devel = All the development libraries and applications that most users never install That way a user can set up a working os with as little as 1 cd. Keith. On 20/11/06, Arjan van de Ven wrote: > On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote: > > How will future decisions be made on which packages constitute the > > official release (included in the release CDs and DVD)? > > I think at some point the "CD" needs to shrink down; it's an online > world after all, and 5 cd's is just "too much" for people to look up > against. > > In addition to making "the cd set" smaller, another option is to make > groups of packages and then have special cds for them like > > fedora-base (1 or 2 cds with basic OS) > fedora-server (all "server only" things such as apache) > fedora-gnome (the gnome desktop packages) > fedora-kde (the kde desktop packages) > fedora-openoffice (the lot of openoffice.org) > > that way if you don't use kde (or gnome) you don't need to download&burn > that CD. Same for openoffice... or you can elect to get that part of the > upgrade via the network > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From j.w.r.degoede at hhs.nl Mon Nov 20 13:27:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 14:27:32 +0100 Subject: Core + Exrtas 2 Message-ID: <4561AD44.6040404@hhs.nl> Hi, Now that the discussion on this is getting started allow me to chime in with my 2 euro cents: In general I like the proposal which can be found here: http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess I've got 2 questions though: 1) I think there should be a procedure to skip update-testing, this will ofcourse be needed for security fixes, but also for trivial correct (and somewhat important) fixes and to fix brownpaper bag bugs. 2) What about new packages? FE is growing almost daily. One of the huge advantages of the current model is that people can get access to new packages within a stable cycle. I like the whole do not update unless there is a good reason model to give people more stability, but most new packages will not hurt stability of existing packages, and will have 100% impact on our users unless they specificly instruct yum to install the new package. There will ofcourse be exceptions, but as a general rule of thumb I think it should be normal procedure for new packages to enter the stable branch so that all our users can benefit from them (not only those running devel) and so that all our users can test them. Remember, release early release often. I think we should do this entering through updates-testing so that we can catch any last minute bugs. Regards, Hans From dwmw2 at infradead.org Mon Nov 20 13:41:13 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Nov 2006 13:41:13 +0000 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <667750500611200502v615a5478sab20b75131e734ae@mail.gmail.com> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> <1164018906.6925.93.camel@pmac.infradead.org> <667750500611200502v615a5478sab20b75131e734ae@mail.gmail.com> Message-ID: <1164030073.6925.126.camel@pmac.infradead.org> On Mon, 2006-11-20 at 13:02 +0000, Keith G wrote: > Forgive my ignorance, but will this actually allow a linux game to > take full advantage of the graphical capabilities of the PS3? Or are > there restrictions preventing this? Unfortunately it doesn't -- the Linux video support is currently just a linear framebuffer. Hopefully Sony will get a clue and open it up a little more some time soon. We may well find a way to abuse the SPUs to do acceleration in the meantime :) -- dwmw2 From sundaram at fedoraproject.org Mon Nov 20 13:41:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 19:11:28 +0530 Subject: Core + Exrtas 2 In-Reply-To: <4561AD44.6040404@hhs.nl> References: <4561AD44.6040404@hhs.nl> Message-ID: <4561B088.5080203@fedoraproject.org> Hans de Goede wrote: > Hi, > > Now that the discussion on this is getting started allow me to chime in > with my 2 euro cents: > > In general I like the proposal which can be found here: > http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess > I've got 2 questions though: > 1) I think there should be a procedure to skip update-testing, this will > ofcourse be needed > for security fixes, but also for trivial correct (and somewhat > important) fixes and to fix > brownpaper bag bugs. absolutely. This might be handled by http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem > 2) What about new packages? FE is growing almost daily. One of the huge > advantages of the current > model is that people can get access to new packages within a stable > cycle. I like the whole do not > update unless there is a good reason model to give people more > stability, but most new packages > will not hurt stability of existing packages, and will have 100% > impact on our users unless they > specificly instruct yum to install the new package. There will > ofcourse be exceptions, but as a general > rule of thumb I think it should be normal procedure for new packages > to enter the stable branch so that all our users can benefit from them > (not only those running devel) and so that all our users can test > them. Remember, release early release often. I think we should do this > entering through updates-testing so > that we can catch any last minute bugs. Are you talking about having a general policy on updates or having a release freeze like FC instead of rolling updates like FE? Rahul From jakub at redhat.com Mon Nov 20 13:50:10 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 20 Nov 2006 08:50:10 -0500 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <1164030073.6925.126.camel@pmac.infradead.org> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> <1164018906.6925.93.camel@pmac.infradead.org> <667750500611200502v615a5478sab20b75131e734ae@mail.gmail.com> <1164030073.6925.126.camel@pmac.infradead.org> Message-ID: <20061120135010.GC6570@devserv.devel.redhat.com> On Mon, Nov 20, 2006 at 01:41:13PM +0000, David Woodhouse wrote: > On Mon, 2006-11-20 at 13:02 +0000, Keith G wrote: > > Forgive my ignorance, but will this actually allow a linux game to > > take full advantage of the graphical capabilities of the PS3? Or are > > there restrictions preventing this? > > Unfortunately it doesn't -- the Linux video support is currently just a > linear framebuffer. Hopefully Sony will get a clue and open it up a > little more some time soon. > > We may well find a way to abuse the SPUs to do acceleration in the > meantime :) FYI, spu-*-elf GCC port has been recently submitted for inclusion in GCC 4.3 (though, it hasn't been committed yet). Jakub From jkeating at redhat.com Mon Nov 20 14:13:52 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 09:13:52 -0500 Subject: Core + Exrtas 2 In-Reply-To: <4561B088.5080203@fedoraproject.org> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> Message-ID: <200611200913.52895.jkeating@redhat.com> On Monday 20 November 2006 08:41, Rahul Sundaram wrote: > Are you talking about having a general policy on updates or having a > release freeze like FC instead of rolling updates like FE? No, he's asking about introducing new packages to a released product. Say Fedora 7 goes out the door with a given package set. Three weeks later a great new package gets added to the Fedora universe, what kind of policy would there be in making this package available to the Fedora 7 users? Its an interesting question, one that I'd like to hear opinions on. Historically we haven't made new packages available in core unless they were needed by something else already in. However having Extras around helped in that new packages could get introduced there. Just adding the package in sounds OK on the surface, but one needs to consider some of the guidelines we're putting up as far as what can be spun and called Fedora. If a bunch of new packages show up after Fedora 7 is cut, would somebody be able to make use of those packages when spinning their cut of Fedora 7? I think it's pretty safe to say that a lot of these packages wouldn't have a chance to go through any kind of QA / Testing that Will is trying to put in place. An interesting topic indeed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Mon Nov 20 14:33:05 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 20 Nov 2006 09:33:05 -0500 Subject: rawhide report: 20061118 changes In-Reply-To: <1163849313.3566.2.camel@localhost.localdomain> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> Message-ID: <1164033185.28927.9.camel@localhost.localdomain> On Sat, 2006-11-18 at 11:28 +0000, Richard Hughes wrote: > On Sat, 2006-11-18 at 06:16 -0500, buildsys at redhat.com wrote: > > * Fri Nov 17 2006 Adam Jackson 2.3.0-1.fc7 > > - Update to 2.3.0 from upstream. > > - Add nouveau userspace header. > > Hey, looking good. What's the consequence of this? We can start hacking > nouveau[1] easily? Or am I getting excited over nothing? That too. Or, if you just want to run it, you can do that too ;) The nouveau driver requires a DRM component in the kernel (the good kind, not the RIAA kind), which I have more or less merged and am really just waiting for the kernel to be in a buildable state before pushing to rawhide. After that piece lands, the xorg-x11-drv-nv package will install two drivers, nv and nouveau, similar to the i810/intel bundle. As mentioned later in the thread, nv will still be the default. So basically, if you want to work on nouveau, all the source and all the buildreqs will already be set up for you. Yay! If instead you just want to try it and compare, you can do that too. Also yay! No DRI support yet, but that's coming, I hear. - ajax From giallu at gmail.com Mon Nov 20 14:37:44 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 20 Nov 2006 15:37:44 +0100 Subject: Fedora and cvs 1.12.x? In-Reply-To: References: Message-ID: On 11/20/06, Leo wrote: > On Mon, 20/11/06, Jeroen Janssen wrote: > > I was wondering if/when Fedora is going to ship CVS 1.12.x (the > > current is 1.11-22 in Fedora Core 6). > > > > Didn't realize CVS is this old in Fedora. I'd also like to see an > update. Thanks. 1.11.22 is the latest release of cvs from their stable branch: being released in July I can hardly call it "old". Please note that, despite having an even release number, 1.12.x is a "feature" branch (and the last release from that branch is from July as well) From dwmw2 at infradead.org Mon Nov 20 14:40:11 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Nov 2006 14:40:11 +0000 Subject: Fedora/PowerPC on PlayStation 3 In-Reply-To: <20061120135010.GC6570@devserv.devel.redhat.com> References: <1164014643.6925.85.camel@pmac.infradead.org> <1164018075.27395.29.camel@localhost.localdomain> <1164018906.6925.93.camel@pmac.infradead.org> <667750500611200502v615a5478sab20b75131e734ae@mail.gmail.com> <1164030073.6925.126.camel@pmac.infradead.org> <20061120135010.GC6570@devserv.devel.redhat.com> Message-ID: <1164033611.6925.136.camel@pmac.infradead.org> On Mon, 2006-11-20 at 08:50 -0500, Jakub Jelinek wrote: > FYI, spu-*-elf GCC port has been recently submitted for inclusion in GCC 4.3 > (though, it hasn't been committed yet). Yep, that (or an older version) should turn up in Extras some time soon. I'd have submitted it myself but I couldn't be any better than a package-monkey for it, and Fedora needs package _maintainers_ not package-monkeys. -- dwmw2 From mattdm at mattdm.org Mon Nov 20 14:46:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 09:46:13 -0500 Subject: Core + Extras In-Reply-To: <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> Message-ID: <20061120144613.GA19155@jadzia.bu.edu> On Mon, Nov 20, 2006 at 01:21:11PM +0000, Keith G wrote: > I like the idea of separate fedora-server, fedora-gnome and fedora-kde > CDs, although I think main essential applications like openoffice and > firefox should be on the main CD. I think it would be better to split > the CDs thus: openoffice.org takes up almost 700mb by itself. (You want "essential", try abiword at 7MB and gnumeric at 12MB.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Nov 20 14:48:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 09:48:22 -0500 Subject: Core + Exrtas 2 In-Reply-To: <200611200913.52895.jkeating@redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <20061120144822.GB19155@jadzia.bu.edu> On Mon, Nov 20, 2006 at 09:13:52AM -0500, Jesse Keating wrote: > Its an interesting question, one that I'd like to hear opinions on. > Historically we haven't made new packages available in core unless they were > needed by something else already in. However having Extras around helped in > that new packages could get introduced there. Just adding the package in > sounds OK on the surface, but one needs to consider some of the guidelines > we're putting up as far as what can be spun and called Fedora. If a bunch of > new packages show up after Fedora 7 is cut, would somebody be able to make > use of those packages when spinning their cut of Fedora 7? I think it's > pretty safe to say that a lot of these packages wouldn't have a chance to go > through any kind of QA / Testing that Will is trying to put in place. I think Fedora has fast enough a release schedule that new packages and major upgrades of existing packages (except when it's the most straightforward security fix -- thanks, firefox developers!) should wait for the next release. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Mon Nov 20 15:01:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 16:01:38 +0100 Subject: Core + Exrtas 2 In-Reply-To: <200611200913.52895.jkeating@redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <4561C352.9050707@hhs.nl> Jesse Keating wrote: > On Monday 20 November 2006 08:41, Rahul Sundaram wrote: >> Are you talking about having a general policy on updates or having a >> release freeze like FC instead of rolling updates like FE? > > No, he's asking about introducing new packages to a released product. Say > Fedora 7 goes out the door with a given package set. Three weeks later a > great new package gets added to the Fedora universe, what kind of policy > would there be in making this package available to the Fedora 7 users? > Correct, thats what I'm trying to say. > Its an interesting question, one that I'd like to hear opinions on. > Historically we haven't made new packages available in core unless they were > needed by something else already in. However having Extras around helped in > that new packages could get introduced there. Just adding the package in > sounds OK on the surface, but one needs to consider some of the guidelines > we're putting up as far as what can be spun and called Fedora. Can we split the question / discussion in 2 please: 1) Is it allowed to introducing a new package to the online repository / updates directory of a released product And if we allow that, only then discuss: 2) Is it allowed to spin a cut of Fedora and still call it Fedora with such "post release" addon packages included. Discussing 1) first seems to make sense as without 1) happening there is no 2) to discuss. Regards, Hans From j.w.r.degoede at hhs.nl Mon Nov 20 15:03:45 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 16:03:45 +0100 Subject: Core + Exrtas 2 In-Reply-To: <20061120144822.GB19155@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120144822.GB19155@jadzia.bu.edu> Message-ID: <4561C3D1.2020106@hhs.nl> Matthew Miller wrote: > On Mon, Nov 20, 2006 at 09:13:52AM -0500, Jesse Keating wrote: >> Its an interesting question, one that I'd like to hear opinions on. >> Historically we haven't made new packages available in core unless they were >> needed by something else already in. However having Extras around helped in >> that new packages could get introduced there. Just adding the package in >> sounds OK on the surface, but one needs to consider some of the guidelines >> we're putting up as far as what can be spun and called Fedora. If a bunch of >> new packages show up after Fedora 7 is cut, would somebody be able to make >> use of those packages when spinning their cut of Fedora 7? I think it's >> pretty safe to say that a lot of these packages wouldn't have a chance to go >> through any kind of QA / Testing that Will is trying to put in place. > > I think Fedora has fast enough a release schedule that new packages and > major upgrades of existing packages (except when it's the most > straightforward security fix -- thanks, firefox developers!) should wait for > the next release. > Why, what is there to loose? I agree with you on major upgrades of existing packages, but adding a new package to the repo, say a new game for example, will not hurt existing users in anyway, even if they do a daily yum update it will change nothing for them, except an ever so slightly larger metadata download. Regards, Hans From cmadams at hiwaay.net Mon Nov 20 15:05:06 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 20 Nov 2006 09:05:06 -0600 Subject: Core + Extras In-Reply-To: <1164027739.31358.594.camel@laptopd505.fenrus.org> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> Message-ID: <20061120150506.GA1090806@hiwaay.net> Once upon a time, Arjan van de Ven said: > On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote: > > How will future decisions be made on which packages constitute the > > official release (included in the release CDs and DVD)? > > I think at some point the "CD" needs to shrink down; it's an online > world after all, and 5 cd's is just "too much" for people to look up > against. The problem is that it is _not_ an online world for a lot of people. I've got a friend that lives in a broadband-challenged area; his only option for anything faster than dialup is satellite, and that doesn't help with Fedora (since they cap downloads). Right now, Extras is "second class" for that kind of user, because they just can't get to it and install much. The ability to spin ISOs for Extras will help, but the problem with custom spins is distribution. Unless there are "official" ISOs, they can't easily be mirrored or torrented. It would still be nice to see a release-day snapshot of Extras in ISO format (or even move Extras to a release and update directory structure like Core). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rdieter at math.unl.edu Mon Nov 20 15:05:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Nov 2006 09:05:24 -0600 Subject: Core + Extras 2 References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Monday 20 November 2006 08:41, Rahul Sundaram wrote: >> Are you talking about having a general policy on updates or having a >> release freeze like FC instead of rolling updates like FE? > > No, he's asking about introducing new packages to a released product. Say > Fedora 7 goes out the door with a given package set. Three weeks later a > great new package gets added to the Fedora universe, what kind of policy > would there be in making this package available to the Fedora 7 users? IMO, barring policy details on how to make it work (which can be hammerred out later), adding new packages to Fedora after "release" is IMO absolutely essential. -- Rex From mattdm at mattdm.org Mon Nov 20 15:09:03 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:09:03 -0500 Subject: Core + Exrtas 2 In-Reply-To: <4561C3D1.2020106@hhs.nl> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120144822.GB19155@jadzia.bu.edu> <4561C3D1.2020106@hhs.nl> Message-ID: <20061120150903.GA20741@jadzia.bu.edu> On Mon, Nov 20, 2006 at 04:03:45PM +0100, Hans de Goede wrote: > Why, what is there to loose? I agree with you on major upgrades of > existing packages, but adding a new package to the repo, say a new game > for example, will not hurt existing users in anyway, even if they do a > daily yum update it will change nothing for them, except an ever so > slightly larger metadata download. It encourages people to move to new releases to get new stuff. And of course skilled users who want the package on an older release can always rebuild it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Nov 20 15:09:51 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:09:51 -0500 Subject: Core + Extras 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <20061120150951.GB20741@jadzia.bu.edu> On Mon, Nov 20, 2006 at 09:05:24AM -0600, Rex Dieter wrote: > IMO, barring policy details on how to make it work (which can be hammerred > out later), adding new packages to Fedora after "release" is IMO absolutely > essential. What can't stand six months of testing in rawhide? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Mon Nov 20 14:41:10 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 20 Nov 2006 08:41:10 -0600 Subject: [RFE, Patch, Multi-lib] 32bit support /usr/bin/firefox In-Reply-To: <45574FD3.5000305@togami.com> References: <1163168226.26941.21.camel@gilboa-home-dev.localhost> <4555F806.80709@redhat.com> <1163322809.1615.6.camel@gilboa-work-dev> <45574C0A.1060309@redhat.com> <1163349691.1615.99.camel@gilboa-work-dev> <45574FD3.5000305@togami.com> Message-ID: <1164033670.17203.5.camel@goat.booze> On Sun, 2006-11-12 at 11:46 -0500, Warren Togami wrote: > The real solution is to make browser plugins run out-of-process. This > would have tremendous benefits to us in the long-term. I am skeptical > however that it will happen in a timely manner. mozplugger! From seg at haxxed.com Mon Nov 20 03:03:11 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 19 Nov 2006 21:03:11 -0600 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <4559E440.7030307@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> Message-ID: <1163991791.17203.3.camel@goat.booze> On Tue, 2006-11-14 at 18:44 +0300, Dmitry Butskoy wrote: > The latest updated kernel has another HZ value (1000 instead of 250), > according to: > > > * Thu Nov 9 2006 Dave Jones > > - Change HZ to 1000 for increased accuracy. > > (Except in Xen, where it stays at 250 for now). Woohoo, Rosegarden (which I maintain in Extras) doesn't bitch anymore! From rc040203 at freenet.de Mon Nov 20 15:08:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 16:08:48 +0100 Subject: Core + Exrtas 2 In-Reply-To: <200611200913.52895.jkeating@redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <1164035329.6875.13.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: > On Monday 20 November 2006 08:41, Rahul Sundaram wrote: > > Are you talking about having a general policy on updates or having a > > release freeze like FC instead of rolling updates like FE? > > No, he's asking about introducing new packages to a released product. Say > Fedora 7 goes out the door with a given package set. Three weeks later a > great new package gets added to the Fedora universe, what kind of policy > would there be in making this package available to the Fedora 7 users? IMO, basically like FE has been doing it, so far, except that breaking APIs, ABIs and packages deps etc. must not happen. > Its an interesting question, one that I'd like to hear opinions on. > Historically we haven't made new packages available in core unless they were > needed by something else already in. However having Extras around helped in > that new packages could get introduced there. Exactly, you'd loose this advantage. Also you seem to be neglecting that "volunteer contributors" are interested in seeing their packages being shipped and used, i.e. as part of the current distro. At least to me contributing packages to "rawhide" at the price of having to cope with "rawhide" would be highly non-interesting and non-applicable. Ralf From jeff at ocjtech.us Mon Nov 20 15:12:46 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 20 Nov 2006 09:12:46 -0600 Subject: Core + Exrtas 2 In-Reply-To: <200611200913.52895.jkeating@redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: > On Monday 20 November 2006 08:41, Rahul Sundaram wrote: > > Are you talking about having a general policy on updates or having a > > release freeze like FC instead of rolling updates like FE? > > No, he's asking about introducing new packages to a released product. Say > Fedora 7 goes out the door with a given package set. Three weeks later a > great new package gets added to the Fedora universe, what kind of policy > would there be in making this package available to the Fedora 7 users? > > Its an interesting question, one that I'd like to hear opinions on. > Historically we haven't made new packages available in core unless they were > needed by something else already in. However having Extras around helped in > that new packages could get introduced there. Just adding the package in > sounds OK on the surface, but one needs to consider some of the guidelines > we're putting up as far as what can be spun and called Fedora. If a bunch of > new packages show up after Fedora 7 is cut, would somebody be able to make > use of those packages when spinning their cut of Fedora 7? I think it's > pretty safe to say that a lot of these packages wouldn't have a chance to go > through any kind of QA / Testing that Will is trying to put in place. Here's a proposal to consider: "Official" packages for Fedora release X would consist of those packages that exist in the development repository at the time that release X is branched, plus official packages that are updated to fix security issues or bugs. Maintainers would be discouraged from performing non- security or bugfix related updates to official packages, especially if the update would require updates to other packages. New packages (i.e. packages that were not in the development repository when the release was branched) would be added officially to a Fedora X release only if they were required to fix a security issue or bug with a package already in the official release. Approval from whatever board is in charge of Fedora would be required to give a new package official status in a released version of Fedora. However, builds for new packages could be requested for non-development branches. The binary packages would go into the same yum repos as official packages but would have "unofficial" status. No official package could have a build- or run-time dependency on an unofficial package, no conflicts between official and unofficial packages, etc. etc. Also, no Fedora branded {server,desktop,yadda yadda} CD/DVD release could include unofficial packages (you could make a release, you just couldn't call it Fedora). Use of the package database would be required to track the status of packages, and hopefully scripts could be developed that would prevent (or at least detect) violations of policy. Allowing "unofficial" packages in the yum repos is so that people could access new packages easily (as long as they have Internet access). Requiring people to run development (or downloading the SRPM and rebuilding it) just to access new packages just seems too cruel. I'm sure that there are a lot of people out there like me that want to try out that new game or word processor or whatever but need a stable enough system that they can rely on it being in a working state. Jeff -------------- 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 rc040203 at freenet.de Mon Nov 20 15:09:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 16:09:45 +0100 Subject: Core + Extras 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <1164035385.6875.16.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 09:05 -0600, Rex Dieter wrote: > Jesse Keating wrote: > > > On Monday 20 November 2006 08:41, Rahul Sundaram wrote: > >> Are you talking about having a general policy on updates or having a > >> release freeze like FC instead of rolling updates like FE? > > > > No, he's asking about introducing new packages to a released product. Say > > Fedora 7 goes out the door with a given package set. Three weeks later a > > great new package gets added to the Fedora universe, what kind of policy > > would there be in making this package available to the Fedora 7 users? > > IMO, barring policy details on how to make it work (which can be hammerred > out later), adding new packages to Fedora after "release" is IMO absolutely > essential. Definitely - It's one of the essentials the current FE is based on. Ralf From alan at redhat.com Mon Nov 20 15:16:21 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Nov 2006 10:16:21 -0500 Subject: Core + Extras 2 In-Reply-To: <20061120150951.GB20741@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> Message-ID: <20061120151621.GB23437@devserv.devel.redhat.com> On Mon, Nov 20, 2006 at 10:09:51AM -0500, Matthew Miller wrote: > > out later), adding new packages to Fedora after "release" is IMO absolutely > > essential. > > What can't stand six months of testing in rawhide? Packaging assumptions which block extras packages, updates which change name due to trademarks From mattdm at mattdm.org Mon Nov 20 15:18:52 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:18:52 -0500 Subject: Core + Extras 2 In-Reply-To: <20061120151621.GB23437@devserv.devel.redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> <20061120151621.GB23437@devserv.devel.redhat.com> Message-ID: <20061120151852.GA21270@jadzia.bu.edu> On Mon, Nov 20, 2006 at 10:16:21AM -0500, Alan Cox wrote: > > > out later), adding new packages to Fedora after "release" is IMO absolutely > > > essential. > > What can't stand six months of testing in rawhide? > Packaging assumptions which block extras packages, updates which change > name due to trademarks ? That sounds exactly like a reason to have rawhide rather than dropping instability into the released distro. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Mon Nov 20 15:25:11 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 16:25:11 +0100 Subject: Core + Extras 2 In-Reply-To: <20061120150951.GB20741@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> Message-ID: <1164036311.6875.32.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 10:09 -0500, Matthew Miller wrote: > On Mon, Nov 20, 2006 at 09:05:24AM -0600, Rex Dieter wrote: > > IMO, barring policy details on how to make it work (which can be hammerred > > out later), adding new packages to Fedora after "release" is IMO absolutely > > essential. > > What can't stand six months of testing in rawhide? Users, who want to use/need a package, developers/maintainers who want to see their work used. Rawhide doesn't cater these *user demands*, rawhide is a mere developer platform trying to cater their demands. Ralf From jkeating at redhat.com Mon Nov 20 15:28:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 10:28:33 -0500 Subject: Core + Exrtas 2 In-Reply-To: <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> References: <4561AD44.6040404@hhs.nl> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> Message-ID: <200611201028.36717.jkeating@redhat.com> On Monday 20 November 2006 10:12, Jeffrey C. Ollie wrote: > Here's a proposal to consider: I'd like to mull over your proposal, but on the service it seems very confusing, and would be confusing to packagers trying to figure out where their package goes, and composers trying to figure out what they could use for a compose. I'd prefer very simplistic and easy to understand rules if possible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Mon Nov 20 15:31:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 16:31:03 +0100 Subject: Core + Exrtas 2 In-Reply-To: <20061120150903.GA20741@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120144822.GB19155@jadzia.bu.edu> <4561C3D1.2020106@hhs.nl> <20061120150903.GA20741@jadzia.bu.edu> Message-ID: <4561CA37.2070600@hhs.nl> Matthew Miller wrote: > On Mon, Nov 20, 2006 at 04:03:45PM +0100, Hans de Goede wrote: >> Why, what is there to loose? I agree with you on major upgrades of >> existing packages, but adding a new package to the repo, say a new game >> for example, will not hurt existing users in anyway, even if they do a >> daily yum update it will change nothing for them, except an ever so >> slightly larger metadata download. > > It encourages people to move to new releases to get new stuff. And of course > skilled users who want the package on an older release can always rebuild > it. > Lets say we have this merged / unified FC-7, I'm not arguing that we then should still allow packages to be added to FC-6, but we should allow adding them to FC-7, so I don't buy this argument. Actually not allowing them in the new unified one, would result in the opposite of which you advocate, I could still add a new game to FC-6 as that still has the old model, but I couldn't add it to FC-7, that will sure motivate people to update to FC-7. Ant to quote Ralf: ""Exactly, you'd loose this advantage. Also you seem to be neglecting that "volunteer contributors" are interested in seeing their packages being shipped and used, i.e. as part of the current distro. At least to me contributing packages to "rawhide" at the price of having to cope with "rawhide" would be highly non-interesting and non-applicable." I fully agree with this. I invest a not small amount of time to create new packages for Fedora, and then I would like our users, or atleast those who are using a still supported release to be able to use them. Adding packages to a EOL release is a whole other story, I'm agaist that just like you. Regards, Hans From emmanuel.seyman at club-internet.fr Mon Nov 20 15:26:10 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 20 Nov 2006 16:26:10 +0100 Subject: Core + Exrtas 2 In-Reply-To: <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> Message-ID: <20061120152610.GA6644@orient.maison.lan> On Mon, Nov 20, 2006 at 09:12:46AM -0600, Jeffrey C. Ollie wrote: > > "Official" packages for Fedora release X would consist of those packages > that exist in the development repository at the time that release X is > branched, plus official packages that are updated to fix security issues > or bugs. Maintainers would be discouraged from performing non- security > or bugfix related updates to official packages, especially if the update > would require updates to other packages. This is not what I'm looking for in Fedora. Please don't do this. It will just turn Fedora into yet another one of many "backport security fixes only and make our users die of boredom" distributions. Emmanuel From mattdm at mattdm.org Mon Nov 20 15:31:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:31:23 -0500 Subject: Core + Extras 2 In-Reply-To: <1164036311.6875.32.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> <1164036311.6875.32.camel@mccallum.corsepiu.local> Message-ID: <20061120153123.GA21947@jadzia.bu.edu> On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote: > > What can't stand six months of testing in rawhide? > Users, who want to use/need a package, developers/maintainers who want > to see their work used. Rawhide doesn't cater these *user demands*, > rawhide is a mere developer platform trying to cater their demands. I see this side of it too. How about stipulating that new packages will only go in the newest release, and won't be added to older still-supported releases? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Mon Nov 20 15:31:42 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 16:31:42 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1163991791.17203.3.camel@goat.booze> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> Message-ID: <1164036702.6875.37.camel@mccallum.corsepiu.local> On Sun, 2006-11-19 at 21:03 -0600, Callum Lerwick wrote: > On Tue, 2006-11-14 at 18:44 +0300, Dmitry Butskoy wrote: > > The latest updated kernel has another HZ value (1000 instead of 250), > > according to: > > > > > * Thu Nov 9 2006 Dave Jones > > > - Change HZ to 1000 for increased accuracy. > > > (Except in Xen, where it stays at 250 for now). > > Woohoo, Rosegarden (which I maintain in Extras) doesn't bitch anymore! Could it be this change also had an impact on ntpd? At least, since this change I am facing severe problems with my ntp setup (ntp clients are drifting away and have problems to sync). Or is this just a random coincidence? Ralf From mattdm at mattdm.org Mon Nov 20 15:32:56 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:32:56 -0500 Subject: Core + Exrtas 2 In-Reply-To: <20061120152610.GA6644@orient.maison.lan> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> Message-ID: <20061120153256.GB21947@jadzia.bu.edu> On Mon, Nov 20, 2006 at 04:26:10PM +0100, Emmanuel Seyman wrote: > This is not what I'm looking for in Fedora. Perhaps what you are looking for is in rawhide. (That's what I run on my desktop.) > Please don't do this. It will just turn Fedora into yet another one of > many "backport security fixes only and make our users die of boredom" > distributions. There's a six month release cycle! Do you really die of boredom that quickly? There's something to be said for a _little_ boring. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Mon Nov 20 15:35:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 20 Nov 2006 16:35:46 +0100 Subject: Core + Extras 2 In-Reply-To: <20061120153123.GA21947@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> <1164036311.6875.32.camel@mccallum.corsepiu.local> <20061120153123.GA21947@jadzia.bu.edu> Message-ID: <4561CB52.9010407@hhs.nl> Matthew Miller wrote: > On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote: >>> What can't stand six months of testing in rawhide? >> Users, who want to use/need a package, developers/maintainers who want >> to see their work used. Rawhide doesn't cater these *user demands*, >> rawhide is a mere developer platform trying to cater their demands. > > I see this side of it too. > > How about stipulating that new packages will only go in the newest release, > and won't be added to older still-supported releases? > That could be done, but whats the gain? We have recently been discussing to wait with EOL a bit so that users only have to upgrade once every year, thats already pretty often for some users, why disallow them use / pleasure of newer packages? Now adding newer packages to EOL. thats bad, but why not to FC-current and FC-(current-1)? Early updaters will upgrade soon anyways, and others are very unlikely to upgrade sooner for one or 2 new packages which they want, they will probab;y start using atrpms or something like that, which is exactly what we do not want. Regards, Hans From mattdm at mattdm.org Mon Nov 20 15:36:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Nov 2006 10:36:23 -0500 Subject: Core + Extras 2 In-Reply-To: <4561CB52.9010407@hhs.nl> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> <1164036311.6875.32.camel@mccallum.corsepiu.local> <20061120153123.GA21947@jadzia.bu.edu> <4561CB52.9010407@hhs.nl> Message-ID: <20061120153623.GA22553@jadzia.bu.edu> On Mon, Nov 20, 2006 at 04:35:46PM +0100, Hans de Goede wrote: > Early updaters will upgrade soon anyways, and others are very unlikely to > upgrade sooner for one or 2 new packages which they want, > they will probab;y start using atrpms or something like that, which is > exactly what we do not want. Okay, you've convinced me. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buc at odusz.so-cdu.ru Mon Nov 20 15:42:02 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 20 Nov 2006 18:42:02 +0300 Subject: Core + Exrtas 2 In-Reply-To: <1164035329.6875.13.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> Message-ID: <4561CCCA.9070003@odu.neva.ru> Ralf Corsepius wrote: >Also you seem to be neglecting that "volunteer contributors" are >interested in seeing their packages being shipped and used, i.e. as part >of the current distro. At least to me contributing packages to "rawhide" >at the price of having to cope with "rawhide" would be highly >non-interesting and non-applicable. > > +1 Dmitry Butskoy From rc040203 at freenet.de Mon Nov 20 15:44:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 16:44:18 +0100 Subject: Core + Extras 2 In-Reply-To: <20061120153123.GA21947@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <20061120150951.GB20741@jadzia.bu.edu> <1164036311.6875.32.camel@mccallum.corsepiu.local> <20061120153123.GA21947@jadzia.bu.edu> Message-ID: <1164037458.6875.45.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 10:31 -0500, Matthew Miller wrote: > On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote: > > > What can't stand six months of testing in rawhide? > > Users, who want to use/need a package, developers/maintainers who want > > to see their work used. Rawhide doesn't cater these *user demands*, > > rawhide is a mere developer platform trying to cater their demands. > > I see this side of it too. > > How about stipulating that new packages will only go in the newest release, > and won't be added to older still-supported releases? That's the old "legacy" problem. My opinion on this: As long as a new package doesn't break something (no API/ABI changes, no SONAME changes, no package/file conflicts etc.), and as long somebody is volunteering to *maintain* a package for older releases, I don't see much reason to hinder this volunteer. In some cases, this will be possible and easy, in some cases this won't work out. In FE, in practice, this so far had worked out quite well. I also don't disagree, that we need a real "cut-off" mark somewhere, say Fedora(Current-2). Ralf From fedora at leemhuis.info Mon Nov 20 15:52:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 20 Nov 2006 16:52:49 +0100 Subject: Core + Extras 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> Message-ID: <4561CF51.10501@leemhuis.info> Rex Dieter schrieb: > Jesse Keating wrote: >> On Monday 20 November 2006 08:41, Rahul Sundaram wrote: >>> Are you talking about having a general policy on updates or having a >>> release freeze like FC instead of rolling updates like FE? >> No, he's asking about introducing new packages to a released product. Say >> Fedora 7 goes out the door with a given package set. Three weeks later a >> great new package gets added to the Fedora universe, what kind of policy >> would there be in making this package available to the Fedora 7 users? > IMO, barring policy details on how to make it work (which can be hammerred > out later), adding new packages to Fedora after "release" is IMO absolutely > essential. +1 CU thl From vonbrand at inf.utfsm.cl Mon Nov 20 16:33:54 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 20 Nov 2006 13:33:54 -0300 Subject: Core + Extras 2 In-Reply-To: Message from Alan Cox of "Mon, 20 Nov 2006 10:16:21 CDT." <20061120151621.GB23437@devserv.devel.redhat.com> Message-ID: <200611201633.kAKGXsOJ011624@laptop13.inf.utfsm.cl> Alan Cox wrote: > On Mon, Nov 20, 2006 at 10:09:51AM -0500, Matthew Miller wrote: > > > out later), adding new packages to Fedora after "release" is IMO > > > absolutely essential. > > What can't stand six months of testing in rawhide? > Packaging assumptions which block extras packages, If Extras goes away, this would be just "packages that block existing packages". Sure, if it goes that way (an update requires a new package), there is nothing to discuss really (other than if the update is warranted, that is). > updates which change > name due to trademarks That is just "the same package, updated" IMHO. None of these should make anybody loose much sleep. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From emmanuel.seyman at club-internet.fr Mon Nov 20 16:36:19 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 20 Nov 2006 17:36:19 +0100 Subject: Core + Exrtas 2 In-Reply-To: <20061120153256.GB21947@jadzia.bu.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> <20061120153256.GB21947@jadzia.bu.edu> Message-ID: <20061120163619.GA6929@orient.maison.lan> On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote: > > Perhaps what you are looking for is in rawhide. (That's what I run on my > desktop.) That may be. I've never actually tried to run rawhide on a permanent basis because I don't have the time necessary to report bugs for any extended period. > > Please don't do this. It will just turn Fedora into yet another one of > > many "backport security fixes only and make our users die of boredom" > > distributions. > > There's a six month release cycle! Do you really die of boredom that > quickly? In the case of waiting for new drivers that are needed for Fedora to work correctly on my box, I probably would, indeed, die of boredom waiting for the next release. > There's something to be said for a _little_ boring. - Demanding that packages pass through updates-testing before going to updates is a little boring. - Asking for ABI compatibility is a little boring. "Security fixes only" is far too restrictif to have that qualification. Emmanuel From thomas.canniot at laposte.net Mon Nov 20 16:39:23 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Mon, 20 Nov 2006 17:39:23 +0100 Subject: Core + Exrtas 2 In-Reply-To: <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> Message-ID: <1164040763.3657.18.camel@localhost.localdomain> Le lundi 20 novembre 2006 ? 09:12 -0600, Jeffrey C. Ollie a ?crit : > > Here's a proposal to consider: > > "Official" packages for Fedora release X would consist of those packages > that exist in the development repository at the time that release X is > branched, plus official packages that are updated to fix security issues > or bugs. Maintainers would be discouraged from performing non- security > or bugfix related updates to official packages, especially if the update > would require updates to other packages. > This is clearly against the definition of Fedora you can find on http://fedoraproject.org/wiki/FAQ "You should be using Fedora because it includes the best and latest collection of robust free and open source software available." The latest software ... The latest software ... The latest software ... -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From jkeating at redhat.com Mon Nov 20 16:50:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 11:50:18 -0500 Subject: Core + Exrtas 2 In-Reply-To: <1164040763.3657.18.camel@localhost.localdomain> References: <4561AD44.6040404@hhs.nl> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <1164040763.3657.18.camel@localhost.localdomain> Message-ID: <200611201150.18508.jkeating@redhat.com> On Monday 20 November 2006 11:39, Thomas Canniot wrote: > "You should be using Fedora because it includes the best and latest > collection of robust free and open source software available." > > The latest software ... > The latest software ... > The latest software ... But we can't possibly be all the latest all the time or else we'd never have a stable release for people to use :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Nov 20 16:53:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 22:23:44 +0530 Subject: Core + Exrtas 2 In-Reply-To: <20061120163619.GA6929@orient.maison.lan> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> <20061120153256.GB21947@jadzia.bu.edu> <20061120163619.GA6929@orient.maison.lan> Message-ID: <4561DD98.1080802@fedoraproject.org> Emmanuel Seyman wrote: > On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote: >> Perhaps what you are looking for is in rawhide. (That's what I run on my >> desktop.) > > That may be. I've never actually tried to run rawhide on a permanent basis > because I don't have the time necessary to report bugs for any extended > period. > >>> Please don't do this. It will just turn Fedora into yet another one of >>> many "backport security fixes only and make our users die of boredom" >>> distributions. >> There's a six month release cycle! Do you really die of boredom that >> quickly? > > In the case of waiting for new drivers that are needed for Fedora to work > correctly on my box, I probably would, indeed, die of boredom waiting for > the next release. You are bored because you dont get the latest updates but you dont have time to participate in testing of rawhide or updates-testing. Perhaps when you are bored you can help out and contribute. > >> There's something to be said for a _little_ boring. > > - Demanding that packages pass through updates-testing before going to > updates is a little boring. A blanket demand might be cumbersome but it generally is a good idea to shoot for better robustness. Limited exceptions can be granted for high priority security fixes and other very trivial changes. > - Asking for ABI compatibility is a little boring. I dont think we can meet ABI compatibility requirements on all updates. > "Security fixes only" is far too restrictif to have that qualification. Agreed. Rahul From sdl.web at gmail.com Mon Nov 20 16:55:04 2006 From: sdl.web at gmail.com (Leo) Date: Mon, 20 Nov 2006 16:55:04 +0000 Subject: Fedora and cvs 1.12.x? References: Message-ID: On Mon, 20/11/06, Gianluca Sforna wrote: >> Didn't realize CVS is this old in Fedora. I'd also like to see an >> update. Thanks. > > 1.11.22 is the latest release of cvs from their stable branch: being > released in July I can hardly call it "old". > Please note that, despite having an even release number, 1.12.x is a > "feature" branch (and the last release from that branch is from July > as well) I see. Thanks. -- Leo From Lam at Lam.pl Mon Nov 20 17:09:00 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 20 Nov 2006 18:09:00 +0100 Subject: Core + Exrtas 2 In-Reply-To: <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> Message-ID: <1164042540.3323.9.camel@pensja.lam.pl> Dnia 20-11-2006, pon o godzinie 09:12 -0600, Jeffrey C. Ollie napisa?(a): > Here's a proposal to consider: > > "Official" packages for Fedora release X would consist of those packages > that exist in the development repository at the time that release X is > branched, (...) > However, builds for new packages could be requested for non-development > branches. The binary packages would go into the same yum repos as > official packages but would have "unofficial" status. What you propose would become the new Extras - there would be "official" and "unofficial" where currently there's "Core" and "Extras". There's no reason to ban inclusion of e.g. a new game to the repositories UNLESS it's not obsoleting something already in. So I'm for a policy: - update to new versions of existing packages if there are serious reasons (severe bugs, security fixes), - add new packages provided they don't get installed automatically on users' computers. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From rc040203 at freenet.de Mon Nov 20 17:11:21 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Nov 2006 18:11:21 +0100 Subject: Core + Exrtas 2 In-Reply-To: <4561DD98.1080802@fedoraproject.org> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> <20061120153256.GB21947@jadzia.bu.edu> <20061120163619.GA6929@orient.maison.lan> <4561DD98.1080802@fedoraproject.org> Message-ID: <1164042681.6875.72.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 22:23 +0530, Rahul Sundaram wrote: > > - Asking for ABI compatibility is a little boring. > > I dont think we can meet ABI compatibility requirements on all updates. You can't avoid it. In fact, current Core strictly does or at least tries hard to strive for it. FE is a bit sloppier about it. Ralf From jeff at ocjtech.us Mon Nov 20 17:13:52 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 20 Nov 2006 11:13:52 -0600 Subject: Core + Exrtas 2 In-Reply-To: <1164042540.3323.9.camel@pensja.lam.pl> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <1164042540.3323.9.camel@pensja.lam.pl> Message-ID: <1164042832.3425.34.camel@lt21223.campus.dmacc.edu> On Mon, 2006-11-20 at 18:09 +0100, Leszek Matok wrote: > Dnia 20-11-2006, pon o godzinie 09:12 -0600, Jeffrey C. Ollie > napisa?(a): > > Here's a proposal to consider: > > > > "Official" packages for Fedora release X would consist of those packages > > that exist in the development repository at the time that release X is > > branched, (...) > > > However, builds for new packages could be requested for non-development > > branches. The binary packages would go into the same yum repos as > > official packages but would have "unofficial" status. > What you propose would become the new Extras - there would be "official" > and "unofficial" where currently there's "Core" and "Extras". Kindof... it would mostly control what kind of updates could be applied to a package in a release branch and which packages could be selected in a CD/DVD compose and still be branded as "Fedora". Jeff -------------- 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 Mon Nov 20 17:35:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Nov 2006 11:35:17 -0600 Subject: Core + Exrtas 2 References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: >> No, he's asking about introducing new packages to a released product. >> Say >> Fedora 7 goes out the door with a given package set. Three weeks later a >> great new package gets added to the Fedora universe, what kind of policy >> would there be in making this package available to the Fedora 7 users? > IMO, basically like FE has been doing it, so far, except that breaking > APIs, ABIs and packages deps etc. must not happen. That language may be a bit too strong, as I can think of cases where an essential update may end up breaking ABI, though it's not unreasonable to to make policy such that it *should* (not must) be avoided. -- Rex From sundaram at fedoraproject.org Mon Nov 20 17:38:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 23:08:46 +0530 Subject: Core + Exrtas 2 In-Reply-To: <1164042681.6875.72.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> <20061120153256.GB21947@jadzia.bu.edu> <20061120163619.GA6929@orient.maison.lan> <4561DD98.1080802@fedoraproject.org> <1164042681.6875.72.camel@mccallum.corsepiu.local> Message-ID: <4561E826.5060001@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2006-11-20 at 22:23 +0530, Rahul Sundaram wrote: > >>> - Asking for ABI compatibility is a little boring. >> I dont think we can meet ABI compatibility requirements on all updates. > You can't avoid it. In fact, current Core strictly does or at least > tries hard to strive for it. FE is a bit sloppier about it. > Strictly maintaining ABI is very heavy amount of additional work. Since many upstream projects dont care about it, this essentially means backporting fixes, struggle on choiecs between security fixes and ABI breakage, doing QA ack's on every individual patch, running it through a series of tests etc that is being done on RHEL. We cant afford that maintenance overhead currently in Fedora. Rahul From rnorwood at redhat.com Mon Nov 20 18:12:30 2006 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 20 Nov 2006 13:12:30 -0500 Subject: Perl bindings for RPM in FC6 In-Reply-To: <45619737.5050105@city-fan.org> (Paul Howarth's message of "Mon, 20 Nov 2006 11:53:27 +0000") References: <7dd7ab490611181202q17f49d7ctcada79762125b369@mail.gmail.com> <45619737.5050105@city-fan.org> Message-ID: Paul Howarth writes: > Chris Weyl wrote: >> On 11/18/06, Sam Varshavchik wrote: >>> What's the deal with RPM2.pm, it's not in FC6, nor in Extras? >> It has a long and storied history, but now appears to just be >> stalled in review: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 > > The package is actually approved but the original submitter is no > longer around and nobody else has volunteered to pick it up yet. Well > actually Robin (the current Core perl maintainer) did say he'd do it > if nobody else was interested, but that was back in September. Yeah, he sent the email and then he promptly forgot about it. D'oh! I'll see about following the process to get it into extras this week, sorry! (Not sure how the proposed extras/core merge will effect this, though...) -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From nicolas.mailhot at laposte.net Mon Nov 20 18:49:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Nov 2006 19:49:35 +0100 Subject: Core + Exrtas 2 In-Reply-To: <20061120163619.GA6929@orient.maison.lan> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035566.3425.30.camel@lt21223.campus.dmacc.edu> <20061120152610.GA6644@orient.maison.lan> <20061120153256.GB21947@jadzia.bu.edu> <20061120163619.GA6929@orient.maison.lan> Message-ID: <1164048586.3004.20.camel@rousalka.dyndns.org> Le lundi 20 novembre 2006 ? 17:36 +0100, Emmanuel Seyman a ?crit : > On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote: > > > > Perhaps what you are looking for is in rawhide. (That's what I run on my > > desktop.) > > That may be. I've never actually tried to run rawhide on a permanent basis > because I don't have the time necessary to report bugs for any extended > period. It's not like this. Running rawhide means you'll have some parts of the system break at inconvenient time, so you learn workarounding a lot, but no rawhide user has the energy to report every broken thing. You do it when you're really annoyed and you have the time to write a good report. The rest of the time you wait a few days for breakage to fix itself. That's all there is to the eating babies part 99% of the time (unglamorous, I know). Rawhide is only slightly less stable than some Extras parts. -- Nicolas Mailhot From sundaram at fedoraproject.org Mon Nov 20 19:02:52 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Nov 2006 00:32:52 +0530 Subject: Perl bindings for RPM in FC6 In-Reply-To: References: <7dd7ab490611181202q17f49d7ctcada79762125b369@mail.gmail.com> <45619737.5050105@city-fan.org> Message-ID: <4561FBDC.9070507@fedoraproject.org> Robin Norwood wrote: > Paul Howarth writes: > >> Chris Weyl wrote: >>> On 11/18/06, Sam Varshavchik wrote: >>>> What's the deal with RPM2.pm, it's not in FC6, nor in Extras? >>> It has a long and storied history, but now appears to just be >>> stalled in review: >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 >> The package is actually approved but the original submitter is no >> longer around and nobody else has volunteered to pick it up yet. Well >> actually Robin (the current Core perl maintainer) did say he'd do it >> if nobody else was interested, but that was back in September. > > Yeah, he sent the email and then he promptly forgot about it. D'oh! > > I'll see about following the process to get it into extras this week, > sorry! (Not sure how the proposed extras/core merge will effect this, > though...) > It wont. Contributors just basically would have to continue doing their work and we will figure out how to do a merge without getting in the way of people trying to get new packages in. Rahul From tonynelson at georgeanelson.com Mon Nov 20 19:35:34 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 20 Nov 2006 14:35:34 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: Message-ID: At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote: >Tony Nelson writes: > >> I propose that there should be a nightly cron task to check the RPM > >I proposed this several years ago, and got poo-poohed. Well, did you offer to write it for them? :) >I now just have a cron.daily script that just makes a copy of /var/lib/rpm >on a five day rotation. I'm putting something of that sort into the script, saving the last 2 good ones. (Not like logrotate, which rotates the logs weekly whether they need it or not, so a month or so later all the data is lost.) -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From tonynelson at georgeanelson.com Mon Nov 20 19:35:58 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 20 Nov 2006 14:35:58 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <20061120123823.90928.qmail@web52404.mail.yahoo.com> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> Message-ID: At 4:38 AM -0800 11/20/06, Otto Rey wrote: >From: Sam Varshavchik >Sent: Sunday, November 19, 2006 11:50:09 PM > >>Tony Nelson writes: >> >>> I propose that there should be a nightly cron task to check the RPM > >>I proposed this several years ago, and got poo-poohed. >> >>I now just have a cron.daily script that just makes a copy of /var/lib/rpm >>on a five day rotation. > >This sound good, but first we need to detect why rpms database got corrupted. First? Do both at the same time! I'm verifying the database while other people are working on the RPM bugs. Plus, knowing more about the corruption would provide useful data to the effort to fix it. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From davej at redhat.com Mon Nov 20 19:47:31 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 20 Nov 2006 14:47:31 -0500 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164036702.6875.37.camel@mccallum.corsepiu.local> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> Message-ID: <20061120194731.GB27924@redhat.com> On Mon, Nov 20, 2006 at 04:31:42PM +0100, Ralf Corsepius wrote: > On Sun, 2006-11-19 at 21:03 -0600, Callum Lerwick wrote: > > On Tue, 2006-11-14 at 18:44 +0300, Dmitry Butskoy wrote: > > > The latest updated kernel has another HZ value (1000 instead of 250), > > > according to: > > > > > > > * Thu Nov 9 2006 Dave Jones > > > > - Change HZ to 1000 for increased accuracy. > > > > (Except in Xen, where it stays at 250 for now). > > > > Woohoo, Rosegarden (which I maintain in Extras) doesn't bitch anymore! > > Could it be this change also had an impact on ntpd? > > At least, since this change I am facing severe problems with my ntp > setup (ntp clients are drifting away and have problems to sync). > > Or is this just a random coincidence? A coincidence I hope. I'm not sure how increased timing resolution could cause the drifting effects you've observed. I've also not noticed any other similar reports (yet?). Dave -- http://www.codemonkey.org.uk From dedourek at unb.ca Mon Nov 20 21:11:58 2006 From: dedourek at unb.ca (John DeDourek) Date: Mon, 20 Nov 2006 17:11:58 -0400 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <20061120194731.GB27924@redhat.com> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> Message-ID: <45621A1E.3060608@unb.ca> I have dealt with this issue before. I think that the effect is the result of rounding errors in the timing code in the kernel. In any case, the effective frequency of the clock changes slightly when the Hz. is changed. When starting ntpd, it uses the "remembered" effective frequency of the clock from the previous shutdown in the "drift file". (Actually, this remembers the frequency error from the "nominal" frequency.) In any case, when changing to a kernel with a different Hz., I had the best result when I deleted the drift file and let ntpd create a new one. Otherwise, it appears, that it takes a while for ntpd to convince itself that the frequency of the clock has made a step change. (Of course, if you just let it run a while, it should eventually convince itself of the new frequency; so if you're still having these problems after a while, then it is something different). If you want to convince yourself of the issue, delete (or rename) the drift file, and run the 250 Hz. kernel a while; then record the contents of the drift file. Repeat with the 1000 Hz. kernel. I for one, would be interested in the result, since it has been a significant time since I ran these tests, and the kernel clock code has changed significantly since then. BTW. The most significant problem with a 1000 Hz kernel the last time I ran it several years ago shows up on slow machines. It turns out that changing the frequency of the kernel clock timer doesn't make code in drivers execute any faster; rather that is a function of the CPU speed. Unfortunately, this increases the amount of time that the drivers will lock out interrupts. Unfortunately, since clock interrupts are a simple toggle, if two interrupts occur while the driver has the interrupts locked out, only one interrupt will actually be handled. Higher clock rates increase the probability that this will happen. In the "old days" this showed up as a "falling behind" by one clock interrupt interval whenever it happened. I seem to recall that some code has since been added to the clock interrupt routine to try to detect lost interrupts and add multiple clock intervals on a single interrupt. If it is a "slow processor" (or a dynamically throttled processor running in slow mode) that is showing the clock problems, you may be "debugging" the lost interrupt code. John DeDourek, University of New Brunswick Dave Jones wrote: > On Mon, Nov 20, 2006 at 04:31:42PM +0100, Ralf Corsepius wrote: > > On Sun, 2006-11-19 at 21:03 -0600, Callum Lerwick wrote: > > > On Tue, 2006-11-14 at 18:44 +0300, Dmitry Butskoy wrote: > > > > The latest updated kernel has another HZ value (1000 instead of 250), > > > > according to: > > > > > > > > > * Thu Nov 9 2006 Dave Jones > > > > > - Change HZ to 1000 for increased accuracy. > > > > > (Except in Xen, where it stays at 250 for now). > > > > > > Woohoo, Rosegarden (which I maintain in Extras) doesn't bitch anymore! > > > > Could it be this change also had an impact on ntpd? > > > > At least, since this change I am facing severe problems with my ntp > > setup (ntp clients are drifting away and have problems to sync). > > > > Or is this just a random coincidence? > > A coincidence I hope. I'm not sure how increased timing resolution could > cause the drifting effects you've observed. I've also not noticed > any other similar reports (yet?). > > Dave > From mmcgrath at fedoraproject.org Mon Nov 20 22:34:01 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 20 Nov 2006 16:34:01 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> Message-ID: <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> On 11/19/06, Mike McGrath wrote: > On 11/18/06, Mike McGrath wrote: > > > Bottom line, this sucks but we're working on it. Should be up and > > better than ever by Monday. > > > > Buhhh, late monday. > > -Mike > We've got the box, restores are happening as we speak, 48G restored so far. I'll be restoring the ssh-host keys last so if you're still getting ssh mismatch errors... its not ready to be logged into. -Mike From hughsient at gmail.com Mon Nov 20 22:36:35 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 20 Nov 2006 22:36:35 +0000 Subject: rawhide report: 20061118 changes In-Reply-To: <1164033185.28927.9.camel@localhost.localdomain> References: <200611181116.kAIBGdH2018442@hs20-bc2-6.build.redhat.com> <1163849313.3566.2.camel@localhost.localdomain> <1164033185.28927.9.camel@localhost.localdomain> Message-ID: <1164062195.4485.3.camel@hughsie-laptop> On Mon, 2006-11-20 at 09:33 -0500, Adam Jackson wrote: > On Sat, 2006-11-18 at 11:28 +0000, Richard Hughes wrote: > > On Sat, 2006-11-18 at 06:16 -0500, buildsys at redhat.com wrote: > > > * Fri Nov 17 2006 Adam Jackson 2.3.0-1.fc7 > > > - Update to 2.3.0 from upstream. > > > - Add nouveau userspace header. > > > > Hey, looking good. What's the consequence of this? We can start hacking > > nouveau[1] easily? Or am I getting excited over nothing? > > That too. Or, if you just want to run it, you can do that too ;) > > The nouveau driver requires a DRM component in the kernel (the good > kind, not the RIAA kind), which I have more or less merged and am really > just waiting for the kernel to be in a buildable state before pushing to > rawhide. That was my next question :-) > After that piece lands, the xorg-x11-drv-nv package will > install two drivers, nv and nouveau, similar to the i810/intel bundle. > As mentioned later in the thread, nv will still be the default. Is this what upstream us going to do, i.e. what's the benefit to doing this, rather than just including a new package xorg-x11-drv-nouveau? > So basically, if you want to work on nouveau, all the source and all the > buildreqs will already be set up for you. Yay! If instead you just > want to try it and compare, you can do that too. Also yay! Legend, thanks. Richard. From mrsam at courier-mta.com Mon Nov 20 23:35:56 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 20 Nov 2006 18:35:56 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda References: Message-ID: Tony Nelson writes: > At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote: >>Tony Nelson writes: >> >>> I propose that there should be a nightly cron task to check the RPM >> >>I proposed this several years ago, and got poo-poohed. > > Well, did you offer to write it for them? :) No, but if they need my help to write a ten-line long shell script, I think the whole project is a lost cause. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Mon Nov 20 23:49:54 2006 From: steve at silug.org (Steven Pritchard) Date: Mon, 20 Nov 2006 17:49:54 -0600 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <20061120123823.90928.qmail@web52404.mail.yahoo.com> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> Message-ID: <20061120234954.GA2324@osiris.silug.org> On Mon, Nov 20, 2006 at 04:38:23AM -0800, Otto Rey wrote: > This sound good, but first we need to detect why rpms database got corrupted. It's Berkeley DB. Corruption should be expected. :-/ Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From bob at lorez.org Tue Nov 21 04:32:09 2006 From: bob at lorez.org (Bob Richmond) Date: Mon, 20 Nov 2006 20:32:09 -0800 Subject: gstreamer-plugins-good and (the lack of) taglib Message-ID: <45628149.7080101@lorez.org> The gstreamer-plugins-good package in core is missing taglib support, but the source package will happily build it if you happen to have the taglib-devel package from Extras installed when you build the gstreamer-plugins-good package, but the resulting RPM won't be created because the resulting new library file isn't included in the files list. I've attached a patch that will explicitly require taglib as a BuildRequires and include libgsttaglib.so in the file list so that the standard package has taglib support. Having taglib support in the plugins package means you can install the gstreamer-plugins-ugly package from (eg) Livna, and be able to include ! id3v2mux in the gstreamer pipeline, and actually have it output an MP3 with proper ID3 tags. The only problem I can think of in introducing this patch is the dirtiness of making a package from Extras be a build requirement of a package in core. Is this generally frowned upon? -------------- next part -------------- A non-text attachment was scrubbed... Name: gstreamer-plugins-good.taglib.diff Type: text/x-patch Size: 759 bytes Desc: not available URL: From caillon at redhat.com Tue Nov 21 06:09:49 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 21 Nov 2006 01:09:49 -0500 Subject: gstreamer-plugins-good and (the lack of) taglib In-Reply-To: <45628149.7080101@lorez.org> References: <45628149.7080101@lorez.org> Message-ID: <4562982D.20302@redhat.com> Bob Richmond wrote: > The only problem I can think of in introducing this patch is the > dirtiness of making a package from Extras be a build requirement of a > package in core. Is this generally frowned upon? Until the Extras/Core dichotomy is merged, yes. From rc040203 at freenet.de Tue Nov 21 06:24:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 07:24:24 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <45621A1E.3060608@unb.ca> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <45621A1E.3060608@unb.ca> Message-ID: <1164090264.6875.127.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 17:11 -0400, John DeDourek wrote: > I have dealt with this issue before. I think that the effect is the > result of rounding errors in the timing code in the kernel. In any > case, the effective frequency of the clock changes slightly when the > Hz. is changed. When starting ntpd, it uses the "remembered" effective > frequency of the clock from the previous shutdown in the "drift file". > (Actually, this remembers the frequency error from the "nominal" frequency.) > In any case, when changing to a kernel with a different Hz., I had > the best result when I deleted the drift file and let ntpd create > a new one. Otherwise, it appears, that it takes a while for ntpd > to convince itself that the frequency of the clock has made a step > change. (Of course, if you just let it run a while, it should > eventually convince itself of the new frequency; so if you're still > having these problems after a while, then it is something different). Let me describe what has happened: I have one machine, on which the original fc6-kernel doesn't boot, while fc5-kernels run flawlessly. Therefore, after upgrading to fc6, I had been running an fc5-kernel underneath of fc6 on this machine. In this setup, ntp had been working flawlessly, resulting into a driftfile containing a value |drift| < 100.0. At the time when the 1000Hz fc6-kernels had been released, I finally managed to boot this machine with "noapic" for the first time. Ca. 2 days uptime later, ntp had lost sync. "drift" had hit its tolerance (>512). I tried to set drift to 0. 1-2 days later "drift" hit the 512 tolerance again, ntp didn't converge. This was the situation last Friday. Then, I tried to changed this machine's ntp setup to writing driftfile every 10 minutes instead 60 minutes (ntp.conf: driftfile /var/lib/ntp/drift 10). This finally seems to have helped. At least, since having introduced this change, ntp seems to be able to sync again, |drift| stays < 80.0. > If you want to convince yourself of the issue, delete (or rename) > the drift file, and run the 250 Hz. kernel a while; then record > the contents of the drift file. Repeat with the 1000 Hz. kernel. > I for one, would be interested in the result, since it has been > a significant time since I ran these tests, and the kernel clock > code has changed significantly since then. That's very similar to what I did. > Dave Jones wrote: > > > On Mon, Nov 20, 2006 at 04:31:42PM +0100, Ralf Corsepius wrote: > > > On Sun, 2006-11-19 at 21:03 -0600, Callum Lerwick wrote: > > > > On Tue, 2006-11-14 at 18:44 +0300, Dmitry Butskoy wrote: > > > > > The latest updated kernel has another HZ value (1000 instead of 250), > > > > > according to: > > > > > > > > > > > * Thu Nov 9 2006 Dave Jones > > > > > > - Change HZ to 1000 for increased accuracy. > > > > > > (Except in Xen, where it stays at 250 for now). > > > > > > > > Woohoo, Rosegarden (which I maintain in Extras) doesn't bitch anymore! > > > > > > Could it be this change also had an impact on ntpd? > > > > > > At least, since this change I am facing severe problems with my ntp > > > setup (ntp clients are drifting away and have problems to sync). > > > > > > Or is this just a random coincidence? > > > > A coincidence I hope. I'm not sure how increased timing resolution could > > cause the drifting effects you've observed. I've also not noticed > > any other similar reports (yet?) Well, there had been some "vague/unclear" reports on ntp issues on fedora-users@, which could be read as to falling into the same class of issue. Unfortunately, this all is a rather "soft issue" very hard to grasp. May-be all his a side-effect of a different issue? I don't know[1]. Ralf [1] NetworkManager also seems to be a likely candidate to me. From skvidal at linux.duke.edu Tue Nov 21 06:39:50 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Nov 2006 01:39:50 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <20061120234954.GA2324@osiris.silug.org> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> Message-ID: <1164091190.13465.32.camel@cutter> On Mon, 2006-11-20 at 17:49 -0600, Steven Pritchard wrote: > On Mon, Nov 20, 2006 at 04:38:23AM -0800, Otto Rey wrote: > > This sound good, but first we need to detect why rpms database got corrupted. > > It's Berkeley DB. Corruption should be expected. :-/ > I guess I'm a little confused here, actually. Let's take bsddb out of the example. If I'm a client of an oracle db and I repeatedly open, read, close the database using the interface available, for small amounts of data that might not be the most efficient use of the database connection. However, if as a result of open-read-close the database is corrupted and/or rendered unusable where would you say the bug lies? To me it seems like a valid client connection should not be able to corrupt a database simply by open-read-closing no matter how many times. And if it can then clearly there is something wrong with the database code. -sv From rc040203 at freenet.de Tue Nov 21 06:56:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 07:56:06 +0100 Subject: Core + Exrtas 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> Message-ID: <1164092166.6875.131.camel@mccallum.corsepiu.local> On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote: > Ralf Corsepius wrote: > > > On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: > > >> No, he's asking about introducing new packages to a released product. > >> Say > >> Fedora 7 goes out the door with a given package set. Three weeks later a > >> great new package gets added to the Fedora universe, what kind of policy > >> would there be in making this package available to the Fedora 7 users? > > > IMO, basically like FE has been doing it, so far, except that breaking > > APIs, ABIs and packages deps etc. must not happen. > > That language may be a bit too strong, as I can think of cases where an > essential update may end up breaking ABI, though it's not unreasonable to > to make policy such that it *should* (not must) be avoided. Well, this "must" is the core point about all this - Fedora should be a stable distro. Where would be the difference to rawhide, otherwise? Ralf From mmcgrath at fedoraproject.org Tue Nov 21 07:00:42 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Nov 2006 01:00:42 -0600 Subject: CVS is busted In-Reply-To: <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> Message-ID: <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> On 11/20/06, Mike McGrath wrote: > On 11/19/06, Mike McGrath wrote: > > On 11/18/06, Mike McGrath wrote: > > > > > Bottom line, this sucks but we're working on it. Should be up and > > > better than ever by Monday. > > > > > > > Buhhh, late monday. > > > > -Mike > > > > > We've got the box, restores are happening as we speak, 48G restored so > far. I'll be restoring the ssh-host keys last so if you're still > getting ssh mismatch errors... its not ready to be logged into. > Alrighty then, new box is up. The following service should be working (if they are not, let me know immediately) legacy - cvs extras - cvs fedora - cvs dist (copy) - cvs docs - cvs font - cvs (whatever that is) viewcvs Services known NOT to work git (needs a new chroot but no data loss) Services in ????: There were a number of web services on the box that were never properly configured in the first place. Let me know if there are services taht don't work now that did before the crash. AFAIK we had no actual data loss except for commits that happened after the last backup and before the failure (which was bout an 8 hour window or so with 10 commits. I believe warren is going to contact these people or already has). I'll be working on getting the git repo back up tomorrow morning and will need someone to test, any volunteers please contact me. CVS is a very strange box in that many people have access to make changes on it (and they do) it could take a while before we get every service back online but we're doing well. Please contact me (or admin at fedoraproject) with any issues or bugs, we'll get to them soon. -Mike From pmatilai at laiskiainen.org Tue Nov 21 07:43:17 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 21 Nov 2006 09:43:17 +0200 (EET) Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <1164091190.13465.32.camel@cutter> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> Message-ID: On Tue, 21 Nov 2006, seth vidal wrote: > On Mon, 2006-11-20 at 17:49 -0600, Steven Pritchard wrote: >> On Mon, Nov 20, 2006 at 04:38:23AM -0800, Otto Rey wrote: >>> This sound good, but first we need to detect why rpms database got corrupted. >> >> It's Berkeley DB. Corruption should be expected. :-/ >> > > I guess I'm a little confused here, actually. > > Let's take bsddb out of the example. > > If I'm a client of an oracle db and I repeatedly open, read, close the > database using the interface available, for small amounts of data that > might not be the most efficient use of the database connection. > > However, if as a result of open-read-close the database is corrupted > and/or rendered unusable where would you say the bug lies? > > To me it seems like a valid client connection should not be able to > corrupt a database simply by open-read-closing no matter how many times. > And if it can then clearly there is something wrong with the database > code. Well, obviously. I think that's exactly what Steven means... Personal experience with both subversion repos using Berkeley DB storage and rpmdb has made me too expect nothing else but eventual corruption from BDB :-/ - Panu - From dominik at greysector.net Tue Nov 21 07:44:45 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 21 Nov 2006 08:44:45 +0100 Subject: CVS is busted In-Reply-To: <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> Message-ID: <20061121074445.GB29948@rathann.pekin.waw.pl> On Tuesday, 21 November 2006 at 08:00, Mike McGrath wrote: [...] > Alrighty then, new box is up. The following service should be working > (if they are not, let me know immediately) > > legacy - cvs > extras - cvs > fedora - cvs > dist (copy) - cvs > docs - cvs > font - cvs (whatever that is) > viewcvs Thank you very much for the hard work! I've just imported and built another package. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dakingun at gmail.com Tue Nov 21 07:47:06 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 21 Nov 2006 02:47:06 -0500 Subject: CVS is busted In-Reply-To: <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> References: <3237e4410611170719v4ae55d8amec76fb1f501cbcd1@mail.gmail.com> <455EBFA7.3070400@argo.co.il> <3237e4410611180928q94fa51fx7f77fdee3f3a0a55@mail.gmail.com> <3237e4410611191826hf9b20e3h5a8f108841dcb0f9@mail.gmail.com> <3237e4410611201434h4e687411u56110fc8f8fb355c@mail.gmail.com> <3237e4410611202300mc20d964s65ef708bd6d1f244@mail.gmail.com> Message-ID: On 11/21/06, Mike McGrath wrote: > On 11/20/06, Mike McGrath wrote: > > On 11/19/06, Mike McGrath wrote: > > > On 11/18/06, Mike McGrath wrote: > > > > > > > Bottom line, this sucks but we're working on it. Should be up and > > > > better than ever by Monday. > > > > > > > > > > Buhhh, late monday. > > > > > > -Mike > > > > > > > > > We've got the box, restores are happening as we speak, 48G restored so > > far. I'll be restoring the ssh-host keys last so if you're still > > getting ssh mismatch errors... its not ready to be logged into. > > > > > Alrighty then, new box is up. The following service should be working > (if they are not, let me know immediately) > Good job, thanks. From arjan at fenrus.demon.nl Tue Nov 21 08:10:53 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 09:10:53 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164090264.6875.127.camel@mccallum.corsepiu.local> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <45621A1E.3060608@unb.ca> <1164090264.6875.127.camel@mccallum.corsepiu.local> Message-ID: <1164096653.31358.634.camel@laptopd505.fenrus.org> > At the time when the 1000Hz fc6-kernels had been released, I finally > managed to boot this machine with "noapic" for the first time. this is a SMP machine? From rc040203 at freenet.de Tue Nov 21 08:15:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 09:15:39 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164096653.31358.634.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <45621A1E.3060608@unb.ca> <1164090264.6875.127.camel@mccallum.corsepiu.local> <1164096653.31358.634.camel@laptopd505.fenrus.org> Message-ID: <1164096939.7666.7.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 09:10 +0100, Arjan van de Ven wrote: > > At the time when the 1000Hz fc6-kernels had been released, I finally > > managed to boot this machine with "noapic" for the first time. D***d, this should have been "acpi=off" :( > this is a SMP machine? Nope, it's a P4 2.6GHz. Details in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213254 Ralf From arjan at fenrus.demon.nl Tue Nov 21 08:25:52 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 09:25:52 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164096939.7666.7.camel@mccallum.corsepiu.local> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <45621A1E.3060608@unb.ca> <1164090264.6875.127.camel@mccallum.corsepiu.local> <1164096653.31358.634.camel@laptopd505.fenrus.org> <1164096939.7666.7.camel@mccallum.corsepiu.local> Message-ID: <1164097552.31358.638.camel@laptopd505.fenrus.org> On Tue, 2006-11-21 at 09:15 +0100, Ralf Corsepius wrote: > On Tue, 2006-11-21 at 09:10 +0100, Arjan van de Ven wrote: > > > At the time when the 1000Hz fc6-kernels had been released, I finally > > > managed to boot this machine with "noapic" for the first time. > D***d, this should have been "acpi=off" :( but it's worth trying noapic since somehow it seems apics get enabled anyhow on your box (based on the log in bugzilla) From j.rink at freenet.de Tue Nov 21 08:27:39 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Tue, 21 Nov 2006 09:27:39 +0100 Subject: update from fc 5 -> 6 thinkpad t23 savage, dri is disabled Message-ID: <20061121092739.8db49b0c.j.rink@freenet.de> Hi, i have updated my laptop successfully from fc 5 to fc6. Now i have 2 problems, which i cannot bring together at this moment. The first problem is, that i can open a wine program with a user only once, the second time the screen will not openened. Further investigations shows, that glxgears is starting, but only shows a black window. Googling arround, brings me a thread, where one guy has this problem in september, which is solved in the savage driver for x11. I take a look at the X.log file, and there i can see: (II) SAVAGE(0): [drm] DRM interface version 1.0 (II) SAVAGE(0): [drm] drmSetBusid failed (7, pci:0000:01:00.0), Permission denied (EE) SAVAGE(0): [drm] DRIScreenInit failed. Disabling DRI. (EE) SAVAGE(0): DRI isn't enabled So, where should i open a bug report? Here? in x11? Anyonelse here with the wine problem? I have 3 boxes with fc6, 2 are running wine (notes 6.5 and 7.x) fine here, only the t23 makes problems. I have deinstalled all devel pakets and reinstalled them, compiling wine once again, nothing helps. On fc5 i had no problems with wine on the t23. sry when this is the false plattform. From buildsys at redhat.com Tue Nov 21 11:24:28 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 21 Nov 2006 06:24:28 -0500 Subject: rawhide report: 20061121 changes Message-ID: <200611211124.kALBOS4e025414@hs20-bc2-6.build.redhat.com> Updated Packages: cpuspeed-1:1.2.1-1.42.fc7 ------------------------- * Mon Nov 20 2006 Dave Jones - Merge patch from Michal Jaegermann that solves the acpi-cpufreq problem in an improved way and fixes several other nits. * Sat Oct 28 2006 Dave Jones - Only load acpi-cpufreq on speedstep capable machines. - Unload acpi-cpufreq if BIOS tables didn't exist or other acpi-cpufreq failures occured. dbus-1.0.1-1.fc7 ---------------- * Mon Nov 20 2006 Ray Strode - 1.0.1-1 - Update to 1.0.1 - Apply patch from Thiago Macieira to fix failed assertion in threading implementation - Drop some crazy looking build time speed optimization * Tue Nov 14 2006 John (J5) Palmieri - 1.0.0-2 - add patch to fix dbus_threads_init_default * Mon Nov 13 2006 John (J5) Palmieri - 1.0.0-1 - update to D-Bus 1.0.0 "Blue Bird" - build with verbose mode on but tests and asserts off dogtail-0.6.1-1.fc6 ------------------- * Mon Oct 16 2006 Zack Cerza - 0.6.1-1 - New upstream release. gamin-0.1.8-2.fc7 ----------------- * Mon Nov 20 2006 Alexander Larsson - 0.1.8-2.fc7 - Fix polling backend, making NFS work again - Resolves: #212551 gcc-4.1.1-39 ------------ * Mon Nov 20 2006 Jakub Jelinek 4.1.1-39 - update from gcc-4_1-branch (-r118891:119021) - PRs middle-end/26306, middle-end/29753, target/18553, target/29114, target/29449, tree-opt/29788, tree-optimization/28888 - fix some C++ vector conversions (PR c++/29734) - fix C++ ICE with value dependent const brace enclosed initializer (PR c++/29570) gd-2.0.33-11.fc7 ---------------- * Tue Nov 21 2006 Ivana Varekova 2.0.33-11 - Fix problem with to large box boundaries Resolves: #197747 * Thu Nov 16 2006 Ivana Varekova 2.0.33-10 - added 'thick' - variable support for AA line (#198042) * Tue Oct 31 2006 Adam Tkac 2.0.33-9.4 - patched some additionals overflows in gd (#175414) glibc-2.5.90-7 -------------- * Mon Nov 20 2006 Jakub Jelinek 2.5.90-7 - handle IPv6 addresses in /etc/hosts that are mappable to IPv4 addresses in IPv4 host lookups (#215283) - fix :include: /etc/alias handling (#215572) - handle new tzdata format to cope with year > 2037 transitions on 64-bit architectures gnome-applet-vm-0.1.2-1 ----------------------- * Thu Nov 02 2006 Karel Zak 0.1.2-1 - sync with upstream - remove dependence on dbus libs - fix collaboration with virt-manager - fix rh#213790 - not able to create a new virtual machine via the applet - fix rh#211560 - s/button-press-event/button-release-event/ (GTK events) gnome-session-2.17.2-3.fc7 -------------------------- * Mon Nov 20 2006 Ray Strode - 2.17.2-3 - don't make gnome.desktop executable (bug 196105) hwbrowser-0.28-1.fc7 -------------------- * Mon Nov 20 2006 Nils Philippsen - 0.28 - find device manufacturers' names in pci.ids and usb.ids (#215275) - make update-po - add disttag * Thu Jul 13 2006 Jesse Keating - 0.27-2 - rebuild - br gettext * Wed May 31 2006 Nils Philippsen 0.27 - buildrequire perl-XML-Parser (#193400) libICE-1.0.2-1 -------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2. * Wed Jul 12 2006 Jesse Keating 1.0.1-2.1 - rebuild * Mon Jun 05 2006 Mike A. Harris 1.0.1-2 - Added "Requires: xorg-x11-proto-devel" - Replace "makeinstall" with "make install DESTDIR=..." - Remove package ownership of mandir/libdir/etc. libSM-1.0.2-1 ------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-3.1 - rebuild * Tue Jun 06 2006 Mike A. Harris 1.0.1-3 - Added "Requires: xorg-x11-proto-devel" to devel package. libXScrnSaver-1.1.1-1 --------------------- * Mon Nov 20 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 * Wed Jul 12 2006 Jesse Keating 1.1.0-3.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 1.1.0-3 - Update build dep to "xorg-x11-proto-devel >= 7.0-9" for scrnsaverproto 1.1 - Added "Requires: xorg-x11-proto-devel >= 7.0-9" to devel package, to match what is listed as required in xscrnsaver.pc libXau-1.0.2-1 -------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-3.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 1.0.1-3 - Remove package ownership of mandir/libdir/etc. - Added "BuildRequires: xorg-x11-proto-devel" needed by xau.pc libXcomposite-0.3.1-1 --------------------- * Mon Nov 20 2006 Adam Jackson 0.3.1-1 - Update to 0.3.1 * Wed Jul 12 2006 Jesse Keating 0.3-5.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 0.3-5 - Replace "makeinstall" with "make install DESTDIR=..." - Added "Requires: xorg-x11-proto-devel >= 7.0-10, libXfixes-devel to devel subpackage needed by xcomposite.pc - Remove package ownership of mandir/libdir/etc. libXcursor-1.1.8-1 ------------------ * Mon Nov 20 2006 Adam Jackson 1.1.8-1 - Update to 1.1.8 * Wed Jul 12 2006 Jesse Keating 1.1.7-1.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 1.1.7-1 - Update to 1.1.7 from X11R7.1 libXdamage-1.0.4-1 ------------------ * Mon Nov 20 2006 Adam Jackson 1.0.4-1 - Update to 1.0.4 * Wed Jul 12 2006 Jesse Keating 1.0.3-2.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 1.0.3-2 - Added "BuildRequires: xorg-x11-proto-devel >= 7.0-1" as xcursor.pc indicates "damageproto >= 1.0" is required. - Added "Requires: xorg-x11-proto-devel >= 7.0-1, libXfixes-devel" to devel package also, as per xcursor.pc - Replace "makeinstall" with "make install DESTDIR=..." - Remove package ownership of mandir/libdir/etc. libXdmcp-1.0.2-2.fc7 -------------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-2.fc7 - libXdmcp-1.0.2-namespace-pollution.patch: Hide Xalloc and friends from the dynamic linker. * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-2.1 - rebuild libXevie-1.0.2-1 ---------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-3.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 1.0.1-3 - Added "Requires: xorg-x11-proto-devel" to devel package, needed by xevie.pc - Remove package ownership of mandir/libdir/etc. libXfixes-4.0.3-1 ----------------- * Mon Nov 20 2006 Adam Jackson 4.0.3-1 - Update to 4.0.3 * Wed Jul 12 2006 Jesse Keating 4.0.1-2.1 - rebuild * Wed Jun 07 2006 Mike A. Harris 4.0.1-2 - Added "BuildRequires: xorg-x11-proto-devel >= 7.0-7" for "fixesproto >= 4.0" - Added "Requires: xorg-x11-proto-devel >= 7.0-7" for "fixesproto >= 4.0" to devel package, needed by xfixes.pc - Replace "makeinstall" with "make install DESTDIR=..." - Remove package ownership of mandir/libdir/etc. libXfont-1.2.3-3.fc7 -------------------- * Mon Nov 20 2006 Adam Jackson 1.2.3-3.fc7 - libXdmcp-1.0.2-namespace-pollution.patch: One more collision avoider. * Mon Nov 20 2006 Adam Jackson 1.2.3-2.fc7 - libXfont-1.2.3-namespace-pollution.patch: Hide some symbols from the dynamic linker to avoid colliding with other libs. * Mon Nov 20 2006 Adam Jackson 1.2.3-1.fc6 - Update to 1.2.3 libXfontcache-1.0.3-1.fc7 ------------------------- * Mon Nov 20 2006 Adam Jackson 1.0.3-1.fc7 - Update to 1.0.3 * Wed Jul 12 2006 Jesse Keating 1.0.2-3.1 - rebuild * Mon Jun 05 2006 Mike A. Harris 1.0.2-3 - Added "Requires: xorg-x11-proto-devel" to devel package for xfontcache.pc libXi-1.0.2-1 ------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-3.1 - rebuild * Mon Jun 05 2006 Mike A. Harris 1.0.1-3 - Added "Requires: xorg-x11-proto-devel" to devel package for xi.pc - Remove package ownership of mandir/libdir/etc. libXmu-1.0.3-1.fc7 ------------------ * Mon Nov 20 2006 Adam Jackson 1.0.3-1.fc7 - Update to 1.0.3 libXpm-3.5.6-1 -------------- * Mon Nov 20 2006 Adam Jackson 3.5.6-1 - Update to 3.5.6 libXrandr-1.1.2-1.fc7 --------------------- * Mon Nov 20 2006 Adam Jackson 1.1.1-2.1 - Update to 1.1.2 * Wed Jul 12 2006 Jesse Keating 1.1.1-3.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 1.1.1-3 - Added "Requires: xorg-x11-proto-devel" to devel pkg for xrandr.pc libXrender-0.9.2-1.fc7 ---------------------- * Mon Nov 20 2006 Adam Jackson 0.9.2-1 - Update to 0.9.2 * Wed Jul 12 2006 Jesse Keating 0.9.1-3.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 0.9.1-3 - Added "Requires: libX11-devel" to devel package for xrender.pc libXres-1.0.2-1.fc7 ------------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-3.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 1.0.1-3 - Added "Requires: xorg-x11-proto-devel" to devel package for xres.pc libXt-1.0.4-1.fc7 ----------------- * Mon Nov 20 2006 Adam Jackson 1.0.4-1.fc7 - Update to 1.0.4 * Wed Jul 12 2006 Jesse Keating 1.0.2-3.1.fc6 - rebuild * Tue Jul 11 2006 Mike A. Harris 1.0.2-3.fc6 - Add the {_datadir}/X11/app-defaults directory to the file manifest, as libXt is the canonical owner of the directory. Discovered in (#198025). libXv-1.0.2-1.fc7 ----------------- * Mon Nov 20 2006 Adam Jackson 1.0.2-1.fc7 - Update to 1.0.2 * Wed Jul 12 2006 Jesse Keating 1.0.1-4.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 1.0.1-4 - Added "Requires: xorg-x11-proto-devel" to devel package for xv.pc libXvMC-1.0.3-1.fc7 ------------------- * Mon Nov 20 2006 Adam Jackson 1.0.3-1 - Update to 1.0.3 * Wed Jul 12 2006 Jesse Keating 1.0.2-2.1 - rebuild * Mon Jun 05 2006 Mike A. Harris 1.0.2-2 - Added "BuildRequires: pkgconfig" for (#193506) - Replace "makeinstall" with "make install DESTDIR=..." - Touch XvMCConfig during install phase, and add to file manifest as a ghost file, so that it is owned by the package if the user creates it. (#192254) libchewing-0.3.0-5.fc7 ---------------------- * Tue Nov 21 2006 Caius Chance - 0.3.0-5.fc7 - Fixed bz#216581: Ported the following bugfix: - (bz#216337: Page Up / Page Down key doesn't when Chewing is activated.) - (bz#209575: preedit buffer is not cleared when framework calls for instance reset.) libfontenc-1.0.3-1.fc7 ---------------------- * Mon Nov 20 2006 Adam Jackson 1.0.3-1.fc7 - Update to 1.0.3 * Wed Jul 12 2006 Jesse Keating 1.0.2-2.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 1.0.2-2 - Remove package ownership of mandir/libdir/etc. - Added "BuildRequires: autoconf" temporarily as long as autoconf is needed libgpod-0.4.0-2.fc7 ------------------- * Mon Nov 20 2006 Alexander Larsson - 0.4.0-2 - Add ldconfig calls in post/postun libxkbfile-1.0.4-1.fc7 ---------------------- * Mon Nov 20 2006 Adam Jackson 1.0.4-1.fc7 - Update to 1.0.4 * Wed Jul 12 2006 Jesse Keating 1.0.3-3.1 - rebuild * Fri Jun 09 2006 Mike A. Harris 1.0.3-3 - Added "Requires: xorg-x11-proto-devel" to devel package for xkbfile.pc lvm2-2.02.15-1.fc7 ------------------ * Mon Nov 20 2006 Alasdair Kergon - 2.02.15-1 - New upstream - see WHATS_NEW. m17n-db-1.3.3-39.fc7 -------------------- * Mon Nov 20 2006 Mayank Jain - Retained mapping of (.) to (.) in as-inscript as per bug 215486 - Fixed an error in ta-tamil99 key summary. mc-1:4.6.1a-35.fc7 ------------------ * Thu Nov 16 2006 Jindrich Novy 4.6.1a-35 - update to new CVS snapshot - drop .fishfix, .rpmconf patches, applied upstream - fix IPv6 patch (should fix #206234 and #213212) - don't crash when directory ending with newline is listed (#215909), disable support for directories with '\n' in name to avoid further issues (remove .uglydir patch) and report chdir error mesa-6.5.1-8.fc6 ---------------- * Mon Oct 16 2006 Kristian - 6.5.1-8.fc6 - Add i965-interleaved-arrays-fix.patch to fix (#209318). nss_ldap-253-4 -------------- * Mon Nov 20 2006 Nalin Dahyabhai - 253-4 - rebuild * Mon Nov 20 2006 Nalin Dahyabhai - 253-3 - rebuild * Mon Nov 20 2006 Nalin Dahyabhai - 253-2 - update to pam_ldap 183, resolving CVE-2006-5170 (#216421) openoffice.org-1:2.1.0-4.1 -------------------------- * Wed Nov 15 2006 Caolan McNamara - 1:2.1.0-4.1 - Resolves: rhbz#215511 can't print brochure on landscape mode - Resolves: rhbz#216089 zoom affecting cjk substitution - add openoffice.org-2.1.0.ooo71662.dbaccess.noasync.patch policycoreutils-1.33.2-2.fc7 ---------------------------- * Mon Nov 20 2006 Dan Walsh 1.33.2-2 - Fixes for the gui * Mon Nov 20 2006 Dan Walsh 1.33.2-1 - Upstream accepted my patches python-virtinst-0.97.0-1 ------------------------ * Mon Nov 20 2006 Jeremy Katz - 0.97.0-1 - handle multiple nics/disks on virt-install command line (#215726) - buildrequire python redhat-menus-6.7.8-2.fc7 ------------------------ * Mon Nov 20 2006 Ray Strode - 6.7.8-2 - Move to end of applications.menu rpm-4.4.2-36.fc7 ---------------- * Mon Nov 20 2006 Paul Nasrat - 4.4.2-36 - Fix ordering issues (#196590) scim-chewing-0.3.1-9.fc7 ------------------------ * Tue Nov 21 2006 Caius Chance - 0.3.1-9.fc7 - Fixed bz#216851 : ported following bugfix to rawhide: (bz#216377: PageUp/PageDown doesn't work when Chewing is activated.) selinux-policy-2.4.5-3.fc7 -------------------------- * Mon Nov 20 2006 Dan Walsh 2.4.5-3 - Fix load_policy to be able to mls_write_down so it can talk to the terminal * Mon Nov 20 2006 Dan Walsh 2.4.5-2 - Fixes for hwclock, clamav, ftp setroubleshoot-1.6-1.fc7 ------------------------ * Mon Nov 20 2006 John Dennis - 1.6-1 * logfile scanning finally seems to work connected to browser * Additional Information section of report now includes line number information (if alert was generated from logfile) * replace database update_callback() with notify interface, a more generic solution more easily shared between components * object implementing rpc method is now explicitly attached via connect_rpc_interface() instead of walking the MRO chain with magic exclusions. explicitly connecting is more flexible and robust (no getting the wrong object by mistake) * fix handling of return args in local rpc case * fix signal connections between audit and logfile * split databae and database_properties for audit and logfile * fix initial connection state * fix lookup_local_id * add more support for updating single rows in browser list view rather than reloading everything * correctly handle moving selection after a delete, lots of little selection fixes. * improve handling of ListStore model, nuke the kludgy pre-extended rows * signatures_updated() now works * fix bug #214218, sealert aborts if lang is not english, also improve error handling, the actual error was not being trapped and instead a subsequent error induced as a consequence was being reported, which was a red herring, also fix redundant variable which was used to hold the broswer window/widget instance. * modify how changes to the database are propagated, database object now takes an update callback. Now only the database is responsible for reporting changes, previously it had been the caller who modified the database and then had to also know what type of update to signal. Modify the 'signatures_updated' family of functions and signals to pass a upated type (add,delete,modify) and an item identifier, currently the local id. * signals to display the browser window now take an optional argument to indicate what it should be displaying. This was added for the case where the browser was visiting a logfile but the user clicked on the alert notification icon, the browser should in this instance always display the current alert, the user can use the view menu to switch back to the logfile view after having viewed the current alert. * add timeout's to status messages * tighten up the concept of 'visiting' in the browser, both in data structure and methods, as well as status messages. * make sure when the 'mark_seen' event triggers in the future it is bound the database that generated it, not the currently viewed database. * fix some debug messages which were not inside 'if debug' * move the signatures_updated signal to the database family of objects. * modify the RPC call mechanism so that it is possible to call a local object through the RPC API without it connecting to a remote object. Thus users of the RPC API can be ignorant if the object they are bound to is local or remote. * split the RPC interface for the server into server specific entry points and a new database interface. The new database interface supports the browser binding to either a remote database or a local instance created for logfile scanning. * fix how timestamps are assigned, we used to just timestamp an alert when it arrived from the audit system but now with logfile scanning timestamps are embedded in the logfile messages so in order to display the correct time an event occurred we needed to pass the timestamp read in the logfile through the pipeline. * create a thread in the browser for logfile scanning, perform the analysis in the thread with the browser GUI bound to the threads operation, display the scanning progress in the progress bar. * introduce the notion in the broswer of "visiting" a database, at the moment one is either vising the audit database or the last scanned logfile, added "View" menu and menu items to view the audit database or the logfile. When visiting have the browser connect to different signals. The visit mechanism still needs some work. spamassassin-3.1.7-1.fc7 ------------------------ * Mon Nov 20 2006 Warren Togami - 3.1.7-1 - 3.1.7 maintenance release strace-4.5.14-4 --------------- * Mon Nov 20 2006 Jakub Jelinek - 4.5.14-4 - Fix ia64 syscall decoding (#206768) - Fix build with glibc-2.4.90-33 and up on all arches but ia64 - Fix build against 2.6.18+ headers system-config-kickstart-2.6.18-1.fc7 ------------------------------------ * Mon Nov 20 2006 Chris Lumens 2.6.18-1 - Don't require a root password (#215190). - Disable package screen if yum couldn't download (#216439). totem-2.17.3-2.fc7 ------------------ * Mon Nov 20 2006 Alexander Larsson - 2.17.3-2 - Remove libtotem-plparser.so from totem package - Split out totem-plparser into subpackage - Resolves: #203640 util-linux-2.13-0.45.fc6 ------------------------ * Wed Nov 01 2006 Karel Zak 2.13-0.45 - fix #211827 - Can't mount with additional contexts - fix #213127 - mount --make-unbindable does not work - fix #211749 - add -r option to losetup to create a read-only loop Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jfrieben at freesurf.fr Tue Nov 21 11:27:46 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Tue, 21 Nov 2006 12:27:46 +0100 (CET) Subject: update from fc 5 -> 6 thinkpad t23 savage, dri is disabled In-Reply-To: <20061121092739.8db49b0c.j.rink@freenet.de> References: <20061121092739.8db49b0c.j.rink@freenet.de> Message-ID: <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> > Hi, > i have updated my laptop successfully from fc 5 to fc6. > Now i have 2 problems, which i cannot bring together at this moment. > > The first problem is, that i can open a wine program with > a user only once, the second time the screen will not openened. > > Further investigations shows, that glxgears is starting, but > only shows a black window. > > Googling arround, brings me a thread, where one guy has this problem in > september, which is solved in the savage driver for x11. > > I take a look at the X.log file, and there i can see: > > (II) SAVAGE(0): [drm] DRM interface version 1.0 > (II) SAVAGE(0): [drm] drmSetBusid failed (7, pci:0000:01:00.0), > Permission denied (EE) SAVAGE(0): [drm] DRIScreenInit failed. > Disabling DRI. (EE) SAVAGE(0): DRI isn't enabled A black "glxgears" window is a known issue which has been filed at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 and upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=6357 , where you can find a patch which allows to settle the issue. It is included in the current "Xorg" development tree, so expect things to work better in "Xorg" 7.2 which should make its appearance in "FC7". Otherwise, a "Red Hat" fix for "FC6" applying the patch mentioned above is pending according to "Bugzilla" #195851. I have patched the "xorg-x11-drv-savage" driver package myself, and it works very well now. From rdieter at math.unl.edu Tue Nov 21 12:04:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 06:04:17 -0600 Subject: gstreamer-plugins-good and (the lack of) taglib In-Reply-To: <4562982D.20302@redhat.com> References: <45628149.7080101@lorez.org> <4562982D.20302@redhat.com> Message-ID: Christopher Aillon wrote: > Bob Richmond wrote: >> The only problem I can think of in introducing this patch is the >> dirtiness of making a package from Extras be a build requirement of a >> package in core. Is this generally frowned upon? > > Until the Extras/Core dichotomy is merged, yes. Alternatively, you can make some sort of gstreamer-plugins-good-extras that includes only the taglib bits, and submit that to Extras. Not ideal, but it should do the trick. -- Rex From buc at odusz.so-cdu.ru Tue Nov 21 12:12:55 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 21 Nov 2006 15:12:55 +0300 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <20061120194731.GB27924@redhat.com> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> Message-ID: <4562ED47.4070002@odu.neva.ru> Dave Jones wrote: >A coincidence I hope. I'm not sure how increased timing resolution could >cause the drifting effects you've observed. I've also not noticed >any other similar reports (yet?). > > Dave > > Dave, As you have appeared here, could you please comment why HZ was changed? I have some confusion on this. First, the upstream kernel has this changed (since 2.6.13 ?) in backward direction, i.e. from 1000 to 250. Second, why Fedora's change is implemented just now (in the middle of life cycle), but not at distro release boundary? And finally, why 1000Hz even for i586 kernel? Does anybody use i586 machine for low-latency tasks? Or even desktop now? Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From arjan at fenrus.demon.nl Tue Nov 21 12:28:40 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 13:28:40 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <4562ED47.4070002@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> Message-ID: <1164112120.31358.659.camel@laptopd505.fenrus.org> On Tue, 2006-11-21 at 15:12 +0300, Dmitry Butskoy wrote: > Dave Jones wrote: > > >A coincidence I hope. I'm not sure how increased timing resolution could > >cause the drifting effects you've observed. I've also not noticed > >any other similar reports (yet?). > > > > Dave > > > > > Dave, > As you have appeared here, could you please comment why HZ was changed? > > I have some confusion on this. > First, the upstream kernel has this changed (since 2.6.13 ?) in backward > direction, i.e. from 1000 to 250. actually the upstream kernel changed to offer a choice, with 3 options, 1000, 250 and 100. This was done after it was recognized that there are different valid scenarios for either of those values. > Second, why Fedora's change is implemented just now (in the middle of > life cycle), but not at distro release boundary? does it matter? This is only internally visible to the kernel, not to userspace (other than an improvement in accuracy) From pekkas at netcore.fi Tue Nov 21 12:47:03 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 21 Nov 2006 14:47:03 +0200 (EET) Subject: Core + Extras In-Reply-To: <20061120144613.GA19155@jadzia.bu.edu> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> <20061120144613.GA19155@jadzia.bu.edu> Message-ID: On Mon, 20 Nov 2006, Matthew Miller wrote: > On Mon, Nov 20, 2006 at 01:21:11PM +0000, Keith G wrote: > > I like the idea of separate fedora-server, fedora-gnome and fedora-kde > > CDs, although I think main essential applications like openoffice and > > firefox should be on the main CD. I think it would be better to split > > the CDs thus: > > openoffice.org takes up almost 700mb by itself. > > (You want "essential", try abiword at 7MB and gnumeric at 12MB.) But how do you deal with .PPT? I haven't found a reasonable way yet.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From buc at odusz.so-cdu.ru Tue Nov 21 13:11:16 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 21 Nov 2006 16:11:16 +0300 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164112120.31358.659.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> Message-ID: <4562FAF4.7060307@odu.neva.ru> Arjan van de Ven wrote: >>Dave, >>As you have appeared here, could you please comment why HZ was changed? >> >>I have some confusion on this. >>First, the upstream kernel has this changed (since 2.6.13 ?) in backward >>direction, i.e. from 1000 to 250. >> >> > >actually the upstream kernel changed to offer a choice, with 3 options, >1000, 250 and 100. > Sure! But I meant the *upstream default" was chosen to be 250 (not 1000). >>Second, why Fedora's change is implemented just now (in the middle of >>life cycle), but not at distro release boundary? >> >> > >does it matter? This is only internally visible to the kernel, not to >userspace > > But these changes are appreciable enough. For production servers (more system CPU time), for laptops (less battery life), etc. And note the ntp issue discussed here too... ~buc From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From mattdm at mattdm.org Tue Nov 21 13:18:10 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Nov 2006 08:18:10 -0500 Subject: Core + Extras In-Reply-To: References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> <20061120144613.GA19155@jadzia.bu.edu> Message-ID: <20061121131810.GA7565@jadzia.bu.edu> On Tue, Nov 21, 2006 at 02:47:03PM +0200, Pekka Savola wrote: > > > CDs, although I think main essential applications like openoffice and > > > firefox should be on the main CD. I think it would be better to split > > > the CDs thus: > > openoffice.org takes up almost 700mb by itself. > > (You want "essential", try abiword at 7MB and gnumeric at 12MB.) > But how do you deal with .PPT? I haven't found a reasonable way yet.. Thank goodness that doesn't rank as "essential" for me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From jkeating at redhat.com Tue Nov 21 13:46:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 08:46:14 -0500 Subject: Duplicate mail deliveries Message-ID: <200611210846.14281.jkeating@redhat.com> As you may have noticed, we're getting the same rawhide report over and over. This is not getting generated over and over, the mail software seems to be delivering it over and over. Our IS team is investigating it to make it stop. Sorry for the noise. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Tue Nov 21 13:48:02 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 14:48:02 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <4562FAF4.7060307@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <4562FAF4.7060307@odu.neva.ru> Message-ID: <1164116882.31358.667.camel@laptopd505.fenrus.org> On Tue, 2006-11-21 at 16:11 +0300, Dmitry Butskoy wrote: > Arjan van de Ven wrote: > > >>Dave, > >>As you have appeared here, could you please comment why HZ was changed? > >> > >>I have some confusion on this. > >>First, the upstream kernel has this changed (since 2.6.13 ?) in backward > >>direction, i.e. from 1000 to 250. > >> > >> > > > >actually the upstream kernel changed to offer a choice, with 3 options, > >1000, 250 and 100. > > > Sure! But I meant the *upstream default" was chosen to be 250 (not 1000). upstream "defaults" don't mean much; Fedora ships a kernel config that deviates from that in hundreds and hundreds of places. > >does it matter? This is only internally visible to the kernel, not to > >userspace > > > > > But these changes are appreciable enough. For production servers (more > system CPU time), this is probably so little it's not even measurable. > for laptops (less battery life), etc. actually the "knee" in battery life for laptops is between 100 and 250, not between 250 and 1000. Both 250 and 1000 have very similar power use; only when you go really below 250 are you going to get some extra savings. (And only if you don't use USB at all.. which Fedora by default enables) > And note the ntp > issue discussed here too... .... with the upside that userspace can now sleep far more accurately which helps media playback, the desktop and all kinds of business applications. In addition the scheduler now has better information and makes better decisions as a result. Even ntp should be better off with this more finegrained data, but I can believe it'll need to get used to it for some time ;) From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From laroche at redhat.com Tue Nov 21 13:57:10 2006 From: laroche at redhat.com (Florian La Roche) Date: Tue, 21 Nov 2006 14:57:10 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164116882.31358.667.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <4562FAF4.7060307@odu.neva.ru> <1164116882.31358.667.camel@laptopd505.fenrus.org> Message-ID: <20061121135710.GA6972@dudweiler.stuttgart.redhat.com> > savings. (And only if you don't use USB at all.. which Fedora by default > enables) "nousb" as kernel command line option should help with this. regards, Florian La Roche From denis at poolshark.org Tue Nov 21 13:58:59 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 21 Nov 2006 14:58:59 +0100 Subject: gstreamer-plugins-good and (the lack of) taglib In-Reply-To: References: <45628149.7080101@lorez.org> <4562982D.20302@redhat.com> Message-ID: <45630623.8000607@poolshark.org> Rex Dieter wrote: > Christopher Aillon wrote: >> Bob Richmond wrote: >>> The only problem I can think of in introducing this patch is the >>> dirtiness of making a package from Extras be a build requirement of a >>> package in core. Is this generally frowned upon? >> Until the Extras/Core dichotomy is merged, yes. > > Alternatively, you can make some sort of gstreamer-plugins-good-extras > that includes only the taglib bits, and submit that to Extras. Not > ideal, but it should do the trick. gnome-python2-gda in FE is an example of such a package (a disabled part of gnome-pytnon2-extras in Core). From dedourek at unb.ca Tue Nov 21 14:06:46 2006 From: dedourek at unb.ca (John DeDourek) Date: Tue, 21 Nov 2006 10:06:46 -0400 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164116882.31358.667.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <4562FAF4.7060307@odu.neva.ru> <1164116882.31358.667.camel@laptopd505.fenrus.org> Message-ID: <456307F6.6040809@unb.ca> Arjan van de Ven wrote: > > Even ntp should be better off with this more finegrained data, but I can > believe it'll need to get used to it for some time ;) > Can anyone report on whether the lost tick interrupt problem at 1000Hz interrupt rate been firmly resolved on slower machines and machines wih the CPU speed stepped down? I haven't looked at the interrupt handling code in some time. The net effect of a lost interrupt was the appearance that the system time stood still for one clock interval out of the two that had just passed. This caused significant variations in system time. Ntp was forced to accelerate the clock until it caught up with true time and then deaccelerate to avoid overshoot. This was repeated with every lost interrupt resulting in system time that observed a "sawtooth" path relative to true time. From fedora at camperquake.de Tue Nov 21 14:08:24 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 21 Nov 2006 15:08:24 +0100 Subject: Duplicate mail deliveries In-Reply-To: <200611210846.14281.jkeating@redhat.com> References: <200611210846.14281.jkeating@redhat.com> Message-ID: <20061121150824.7a2ef0b8@yareena.int.addix.net> Hi. On Tue, 21 Nov 2006 08:46:14 -0500, Jesse Keating wrote: > As you may have noticed, we're getting the same rawhide report over > and over. This is not getting generated over and over, the mail > software seems to be delivering it over and over. Our IS team is > investigating it to make it stop. Sorry for the noise. Thankfully it seems to be always sent with the same Message-ID, so Cyrus' duplicate filter has eaten them all :) From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From rdieter at math.unl.edu Tue Nov 21 14:34:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 08:34:21 -0600 Subject: gstreamer-plugins-good and (the lack of) taglib In-Reply-To: <45630623.8000607@poolshark.org> References: <45628149.7080101@lorez.org> <4562982D.20302@redhat.com> <45630623.8000607@poolshark.org> Message-ID: <45630E6D.8030703@math.unl.edu> Denis Leroy wrote: > Rex Dieter wrote: >> Christopher Aillon wrote: >>> Bob Richmond wrote: >>>> The only problem I can think of in introducing this patch is the >>>> dirtiness of making a package from Extras be a build requirement of a >>>> package in core. Is this generally frowned upon? >>> Until the Extras/Core dichotomy is merged, yes. >> >> Alternatively, you can make some sort of gstreamer-plugins-good-extras >> that includes only the taglib bits, and submit that to Extras. Not >> ideal, but it should do the trick. > > gnome-python2-gda in FE is an example of such a package (a disabled part > of gnome-pytnon2-extras in Core). There are lots of examples of similar Extras packages, including k3b-extras, kdeartwork-extras, kdegraphics-extras, kdemultimedia-extras. -- Rex From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From keithishere2004 at gmail.com Tue Nov 21 14:33:44 2006 From: keithishere2004 at gmail.com (Keith G) Date: Tue, 21 Nov 2006 14:33:44 +0000 Subject: Core + Extras In-Reply-To: <20061120144613.GA19155@jadzia.bu.edu> References: <200611181011.13773.jkeating@redhat.com> <3239-SnapperMsg827D11E1C184DC68@68.26.216.186> <200611181127.50995.jkeating@redhat.com> <667750500611200456n10ceb274yfdfb8341ebbcc04f@mail.gmail.com> <1164027739.31358.594.camel@laptopd505.fenrus.org> <667750500611200521xab5985r2a851acde890ae86@mail.gmail.com> <20061120144613.GA19155@jadzia.bu.edu> Message-ID: <667750500611210633g36fccd8cydb03fda7df31662a@mail.gmail.com> >> I like the idea of separate fedora-server, fedora-gnome and fedora-kde >> CDs, although I think main essential applications like openoffice and >> firefox should be on the main CD. I think it would be better to split >> the CDs thus: >> >> * fedora-gnome = basic OS + Gnome + main essential applications >> * fedora-kde = basic OS + KDE + main essential applications >> * fedora-server = basic OS + server packages >> * fedora-extras = other popular packages and applications >> * fedora-devel = All the development libraries and applications that >> most users never install >> >> That way a user can set up a working os with as little as 1 cd. > > openoffice.org takes up almost 700mb by itself. > > (You want "essential", try abiword at 7MB and gnumeric at 12MB.) According to the OpenOffice.org download page, the linux version of 2.2.13 is 120MB. That's not including the SDK and such, but most users wouldn't need that anyway. So the 'normal' OpenOffice installation could easily be included as one of the main essential applications on the fedora-gnome and fedora-kde CDs as stated above. I think this is the best course of action, and I know it's technically possible, because its similar to what Ubuntu does with their two distros: * Ubuntu = basic OS + gnome + essential apps (incl. openoffice) = 1 CD * Kubuntu = basic OS + KDE + essential apps (incl. openoffice) = 1CD Keith. From rc040203 at freenet.de Tue Nov 21 14:41:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 15:41:52 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164112120.31358.659.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> Message-ID: <1164120113.5059.21.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 13:28 +0100, Arjan van de Ven wrote: > On Tue, 2006-11-21 at 15:12 +0300, Dmitry Butskoy wrote: > > Second, why Fedora's change is implemented just now (in the middle of > > life cycle), but not at distro release boundary? > > does it matter? This is only internally visible to the kernel, not to > userspace (other than an improvement in accuracy) Well, in the past (several years ago), changes to HZ and kernel ticker frequencies had broken "make"/"gmake" and similar tools. I don't know if this still applies and/or whether this change to HZ exposes similar problems. Ralf From dwmw2 at infradead.org Tue Nov 21 14:46:16 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 14:46:16 +0000 Subject: Duplicate mail deliveries In-Reply-To: <20061121150824.7a2ef0b8@yareena.int.addix.net> References: <200611210846.14281.jkeating@redhat.com> <20061121150824.7a2ef0b8@yareena.int.addix.net> Message-ID: <1164120376.19448.39.camel@pmac.infradead.org> On Tue, 2006-11-21 at 15:08 +0100, Ralf Ertzinger wrote: > Hi. > > On Tue, 21 Nov 2006 08:46:14 -0500, Jesse Keating wrote: > > > As you may have noticed, we're getting the same rawhide report over > > and over. This is not getting generated over and over, the mail > > software seems to be delivering it over and over. Our IS team is > > investigating it to make it stop. Sorry for the noise. > > Thankfully it seems to be always sent with the same Message-ID, > so Cyrus' duplicate filter has eaten them all :) As usual it's some muppet with a broken mail setup spamming us all. You should _NEVER_ extract recipients from To: and Cc: headers and attempt to reinject mail into the mail system. Received: from logic.net (logic.net [70.91.101.43]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id kALDdnGq019471; Tue, 21 Nov 2006 08:39:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by logic.net (Postfix) with ESMTP id EF822454013; Tue, 21 Nov 2006 07:39:48 -0600 (CST) X-Virus-Scanned: amavisd-new at example.com Received: from logic.net ([127.0.0.1]) by localhost (talus.logic.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LyUi2s8zVHvE; Tue, 21 Nov 2006 07:39:48 -0600 (CST) Received: by logic.net (Postfix, from userid 0) id 461554540B2; Tue, 21 Nov 2006 07:19:36 -0600 (CST) Received: by logic.net (Postfix, from userid 504) id 95A9B454006; Mon, 20 Nov 2006 07:03:05 -0600 (CST) Received: from gatekeeper.logic.net (internal.logic.net [70.91.101.41]) by logic.net (Postfix) with ESMTP id 8CE5A45401E for ; Mon, 20 Nov 2006 07:02:30 -0600 (CST) Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30]) by gatekeeper.logic.net (Postfix) with ESMTP id 4BF9A1700CE for ; Mon, 20 Nov 2006 04:57:30 -0600 (CST) Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id D92457336E; Mon, 20 Nov 2006 05:52:19 -0500 (EST) -- dwmw2 From kevin.kofler at chello.at Tue Nov 21 14:47:28 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 21 Nov 2006 14:47:28 +0000 (UTC) Subject: Core + Exrtas 2 References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > > That language may be a bit too strong, as I can think of cases where an > > essential update may end up breaking ABI, though it's not unreasonable to > > to make policy such that it *should* (not must) be avoided. > Well, this "must" is the core point about all this - Fedora should be a > stable distro. > > Where would be the difference to rawhide, otherwise? * Less bugs (because stuff usually got through Rawhide and/or updates-testing before, and also because updates which are known to break stuff are not pushed to the stable distro). * Less dependency problems within packages shipped by Fedora (as in "reverse-dependencies get rebuilt for the ABI change and pushed together with the ABI-changing library update", not as in "ABIs never change"; the Core/Extras merger will probably make it easier to coordinate ABI changes in core packages, so the lag between a core library update and all packages getting rebuilt can in principle be made invisible to the user through coordination of the pushes). Kevin Kofler From arjan at fenrus.demon.nl Tue Nov 21 15:00:33 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 16:00:33 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164120113.5059.21.camel@mccallum.corsepiu.local> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <1164120113.5059.21.camel@mccallum.corsepiu.local> Message-ID: <1164121234.31358.672.camel@laptopd505.fenrus.org> On Tue, 2006-11-21 at 15:41 +0100, Ralf Corsepius wrote: > On Tue, 2006-11-21 at 13:28 +0100, Arjan van de Ven wrote: > > On Tue, 2006-11-21 at 15:12 +0300, Dmitry Butskoy wrote: > > > > Second, why Fedora's change is implemented just now (in the middle of > > > life cycle), but not at distro release boundary? > > > > does it matter? This is only internally visible to the kernel, not to > > userspace (other than an improvement in accuracy) > Well, in the past (several years ago), changes to HZ and kernel ticker > frequencies had broken "make"/"gmake" and similar tools. in the 2.4 kernel this was an issue yes; in 2.6 it shouldn't (also remember that earlier FC versions had 1000 already for a long time) From rdieter at math.unl.edu Tue Nov 21 15:26:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 09:26:14 -0600 Subject: Core + Exrtas 2 In-Reply-To: <1164092166.6875.131.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote: >> Ralf Corsepius wrote: >> >>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: >>>> No, he's asking about introducing new packages to a released product. >>>> Say >>>> Fedora 7 goes out the door with a given package set. Three weeks later a >>>> great new package gets added to the Fedora universe, what kind of policy >>>> would there be in making this package available to the Fedora 7 users? >>> IMO, basically like FE has been doing it, so far, except that breaking >>> APIs, ABIs and packages deps etc. must not happen. >> That language may be a bit too strong, as I can think of cases where an >> essential update may end up breaking ABI, though it's not unreasonable to >> to make policy such that it *should* (not must) be avoided. > Well, this "must" is the core point about all this - Fedora should be a > stable distro. I guess we disagree then. I consider ABI compatibility as just one part of what defines a stable distro, but, imo, there are certainly cases where breaking ABI is justified (for essential features, bug fixes, and yes, stability sometimes). -- Rex From rdieter at math.unl.edu Tue Nov 21 15:29:16 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 09:29:16 -0600 Subject: Core + Exrtas 2 In-Reply-To: <1164092166.6875.131.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote: >> Ralf Corsepius wrote: >> >>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: >>>> No, he's asking about introducing new packages to a released product. >>>> Say >>>> Fedora 7 goes out the door with a given package set. Three weeks later a >>>> great new package gets added to the Fedora universe, what kind of policy >>>> would there be in making this package available to the Fedora 7 users? >>> IMO, basically like FE has been doing it, so far, except that breaking >>> APIs, ABIs and packages deps etc. must not happen. >> That language may be a bit too strong, as I can think of cases where an >> essential update may end up breaking ABI, though it's not unreasonable to >> to make policy such that it *should* (not must) be avoided. > Well, this "must" is the core point about all this - Fedora should be a > stable distro. I guess we disagree then. I consider ABI compatibility as just one part of what defines a stable distro, but, imo, there are certainly cases where breaking ABI is justified (for essential features, bug fixes, and yes, stability sometimes). -- Rex From buildsys at redhat.com Mon Nov 20 10:52:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 20 Nov 2006 05:52:16 -0500 Subject: rawhide report: 20061120 changes Message-ID: <200611201052.kAKAqGXL019163@hs20-bc2-6.build.redhat.com> Updated Packages: glib2-2.12.4-2.fc7 ------------------ gtk2-2.10.6-4.fc7 ----------------- * Mon Nov 20 2006 Matthias Clasen - 2.10.6-4 - Some spec file cleanups Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From rc040203 at freenet.de Tue Nov 21 15:30:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 16:30:56 +0100 Subject: Core + Exrtas 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> Message-ID: <1164123057.5059.39.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote: > >> Ralf Corsepius wrote: > >> > >>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: > >>>> No, he's asking about introducing new packages to a released product. > >>>> Say > >>>> Fedora 7 goes out the door with a given package set. Three weeks later a > >>>> great new package gets added to the Fedora universe, what kind of policy > >>>> would there be in making this package available to the Fedora 7 users? > >>> IMO, basically like FE has been doing it, so far, except that breaking > >>> APIs, ABIs and packages deps etc. must not happen. > >> That language may be a bit too strong, as I can think of cases where an > >> essential update may end up breaking ABI, though it's not unreasonable to > >> to make policy such that it *should* (not must) be avoided. > > > Well, this "must" is the core point about all this - Fedora should be a > > stable distro. > > I guess we disagree then. Welcome to the wonderful "world of rawhide" - Good Night, Fedora! You once had been a usable distro, but your masters now seem to be wanting to convert you into a jungle :( > I consider ABI compatibility as just one part > of what defines a stable distro, but, imo, there are certainly cases > where breaking ABI is justified (for essential features, bug fixes, and > yes, stability sometimes). Please ask RH how they have been handling Core, so far. I don't know how many times I've been told: "No API-changes, no ABI upgrade, no feature upgrades, often not even bugfixes (aka FIXEDRAWHIDE)"! Ralf From wtogami at redhat.com Tue Nov 21 15:32:10 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 21 Nov 2006 10:32:10 -0500 Subject: CVS Restored, Help Needed in Verification Message-ID: <45631BFA.4030800@redhat.com> Sometime Early Friday, November 17th we suffered some kind of catastrophic multi-disk or SCSI backplane failure accompanied with filesystem corruption in cvs.fedora.redhat.com. Thanks to volunteer efforts of Fedora Infrastructure and tremendous help from Red Hat IS/IT, we are now nearing restoration of cvs.fedora.redhat.com from a backup on a powerful new server graciously donated by Dell. We are restoring from a backup that began November 16th, 2006 at 8:01PM MST (Friday, November 17, 2006 at 03:01) and finished 100 minutes later. Because this backup is not an exact snapshot, it is possible that checkins that happened after 8:01PM are already in the restored data. https://www.redhat.com/archives/fedora-extras-commits/2006-November/date.html We require your help to verify that all checkins are properly in /cvs/extras and everything generally is working as expected. Please pay careful attention to everything that changed in November 16th and 17th according to the mailing list archive. My personal records indicate that no CVS imports happened after this backup, so we are fine in that regard. PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to verify and fix their own CVS modules, or explicitly identify someone else to do it on their behalf. EVERYONE ELSE - please keep an eye on CVS. SCREAM LOUDLY on fedora-extras-list if you see anything that is wrong. Sorry about any inconvenience or disruption that this unexpected problem may have caused. Everyone owes a beer to the Fedora Infrastructure and Red Hat IS/IT teams. =) Thank you for supporting the Fedora Project. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Tue Nov 21 15:47:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Nov 2006 16:47:51 +0100 Subject: CVS Restored, Help Needed in Verification In-Reply-To: <45631BFA.4030800@redhat.com> References: <45631BFA.4030800@redhat.com> Message-ID: <1164124071.5059.47.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 10:32 -0500, Warren Togami wrote: > PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to > verify and fix their own CVS modules, or explicitly identify someone > else to do it on their behalf. AFAICT, everything seems to be OK with my packages. Ralf From darrellpf at gmail.com Tue Nov 21 16:03:25 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 21 Nov 2006 08:03:25 -0800 Subject: rawhide report: 20061121 changes In-Reply-To: <200611211124.kALBOS4e025414@hs20-bc2-6.build.redhat.com> References: <200611211124.kALBOS4e025414@hs20-bc2-6.build.redhat.com> Message-ID: After the X updates X refused to start. It couldn't find any fonts, I think because XFS was crashing. Restored libXfont and libXfontcache to a previous version, which fixed the problem. darrell From buc at odusz.so-cdu.ru Tue Nov 21 16:10:43 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 21 Nov 2006 19:10:43 +0300 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <1164121234.31358.672.camel@laptopd505.fenrus.org> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <1164120113.5059.21.camel@mccallum.corsepiu.local> <1164121234.31358.672.camel@laptopd505.fenrus.org> Message-ID: <45632503.7090202@odu.neva.ru> Arjan van de Ven wrote: >(also remember that earlier FC versions had 1000 already for a long >time) > > ...as well as earlier 2.6 kernels had 1000 too, but now it has the default of 250 (with the possibility to re-compile kernel with values of 100 and 1000 for some specific targets). It seems that default of 1000 is not applicable for the upstream kernel now... ~buc From rdieter at math.unl.edu Tue Nov 21 17:31:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 11:31:10 -0600 Subject: Core + Exrtas 2 In-Reply-To: <1164123057.5059.39.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> <1164123057.5059.39.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote: >> I consider ABI compatibility as just one part >> of what defines a stable distro, but, imo, there are certainly cases >> where breaking ABI is justified (for essential features, bug fixes, and >> yes, stability sometimes). > > Please ask RH how they have been handling Core, so far. > > I don't know how many times I've been told: "No API-changes, no ABI > upgrade, no feature upgrades, often not even bugfixes (aka > FIXEDRAWHIDE)"! When it comes to breaking API/ABI, I'd say it's primarily the package maintainers' call to make. You just experienced cases where they chose not to upgrade, which isn't contrary at all to what I described. -- Rex From arjan at fenrus.demon.nl Tue Nov 21 17:25:17 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Nov 2006 18:25:17 +0100 Subject: HZ value changed from 250 to 1000 in the latest updated kernel In-Reply-To: <45632503.7090202@odu.neva.ru> References: <4559E440.7030307@odu.neva.ru> <1163991791.17203.3.camel@goat.booze> <1164036702.6875.37.camel@mccallum.corsepiu.local> <20061120194731.GB27924@redhat.com> <4562ED47.4070002@odu.neva.ru> <1164112120.31358.659.camel@laptopd505.fenrus.org> <1164120113.5059.21.camel@mccallum.corsepiu.local> <1164121234.31358.672.camel@laptopd505.fenrus.org> <45632503.7090202@odu.neva.ru> Message-ID: <1164129917.31358.685.camel@laptopd505.fenrus.org> On Tue, 2006-11-21 at 19:10 +0300, Dmitry Butskoy wrote: > Arjan van de Ven wrote: > > >(also remember that earlier FC versions had 1000 already for a long > >time) > > > > > ...as well as earlier 2.6 kernels had 1000 too, but now it has the > default of 250 (with the possibility to re-compile kernel with values of > 100 and 1000 for some specific targets). It seems that default of 1000 > is not applicable for the upstream kernel now... again the kernel developers recognized that this is something people want differently and made it an OPTION that you get asked at make (old)config time. You are reading a *lot* more into the "default" value (the one you get when you hit "enter" on the question) than there is meaning in that.... From mlichvar at redhat.com Tue Nov 21 17:49:45 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 21 Nov 2006 18:49:45 +0100 Subject: removing termcap Message-ID: <20061121174945.GC7982@localhost> Hi, I would like to see termcap and libtermcap removed, and to use ncurses everywhere. termcap is an obsolete system for describing terminal capabilities, it has annoying size limitations for the description and libtermcap is an old, unmaintained code. The ncurses library has a termcap emulation which is internally using terminfo database. It isn't 100% accurate (see curs_termcap(3)), but should be ok for most applications. libtermcap's API and ABI are compatible with ncurses. So what would be required to replace completely libtermcap with ncurses? - Move libncurses.so.* and/or libncursesw.so.* to /lib{,64}. - Move the most important entries in the terminfo database to /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, but the second option isn't much better as it will duplicate the entries on multiarch. - Rebuild packages currently using libtermcap against ncurses. It would be good to choose one of libncurses{,w} and link all binaries with it; linking with libncursesw will probably require more patching of configure scripts as some of them are prepared for libncurses already. Any thoughts? List of Core packages depending on libtermcap.so.2: amanda-0:2.5.0p2-4.i386 amanda-client-0:2.5.0p2-4.i386 amanda-server-0:2.5.0p2-4.i386 bash-0:3.1-16.1.i386 bc-0:1.06-21.i386 festival-0:1.95-5.2.1.i386 gnupg-0:1.4.5-5.i386 gnuplot-0:4.0.0-12.i386 gnutls-utils-0:1.4.1-2.i386 guile-5:1.8.1-1.fc7.i386 libtermcap-0:2.0.8-46.1.i386 libtermcap-devel-0:2.0.8-46.1.i386 lv-0:4.51-8.1.i386 pilot-link-2:0.11.8-16.i386 postgresql-0:8.1.4-1.1.i386 postgresql-contrib-0:8.1.4-1.1.i386 postgresql-devel-0:8.1.4-1.1.i386 postgresql-server-0:8.1.4-1.1.i386 procinfo-0:18-19.i386 python-0:2.4.4-1.fc7.i386 quagga-0:0.98.6-2.1.i386 ruby-libs-0:1.8.5-4.fc7.i386 tcsh-0:6.14-12.i386 util-linux-0:2.13-0.44.fc6.i386 vim-enhanced-2:7.0.162-2.i386 vim-minimal-2:7.0.162-2.i386 vim-X11-2:7.0.162-2.i386 xfsprogs-0:2.8.11-3.fc6.i386 xterm-0:215-3.fc6.i386 zsh-0:4.2.6-1.i386 And Extras packages: abiword-1:2.4.6-1.fc7.i386 clips-0:6.24-20.fc6.i386 clisp-0:2.41-1.fc6.i386 cyphesis-0:0.5.10-1.fc6.i386 darcs-0:1.0.8-4.fc7.i386 genius-0:0.7.6.1-3.fc6.i386 ghc66-0:6.6-1.fc7.i386 ginac-utils-0:1.3.5-1.fc6.i386 gnome-genius-0:0.7.6.1-3.fc6.i386 gnucap-0:0.34-3.fc6.i386 gnupg2-0:2.0.0-4.fc7.i386 gpsim-0:0.22.0-1.fc7.i386 grads-0:1.9b4-19.fc7.i386 hugs98-0:2006.09-1.fc7.i386 js-0:1.5-6.fc6.i386 koffice-kexi-0:1.6.0-2.fc7.i386 ktechlab-0:0.3-5.fc6.i386 lash-0:0.5.1-10.fc6.i386 maxima-runtime-clisp-0:5.10.0-8.fc7.i386 mono-debugger-0:0.30-7.fc6.i386 ngspice-0:17-7.fc6.i386 nmh-0:1.1-19.fc6.i386 octave-forge-0:2006.07.09-8.fc7.i386 opensc-0:0.11.1-6.fc6.i386 pari-gp-0:2.3.0-4.fc6.i386 php-readline-0:5.1.6-1.fc6.i386 pl-0:5.6.20-1.fc6.i386 q-0:7.5-2.fc7.i386 q-devel-0:7.5-2.fc7.i386 R-0:2.4.0-2.fc7.i386 ucblogo-0:5.5-5.fc6.i386 yafc-0:1.1.1-5.fc6.i386 yap-0:5.1.1-2.fc6.i386 yaz-0:2.1.26-1.1.fc6.i386 -- Miroslav Lichvar From agk at redhat.com Tue Nov 21 18:45:38 2006 From: agk at redhat.com (Alasdair G Kergon) Date: Tue, 21 Nov 2006 18:45:38 +0000 Subject: Avoid lvm2-2.02.15-1.fc7 Message-ID: <20061121184538.GB32560@agk.surrey.redhat.com> The current rawhide includes lvm2-2.02.15-1.fc7 which can segfault during program initialisation. It's best not to install this package: wait for lvm2-2.02.15-3.fc7 in the next update (~4am EST). A workaround if you have the package and need to get past the segfault is to move away /etc/lvm/lvm.conf. Alasdair -- agk at redhat.com From caillon at redhat.com Tue Nov 21 18:59:36 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 21 Nov 2006 13:59:36 -0500 Subject: Core + Exrtas 2 In-Reply-To: <1164123057.5059.39.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> <1164123057.5059.39.camel@mccallum.corsepiu.local> Message-ID: <45634C98.5000501@redhat.com> Ralf Corsepius wrote: > On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote: >> Ralf Corsepius wrote: >>> On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote: >>>> Ralf Corsepius wrote: >>>> >>>>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote: >>>>>> No, he's asking about introducing new packages to a released product. >>>>>> Say >>>>>> Fedora 7 goes out the door with a given package set. Three weeks later a >>>>>> great new package gets added to the Fedora universe, what kind of policy >>>>>> would there be in making this package available to the Fedora 7 users? >>>>> IMO, basically like FE has been doing it, so far, except that breaking >>>>> APIs, ABIs and packages deps etc. must not happen. >>>> That language may be a bit too strong, as I can think of cases where an >>>> essential update may end up breaking ABI, though it's not unreasonable to >>>> to make policy such that it *should* (not must) be avoided. >>> Well, this "must" is the core point about all this - Fedora should be a >>> stable distro. >> I guess we disagree then. > > Welcome to the wonderful "world of rawhide" - Good Night, Fedora! > > You once had been a usable distro, but your masters now seem to be > wanting to convert you into a jungle :( > > >> I consider ABI compatibility as just one part >> of what defines a stable distro, but, imo, there are certainly cases >> where breaking ABI is justified (for essential features, bug fixes, and >> yes, stability sometimes). > > Please ask RH how they have been handling Core, so far. > > I don't know how many times I've been told: "No API-changes, no ABI > upgrade, no feature upgrades, often not even bugfixes (aka > FIXEDRAWHIDE)"! There is no one-size-fits-all solution here. Sometimes, it is just plain dumb to not break API. Case study: https://bugzilla.mozilla.org/show_bug.cgi?id=296639 fixes a few critical security issues and other important bugs by differentiating priveleged and unpriveleged window objects. Effectively, this is a complete re-architecturing of the way DOM windows are handled internally to gecko, required because the previous architecture was flawed by design. It's a very large patch, which caused quite a number of regressions. Still, it was deemed necessary to get this fix into Red Hat Enterprise Linux 2.1, 3, and 4 for security purposes in a meeting with our security response team, product management, QA, and myself. Option A: wait for someone else to do something. wait time is high. potential for regression is high. Option B: spend many weeks on a solution, getting little exposure on it before releasing it to the wild as an update. Potential for regression is high. Option C: take the new version wholesale. The flaws are guaranteed fixed. API will break slightly, but with warning and possibly a little help, people can adapt. Most applications were fine with little to no changes. Eclipse needed some help, but I helped the team get around that. Devhelp needed a little bit of help, but it didn't take long. Naturally, we went with option C, after discussing the options, although it became clear quickly that option C was the best choice. I see no reason Fedora can't make informed, intelligent decisions if the need arises. Expressly forbidding these decisions to be made is the wrong thing to do. Rex is correct. We should look to avoid these situations if at all possible. But sometimes, there is no good alternative. From Liste at FamilleCollet.com Tue Nov 21 19:03:02 2006 From: Liste at FamilleCollet.com (Remi Collet) Date: Tue, 21 Nov 2006 20:03:02 +0100 Subject: CVS Restored, Help Needed in Verification In-Reply-To: <45631BFA.4030800@redhat.com> References: <45631BFA.4030800@redhat.com> Message-ID: <45634D66.3070606@FamilleCollet.com> Warren Togami a ?crit : > PACKAGE OWNERS - especially kevin, corsepiu, remi and qspencer are to > verify and fix their own CVS modules, or explicitly identify someone > else to do it on their behalf. php-pear-SOAP new branch (FC5, FC6) have been lost. I ask for (re)creation on the CVSSyncNeeded wiki page As the RPM are already build and available in the repo, i think i have nothing more to do. Thanks for this notification. Remi. P.S. and GREAT JOB done by the "Fedora Infrastructure and Red Hat IS/IT teams", thanks thanks thanks. From j.rink at freenet.de Tue Nov 21 21:08:18 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Tue, 21 Nov 2006 22:08:18 +0100 Subject: update from fc 5 -> 6 thinkpad t23 savage, dri is disabled In-Reply-To: <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> References: <20061121092739.8db49b0c.j.rink@freenet.de> <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> Message-ID: <20061121220818.2c59f3a0.j.rink@freenet.de> Am Tue, 21 Nov 2006 12:27:46 +0100 (CET) hat "Joachim Frieben" (Joachim Frieben) folgendes geschrieben: > > A black "glxgears" window is a known issue which has been filed at: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 > yes, this patch is in the fc6 package, but glxgears is black hear > and upstream at: > > https://bugs.freedesktop.org/show_bug.cgi?id=6357 , > > where you can find a patch which allows to settle the issue. It is > included in the current "Xorg" development tree, so expect things to > work better in "Xorg" 7.2 which should make its appearance in "FC7". > Otherwise, a "Red Hat" fix for "FC6" applying the patch mentioned > above is pending according to "Bugzilla" #195851. > I have patched the "xorg-x11-drv-savage" driver package myself, and it > works very well now. Have you downloaded the src.rpm and patched it? can you give me a link where i can download it? are you using fc6? can you show me your xorg.conf? Those patches in the link are in the fc 6 drv-savage packet, IMHO. Thanks for your answer Nine From j.rink at freenet.de Tue Nov 21 21:25:54 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Tue, 21 Nov 2006 22:25:54 +0100 Subject: update from fc 5 -> 6 thinkpad t23 savage, dri is disabled In-Reply-To: <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> References: <20061121092739.8db49b0c.j.rink@freenet.de> <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> Message-ID: <20061121222554.ddad2f2b.j.rink@freenet.de> Am Tue, 21 Nov 2006 12:27:46 +0100 (CET) hat "Joachim Frieben" (Joachim Frieben) folgendes geschrieben: > where you can find a patch which allows to settle the issue. It is > included in the current "Xorg" development tree, so expect things to > work better in "Xorg" 7.2 which should make its appearance in "FC7". which patches do you use? One is a dri tree patch in the dri.c Nine From dimi at lattica.com Tue Nov 21 22:30:51 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 21 Nov 2006 17:30:51 -0500 (EST) Subject: FC6: some impressions Message-ID: <2002.207.245.37.34.1164148251.squirrel@lattica.com> Hi folks, Congratulations for FC6, great work! I've been a long time RH/FC user ('95), so I'm pretty excited about this release. That being said, it's been a very rough experience from the POV of a desktop experience. In fact, rather frustrating and disappointing. Before I list the problems, let me just list a few datapoints: * I try to keep a clean install, as close as possible to standard * I use my desktop for email, browsing, VOIP, and hacking. * I don't need proprietary 3D drivers, no games. This is a very typical and non-taxing usage. Like for many (most?) people out there the email, browsing, CD burning, and VOIP accounts for probably 98% of what I need the desktop for. So, considering this quite typical use case, this is what I get from the upgrade from FC5: 1. Sound stopped working on my Intel ICH5 AC'97 Audio Controller https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216056 This killed VOIP on my box. 2. Evolution hangs when sending email https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208227 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208724 This renders Evolution almost entirely useless, making this a critical bug. 3. Evolution continued to not print email bodies https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186653 A long standing and crippling bug in a business environment where you receive invoices via email that you need to print. 4. CD burining in Nautilus is broken When clinking on the "Burn to CD..." button nothing happens for >30 of seconds, then dialog appears. Clicking on the drive dropdown to select another drive results in the same freeze lasting 20s or so. A non-technical user would have had to reboot the box! 5. Firefox starts using 100% after some time. No bug report here, as I haven't figure out what to report, but this makes browsing a painful experience. Slow, sluggish, with hangs that lasts 10s of seconds. Every time I close a Firefox window GNOME asks me if I want to kill it since it's not reporting, etc. Horrible. Considering these bugs, what is left of my desktop? I can't use email, no sound/VOIP, CD burning is boken, substandard browsing. I am not complaining about 3D drivers, fancy features, or Windows games, but absolutely basic desktop features. My question is: Quo Vadis? Shouldn't these problem been caught by QA? Aren't these issues considered show stoppers for a Desktop distribution? -- Dimi Paun Lattica, Inc. From naren_had at yahoo.com Tue Nov 21 22:44:49 2006 From: naren_had at yahoo.com (Narendra Hadke) Date: Tue, 21 Nov 2006 14:44:49 -0800 (PST) Subject: iSCSI Boot and FC6 Message-ID: <20061121224450.56690.qmail@web57906.mail.re3.yahoo.com> Hi, I am exploring iSCSI Install to target LUN support in FC6 and came across few issues while trying out the same. 1. Found that if network is not configured before graphical install, ?Advance Storage Option? dialog doesn?t prompt for the target ip address. It prompts for network config but doesn't go to "target ip dialog". For some reason "linux asknetwork" did not work as expected. 2. I used option ?linux updates? to configure network manually from the command prompt. Fedora 6 was installed(default) completely on the target LUN. After booting, kernel panic while mounting root filesystem. I beleive reason being install image didn't have "initrd" which can does discovery for boot LUN. 3. Before rebooting the installation, created "initrd" and modified grub setting. Discovery happened and root filesystem got mounted correctly. 4. Booting got struck during network install as interface on which initiator connected was brought down by network script. I bypassed this commenting this script( not elegant way of doing though) in sysinit. I was able to boot with FC6 from target LUN. Question I have is, if this feature fully supported without the workarrounds in FC6 I have done or I am missing some thing? Thanks, Narendra Hadke --------------------------------- Sponsored Link Rates near 39yr lows. $510,000 Loan for $1698/mo - Calculate new house payment -------------- next part -------------- An HTML attachment was scrubbed... URL: From gemi at bluewin.ch Tue Nov 21 22:47:55 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 21 Nov 2006 23:47:55 +0100 Subject: FC6: some impressions In-Reply-To: <2002.207.245.37.34.1164148251.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> Message-ID: <1164149275.13294.1.camel@scriabin.tannenrauch.ch> On Tue, 2006-11-21 at 17:30 -0500, Dimi Paun wrote: > My question is: Quo Vadis? Shouldn't these problem been caught by QA? > Aren't these issues considered show stoppers for a Desktop distribution? I have not experienced any of the problems you describe on FC6. However it may happen even on a clean install that a specific configuration triggers a bug that has not been detected or could not be reproduced during QA. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From alan at redhat.com Tue Nov 21 23:06:03 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 21 Nov 2006 18:06:03 -0500 Subject: FC6: some impressions In-Reply-To: <2002.207.245.37.34.1164148251.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> Message-ID: <20061121230603.GA13830@devserv.devel.redhat.com> On Tue, Nov 21, 2006 at 05:30:51PM -0500, Dimi Paun wrote: > 4. CD burining in Nautilus is broken > When clinking on the "Burn to CD..." button nothing happens > for >30 of seconds, then dialog appears. Clicking on the > drive dropdown to select another drive results in the same > freeze lasting 20s or so. A non-technical user would have > had to reboot the box! No bug number ? - Can you give me the results of "dmesg" when this happens and tell me what sort of IDE or SATA controller you have ? > 5. Firefox starts using 100% after some time. Seen that with FC6, went away after I removed the flash plugin crap. > My question is: Quo Vadis? Shouldn't these problem been caught by QA? > Aren't these issues considered show stoppers for a Desktop distribution? You assume everyone has the same experience you do - FC6 for me for example burns CDs fine and evolution sends email (its about all that particular pile of garbage does but thats a large upstream problem not an RH packaging one). You might want want to investigate a better email client - eg sylpheed-claws. I am interested in the CD one, thats something I need to know more about. Alan From hughsient at gmail.com Tue Nov 21 23:22:35 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 21 Nov 2006 23:22:35 +0000 Subject: FC6: some impressions In-Reply-To: <2002.207.245.37.34.1164148251.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> Message-ID: <1164151355.4318.3.camel@hughsie-laptop> On Tue, 2006-11-21 at 17:30 -0500, Dimi Paun wrote: > > 2. Evolution hangs when sending email > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208227 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208724 > This renders Evolution almost entirely useless, > making this a critical bug. Happening to me too - evolutions hangs when it tries to connect to smtp.gmail.com and then requires a manual kill -9 to close it. Richard. From otto_rey at yahoo.com.ar Wed Nov 22 00:25:07 2006 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Tue, 21 Nov 2006 16:25:07 -0800 (PST) Subject: FC6: some impressions Message-ID: <20061122002507.65789.qmail@web52415.mail.yahoo.com> Evolution hang when press send/recive with M$ Exchange account. I am tired of Evolution bugs. One update, work, next update, broken, next update work, next update broken and so on. Do you know some alternative for Exchange accounts? I am the Developer of JPVMailer email client (only winshit, now deprecated) and im starting development of JPVMailerX (GPL licence of course) completely written in Java (Sun GPL java :) ). More information http://www.ottorey.com.ar or the same http://www.jpvmailer.com.ar (Sorry, only spanish by now) Im planning to setup CVS repository and translate the site to English. Next i will call for voluntaries. (umm... looks like sourceforge...:) ) Well... for now just ideas.... and a bit of work... ----- Original Message ---- From: Richard Hughes To: Development discussions related to Fedora Core Sent: Tuesday, November 21, 2006 8:22:35 PM Subject: Re: FC6: some impressions On Tue, 2006-11-21 at 17:30 -0500, Dimi Paun wrote: > > 2. Evolution hangs when sending email > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208227 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208724 > This renders Evolution almost entirely useless, > making this a critical bug. Happening to me too - evolutions hangs when it tries to connect to smtp.gmail.com and then requires a manual kill -9 to close it. Richard. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimi at lattica.com Wed Nov 22 02:10:36 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 21 Nov 2006 21:10:36 -0500 (EST) Subject: FC6: some impressions In-Reply-To: <20061121230603.GA13830@devserv.devel.redhat.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> Message-ID: <37941.74.96.19.63.1164161436.squirrel@lattica.com> On Tue, November 21, 2006 6:06 pm, Alan Cox wrote: > No bug number ? - Can you give me the results of "dmesg" when this happens > and tell me what sort of IDE or SATA controller you have ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216810 >> 5. Firefox starts using 100% after some time. > > Seen that with FC6, went away after I removed the flash plugin crap. True, it's probably related to flash, but I'm afraid it's no longer an optional component judging by how many sites I can't visit without it. > You might want want to investigate a better email client - eg > sylpheed-claws. The email client is a particularly difficult problem. I have reluctantly switched to it some time ago following RedHat's lead, and frankly now it's part of my business process. Changing it is non-trivial, and it can not be done on a whim. >From a pure user perspective, an email client is like a kernel, it's so basic that you can't just change it left right and center. What is the new direction for the email client? Is there one? -- Dimi Paun Lattica, Inc. From rc040203 at freenet.de Wed Nov 22 03:55:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Nov 2006 04:55:24 +0100 Subject: Core + Exrtas 2 In-Reply-To: References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> <1164123057.5059.39.camel@mccallum.corsepiu.local> Message-ID: <1164167724.5059.167.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 11:31 -0600, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote: > > >> I consider ABI compatibility as just one part > >> of what defines a stable distro, but, imo, there are certainly cases > >> where breaking ABI is justified (for essential features, bug fixes, and > >> yes, stability sometimes). > > > > Please ask RH how they have been handling Core, so far. > > > > I don't know how many times I've been told: "No API-changes, no ABI > > upgrade, no feature upgrades, often not even bugfixes (aka > > FIXEDRAWHIDE)"! > > When it comes to breaking API/ABI, I'd say it's primarily the package > maintainers' call to make. I am inclined to agree in those cases, where a package is of limited importance, has a very limited number of dependencies and/or a small userbase, but I can't avoid to disagree in general. But what would you think of a kernel, GCC, Glibc, Gtk/Gtk or Qt/KDE maintainer, who breaks things midst of a distro's life time? Have a look at FE: A classic breakdown is maintainers not paying attention to SONAMEs/ABIs/APIs and them inadvertently breaking something by not so. Most maintainers, after having gone through a learning curse, will try to circumvent such issues, either by providing compat-packages, by trying to inform their users in advance, or ... to resort to refraining from their plans. Ralf From rc040203 at freenet.de Wed Nov 22 04:07:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Nov 2006 05:07:45 +0100 Subject: Core + Exrtas 2 In-Reply-To: <45634C98.5000501@redhat.com> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> <1164123057.5059.39.camel@mccallum.corsepiu.local> <45634C98.5000501@redhat.com> Message-ID: <1164168465.5059.176.camel@mccallum.corsepiu.local> On Tue, 2006-11-21 at 13:59 -0500, Christopher Aillon wrote: > Rex is correct. We should look to avoid these situations if at all > possible. But sometimes, there is no good alternative. No disagreement ... if "there is no good alternative" ... I am not against breaking ABIs/APIs/etc. But, from an FE background, the situation is conversely: People break ABIs/APIs/etc., because they are not aware about doing so, because they do not care about it, because they blindly follow upstream (and upstream doesn't care about ABI/API/etc.) or because they think "having feature XXX outweighs ABI/API/etc.". Ralf From aalam at redhat.com Wed Nov 22 05:38:33 2006 From: aalam at redhat.com (A S Alam) Date: Wed, 22 Nov 2006 11:08:33 +0530 Subject: gnome-appliation/firefox crashed with Xfce Message-ID: <4563E259.1080707@redhat.com> Hi during login to Xfce environment, firefox and gnome applications are crashing with message as following: ** Error ** Could not locate registry aborting.... Bonobo accessibility support initialized GTK accessibility Module initialized **(gnome_segv2:3345): CRITICAL **AT_SPI_REGISTRY was not started at session startup. ** (gnome_seg3:3345): WARNING ** IOR not set. I have latest rawhide. Can some check th -- A S Alam timezone: GMT+5:30 join us at #fedora-l10n (freenode) "Either find a way or make one" From jochen.schlick at comsoft.de Wed Nov 22 07:12:10 2006 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Wed, 22 Nov 2006 08:12:10 +0100 Subject: After Rawhide update yesterday xfs crashes Message-ID: <4563F84A.9010209@comsoft.de> immediately. Xorg.log says something about not finding the fixed font (which is because xfs isn't running) Is this a known problem ?? best regards -- ------------------------------------------------------------ Jochen Schlick From j.rink at freenet.de Wed Nov 22 08:32:49 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Wed, 22 Nov 2006 09:32:49 +0100 Subject: FC6: some impressions In-Reply-To: <20061121230603.GA13830@devserv.devel.redhat.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> Message-ID: <20061122093249.3c619f41.j.rink@freenet.de> Am Tue, 21 Nov 2006 18:06:03 -0500 hat Alan Cox (Alan Cox) folgendes geschrieben: > You assume everyone has the same experience you do - FC6 for me for > example burns CDs fine and evolution sends email (its about all that > particular pile of garbage does but thats a large upstream problem > not an RH packaging one). You might want want to investigate a better > email client - eg sylpheed-claws. > The DVD fc6 iso i burned with fc5 (double click in nautilus) does not go through the chksum test and failed in anaconda ;-) I burned it with nero :) -- Nine (not 9) Never trust a hippie From jfrieben at freesurf.fr Wed Nov 22 09:52:44 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 22 Nov 2006 10:52:44 +0100 (CET) Subject: update from fc 5 -& gt; 6 thinkpad t23 savage, dri is disabled In-Reply-To: <20061121220818.2c59f3a0.j.rink@freenet.de> References: <20061121220818.2c59f3a0.j.rink@freenet.de> Message-ID: <21011.194.94.224.254.1164189164.squirrel@jose.freesurf.fr> >> A black "glxgears" window is a known issue which has been filed at: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 >> > > yes, this patch is in the fc6 package, but glxgears is black hear No, the patch is not included. Current version is "xorg-x11-drv-savage-2.1.1-5.fc6" from August 2006. I had submitted the patch I am talking about mid-September 2006 as https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=136548 A. Deucher's original patch has already been included upstream, but current "Xorg" in "FC6" is based on "Xorg" 7.1.1 and lags behind. However, "ajax" has changed the summary to "Update Savage driver to fix DRI hang", so a corresponding update seems to be scheduled for "FC6". From jakub at redhat.com Wed Nov 22 10:08:00 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 05:08:00 -0500 Subject: Static linking considered harmful Message-ID: <20061122100800.GQ6570@devserv.devel.redhat.com> Hi! We should more proactively discourage static linking in FC7+, for reasons for that see http://people.redhat.com/drepper/no_static_linking.html Removing libc.a would be most effective, but I'm afraid we still need a handful of statically linked binaries for boot time initialization and system recovery utilities. So, I think it would be best if we could analyze what in FC7/FE7 is linked statically, why, if it really needs to be linked that way and what *.a libraries does it link in and kill all other *.a libraries (unless the library is only in *.a form, examples libbfd.a, libc_nonshared.a, libpthread_nonshared.a, libsupc++.a, libgfortranbegin.a) and kill all other libraries. E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, libboost*.a, all GUI libs that have also *.so libs, etc. Thoughts? Jakub From pertusus at free.fr Wed Nov 22 10:24:28 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 11:24:28 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <20061122102428.GD2799@free.fr> On Wed, Nov 22, 2006 at 05:08:00AM -0500, Jakub Jelinek wrote: > Hi! > > We should more proactively discourage static linking in FC7+, for > reasons for that see > http://people.redhat.com/drepper/no_static_linking.html > > Removing libc.a would be most effective, but I'm afraid we still need > a handful of statically linked binaries for boot time initialization and > system recovery utilities. Not only. There are cases when all those issues are moot, a prominent one being for numerical models. Compiling models statically makes it possible to run them on any other linux (including different fedora version) box without recompiling. So all the libraries that can be used for numerical computations should have static libraries kept. To be able to compile statically those kind of executables requires in turn to keep static version of 'standard' libraries, and also maybe some libraries used in data processing and conversion and the like. -- Pat From aph at redhat.com Wed Nov 22 10:29:44 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2006 10:29:44 +0000 Subject: Static linking considered harmful In-Reply-To: <20061122102428.GD2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> Message-ID: <17764.9880.953733.167732@zebedee.pink> Patrice Dumas writes: > On Wed, Nov 22, 2006 at 05:08:00AM -0500, Jakub Jelinek wrote: > > Hi! > > > > We should more proactively discourage static linking in FC7+, for > > reasons for that see > > http://people.redhat.com/drepper/no_static_linking.html > > > > Removing libc.a would be most effective, but I'm afraid we still need > > a handful of statically linked binaries for boot time initialization and > > system recovery utilities. > > Not only. There are cases when all those issues are moot, a prominent one > being for numerical models. Compiling models statically makes it possible > to run them on any other linux (including different fedora version) box > without recompiling. So all the libraries that can be used for numerical > computations should have static libraries kept. This seems like a non sequitur. What's special about numerical computations? Andrew. From avi at argo.co.il Wed Nov 22 10:32:52 2006 From: avi at argo.co.il (Avi Kivity) Date: Wed, 22 Nov 2006 12:32:52 +0200 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <45642754.9050706@argo.co.il> Jakub Jelinek wrote: > Hi! > > We should more proactively discourage static linking in FC7+, for > reasons for that see > http://people.redhat.com/drepper/no_static_linking.html > > Removing libc.a would be most effective, but I'm afraid we still need > a handful of statically linked binaries for boot time initialization and > system recovery utilities. > > So, I think it would be best if we could analyze what in FC7/FE7 > is linked statically, why, if it really needs to be linked that way > and what *.a libraries does it link in and kill all other *.a libraries > (unless the library is only in *.a form, examples libbfd.a, > libc_nonshared.a, libpthread_nonshared.a, libsupc++.a, libgfortranbegin.a) > and kill all other libraries. > > E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, > libboost*.a, all GUI libs that have also *.so libs, etc. > > That would prevent static linking not only for Fedora apps, but also for user applications built on Fedora. I don't see a reason to prevent users from using static linking, only Fedora apps. -- error compiling committee.c: too many arguments to function From arjan at fenrus.demon.nl Wed Nov 22 10:34:14 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 22 Nov 2006 11:34:14 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122102428.GD2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> Message-ID: <1164191654.31358.728.camel@laptopd505.fenrus.org> On Wed, 2006-11-22 at 11:24 +0100, Patrice Dumas wrote: > On Wed, Nov 22, 2006 at 05:08:00AM -0500, Jakub Jelinek wrote: > > Hi! > > > > We should more proactively discourage static linking in FC7+, for > > reasons for that see > > http://people.redhat.com/drepper/no_static_linking.html > > > > Removing libc.a would be most effective, but I'm afraid we still need > > a handful of statically linked binaries for boot time initialization and > > system recovery utilities. > > Not only. There are cases when all those issues are moot, a prominent one > being for numerical models. Compiling models statically makes it possible > to run them on any other linux (including different fedora version) box > without recompiling actually static linking DECREASES that portability !! From pertusus at free.fr Wed Nov 22 10:37:43 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 11:37:43 +0100 Subject: Static linking considered harmful In-Reply-To: <17764.9880.953733.167732@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <17764.9880.953733.167732@zebedee.pink> Message-ID: <20061122103743.GE2799@free.fr> On Wed, Nov 22, 2006 at 10:29:44AM +0000, Andrew Haley wrote: > > > > Not only. There are cases when all those issues are moot, a prominent one > > being for numerical models. Compiling models statically makes it possible > > to run them on any other linux (including different fedora version) box > > without recompiling. So all the libraries that can be used for numerical > > computations should have static libraries kept. > > This seems like a non sequitur. What's special about numerical > computations? I already explained it in my mail? To be more precise * security considerations are moot * nss, iconv are not needed Other arguments for dynamic linking are not compulsory. And numerical models are programs we would like to be able to run on other linux box without recompiling. Imagine that compilation takes 30 minutes and that you want to start 20 runs in paralell from nfs mounted filesystem in an heterogeneous linux environment with some redhat 6.2, 7.x, centos, debian, mandrake and fedora core (real world example, of course). -- Pat From rc040203 at freenet.de Wed Nov 22 10:39:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Nov 2006 11:39:37 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <1164191978.8385.15.camel@mccallum.corsepiu.local> On Wed, 2006-11-22 at 05:08 -0500, Jakub Jelinek wrote: > Hi! > > We should more proactively discourage static linking in FC7+, for > reasons for that see > http://people.redhat.com/drepper/no_static_linking.html > > Removing libc.a would be most effective, but I'm afraid we still need > a handful of statically linked binaries for boot time initialization and > system recovery utilities. > > So, I think it would be best if we could analyze what in FC7/FE7 > is linked statically, why, if it really needs to be linked that way > and what *.a libraries does it link in and kill all other *.a libraries > (unless the library is only in *.a form, examples libbfd.a, > libc_nonshared.a, libpthread_nonshared.a, libsupc++.a, libgfortranbegin.a) > and kill all other libraries. > > E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, > libboost*.a, all GUI libs that have also *.so libs, etc. > > Thoughts? Excellent proposal, way over due. Also, the FPC had accepted proposal aim at similar objectives a couple of weeks ago: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage Ralf From aph at redhat.com Wed Nov 22 10:39:50 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2006 10:39:50 +0000 Subject: Static linking considered harmful In-Reply-To: <45642754.9050706@argo.co.il> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45642754.9050706@argo.co.il> Message-ID: <17764.10486.933592.120084@zebedee.pink> Avi Kivity writes: > > That would prevent static linking not only for Fedora apps, but also for > user applications built on Fedora. Yep. > I don't see a reason to prevent users from using static linking, See http://people.redhat.com/drepper/no_static_linking.html, especially # fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. Andrew. From pertusus at free.fr Wed Nov 22 10:39:35 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 11:39:35 +0100 Subject: Static linking considered harmful In-Reply-To: <1164191654.31358.728.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> Message-ID: <20061122103935.GF2799@free.fr> On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > > actually static linking DECREASES that portability !! Are you saying that you can compile a program dynamically and run it on old redhat, centos, old debian, mandrake and fedora core boxes? I tried, it fails, while statically linked programs are fine (at least numerical models). -- Pat From jakub at redhat.com Wed Nov 22 10:41:19 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 05:41:19 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122102428.GD2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> Message-ID: <20061122104119.GT6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 11:24:28AM +0100, Patrice Dumas wrote: > Not only. There are cases when all those issues are moot, a prominent one > being for numerical models. Compiling models statically makes it possible > to run them on any other linux (including different fedora version) box > without recompiling. That's a myth, static linking decreases portability, e.g. because statically linked binaries have the dynamic linking code compiled statically into the binary, thus they can't deal with new system shared libraries, new iconv modules, nss modules, locale data formats, etc. And, most of statically linked programs touch one of those areas, many functions use nss services, stdio uses internally iconv, many functions deal with locales, etc. E.g. all shared libraries in FC6 except those from glibc rpm can't be understood by FC5 or earlier dynamic linker or dynamic linking code linked into statically linked programs. Jakub From aph at redhat.com Wed Nov 22 10:48:21 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2006 10:48:21 +0000 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <17764.10997.398434.309096@zebedee.pink> Jakub Jelinek writes: > > Thoughts? Just Do It! Andrew. From pertusus at free.fr Wed Nov 22 10:49:04 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 11:49:04 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122104119.GT6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> Message-ID: <20061122104904.GG2799@free.fr> On Wed, Nov 22, 2006 at 05:41:19AM -0500, Jakub Jelinek wrote: > On Wed, Nov 22, 2006 at 11:24:28AM +0100, Patrice Dumas wrote: > > Not only. There are cases when all those issues are moot, a prominent one > > being for numerical models. Compiling models statically makes it possible > > to run them on any other linux (including different fedora version) box > > without recompiling. > > That's a myth, static linking decreases portability, e.g. because statically > linked binaries have the dynamic linking code compiled statically into the > binary, thus they can't deal with new system shared libraries, new iconv > modules, nss modules, locale data formats, etc. And, most of statically That's exactly the point. In that case we don't want to deal with new system shared libraries, new iconv modules, nss modules, locale data formats, etc. In fact this is the reverse, sometimes it is usefull to be able to rerun old executables to have exact same results for chaotic models, for example (although I have not myself come accross such cases). > linked programs touch one of those areas, many functions use nss services, > stdio uses internally iconv, many functions deal with locales, etc. That's not true for numerical models. I don't really underestand what you are talking about. When I compile a model with gcc -static mymodel.o -lnumerical-lib I don't care at all about system share libraries, this is not a shared executable, so no trouble with new system shared libraries. And once more for numerical models iconv, locales, and nss are not really usefull. -- Pat From jakub at redhat.com Wed Nov 22 10:56:07 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 05:56:07 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122103935.GF2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122103935.GF2799@free.fr> Message-ID: <20061122105607.GV6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 11:39:35AM +0100, Patrice Dumas wrote: > On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > > > > actually static linking DECREASES that portability !! > > Are you saying that you can compile a program dynamically and run it > on old redhat, centos, old debian, mandrake and fedora core boxes? > I tried, it fails, while statically linked programs are fine (at least > numerical models). Yes and no. Assuming if you link statically on very recent distro that your program will work on any old Linux distro is just very bad assumption. E.g. each glibc is configured for some minimal kernel version, if you attempt to run the program on older kernel some functions will crash, misbehave or the program won't start at all. E.g. FC5+ glibc is configured for 2.6.9 and later kernels, so running it on say FC1 just isn't going to fly. If you want to create a program that will work on older distributions (within reasonable limits, e.g. glibc 2.0 or libc5 or a.out stuff isn't supported anymore in recent FCs), just compile/link against the oldest glibc etc. you want to support, whether by installing an old distro in the chroot or by installing and linking against something like compat-glibc (these days only present in RHEL, but could very well be revived for FC as well), using compat-gcc (on FC6 that has e.g. a side-effect of using -Wl,--hash-style=sysv etc.). Jakub From andy at warmcat.com Wed Nov 22 10:53:58 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 22 Nov 2006 10:53:58 +0000 Subject: Static linking considered harmful In-Reply-To: <20061122104904.GG2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> Message-ID: <45642C46.9040803@warmcat.com> Patrice Dumas wrote: > I don't care at all about system share libraries, this is not a shared > executable, so no trouble with new system shared libraries. And once more > for numerical models iconv, locales, and nss are not really usefull. You could alter your build methodology so that each of the target boxes,eg, rebuilds an SRPM with the local library environment? You need the compiler and -devel bits and bobs then on the boxes. Or, leaving the .a files in the packages can be a policy controlled by a macro on the build box? Then you can rebuild the -devel packages for your build box with the .a files still in how you like and go on as you are. -Andy From galibert at pobox.com Wed Nov 22 10:57:11 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 11:57:11 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122104904.GG2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> Message-ID: <20061122105711.GA89035@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 11:49:04AM +0100, Patrice Dumas wrote: > That's not true for numerical models. I don't really underestand what you > are talking about. When I compile a model with > > gcc -static mymodel.o -lnumerical-lib > > I don't care at all about system share libraries, this is not a shared > executable, so no trouble with new system shared libraries. And once more > for numerical models iconv, locales, and nss are not really usefull. Actually, given the incompetence of the glibc developpers, you do. They use shared objects whether you want them or not. You can't resolve localhost for instance, which is quite annoying for X applications. OG. From galibert at pobox.com Wed Nov 22 11:03:17 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 12:03:17 +0100 Subject: Static linking considered harmful In-Reply-To: <45642C46.9040803@warmcat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> Message-ID: <20061122110317.GB89035@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 10:53:58AM +0000, Andy Green wrote: > You could alter your build methodology so that each of the target > boxes,eg, rebuilds an SRPM with the local library environment? You need > the compiler and -devel bits and bobs then on the boxes. That's the point where he should use gentoo and not fedora. OG. From jakub at redhat.com Wed Nov 22 11:08:56 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 06:08:56 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122105711.GA89035@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <20061122105711.GA89035@dspnet.fr.eu.org> Message-ID: <20061122110856.GW6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 11:57:11AM +0100, Olivier Galibert wrote: > On Wed, Nov 22, 2006 at 11:49:04AM +0100, Patrice Dumas wrote: > > That's not true for numerical models. I don't really underestand what you > > are talking about. When I compile a model with > > > > gcc -static mymodel.o -lnumerical-lib > > > > I don't care at all about system share libraries, this is not a shared > > executable, so no trouble with new system shared libraries. And once more > > for numerical models iconv, locales, and nss are not really usefull. > > Actually, given the incompetence of the glibc developpers, you do. > They use shared objects whether you want them or not. You can't > resolve localhost for instance, which is quite annoying for X > applications. And how do you want to resolve localhost when on one box you use files for that, on another NIS, on another NIS+, on another LDAP, on another Berkeley DB, etc.? Even if you only wanted to put files parsing into statically linked programs and do the rest dynamically, what would e.g. with #215283, where FC6 anaconda now writes localhost entry as ::1 localhost.localdomain localhost instead of 127.0.0.1 and gethostbyname would just fail in that case? When libnss_files.so.2 is used, this is fixable (and will be fixed soon), otherwise you'd have to recompile all your statically linked binaries? Jakub From andy at warmcat.com Wed Nov 22 11:08:34 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 22 Nov 2006 11:08:34 +0000 Subject: Static linking considered harmful In-Reply-To: <20061122110317.GB89035@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122110317.GB89035@dspnet.fr.eu.org> Message-ID: <45642FB2.5050109@warmcat.com> Olivier Galibert wrote: > On Wed, Nov 22, 2006 at 10:53:58AM +0000, Andy Green wrote: >> You could alter your build methodology so that each of the target >> boxes,eg, rebuilds an SRPM with the local library environment? You need >> the compiler and -devel bits and bobs then on the boxes. > > That's the point where he should use gentoo and not fedora. But he isn't just using Fedora, he has a bunch of not very compatible OS installs of varying ages, and he would need to work around this change one way or another. I didn't miss the joke but if he could actually use Gentoo or anything else that was the same on all the boxes that would indeed solve his problem. -Andy From pertusus at free.fr Wed Nov 22 11:39:40 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 12:39:40 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122105607.GV6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122103935.GF2799@free.fr> <20061122105607.GV6570@devserv.devel.redhat.com> Message-ID: <20061122113940.GH2799@free.fr> On Wed, Nov 22, 2006 at 05:56:07AM -0500, Jakub Jelinek wrote: > On Wed, Nov 22, 2006 at 11:39:35AM +0100, Patrice Dumas wrote: > > On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > > > > > > actually static linking DECREASES that portability !! > > > > Are you saying that you can compile a program dynamically and run it > > on old redhat, centos, old debian, mandrake and fedora core boxes? > > I tried, it fails, while statically linked programs are fine (at least > > numerical models). > > Yes and no. > > Assuming if you link statically on very recent distro that your program > will work on any old Linux distro is just very bad assumption. > E.g. each glibc is configured for some minimal kernel version, if you > attempt to run the program on older kernel some functions will crash, > misbehave or the program won't start at all. E.g. FC5+ glibc is > configured for 2.6.9 and later kernels, so running it on say FC1 > just isn't going to fly. Ok, my tests where from pre-FC5. > If you want to create a program that will work on older distributions > (within reasonable limits, e.g. glibc 2.0 or libc5 or a.out stuff > isn't supported anymore in recent FCs), just compile/link against I am not targeting such old systems. Assuming kernel 2.4 and glibc above 2.0 is very reasonable, computers with oldest softs are likely to be slow anyway. > the oldest glibc etc. you want to support, whether by installing > an old distro in the chroot or by installing and linking against > something like compat-glibc (these days only present in RHEL, > but could very well be revived for FC as well), using compat-gcc > (on FC6 that has e.g. a side-effect of using -Wl,--hash-style=sysv > etc.). That would be cool to be able to do that. I indeed tested that on mandrake 9.2 it fails the way you describe (with kernel too old message). In the mean time it is allready interesting to be able to run on any computer with kernel > 2.6.9, even if the libraries are not installed or there is no compatibility between the shared libraries. And once more that can only be achieved by statically compiling. -- Pat From alan at redhat.com Wed Nov 22 11:47:37 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Nov 2006 06:47:37 -0500 Subject: FC6: some impressions In-Reply-To: <37941.74.96.19.63.1164161436.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> Message-ID: <20061122114737.GB10961@devserv.devel.redhat.com> On Tue, Nov 21, 2006 at 09:10:36PM -0500, Dimi Paun wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216810 Thanks > >> 5. Firefox starts using 100% after some time. > > > > Seen that with FC6, went away after I removed the flash plugin crap. > > True, it's probably related to flash, but I'm afraid it's no longer an > optional component judging by how many sites I can't visit without it. If you have the flash plugin loaded try a bit without - if that stops the hang try the flash 9 beta, and report problems to the flash folks as they ask so they can get the final flash 9 stable. > What is the new direction for the email client? Is there one? Beats me. Evolution has things some people think are essential that the others lack, but its slow and nobody seems to be fixing the real bugs (eg the year old remote DoS I sent to bugtraq) From pertusus at free.fr Wed Nov 22 11:50:15 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 12:50:15 +0100 Subject: Static linking considered harmful In-Reply-To: <45642C46.9040803@warmcat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> Message-ID: <20061122115015.GI2799@free.fr> On Wed, Nov 22, 2006 at 10:53:58AM +0000, Andy Green wrote: > Patrice Dumas wrote: > > You could alter your build methodology so that each of the target > boxes,eg, rebuilds an SRPM with the local library environment? You need > the compiler and -devel bits and bobs then on the boxes. I am not necessarilly root on all the boxes, some may not be rpm based. The compilation may be time consuming too. > Or, leaving the .a files in the packages can be a policy controlled by a > macro on the build box? Then you can rebuild the -devel packages for > your build box with the .a files still in how you like and go on as you are. Of course, but this decreases a lot the usefullness of fedora for me. Maybe I am the only one to have these needs, but I hope not, it would be a bit sad for fedora. -- Pat From alan at redhat.com Wed Nov 22 11:58:44 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Nov 2006 06:58:44 -0500 Subject: Static linking considered harmful In-Reply-To: <17764.9880.953733.167732@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <17764.9880.953733.167732@zebedee.pink> Message-ID: <20061122115844.GF10961@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 10:29:44AM +0000, Andrew Haley wrote: > > Not only. There are cases when all those issues are moot, a prominent one > > being for numerical models. Compiling models statically makes it possible > > to run them on any other linux (including different fedora version) box > > without recompiling. So all the libraries that can be used for numerical You can bundle sets of dynamic libraries with an application > > computations should have static libraries kept. > > This seems like a non sequitur. What's special about numerical > computations? One reason there for static is to avoid the elf register overhead, but that isn't so bad nowdays From pertusus at free.fr Wed Nov 22 12:00:50 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 13:00:50 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122115844.GF10961@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <17764.9880.953733.167732@zebedee.pink> <20061122115844.GF10961@devserv.devel.redhat.com> Message-ID: <20061122120050.GK2799@free.fr> On Wed, Nov 22, 2006 at 06:58:44AM -0500, Alan Cox wrote: > On Wed, Nov 22, 2006 at 10:29:44AM +0000, Andrew Haley wrote: > > > Not only. There are cases when all those issues are moot, a prominent one > > > being for numerical models. Compiling models statically makes it possible > > > to run them on any other linux (including different fedora version) box > > > without recompiling. So all the libraries that can be used for numerical > You can bundle sets of dynamic libraries with an application Of course, but that's very impractical, while adding -static to the compilation line is really easy. -- Pat From galibert at pobox.com Wed Nov 22 12:11:07 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 13:11:07 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122115844.GF10961@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <17764.9880.953733.167732@zebedee.pink> <20061122115844.GF10961@devserv.devel.redhat.com> Message-ID: <20061122121107.GA99837@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 06:58:44AM -0500, Alan Cox wrote: > One reason there for static is to avoid the elf register overhead, but that > isn't so bad nowdays Another is DT_TEXTREL. OG. From pekkas at netcore.fi Wed Nov 22 13:23:21 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Nov 2006 15:23:21 +0200 (EET) Subject: Reducing Fedora memory footprint? Message-ID: Hi, I'd like to reduce the memory footprint of FC6. Are there already webpages that describe how to make Fedora more manageable on those 3-4 year old "junk hardware"? (Some also have worried about the disk space footprint, but let's leave that out of scope for now..) I think we have a problem if FC6 can't run properly on IBM ThinkPad X30 w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are the amount of memory, relatively slow disks, and swapping on those relatively slow disks. A couple of observations: 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the computer is "idle". Either ACPI is a lot worse than APM, or something is going on. Any ideas how to debug this? 2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours (just the depsolving, upgrade and cleanup -- all packages and headers already existed on local disk). Only yum and Xorg were running at that time. 3) are there more light-weight desktops/WMs than xfce? Recently, it seems it also has become bloated, e.g.,: psavola 2644 0.0 3.3 72840 8292 ? Ss Nov21 0:07 xfce-mcs-manager psavola 2650 0.0 3.7 76792 9140 ? S Nov21 0:31 /usr/bin/xfce4-panel psavola 2654 0.0 3.1 68484 7844 ? S Nov21 0:02 /usr/libexec/xfce4/panel-plugins/xfce4-menu-plugin [...] psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49 /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...] and: $ ldd /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin linux-gate.so.1 => (0x00117000) libxfce4panel.so.1 => /usr/lib/libxfce4panel.so.1 (0x005c4000) libxfcegui4.so.4 => /usr/lib/libxfcegui4.so.4 (0x003d4000) libxfce4util.so.4 => /usr/lib/libxfce4util.so.4 (0x00435000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x006fc000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00118000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x001a5000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00368000) libm.so.6 => /lib/libm.so.6 (0x0050f000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x001c1000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00f1e000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x001ca000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00236000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00dbb000) libdl.so.2 => /lib/libdl.so.2 (0x00110000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00275000) libc.so.6 => /lib/libc.so.6 (0x00a94000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00313000) libICE.so.6 => /usr/lib/libICE.so.6 (0x0031c000) libX11.so.6 => /usr/lib/libX11.so.6 (0x005da000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00336000) libXext.so.6 => /usr/lib/libXext.so.6 (0x0037f000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00eea000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00d04000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00e99000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00d55000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x0038f000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00da6000) /lib/ld-linux.so.2 (0x006e1000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00bdd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00444000) libz.so.1 => /usr/lib/libz.so.1 (0x00399000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x003ac000) librt.so.1 => /lib/librt.so.1 (0x00423000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00d4e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00df0000) libexpat.so.0 => /lib/libexpat.so.0 (0x004d3000) libpthread.so.0 => /lib/libpthread.so.0 (0x00c39000) Something is wrong when when a simple battery plugin takes 80 MB of memory.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From kevin.kofler at chello.at Wed Nov 22 13:36:10 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Nov 2006 13:36:10 +0000 (UTC) Subject: Reducing Fedora memory footprint? References: Message-ID: Pekka Savola netcore.fi> writes: > I'd like to reduce the memory footprint of FC6. Are there already > webpages that describe how to make Fedora more manageable on those 3-4 > year old "junk hardware"? (Some also have worried about the disk > space footprint, but let's leave that out of scope for now..) In my experience, the biggest problem with Fedora on low-memory systems is getting it installed. Anaconda tends to just lock up or reboot if it doesn't have at least something like 256 MB RAM. As for actually running it, it just works on my Pentium II 266 laptop with 160 MB RAM. Some apps like Synaptic (command-line apt and aptitude are bearable) and the usual suspects (OO.o, Eclipse) are just unusable or borderline unusable though. Synaptic used to require a lot less memory with the old repository format, repomd is a big memory eater (which might also explain why Anaconda needs so much memory). Kevin Kofler From buc at odusz.so-cdu.ru Wed Nov 22 13:47:04 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 22 Nov 2006 16:47:04 +0300 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <456454D8.4040000@odu.neva.ru> Jakub Jelinek wrote: >Removing libc.a would be most effective, but I'm afraid we still need >a handful of statically linked binaries for boot time initialization and >system recovery utilities. > >So, I think it would be best if we could analyze what in FC7/FE7 >is linked statically, > Just FYI, what was linked statically in FC5 (as an example ;) ): Package File cryptsetup-luks /sbin/cryptsetup device-mapper /sbin/dmsetup.static dmraid /sbin/dmraid.static dump /sbin/dump dump /sbin/restore e2fsprogs /sbin/e2fsck e2fsprogs /sbin/fsck.ext2 e2fsprogs /sbin/fsck.ext3 glibc /sbin/ldconfig glibc /sbin/sln libgcc /usr/sbin/libgcc_post_upgrade lvm2 /sbin/lvm.static mkinitrd /sbin/nash module-init-tools /sbin/insmod.static rmt /sbin/rmt udev /sbin/udevd.static > > > Thoughts? > I am sure that at least "libc.a/libm.a" must be saved. Certainly as a separate package (say "glibc-static"), not installed by default. If some (advanced) user want to link something statically for some reason, let's give him a chance to do this easier. "Easier" means that he does not need to re-compile all the stuff he need. Just some libraries, but not the whole libc. And if I teach programming, I want to show students that their "Hello, World!" program can be linked statically, and what it differs to dynamic linkage. For this, I want the libc.a to be present... ;) Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From waustin at speakeasy.net Wed Nov 22 13:49:56 2006 From: waustin at speakeasy.net (William W. Austin) Date: Wed, 22 Nov 2006 08:49:56 -0500 Subject: Static linking considered harmful Message-ID: <1164203396l.4626l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> On 2006-11-22 05:37:43, Patrice Dumas wrote: > On Wed, Nov 22, 2006 at 10:29:44AM +0000, Andrew Haley wrote: > > > > > > Not only. There are cases when all those issues are moot, > > > a prominent one > > > being for numerical models. Compiling models statically makes > > > it possible > > > to run them on any other linux (including different fedora > > > version) box > > > without recompiling. So all the libraries that can be used for > > > numerical > > > computations should have static libraries kept. > > > > This seems like a non sequitur. What's special about numerical > > computations? > > I already explained it in my mail? To be more precise > > * security considerations are moot > * nss, iconv are not needed > > Other arguments for dynamic linking are not compulsory. > And numerical models are programs we would like to be able to run > on other linux box without recompiling. Imagine that compilation > takes 30 minutes and that you want to start 20 runs in paralell > from nfs mounted filesystem in an heterogeneous linux environment > with some redhat 6.2, 7.x, centos, debian, mandrake and fedora > core (real world example, of course). > > -- > Pat I have to agree with Patrice Dumas. I regularly do extensive numerical analysis and modeling using such a network, and the compilation time for the central program is VERY long, taking over 40 minutes on the fastest machine I have available. While I don't think we have anything older than RH8 in the pool of runtime machines, many of them cannot be upgraded for other reasons (I don't own them - I just get to use them when they are available, so the pool of machines changes probably every time I visit phase space), and if I had to do a compile for every different O/S+release combination I'm using, it would be a nightmare. While my run time is longer than Pat's example (a little over 4 hours using around 30 machines), if I had to recompile for each of the different variations I use, it would be prohibitively time-consuming and would be a reason to stop upgrading several machines here. I don't know whether eliminating static libraries would be a problem for other types of apps, for what I'm doing its elimination would be a disaster. While I don't see a problem with eliminating static linking of system utilities, IMHO eliminating it for user-written utilities is not a "universal benefit." -- william w. austin waustin at speakeasy.net "life is just another phase i'm going through. this time, anyway ..." From P at draigBrady.com Wed Nov 22 14:23:06 2006 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 22 Nov 2006 14:23:06 +0000 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <45645D4A.9070309@draigBrady.com> Pekka Savola wrote: > Hi, > > I'd like to reduce the memory footprint of FC6. Are there already > webpages that describe how to make Fedora more manageable on those 3-4 > year old "junk hardware"? (Some also have worried about the disk space > footprint, but let's leave that out of scope for now..) Some ideas here: http://www.redhat.com/archives/fedora-devel-list/2006-May/thread.html#00498 > I think we have a problem if FC6 can't run properly on IBM ThinkPad X30 > w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are the > amount of memory, relatively slow disks, and swapping on those > relatively slow disks. Some good optimizations will fall out of the OLPC work. Also independently people are starting to look at bloat: http://primates.ximian.com/~federico/news.html > A couple of observations: > > 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. > With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the > computer is "idle". Either ACPI is a lot worse than APM, or > something is going on. Any ideas how to debug this? When was the last time you tried 7.3? I.E. are you sure you haven't lost cell(s) in your battery in the meantime? > 2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours > (just the depsolving, upgrade and cleanup -- all packages and > headers already existed on local disk). Only yum and Xorg were > running at that time. http://www.redhat.com/archives/fedora-devel-list/2006-October/thread.html#00797 Also anaconda need loads of memory any may be swapping with 256MB RAM? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186067 > 3) are there more light-weight desktops/WMs than xfce? http://xwinman.org/ > Recently, it seems it also has become bloated, e.g.,: > > psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49 > /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...] I don't know what that is the output of exactly, but be careful with mem reporting tools on linux as they are confusing at best. Have a look at http://www.pixelbeat.org/scripts/ps_mem.py P?draig. From buildsys at redhat.com Wed Nov 22 14:31:32 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 22 Nov 2006 09:31:32 -0500 Subject: rawhide report: 20061122 changes Message-ID: <200611221431.kAMEVWlQ031911@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.1-1 ------------------- * Tue Nov 21 2006 Chris Lumens - 11.2.0.1 - Use .discinfo files to determine if a CD tree exists instead of a set limit (pjones, #214787). - Allow fixing/retrying when unable to grab a ksfile (#216446). - Fix typos (pnasrat, #216410, #215232). - Set the RAID minor number in text installs (#215231). - Be smarter about detecting if iscsi is available (katzj, #216128). - Kernel naming fix (katzj, #215746). - Activate/login/logout of all iscsi devices (pjones). - Depsolve on optional/non-grouped packages (pnasrat, #214848). - Update kickstart documentation. - Don't always write out xconfig and monitor in anaconda-ks.cfg (#211977). - Follow drive order specified in kickstart file (#214881). - Unmount source on image installs before %post is run (#214677). - Check return value of getBiosDisk (pjones, #214653). - splittree shouldn't fail with non-rpms in the directory (jkeating). - Order bind mounts correctly on upgrades (#212270). - Always skip networking on kickstart installs (#214584). - Handle ipv6= command line option (dcantrell). - Split up ipv4 and ipv6 options, add radvd support (dcantrell, #213108, - Log exceptions when activating raid (pjones). - Update install method documentation (#214159). - Netconfig UI fixes (katzj, #213356). - Avoid traceback on unused PReP partitions (#211098). - Fix no free space traceback (ddearauj AT us.ibm.com, #213616(. - Fix implantisomd5 output formatting (#214046). - Remove virt group hacks (katzj). - Default to text install if a KVM lies to us about the monitor. - Split media FTP/HTTP loopback mount install fixes (pnasrat, #212014). autoconf-2.61-2 --------------- * Tue Nov 21 2006 Karsten Hopp 2.61-2 - drop obsolete linkX11 patch * Tue Nov 21 2006 Karsten Hopp 2.61-1 - autoconf-2.61 * Thu Nov 09 2006 Karsten Hopp 2.60-4 - autoconf-2.60 automake-1.10-2 --------------- * Tue Nov 21 2006 Karsten Hopp 1.10-2 - rebuild * Fri Nov 10 2006 Karsten Hopp 1.10-1 - automake 1.10 * Wed Jul 12 2006 Jesse Keating - 1.9.6-2.1 - rebuild cpuspeed-1:1.2.1-1.43.fc7 ------------------------- * Tue Nov 21 2006 Dave Jones - Merge one more patch from Michal Jaegermann (#216816) cups-1:1.2.7-3.fc7 ------------------ * Tue Nov 21 2006 Tim Waugh 1:1.2.7-3 - Run the serial backend as root (bug #212577). curl-7.16.0-3.fc7 ----------------- * Thu Nov 16 2006 Jindrich Novy -7.16.0-3 - prevent curl from dlopen()ing missing ldap libraries so that ldap:// requests work (#215928) elinks-0.11.1-5.1 ----------------- * Tue Nov 21 2006 Karel Zak 0.11.1-5.1 - fix #215734: CVE-2006-5925 elinks smb protocol arbitrary file access fonts-indic-2.0.9-1.fc7 ----------------------- * Tue Nov 21 2006 Parag Nemade - 2.0.9-1.fc7 - Fixed Bugs from Parag Nemade - Bug 216060: [pa_IN]Lohit Punjabi: (U+0A03) Gurmukhi Sign Visarga right margin is too wide. * Tue Nov 21 2006 Parag Nemade - 2.0.8-1.fc7 - Fixed Bugs from Parag Nemade - Bug 216629 : [te_IN] GPOS position should be at middle instead of left hand side - Priority B - Bug 216631 : [or_IN] one GSUB Rule is wrongly defined - Priority A - Bug 216628 : [ml] characters are not shown bold during selecting BOLD font - Bug 216624 : [pa_IN] 0a01/0a03/0964/0965 is missing from font - Bug 216634 : Glyphs for two combinations are wrong in Gujarati (gu_IN) - Bug 197216 : [bn_IN]Incorrect glyph for conjunct - Bug 215894 : Relative height of 0x0901 (and 0x0902) on 0x0915 is different than other devnagari characters (hi_IN, mr_IN) - Fixed Bugs from LingNing Zhang - Bug 216626 : [as_IN] Pango - A particular char when Conjuncts, creates Cursor Nevigation Problem - Bug 216627 : [ml_IN] The glyph of 0x25CC is not existing in lohit_ml.ttf - Bug 216639 : [kn_IN] OTF rules to be fixed - Priority A gaim-2:2.0.0-0.22.beta5.fc7 --------------------------- * Tue Nov 21 2006 Warren Togami - 2:2.0.0-0.22.beta4 - 2.0.0 beta5 - Debian patches 02_gnthistory-in-gtk 03_gconf-gstreamer 04_blist-memleak 05_url-handler-xmpp 06_jabber-registration-srv 07_msn-custom-smiley-crash - SILC Account Edit Crash * Tue Nov 21 2006 Warren Togami - 2:2.0.0-0.21.beta4 - #212817 Jabber needs cyrus-sasl plugins for authentication gtk2-2.10.6-5.fc7 ----------------- * Tue Nov 21 2006 Matthias Clasen - 2.10.6-5 - Change the search patch to check for beagle first k3b-0:0.12.17-1 --------------- * Thu Oct 26 2006 Harald Hoyer - 0:0.12.17-1 - - new version 0.12.17 libao-0.8.6-4 ------------- * Tue Nov 21 2006 Behdad Esfahbod - 0.8.6-4 - Only export namespaced symbols. (bug 216108) liboil-0.3.10-1.fc7 ------------------- * Tue Nov 21 2006 Behdad Esfahbod - 0.3.10-1 - Update to 0.3.10 libsoup-2.2.98-1.fc7 -------------------- * Tue Nov 21 2006 Matthew Barnes - 2.2.98-1 - Update to 2.2.98 - Remove patch for RH bug #215919 (fixed upstream). lvm2-2.02.15-3.fc7 ------------------ * Tue Nov 21 2006 Alasdair Kergon - 2.02.15-3 - Fix clvmd init script line truncation. * Tue Nov 21 2006 Alasdair Kergon - 2.02.15-2 - Fix lvm.conf segfault. * Mon Nov 20 2006 Alasdair Kergon - 2.02.15-1 - New upstream - see WHATS_NEW. mod_python-3.2.10-3 ------------------- * Tue Nov 21 2006 Joe Orton 3.2.10-3 - update to 3.2.10 nspr-4.6.4-1 ------------ * Tue Nov 21 2006 Kai Engert - 4.6.4-1 - Update to 4.6.4 nss-3.11.4-1 ------------ * Tue Nov 21 2006 Kai Engert - 3.11.4-1 - Update to 3.11.4 ntp-4.2.2p4-1.fc7 ----------------- * Tue Nov 21 2006 Miroslav Lichvar 4.2.2p4-1 - update to 4.2.2p4 - fix buffer overflow in WWV Audio driver (#216309) - don't mark init script as config openoffice.org-1:2.1.0-4.2 -------------------------- * Tue Nov 21 2006 Caolan McNamara - 1:2.1.0-4.2 - Resolves: rhbz#216347 openoffice.org-2.1.0.ooo71815.bridges.x86_64.patch - Resolves: rhbz#216662 stick to a single .desktop launcher name privoxy-3.0.6-1 --------------- * Tue Nov 21 2006 Karsten Hopp 3.0.6-1 - privoxy-3.0.6 rhythmbox-0.9.6-3.fc7 --------------------- * Tue Nov 21 2006 Ray Strode - 0.9.6-3 - drop keybinding patch scim-pinyin-0.5.91-14.fc7 ------------------------- * Wed Nov 22 2006 Shawn Huang - 0.5.91-14 - Translate refined online help to Chinese (#200702). - Update some msgids in po/zh_CN.po to fix Some tooltips were not translated (#216831). * Wed Oct 11 2006 Caius Chance - 0.5.91-13.fc6 - bz#200702 - refine online help of pinyin helper. sysstat-7.0.2-3.fc7 ------------------- * Tue Nov 21 2006 Ivana Varekova - 7.0.2-3 - update NFS mount statistic patch system-config-bind-4.0.2-3.fc7 ------------------------------ * Tue Nov 21 2006 Martin Stransky - 4.0.2-3 - added a second patch for issue #216584 * Tue Nov 21 2006 Martin Stransky - 4.0.2-2 - added version patch (for #216584) * Tue Oct 17 2006 Martin Stransky - 4.0.2-1 - updated translations system-config-display-1.0.46-1.fc7 ---------------------------------- * Tue Nov 21 2006 Matthias Clasen - 1.0.46-1 - Fix mnemonic for the color depth combo on the last tab Resolves: rhbz#216391 system-config-httpd-5:1.4.2-1.fc7 --------------------------------- * Mon Nov 20 2006 Phil Knirsch 1.4.2-1.fc7 - Fixed description. system-config-keyboard-1.2.11-1.fc7 ----------------------------------- * Tue Nov 21 2006 Paul Nasrat - 1.2.11-1 - Update translations system-config-printer-0.7.39-1.fc7 ---------------------------------- * Tue Nov 21 2006 Tim Waugh 0.7.39-1 - 0.7.39: - Busy cursor while loading foomatic and PPD list (bug #215527). - Make PPD NickName selectable. - Added SMB hint label on device screen (bug #212759). system-config-users-1.2.48-1.fc7 -------------------------------- * Sat Oct 14 2006 Nils Philippsen - 1.2.48 - pick up updated translations traceroute-3:2.0.2-1.fc7 ------------------------ * Tue Nov 21 2006 Martin Bacovsky - 3:2.0.2-1.fc7 - new source - more accurate check_expired() routine. - some minor fixes. vim-2:7.0.164-2 --------------- * Tue Nov 21 2006 Karsten Hopp 7.0.164-2 - patchlevel 164 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From dimi at lattica.com Wed Nov 22 14:33:06 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 22 Nov 2006 09:33:06 -0500 (EST) Subject: FC6: some impressions In-Reply-To: <20061122114737.GB10961@devserv.devel.redhat.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> <20061122114737.GB10961@devserv.devel.redhat.com> Message-ID: <3322.207.245.37.34.1164205986.squirrel@lattica.com> On Wed, November 22, 2006 6:47 am, Alan Cox wrote: > If you have the flash plugin loaded try a bit without - if that stops the > hang try the flash 9 beta, and report problems to the flash folks as > they ask so they can get the final flash 9 stable. Thank you, I'll give that a try. >> What is the new direction for the email client? Is there one? > > Beats me. Evolution has things some people think are essential that the > others lack, but its slow and nobody seems to be fixing the real bugs > (eg the year old remote DoS I sent to bugtraq) And don't people find this in the least worrying? A good email client is no longer optional nowadays, and AFAIU RHEL5 will ship soon. They can't possibly ship Evolution in this state. Email is by far and away the most important tool in a business environment, and it's not an easy proposition to transition folks to a new one. You need something that works. If it crashes, for most people is equivalent to the entire system crashing, as they'll need to reboot the box to fix the problem. This renders the system worse than Windows 3.1. If you really want to tick people off, mess with their email. I'd be _very_ concerned right about now if I were RHEL5 product manager. -- Dimi Paun Lattica, Inc. From ddmbox2 at yahoo.co.uk Wed Nov 22 14:51:02 2006 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 22 Nov 2006 14:51:02 +0000 Subject: gnome-appliation/firefox crashed with Xfce In-Reply-To: <4563E259.1080707@redhat.com> References: <4563E259.1080707@redhat.com> Message-ID: <200611221451.03108.ddmbox2@yahoo.co.uk> On Wed November 22 2006 05:38, A S Alam wrote: > Hi > during login to Xfce environment, firefox and gnome applications are > crashing > with message as following: > ** Error ** Could not locate registry > aborting.... > Bonobo accessibility support initialized > GTK accessibility Module initialized > **(gnome_segv2:3345): CRITICAL **AT_SPI_REGISTRY was not started at > session startup. > > ** (gnome_seg3:3345): WARNING ** IOR not set. > > I have latest rawhide. Can some check th gconftool-2 -t bool -s /desktop/gnome/interface/accessibility false should get you started. search AT_SPI_REGISTRY on this or test list ...dex Send instant messages to your online friends http://uk.messenger.yahoo.com From ddmbox2 at yahoo.co.uk Wed Nov 22 14:53:08 2006 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 22 Nov 2006 14:53:08 +0000 Subject: After Rawhide update yesterday xfs crashes In-Reply-To: <4563F84A.9010209@comsoft.de> References: <4563F84A.9010209@comsoft.de> Message-ID: <200611221453.08276.ddmbox2@yahoo.co.uk> On Wed November 22 2006 07:12, Jochen Schlick wrote: > immediately. Xorg.log says something about not finding > the fixed font (which is because xfs isn't running) > > Is this a known problem ?? > > best regards > -- > ------------------------------------------------------------ > Jochen Schlick known #BZ216661 ...dex Send instant messages to your online friends http://uk.messenger.yahoo.com From gajownik at gmail.com Wed Nov 22 15:01:11 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Wed, 22 Nov 2006 16:01:11 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <45646637.5010106@gmail.com> Dnia 11/22/2006 11:08 AM, U?ytkownik Jakub Jelinek napisa?: > Hi! Ave! > So, I think it would be best if we could analyze what in FC7/FE7 > is linked statically, why, if it really needs to be linked that way > and what *.a libraries does it link in and kill all other *.a libraries Do we need static libs in gd-devel? I asked about it three weeks ago but no one answered to my question. http://www.redhat.com/archives/fedora-devel-list/2006-October/msg00908.html Regards, Dawid -- ^_* From jakub at redhat.com Wed Nov 22 15:06:03 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 10:06:03 -0500 Subject: Static linking considered harmful In-Reply-To: <45646637.5010106@gmail.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45646637.5010106@gmail.com> Message-ID: <20061122150603.GZ6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 04:01:11PM +0100, Dawid Gajownik wrote: > >So, I think it would be best if we could analyze what in FC7/FE7 > >is linked statically, why, if it really needs to be linked that way > >and what *.a libraries does it link in and kill all other *.a libraries > > Do we need static libs in gd-devel? I asked about it three weeks ago but > no one answered to my question. Almost certainly nothing needs them. Jakub From emmanuel.seyman at club-internet.fr Wed Nov 22 15:05:51 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 22 Nov 2006 16:05:51 +0100 Subject: FC6: some impressions In-Reply-To: <3322.207.245.37.34.1164205986.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> <20061122114737.GB10961@devserv.devel.redhat.com> <3322.207.245.37.34.1164205986.squirrel@lattica.com> Message-ID: <20061122150551.GA13992@orient.maison.lan> On Wed, Nov 22, 2006 at 09:33:06AM -0500, Dimi Paun wrote: > > And don't people find this in the least worrying? A good email client > is no longer optional nowadays, and AFAIU RHEL5 will ship soon. They > can't possibly ship Evolution in this state. Check out the last discussion we had on the subject. https://www.redhat.com/archives/fedora-devel-list/2006-April/msg00197.html Quick summary: People expect Evolution to be shipped with Fedora/RHEL. The fact that it doesn't work is completely irrelevant. Emmanuel From Matt_Domsch at dell.com Wed Nov 22 15:27:26 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 22 Nov 2006 09:27:26 -0600 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <20061122152726.GA28976@lists.us.dell.com> On Wed, Nov 22, 2006 at 01:36:10PM +0000, Kevin Kofler wrote: > In my experience, the biggest problem with Fedora on low-memory systems is > getting it installed. Anaconda tends to just lock up or reboot if it doesn't > have at least something like 256 MB RAM. Indeed, a network install with 128MB just doesn't work; Something called 'exe' gets hung trying to install glibc. :-( I noticed that the RAM file systems in use are actually ramfs, not tmpfs, so even after swap is enabled, swap can't be used as backing store for the files we're downloading, some of which are quite large. Doing a local CD-ROM install did succeed on this same system, which leads me to think that the ramfs->tmpfs switch might be beneficial for exactly this reason. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dimi at lattica.com Wed Nov 22 15:29:02 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 22 Nov 2006 10:29:02 -0500 (EST) Subject: FC6: some impressions In-Reply-To: <20061122150551.GA13992@orient.maison.lan> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> <20061122114737.GB10961@devserv.devel.redhat.com> <3322.207.245.37.34.1164205986.squirrel@lattica.com> <20061122150551.GA13992@orient.maison.lan> Message-ID: <3528.207.245.37.34.1164209342.squirrel@lattica.com> On Wed, November 22, 2006 10:05 am, Emmanuel Seyman wrote: > Check out the last discussion we had on the subject. > https://www.redhat.com/archives/fedora-devel-list/2006-April/msg00197.html I know, I was part of that discussion :) > Quick summary: People expect Evolution to be shipped with Fedora/RHEL. > The fact that it doesn't work is completely irrelevant. Well yes, people expect it to be there because it's hard to switch email clients. It's certainly not a trivial undertaking, and it would be a major problem in any conceivable corporate environment. I'd go as far as to say it's simply a showstopper for desktop OS. Now thing is that Evo in FC6 is orders of magnitude worse than in FC5! I mean, the bugs that were listed in the discussion you pointed at seem trivial in comparison. Right now it's not a matter that it's slow, or can't be used over slow links. No. Now it simply hangs while sending (or sometimes receiving mail), and the only viable option for a regular user is to restart X or reboot! What good is an email client that can't send mail?!? -- Dimi Paun Lattica, Inc. From jreiser at BitWagon.com Wed Nov 22 15:33:37 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 07:33:37 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <45646DD1.3040409@BitWagon.com> > E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, > libboost*.a, all GUI libs that have also *.so libs, etc. libstdc++.a must stay in Fedora Core. libstdc++ is not compatible AT ALL across versions, and there are _many_. g++ has not learned or implemented a stable ABI (application binary interface); the "name mangling" to encode types is not even stable yet. In fact, the best advice is that libstdc++ MUST be linked static for any "portable" program. The mechnanism for doing so isn't obvious; '-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic' is not sufficient. Instead use: ln -s `g++ --print-file-name=libstdc++.a` . g++ -m386 -L. file.cpp rm libstdc++.a See http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/a0859ce6cfebb9f5/ba5e8db73b87e97f?lnk=st&q=libstdc%2B%2B+group%3A*linux*+author%3APaul+author%3APluzhnikov+%22you%27d+think+that%22&rnum=1#ba5e8db73b87e97f Even libgcc_s has a couple more years before it can be considered stable. -- From jakub at redhat.com Wed Nov 22 15:51:24 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 10:51:24 -0500 Subject: Static linking considered harmful In-Reply-To: <45646DD1.3040409@BitWagon.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45646DD1.3040409@BitWagon.com> Message-ID: <20061122155124.GA6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 07:33:37AM -0800, John Reiser wrote: > > E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, > > libboost*.a, all GUI libs that have also *.so libs, etc. > > libstdc++.a must stay in Fedora Core. libstdc++ is not compatible AT ALL > across versions, and there are _many_. g++ has not learned or implemented > a stable ABI (application binary interface); the "name mangling" to encode > types is not even stable yet. That's simply not true. libstdc++ is backwards ABI compatible (similarly to glibc etc.) between 3.4.x/4.0.x/4.1.x/4.2.x and I don't think that will change in 4.3.x either. In FC we include older libstdc++'s (2.96-RH, 3.2.x/3.3.x (those 2 were also backwards ABI compatible)) too, so unless you use very old gcc, you should be just fine if you link dynamically. > Even libgcc_s has a couple more years before it can be considered stable. Care to share the details? libgcc_s is symbol versioned and is backwards compatible. In FC we try to backport libgcc_s additions even from newer gcc's than the one shipped, so e.g. current GCC 4.1.x-RH libgcc_s has even all of GCC_4.2.0 stuff in it (and will add GCC_4.3.0 stuff soon). Jakub From dennis at ausil.us Wed Nov 22 15:54:52 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Nov 2006 09:54:52 -0600 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <200611220954.52939.dennis@ausil.us> Once upon a time Wednesday 22 November 2006 4:08 am, Jakub Jelinek wrote: > Hi! > > We should more proactively discourage static linking in FC7+, for > reasons for that see > http://people.redhat.com/drepper/no_static_linking.html The Fedora Packaging guidelines for quite some time have actively been discouraging static linking. Very few applications have gotten though with static libraries. We have also push to have upstream make shared libraries if they do not see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 as an example. yes Red Hat is upstream so its all the more reason to do the right thing. But this is definetly something that has been on its way for awhile now. I give a big +1 lets make it happen. Dennis From dominik at greysector.net Wed Nov 22 16:04:17 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 22 Nov 2006 17:04:17 +0100 Subject: Static linking considered harmful In-Reply-To: <200611220954.52939.dennis@ausil.us> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <200611220954.52939.dennis@ausil.us> Message-ID: <20061122160417.GA19613@rathann.pekin.waw.pl> On Wednesday, 22 November 2006 at 16:54, Dennis Gilmore wrote: > Once upon a time Wednesday 22 November 2006 4:08 am, Jakub Jelinek wrote: > > Hi! > > > > We should more proactively discourage static linking in FC7+, for > > reasons for that see > > http://people.redhat.com/drepper/no_static_linking.html > The Fedora Packaging guidelines for quite some time have actively been > discouraging static linking. Very few applications have gotten though with > static libraries. We have also push to have upstream make shared > libraries if they do not see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 as an example. > yes Red Hat is upstream so its all the more reason to do the right thing. > But this is definetly something that has been on its way for awhile now. > > I give a big +1 lets make it happen. What's wrong with providing some -static subpackages for those who need them? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jreiser at BitWagon.com Wed Nov 22 16:05:21 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 08:05:21 -0800 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <45647541.1010101@BitWagon.com> > In my experience, the biggest problem with Fedora on low-memory systems is > getting it installed. The RULE Project (Run Up2date Linux Everywhere) has an installer "slinky" http://www.fzk.at/SLINKY/ that can install Fedora Core 5 in 32MB RAM. I did it in 64MB on a PentiumMMX-166 in about 3.5 hours. Starting OpenOffice took two minutes, but typing and mousing was fine. On a network, then a "reverse NFS install" can be used. Boot the target machine using a rescue CD or DVD, partition+format+mount the disk, start NFS and export the target root filesystem. From another machine on the network, run rpm using "--dbpath DIRECTORY" and "--root DIRECTORY" to re-direct those places to the target machine. You might also need to use --ignorearch. After installing kernel, glibc, grub, and yum (use "--aid" to fill in the dependencies), then you'll have enough to boot the target machine by itself, and finish installation using yum and system-config-*. -- From jreiser at BitWagon.com Wed Nov 22 16:08:32 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 08:08:32 -0800 Subject: Reducing Fedora memory footprint? In-Reply-To: <20061122152726.GA28976@lists.us.dell.com> References: <20061122152726.GA28976@lists.us.dell.com> Message-ID: <45647600.6020501@BitWagon.com> Matt Domsch wrote: > Indeed, a network install with 128MB just doesn't work; Something > called 'exe' gets hung trying to install glibc. :-( > > I noticed that the RAM file systems in use are actually ramfs, not > tmpfs, so even after swap is enabled, swap can't be used as backing > store for the files we're downloading, some of which are quite large. Doesn't the installer's "stage2" filesystem get put into "swap space" on low-memory machines during a network install? > > Doing a local CD-ROM install did succeed on this same system, which > leads me to think that the ramfs->tmpfs switch might be beneficial for > exactly this reason. -- From alan at redhat.com Wed Nov 22 16:10:11 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Nov 2006 11:10:11 -0500 Subject: Static linking considered harmful In-Reply-To: <200611220954.52939.dennis@ausil.us> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <200611220954.52939.dennis@ausil.us> Message-ID: <20061122161011.GA26250@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 09:54:52AM -0600, Dennis Gilmore wrote: > But this is definetly something that has been on its way for awhile now. > I give a big +1 lets make it happen. Forcing people not to static link is just crude and inappropriate. Its all a bit "you will upgrade to vista or else" and hardly IMHO in keeping with the free software spirit. Far simpler, cleaner and more friendly will be to dump the static libraries into libfoo-devel-static packages which are not in the default install. That ensures people who need to can do static links and the default behaviour is that they are not there. The -static packages could even get dropped off the CD easily enough once the mechanisms for handling one srpm spitting out binary components for extras and core are sorted From pekkas at netcore.fi Wed Nov 22 16:10:40 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 22 Nov 2006 18:10:40 +0200 (EET) Subject: Reducing Fedora memory footprint? In-Reply-To: <45645D4A.9070309@draigBrady.com> References: <45645D4A.9070309@draigBrady.com> Message-ID: On Wed, 22 Nov 2006, P?draig Brady wrote: >> I'd like to reduce the memory footprint of FC6. Are there already >> webpages that describe how to make Fedora more manageable on those 3-4 >> year old "junk hardware"? (Some also have worried about the disk space >> footprint, but let's leave that out of scope for now..) > > Some ideas here: > http://www.redhat.com/archives/fedora-devel-list/2006-May/thread.html#00498 Thanks. >> A couple of observations: >> >> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. >> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the >> computer is "idle". Either ACPI is a lot worse than APM, or >> something is going on. Any ideas how to debug this? > > When was the last time you tried 7.3? I.E. are you sure > you haven't lost cell(s) in your battery in the meantime? About a year ago, a bit more. Given that the laptop is ~4 years old now, such a dramatic drop IMHO cannot be explained by battery aging alone. However, the proc says: # more /proc/acpi/battery/BAT0/info present: yes design capacity: 47520 mWh last full capacity: 18260 mWh ... The ratio of "last full" and "design" is similar to the 1.5h/4.0h lifetime I'm now seeing. Unfortunately, I don't know what the numbers might have been with RHL73, and whether ACPI/APM has any effect here. >> 2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours >> (just the depsolving, upgrade and cleanup -- all packages and >> headers already existed on local disk). Only yum and Xorg were >> running at that time. > > http://www.redhat.com/archives/fedora-devel-list/2006-October/thread.html#00797 > Also anaconda need loads of memory any may be swapping with 256MB RAM? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186067 Interesting -- but in my case, I wasn't running anaconda. I did 'yum upgrade' from command line. In case a rough breakdown of time spent in each step would be useful, depsolving took a while, but only in the order of dozens of minutes. Running transaction check took something around 30-60 minutes. The first stage of running transaction for real (i.e., before any progress bards appeared) took a very long time, maybe 1-2 hours. The upgrade itself took maybe 3 hours. The cleanup took maybe 2-3 hours. >> 3) are there more light-weight desktops/WMs than xfce? > > http://xwinman.org/ Unfortunately, that doesn't answer the question of 'more light-weight' as I fear that xfce is the most lightweight of the desktop bunch at least... >> Recently, it seems it also has become bloated, e.g.,: >> >> psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49 >> /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...] > > I don't know what that is the output of exactly, but be careful > with mem reporting tools on linux as they are confusing at best. > Have a look at http://www.pixelbeat.org/scripts/ps_mem.py That shows total memory usage of 197 MB (including firefox taking 82MB), though top reports that 100+ MB of swap is being used: Mem: 246632k total, 240024k used, 6608k free, 3096k buffers Swap: 521632k total, 106408k used, 415224k free, 37504k cached Not sure which is more accurate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Dax at gurulabs.com Wed Nov 22 16:21:07 2006 From: Dax at gurulabs.com (Dax Kelson) Date: Wed, 22 Nov 2006 9:21:07 -0700 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <3768-SnapperMsg827D11E1C18A2981@[68.26.52.229]> ...... Original Message ....... On Wed, 22 Nov 2006 15:23:21 +0200 (EET) "Pekka Savola" wrote: >Hi, > >I'd like to reduce the memory footprint of FC6. Are there already >webpages that describe how to make Fedora more manageable on those 3-4 >year old "junk hardware"? (Some also have worried about the disk >space footprint, but let's leave that out of scope for now..) > >I think we have a problem if FC6 can't run properly on IBM ThinkPad >X30 w/ P3/1200 and 256 MB of memory. I agree. The Playstion 3 only has 256MB of memory too. Once I'm eventually able to locate one to buy (not Ebay), I plan on getting FC6/Rawhide running on it. ___ Dax Kelson Sent with my Treo (please pardon any brevity) From buc at odusz.so-cdu.ru Wed Nov 22 16:24:15 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 22 Nov 2006 19:24:15 +0300 Subject: Static linking considered harmful In-Reply-To: <20061122161011.GA26250@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <200611220954.52939.dennis@ausil.us> <20061122161011.GA26250@devserv.devel.redhat.com> Message-ID: <456479AF.10000@odu.neva.ru> Alan Cox wrote: >Far simpler, cleaner and more friendly will be to dump the static libraries >into libfoo-devel-static packages which are not in the default install. That >ensures people who need to can do static links and the default behaviour is >that they are not there. The -static packages could even get dropped off the >CD easily enough once the mechanisms for handling one srpm spitting out >binary components for extras and core are sorted > > BTW, such a "-static" subpackages might be handled the same way as "-debuginfo". Consider some example of needed rpm macros (attached below), written one year ago when similar topic was discussed at fedore-extras-devel list. Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: macros-staticlibs URL: From tonynelson at georgeanelson.com Wed Nov 22 16:36:17 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 22 Nov 2006 11:36:17 -0500 Subject: Static linking considered harmful In-Reply-To: <1164191654.31358.728.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> Message-ID: At 11:34 AM +0100 11/22/06, Arjan van de Ven wrote: >On Wed, 2006-11-22 at 11:24 +0100, Patrice Dumas wrote: >> On Wed, Nov 22, 2006 at 05:08:00AM -0500, Jakub Jelinek wrote: >> > Hi! >> > >> > We should more proactively discourage static linking in FC7+, for >> > reasons for that see >> > http://people.redhat.com/drepper/no_static_linking.html >> > >> > Removing libc.a would be most effective, but I'm afraid we still need >> > a handful of statically linked binaries for boot time initialization and >> > system recovery utilities. >> >> Not only. There are cases when all those issues are moot, a prominent one >> being for numerical models. Compiling models statically makes it possible >> to run them on any other linux (including different fedora version) box >> without recompiling > >actually static linking DECREASES that portability !! Users of numerical models often want bit-reproducable results. It's not necessarily stupid, as if the results are identical no further comparison is needed, while if the results are merely "close", much thought must go into deciding whether they are close enough. Using different version math libraries makes identical results less likely, and makes more work for the model's users. They would probably switch to a more useful distro, and good riddance to them! Thbpt! -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From tonynelson at georgeanelson.com Wed Nov 22 16:35:53 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 22 Nov 2006 11:35:53 -0500 Subject: Reducing Fedora memory footprint? In-Reply-To: <45645D4A.9070309@draigBrady.com> References: <45645D4A.9070309@draigBrady.com> Message-ID: At 2:23 PM +0000 11/22/06, P?draig Brady wrote: >Pekka Savola wrote: ... >> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. >> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the >> computer is "idle". Either ACPI is a lot worse than APM, or >> something is going on. Any ideas how to debug this? > >When was the last time you tried 7.3? I.E. are you sure >you haven't lost cell(s) in your battery in the meantime? ... Also, back in 7.3 time the kernel probably had HZ=100, and now it is usually 250 or 1000. Slow laptops may not get back to sleep at all between ticks. The kernel can be recompiled for 100 Hz to give better battery life. (AIUI a recompile is needed, I haven't done any such thing.) -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From david at fubar.dk Wed Nov 22 16:38:22 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 22 Nov 2006 11:38:22 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <1164213502.2562.12.camel@daxter.boston.redhat.com> On Wed, 2006-11-22 at 05:08 -0500, Jakub Jelinek wrote: > Removing libc.a would be most effective, Yes, please consider doing that, it sounds pretty effective. > but I'm afraid we still need > a handful of statically linked binaries for boot time initialization and > system recovery utilities. I think it would be nice to avoid even that, it takes up lots of disk space, see [1] which makes Fedora somewhat less appealing for embedded use - such as OLPC where there probably is still a few statically linked binaries that are completely useless on such a system. Note that SUSE just includes the glibc and other required DSO's in the initramfs; I did the same for my livecd stuff (that has a rather complicated initramfs to setup dm-snapshot for rw rootfs) and it works very nicely. So it's definitely possibly but I'd expect some resistance from certain package maintainers :-) David [1] : this is just _some_ of the statically linked binaries on my system $ du -c -h `find /sbin/ -iname "*.static"` 780K /sbin/kpartx.static 4.0K /sbin/restore.static 4.0K /sbin/rrestore.static 4.0K /sbin/dump.static 840K /sbin/dmsetup.static 4.0K /sbin/rdump.static 792K /sbin/udevd.static 460K /sbin/insmod.static 744K /sbin/mdadm.static 1.6M /sbin/lvm.static 964K /sbin/dmraid.static 620K /sbin/mdassemble.static 6.7M total From galibert at pobox.com Wed Nov 22 17:08:49 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 18:08:49 +0100 Subject: Static linking considered harmful In-Reply-To: <1164191654.31358.728.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> Message-ID: <20061122170849.GA37274@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > actually static linking DECREASES that portability !! On which planet ? galibert at m71.limsi.fr:~/git/mmconfig #2 >git grep acpi_table_mcfg_config git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory galibert at m71.limsi.fr:~/git/mmconfig #3 >cat /etc/redhat-release Fedora Core release 5 (Bordeaux) T'was compiled on a 32bits fc3, shared, and I tried to use it on a x86-64 fc5. It is *extremely* hard to be sure that you have all the compatilibity libraries for the previous versions of fc. Missing shared libs is the #1 portability problem in heterogenous environments. Glibc "I hate static linking" shenanigans are a far away second. OG. From jakub at redhat.com Wed Nov 22 17:10:55 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 12:10:55 -0500 Subject: Static linking considered harmful In-Reply-To: References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> Message-ID: <20061122171055.GC6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 11:36:17AM -0500, Tony Nelson wrote: > Users of numerical models often want bit-reproducable results. It's not > necessarily stupid, as if the results are identical no further comparison > is needed, while if the results are merely "close", much thought must go > into deciding whether they are close enough. For bit-reproduceable results you want the same CPUs too, some parts of libm check hwcaps and adjust based on that. Anyway, this kind of use is quite rare, as opposed to thousands of people out there who just have a warm fuzzy feeling that their programs are portable when they link statically without understanding all the issues involved. If you want bit-reproduceable results, you can equally well just stick the shared libraries you need into the same directory as the program and run it as ./ld-linux*.so.2 --library-path . ./the_numerical_program arguments it will cost you just a few extra lines in the Makefile, IMHO not a big deal. Jakub From buc at odusz.so-cdu.ru Wed Nov 22 17:21:07 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 22 Nov 2006 20:21:07 +0300 Subject: Static linking considered harmful In-Reply-To: <20061122171055.GC6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> Message-ID: <45648703.20605@odu.neva.ru> Jakub Jelinek wrote: >you can equally well >just stick the shared libraries you need into the same directory as the >program and run it as >./ld-linux*.so.2 --library-path . ./the_numerical_program arguments > > Maybe create some script, f.e. "/bin/export-binary", which will create a tarball with all needed dso included, the properly file pathes and perhaps some wrappers? ~buc From steve at silug.org Wed Nov 22 17:23:42 2006 From: steve at silug.org (Steven Pritchard) Date: Wed, 22 Nov 2006 11:23:42 -0600 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> Message-ID: <20061122172342.GA23688@osiris.silug.org> On Tue, Nov 21, 2006 at 09:43:17AM +0200, Panu Matilainen wrote: > On Tue, 21 Nov 2006, seth vidal wrote: > >To me it seems like a valid client connection should not be able to > >corrupt a database simply by open-read-closing no matter how many times. > >And if it can then clearly there is something wrong with the database > >code. > > Well, obviously. I think that's exactly what Steven means... Personal > experience with both subversion repos using Berkeley DB storage and rpmdb > has made me too expect nothing else but eventual corruption from BDB :-/ That's been my experience as well. For example, every system that I have running openldap eventually corrupts the database (usually in 2-3 months of continuous use). This is on servers that run for months (sometimes years) at a time without a reboot. Luckily slapd_db_recover and slapindex has fixed the problem every time so far, which is why I'd *really* like it if "service ldap restart" would run both. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199322 Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From jreiser at BitWagon.com Wed Nov 22 17:35:27 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 09:35:27 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122155124.GA6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45646DD1.3040409@BitWagon.com> <20061122155124.GA6570@devserv.devel.redhat.com> Message-ID: <45648A5F.1010302@BitWagon.com> Jakub Jelinek wrote: >> On Wed, Nov 22, 2006 at 07:33:37AM -0800, John Reiser wrote: >> > >>>>>>E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a, >>>>>>libboost*.a, all GUI libs that have also *.so libs, etc. >> >>>> >>>>libstdc++.a must stay in Fedora Core. libstdc++ is not compatible AT ALL >>>>across versions, and there are _many_. g++ has not learned or implemented >>>>a stable ABI (application binary interface); the "name mangling" to encode >>>>types is not even stable yet. > >> >> >> That's simply not true. libstdc++ is backwards ABI compatible (similarly to >> glibc etc.) between 3.4.x/4.0.x/4.1.x/4.2.x and I don't think that will >> change in 4.3.x either. It is true. Dynamic linking to libstdc++.so is a recipe for disaster in a program that intends to be portable, because there have been bugs in the backwards compatibility, and there is no intention of forwards compatibility. Even some pieces of 'new' and 'delete' do not work across different g++/libstdc++ versions because the name mangling changed. This is particularly true for programs that [attempt to] support dynamically-loaded runtime plugin modules. In practice this almost certainly fails if the plugin uses a different version of g++/libstdc++ than the base program, because simultaneous use of two (or more!) different versions of libstdc++ by the same process breaks. Each of the various libstdc++.so thinks that it is the only one, and so does not coordinate with the others. Speaking of glibc, even that has had compatibility problems. For instance, in history the character classification and translation facilities islower, isupper, tolower, toupper have had incompatible usage of external symbols with "ctype" in the name. For example, see this thread: http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/3cb7d8fbf9d82d7b/7e0fb89e71747406?lnk=st&q=ctype+group%3Acomp.os.linux.development.apps&rnum=3#7e0fb89e71747406 Also, there have been libc.so compatibility bugs with symbol visibility of the high precision timers used by ld-linux to measure its own performance. >>In FC we include older libstdc++'s (2.96-RH, >> 3.2.x/3.3.x (those 2 were also backwards ABI compatible)) too, so unless >> you use very old gcc, you should be just fine if you link dynamically. >> >> > >>>>Even libgcc_s has a couple more years before it can be considered stable. > >> >> >> Care to share the details? libgcc_s is symbol versioned and is backwards >> compatible. In FC we try to backport libgcc_s additions even from newer >> gcc's than the one shipped, so e.g. current GCC 4.1.x-RH libgcc_s >> has even all of GCC_4.2.0 stuff in it (and will add GCC_4.3.0 stuff soon). The unwinding code for DWARF2 is not compatible between libgcc_s 3.2.x and libgcc_s 4.y. The bugs are different, so user code that calls the unwinders, and insists on working despite the bugs, must adapt according to which version is being used. True binary compatibility sometimes means bug-for-bug compatibility, because sometimes the runtime language support has not caught up to the user code. -- From Lam at Lam.pl Wed Nov 22 17:38:13 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 22 Nov 2006 18:38:13 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122171055.GC6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> Message-ID: <1164217093.3276.12.camel@pensja.lam.pl> Dnia 22-11-2006, ?ro o godzinie 12:10 -0500, Jakub Jelinek napisa?(a): > If you want bit-reproduceable results, you can equally well > just stick the shared libraries you need into the same directory as the > program This way you still don't upgrade a library to the bug-free version if you don't remember about that. You save compiling time, true. But you still have to remember, which library has to be copied (instead of linked in). I thought the main point of the discussion was the security issues raising when someone forgets to relink some program. > and run it as > ./ld-linux*.so.2 --library-path . ./the_numerical_program arguments This leads to users having LD_LIBRARY_PATH set to ".", which is a huge security risk by itself (and many times greater than staticly linked programs, IMO). Don't tell me users will use your hard to remember and type line - there'll be tens of howtos suggesting LD_LIBRARY_PATH=. everywhere in the Internet if you do that. I'm for making -devel-static packages and sticking with the policy of discouraging, not disallowing compiling programs as static. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From tonynelson at georgeanelson.com Wed Nov 22 17:49:26 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 22 Nov 2006 12:49:26 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: Message-ID: At 9:42 PM -0500 11/19/06, Tony Nelson wrote: >The RPM database should be verified more often than it is now. ... I have written a utility, rpm_verify_db, to automatically verify and repair the RPM database, via a daily cron job. Reports of errors are syslog'd, emailed to root, and shown by logwatch. It could be incorporated into the RPM package, or even Yum. It can be found at . I will be away for a few days, starting tomorrow, US Thanksgiving holiday. When I return I buzilla an RFE for it. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From jreiser at BitWagon.com Wed Nov 22 17:54:43 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 09:54:43 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <45648EE3.9070703@BitWagon.com> > Removing libc.a would be most effective ... Where will the *stat() functions go? The functions that translate the C API into the glibc ABI by adding an additional leading parameter to specify which "struct stat" is to be used for returning the result, and also add an 'x' and some underscores into the global name. -- From pbrobinson at gmail.com Wed Nov 22 18:01:14 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 22 Nov 2006 18:01:14 +0000 Subject: FC6: some impressions In-Reply-To: <3528.207.245.37.34.1164209342.squirrel@lattica.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> <20061122114737.GB10961@devserv.devel.redhat.com> <3322.207.245.37.34.1164205986.squirrel@lattica.com> <20061122150551.GA13992@orient.maison.lan> <3528.207.245.37.34.1164209342.squirrel@lattica.com> Message-ID: <5256d0b0611221001y4f1a690aua013e0474e25661a@mail.gmail.com> > Well yes, people expect it to be there because it's hard to switch > email clients. It's certainly not a trivial undertaking, and it would > be a major problem in any conceivable corporate environment. > I'd go as far as to say it's simply a showstopper for desktop OS. > > Now thing is that Evo in FC6 is orders of magnitude worse than in FC5! > I mean, the bugs that were listed in the discussion you pointed at > seem trivial in comparison. Right now it's not a matter that it's > slow, or can't be used over slow links. No. Now it simply hangs while > sending (or sometimes receiving mail), and the only viable option > for a regular user is to restart X or reboot! > > What good is an email client that can't send mail?!? I don't know that I agree with that necessarily. For what I use EVO for on a day to day basis (connecting to an Exchange 2003 server which can't be done using any other OSS client) Evo have improved considerably in FC6. It at least doesn't crash a couple of times a day when looking up email contacts. It definately isn't at the level I would like stability wise and I wish the developers were a bit more open and spent more time fixing bugs rather than adding things like cairo eye candy but at least I'm not at the stage where I was in FC5 where I'm downloading the developement src rpms and compiling them agaist FC5 to get something close to stable. I really wish they would start to merge some of the dbus port that has been done that seems to include a lot of nice memory improvements and stability improvements etc. I also thought that redhat was looking to hire a full time evo hacker to help get on top of some of it (they may well have). In general I like the feature set of evo I just wish that some of the long standing issues could be cleared up. The merge of the dbus branch would be a good start at least then there would be more developers working on the core branch rather than a fork of the project. Peter From pertusus at free.fr Wed Nov 22 18:16:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 19:16:12 +0100 Subject: Static linking considered harmful In-Reply-To: <1164213502.2562.12.camel@daxter.boston.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <1164213502.2562.12.camel@daxter.boston.redhat.com> Message-ID: <20061122181612.GB2863@free.fr> On Wed, Nov 22, 2006 at 11:38:22AM -0500, David Zeuthen wrote: > > I think it would be nice to avoid even that, it takes up lots of disk > space, see [1] which makes Fedora somewhat less appealing for embedded > use - such as OLPC where there probably is still a few statically linked > binaries that are completely useless on such a system. Statically linked binaries shipped in fedora is a completly different subject than allowing apps not in fedora to be linked statically against static libraries provided in fedora. Removing statically binaries makes sense, just as having dynamic libraries for each packages, but it is a very different issue, still in that case it makes sense to ship static libraries for those who want to build statically programs which are not meant to be shipped in fedora. -- Pat From jreiser at BitWagon.com Wed Nov 22 18:38:01 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 10:38:01 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122171055.GC6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> Message-ID: <45649909.3030108@BitWagon.com> Jakub Jelinek wrote: > If you want bit-reproduceable results, you can equally well > just stick the shared libraries you need into the same directory as the > program and run it as > ./ld-linux*.so.2 --library-path . ./the_numerical_program arguments > it will cost you just a few extra lines in the Makefile, IMHO not a big > deal. Yes, the primary outputs will be the same. But the total user interface will be different. The process name (revealed by ps, top, etc.) will be ld-linux*.so.2 instead of the_numerical_program. So existing scripts that monitor (or get out of the way of) the_numerical_program won't find it; killall won't work; oprofile will group all such programs together as ld-linux instead of as separate numerical programs, etc. This "other stuff" is important to users and administrators. -- From tmraz at redhat.com Wed Nov 22 18:59:15 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 22 Nov 2006 19:59:15 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122170849.GA37274@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122170849.GA37274@dspnet.fr.eu.org> Message-ID: <1164221955.6436.6.camel@perun.kabelta.loc> On Wed, 2006-11-22 at 18:08 +0100, Olivier Galibert wrote: > On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > > actually static linking DECREASES that portability !! > > On which planet ? > > galibert at m71.limsi.fr:~/git/mmconfig #2 >git grep acpi_table_mcfg_config > git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory > galibert at m71.limsi.fr:~/git/mmconfig #3 >cat /etc/redhat-release > Fedora Core release 5 (Bordeaux) > > T'was compiled on a 32bits fc3, shared, and I tried to use it on a > x86-64 fc5. It is *extremely* hard to be sure that you have all the > compatilibity libraries for the previous versions of fc. yum install openssl097a ? But I agree that in other cases it is not always as easy as this one. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From galibert at pobox.com Wed Nov 22 19:10:50 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 20:10:50 +0100 Subject: Static linking considered harmful In-Reply-To: <1164221955.6436.6.camel@perun.kabelta.loc> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122170849.GA37274@dspnet.fr.eu.org> <1164221955.6436.6.camel@perun.kabelta.loc> Message-ID: <20061122191050.GA54373@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 07:59:15PM +0100, Tomas Mraz wrote: > On Wed, 2006-11-22 at 18:08 +0100, Olivier Galibert wrote: > > On Wed, Nov 22, 2006 at 11:34:14AM +0100, Arjan van de Ven wrote: > > > actually static linking DECREASES that portability !! > > > > On which planet ? > > > > galibert at m71.limsi.fr:~/git/mmconfig #2 >git grep acpi_table_mcfg_config > > git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory > > galibert at m71.limsi.fr:~/git/mmconfig #3 >cat /etc/redhat-release > > Fedora Core release 5 (Bordeaux) > > > > T'was compiled on a 32bits fc3, shared, and I tried to use it on a > > x86-64 fc5. It is *extremely* hard to be sure that you have all the > > compatilibity libraries for the previous versions of fc. > > yum install openssl097a ? For which the i386 version is not in core for x86-64, explaining why I'm missing it (I do everything installs systematically, disk is cheaper than time). > But I agree that in other cases it is not always as easy as this one. Especially since you don't know something is missing until some application blows up when you try it. OG. From bkoz at redhat.com Wed Nov 22 19:14:32 2006 From: bkoz at redhat.com (Benjamin Kosnik) Date: Wed, 22 Nov 2006 20:14:32 +0100 Subject: Static linking considered harmful Message-ID: <20061122201432.113132b8.bkoz@redhat.com> (sorry about the messed up references: field. Jakub just pointed me at this discussion and I realized that I was dropped/not-readded from this list.) > Far simpler, cleaner and more friendly will be to dump the static > libraries into libfoo-devel-static packages which are not in the > default install. That ensures people who need to can do static links > and the default behaviour is that they are not there. The -static > packages could even get dropped off the CD easily enough once the > mechanisms for handling one srpm spitting out binary components for > extras and core are sorted yay! I'm glad somebody suggested this. This is my preference as well. I think it provides a better transition plan then the ignominious beheading of all *.a's. -benjamin From david at fubar.dk Wed Nov 22 19:14:27 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 22 Nov 2006 14:14:27 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122181612.GB2863@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <1164213502.2562.12.camel@daxter.boston.redhat.com> <20061122181612.GB2863@free.fr> Message-ID: <1164222867.2562.19.camel@daxter.boston.redhat.com> On Wed, 2006-11-22 at 19:16 +0100, Patrice Dumas wrote: > Removing statically binaries makes > sense, just as having dynamic libraries for each packages, but it is > a very different issue, still in that case it makes sense to ship static > libraries for those who want to build statically programs which are not > meant to be shipped in fedora. Certainly, we shouldn't remove that freedom - I just don't want to see statically linked binaries in a default install. David From jakub at redhat.com Wed Nov 22 19:16:29 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 14:16:29 -0500 Subject: Static linking considered harmful In-Reply-To: <456484AB.30103@BitWagon.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45646DD1.3040409@BitWagon.com> <20061122155124.GA6570@devserv.devel.redhat.com> <456484AB.30103@BitWagon.com> Message-ID: <20061122191629.GE6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 09:11:07AM -0800, John Reiser wrote: > It is true. Dynamic linking to libstdc++.so is a recipe for disaster in > a program that intends to be portable, because there have been bugs in the > backwards compatibility, and there is no intention of forwards compatibility. > Even some pieces of 'new' and 'delete' do not work across different > g++/libstdc++ versions because the name mangling changed. This is > particularly true for programs that [attempt to] support dynamically-loaded > runtime plugin modules. In practice this almost certainly fails if the plugin > uses a different version of g++/libstdc++ than the base program, because > simultaneous use of two (or more!) different versions of libstdc++ > by the same process breaks. Each of the various libstdc++.so thinks > that it is the only one, and so does not coordinate with the others. Plugins are a separate issue, by definition those are dynamically linked and -Bstatic -lstdc++ -Bdynamic plus symver script to hide the stuff isn't the right answer. One of the reasons is that e.g. libstdc++.a isn't -fpic, so linking it into a plugin is highly undesirable if at all possible. For plugins the simplest answer is "don't write plugins in C++ unless it is a plugin for a C++ project where everything already uses some one libstdc++", or libstdc++so7's versioned namespaces. > Speaking of glibc, even that has had compatibility problems. > For instance, in history the character classification and translation > facilities islower, isupper, tolower, toupper have had incompatible usage > of external symbols with "ctype" in the name. For example, see this thread: > http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/3cb7d8fbf9d82d7b/7e0fb89e71747406?lnk=st&q=ctype+group%3Acomp.os.linux.development.apps&rnum=3#7e0fb89e71747406 > Also, there have been libc.so compatibility bugs with symbol visibility of the > high precision timers used by ld-linux to measure its own performance. ctype wasn't in any way a compatibility problem. glibc is even in that regard backwards compatible (though not forwards, as with dozens of other symbols) and never guarantees ABI compatibility if you compile against one glibc and link against a different one - only binaries and shared libraries can count on backwards compatibility. > > Care to share the details? libgcc_s is symbol versioned and is backwards > > compatible. In FC we try to backport libgcc_s additions even from newer > > gcc's than the one shipped, so e.g. current GCC 4.1.x-RH libgcc_s > > has even all of GCC_4.2.0 stuff in it (and will add GCC_4.3.0 stuff soon). > > The unwinding code for DWARF2 is not compatible between libgcc_s 3.2.x > and libgcc_s 4.y. The bugs are different, so user code that calls the > unwinders, and insists on working despite the bugs, must adapt according > to which version is being used. True binary compatibility sometimes > means bug-for-bug compatibility, because sometimes the runtime language > support has not caught up to the user code. I'd argue that apps shouldn't work around unwinder bugs, instead they should be simply reported and the vendors should fix them. Certainly that's far better than e.g. having two or more unwinders within one process. Jakub From kevin.kofler at chello.at Wed Nov 22 19:17:57 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Nov 2006 19:17:57 +0000 (UTC) Subject: Reducing Fedora memory footprint? References: <45647541.1010101@BitWagon.com> Message-ID: John Reiser BitWagon.com> writes: > The RULE Project (Run Up2date Linux Everywhere) has an installer "slinky" > http://www.fzk.at/SLINKY/ that can install Fedora Core 5 in 32MB RAM. > I did it in 64MB on a PentiumMMX-166 in about 3.5 hours. Starting OpenOffice > took two minutes, but typing and mousing was fine. That's probably the best solution for fresh installs. For upgrades, apt-get dist-upgrade will get you through. I guess yum or smart will also work. That's also the way to get FC6 until Slinky is updated for it. For my laptop (160 MB RAM), what I did was: * install FC2 (back when it was current), an almost minimal install (essentially minimal+KDE) over HTTP worked * upgrade to FC5 using Anaconda when that was current - not a nice experience, Anaconda just hung when reading in the metadata for the second ISO, requiring a restart, and so on; at least, it didn't crash during a transaction and leave duplicated packages around (i.e. I was lucky) * upgrade to FC6 using apt-get dist-upgrade. No hickups other than that I had to rpm --rebuilddb afterwards, it's probably the same "corrupted RPM database" bug there's already a thread about on one of the lists. (It also hits some yum or Anaconda users.) Kevin Kofler From jakub at redhat.com Wed Nov 22 19:21:41 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 14:21:41 -0500 Subject: Static linking considered harmful In-Reply-To: <1164217093.3276.12.camel@pensja.lam.pl> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> <1164217093.3276.12.camel@pensja.lam.pl> Message-ID: <20061122192141.GF6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 06:38:13PM +0100, Leszek Matok wrote: > Dnia 22-11-2006, ??ro o godzinie 12:10 -0500, Jakub Jelinek napisa??(a): > > If you want bit-reproduceable results, you can equally well > > just stick the shared libraries you need into the same directory as the > > program > This way you still don't upgrade a library to the bug-free version if > you don't remember about that. You save compiling time, true. But you > still have to remember, which library has to be copied (instead of > linked in). I thought the main point of the discussion was the security > issues raising when someone forgets to relink some program. Here we were talking about extremely specialized needs of very rare apps, nothing that should be massively used, and only for that purpose when you rely on bit-reproduceable results. Jakub From avi at argo.co.il Wed Nov 22 19:22:07 2006 From: avi at argo.co.il (Avi Kivity) Date: Wed, 22 Nov 2006 21:22:07 +0200 Subject: Static linking considered harmful In-Reply-To: <17764.10486.933592.120084@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45642754.9050706@argo.co.il> <17764.10486.933592.120084@zebedee.pink> Message-ID: <4564A35F.8010400@argo.co.il> Andrew Haley wrote: > Avi Kivity writes: > > > > That would prevent static linking not only for Fedora apps, but also for > > user applications built on Fedora. > > Yep. > > > I don't see a reason to prevent users from using static linking, > > See http://people.redhat.com/drepper/no_static_linking.html, > especially > > # fixes (either security or only bug) have to be applied to only one > place: the new DSO(s). If various applications are linked statically, > all of them would have to be relinked. By the time the problem is > discovered the sysadmin usually forgot which apps are built with the > problematic library. > The points are excellent, but there may also be points in favor of static linking. Feel free to statically link all of Fedora and to recommend that users do so, but don't force them. With regard to the points themselves: - many servers and applications don't have security requirements - dynamically linked libraries expose the application to new bugs introduced in the library, reducing stability I'm not advocating static linking; I just oppose the removal of static libraries. The -devel-static proposal sounds great to me (a benefit to dynamic linkers is a major reduction in download size for -devel). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From jakub at redhat.com Wed Nov 22 19:23:07 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 14:23:07 -0500 Subject: Static linking considered harmful In-Reply-To: <45648EE3.9070703@BitWagon.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <45648EE3.9070703@BitWagon.com> Message-ID: <20061122192307.GG6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 09:54:43AM -0800, John Reiser wrote: > > Removing libc.a would be most effective ... > > Where will the *stat() functions go? The functions that translate > the C API into the glibc ABI by adding an additional leading parameter > to specify which "struct stat" is to be used for returning the result, > and also add an 'x' and some underscores into the global name. libc_nonshared.a, libpthread_nonshared.a, libgcc.a, libgfortranbegin.a (and a few others) certainly aren't going away. Jakub From jakub at redhat.com Wed Nov 22 19:25:26 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 14:25:26 -0500 Subject: Static linking considered harmful In-Reply-To: <45649909.3030108@BitWagon.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> <45649909.3030108@BitWagon.com> Message-ID: <20061122192526.GH6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 10:38:01AM -0800, John Reiser wrote: > Jakub Jelinek wrote: > > If you want bit-reproduceable results, you can equally well > > just stick the shared libraries you need into the same directory as the > > program and run it as > > ./ld-linux*.so.2 --library-path . ./the_numerical_program arguments > > it will cost you just a few extra lines in the Makefile, IMHO not a big > > deal. > > Yes, the primary outputs will be the same. But the total user interface > will be different. The process name (revealed by ps, top, etc.) will be > ld-linux*.so.2 instead of the_numerical_program. So existing scripts > that monitor (or get out of the way of) the_numerical_program won't find it; > killall won't work; oprofile will group all such programs together > as ld-linux instead of as separate numerical programs, etc. This > "other stuff" is important to users and administrators. So you link with -Wl,--dynamic-linker,./ld-linux.so.2,-rpath,'${ORIGIN}/lib' or something similar, that's an implementation detail. Jakub From kevin.kofler at chello.at Wed Nov 22 19:21:39 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Nov 2006 19:21:39 +0000 (UTC) Subject: Reducing Fedora memory footprint? References: <45645D4A.9070309@draigBrady.com> Message-ID: Pekka Savola netcore.fi> writes: > Unfortunately, that doesn't answer the question of 'more light-weight' > as I fear that xfce is the most lightweight of the desktop bunch at > least... It depends on what "desktop" features you want. IceWM provides a taskbar if that's what you expect of a desktop. As for desktop icons, you can use ROX Filer to display these with any WM (including IceWM). Personally, I just run KDE on my 160 MB RAM laptop though. ;-) Kevin Kofler From jakub at redhat.com Wed Nov 22 19:27:22 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 14:27:22 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122191050.GA54373@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122170849.GA37274@dspnet.fr.eu.org> <1164221955.6436.6.camel@perun.kabelta.loc> <20061122191050.GA54373@dspnet.fr.eu.org> Message-ID: <20061122192722.GI6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 08:10:50PM +0100, Olivier Galibert wrote: > > But I agree that in other cases it is not always as easy as this one. > > Especially since you don't know something is missing until some > application blows up when you try it. Just use a package manager which will track the dependencies for you? Jakub From philipp_subx at redfish-solutions.com Wed Nov 22 19:45:15 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 22 Nov 2006 12:45:15 -0700 Subject: Incorrect timestamp logging in gssftpd (krb5-workstation) In-Reply-To: <4560C83D.9000506@redfish-solutions.com> References: <4560C83D.9000506@redfish-solutions.com> Message-ID: <4564A8CB.8090909@redfish-solutions.com> Ok, since I don't seem to have picked the right place to post, can someone at least point me in the correct direction? -Philip Philip Prindeville wrote: >I found a situation (fairly common, actually) under which gssftpd >generates incorrect timestamps as a result of chroot()ing and losing >access to the /etc/localtime file (it surprises me that localtime(3) >doesn't cache the file's contents in glibc... oh, well). > >I came up with a work-around for this which is fairly simple. > >Can someone else code review it? And if the Kerberos folks >(krbdev) don't want to include the fix (I sent it to them, but didn't >hear back) what's the criteria for it being included in the Redhat/ >Fedora packaging instead? > >Here's the bug report (fix included): > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216356 > >-Philip > > > From galibert at pobox.com Wed Nov 22 19:54:36 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 20:54:36 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122192722.GI6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122170849.GA37274@dspnet.fr.eu.org> <1164221955.6436.6.camel@perun.kabelta.loc> <20061122191050.GA54373@dspnet.fr.eu.org> <20061122192722.GI6570@devserv.devel.redhat.com> Message-ID: <20061122195436.GA41690@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 02:27:22PM -0500, Jakub Jelinek wrote: > On Wed, Nov 22, 2006 at 08:10:50PM +0100, Olivier Galibert wrote: > > > But I agree that in other cases it is not always as easy as this one. > > > > Especially since you don't know something is missing until some > > application blows up when you try it. > > Just use a package manager which will track the dependencies for you? Uh? What makes you think the application is installed locally? OG. From galibert at pobox.com Wed Nov 22 19:57:57 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 22 Nov 2006 20:57:57 +0100 Subject: Static linking considered harmful In-Reply-To: <45642FB2.5050109@warmcat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122110317.GB89035@dspnet.fr.eu.org> <45642FB2.5050109@warmcat.com> Message-ID: <20061122195757.GB41690@dspnet.fr.eu.org> On Wed, Nov 22, 2006 at 11:08:34AM +0000, Andy Green wrote: > Olivier Galibert wrote: > >On Wed, Nov 22, 2006 at 10:53:58AM +0000, Andy Green wrote: > > >>You could alter your build methodology so that each of the target > >>boxes,eg, rebuilds an SRPM with the local library environment? You need > >>the compiler and -devel bits and bobs then on the boxes. > > > >That's the point where he should use gentoo and not fedora. > > But he isn't just using Fedora, he has a bunch of not very compatible OS > installs of varying ages, and he would need to work around this change > one way or another. I didn't miss the joke but if he could actually use > Gentoo or anything else that was the same on all the boxes that would > indeed solve his problem. It was only half-a-joke. If the Fedora solution to backwards binary compatibility is "recompile locally every application", then Gentoo is much better at that kind of job. OG. From jakub at redhat.com Wed Nov 22 20:07:08 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Nov 2006 15:07:08 -0500 Subject: Static linking considered harmful In-Reply-To: <20061122195757.GB41690@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122110317.GB89035@dspnet.fr.eu.org> <45642FB2.5050109@warmcat.com> <20061122195757.GB41690@dspnet.fr.eu.org> Message-ID: <20061122200708.GJ6570@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 08:57:57PM +0100, Olivier Galibert wrote: > It was only half-a-joke. If the Fedora solution to backwards binary > compatibility is "recompile locally every application", then Gentoo is > much better at that kind of job. Care to explain from what you gathered "recompile locally every application"? All I (and others) said is that "linking statically is almost always a bad idea and not the right answer for binary compatibility", that's very different from "recompile locally everything". Compile/link against the oldest libs/with oldest toolchain you want to support is nothing specific to Fedora, that's simply how e.g. symbol versioning was designed to work. Jakub From drepper at redhat.com Wed Nov 22 20:14:25 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 22 Nov 2006 12:14:25 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122102428.GD2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> Message-ID: <4564AFA1.4090103@redhat.com> Patrice Dumas wrote: > Not only. There are cases when all those issues are moot, a prominent one > being for numerical models. I'm not going to reply to each mail in this thread individually, this is a summary: - I hope every agrees that using static linking with code you do not control yourself has severe consequences. If not, you shouldn't be allowed to create binaries - some people perceive some advantages like "it just runs on another machine" These are the two main camps. I think we can ignore the early boot issue (this can be easily fixed as DavidZ already showed) and the disaster recovery (here you should not trust _any_ binary on the system, just boot from CD/USB stick/network/etc and proceed from there). As for the "works everywhere" argument: - Jakub and others already pointed out that this is mostly a myth. Every non-trivial program needs services which require dynamic linking. glibc's dependencies (iconv, nss, idn, ...) are prominent. But there are an increasing number of other projects which need it. Just look for all the DSOs linked against (explicitly or implicitly) libdl. This includes basically all GUI stuff, all security apps. Heck, even ncurses falls in this category. All of these are out when it comes to static linking. - Other problems are file formats. They change and we've seen problems on many occasions. And I don't blame the maintainers of the packages providing the data. They should not be held back in improving their packages because of an ancient file format. If you do then you and up with a mess like the recent timezone file format change where all files suddenly are more than twice the size. And even that possibility is sometimes not open. - Every only slightly security relevant application must use the latest version of the code it is linked with. As I wrote elsewhere, without dynamic linking it is almost certain that an update is missed which then leads to problems. And don't start with "my servers are not accessible from the Internet therefore I don't care". Complete utter nonsense. The most dangerous and frequent attacker comes from the inside. If you're working in a public company with such an attitude you're probably even legally vulnerable. - The same code used in different environments very often does *not* "just works". + code is compiled with the assumption of a minimal expected runtime environment. For glibc this means a minimal kernel. For other packages the list will likely be longer. And not all packages actually verify the assumptions for each program run (glibc does it but that's probably an exception) + this na?vely assumes that code is not looking at the environment itself and execute different code. Prime examples are different syscalls that are available and where the code in old environment might have to live with incomplete emulations (example: pselect) or code which uses different CPU features depending on the availability (e.g., math code using the multi-media registers instead of floating point ops). Assuming that this has no effects invalidates one's arguments flat out. + similarly, the results of especially math opcodes for a CPU are not the same over different manufacturers and even revisions. If you need this you have to stick with exactly the same hardware on all the machines. But then the argument of using different OS revisions or flavors goes mostly away. Why severely cripple yourself by having the installations which have to be done at approximately the same time (otherwise the hardware would differ) so different? Before going on I want to make one thing clear: there is no problem whatsoever if the code you're linking with statically is also controlled by yourself. Especially if the library code comes in the same problem. In this situation it is even a huge advantage to link statically and avoid the silly DSO which is used just in the programs of the package. This is something which likely applies to many of the users of heterogeneous computing environments (numeric stuff or not). And even if all this does not apply it still is a bad idea to link statically and there is no reason. You can always take the binaries, executable and DSOs, from an old system and install them as an item on all the machines. Yes, you'd be using a non-standard dynamic linker, libc, ... on all the other machines but this is what you want. Jakub already explained how to preserve even the file name to shut those making up phony arguments about things like this. For updates you then only have to keep track on which machines the program is deployed and then replace the updated DSO. Done correctly using network filesystems this would be one single place. There is nothing which you can do with static linking that you cannot do with a dynamically linked executable as well. The other direction is not true. As for automatic -devel-static RPM, this is wrong as well. Yes, for a transitional period some -devel-static RPMs might be needed. But each and every one of them must be justified (e.g., no gnome/kde package should have them, period). And you even need to dig in deeper: each .a file on those RPMs needs to be justified. For instance, glibs's RPMs should not contain libpthread.a at all. This code never really worked as well as the dynamically linked code. And one final thing: we have -debuginfo packages. But those can only work for DSOs. Statically linked code is not debuggable. We cannot effort shipping .a files with debug information included, that data is simply to huge. This means even during development it makes no sense to use static linking with system-provided libraries. I want to see a default policy of dropping all .a files (except special ones like libc_nonshared.a, of course, which are needed during dynamic linking). Everybody having problems with any specific situation will have to make her/his point why a -devel-static package should be provided. If the exception is granted it has to be revisited for the next release. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From pertusus at free.fr Wed Nov 22 21:09:43 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Nov 2006 22:09:43 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122200708.GJ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122110317.GB89035@dspnet.fr.eu.org> <45642FB2.5050109@warmcat.com> <20061122195757.GB41690@dspnet.fr.eu.org> <20061122200708.GJ6570@devserv.devel.redhat.com> Message-ID: <20061122210508.GA2870@free.fr> On Wed, Nov 22, 2006 at 03:07:08PM -0500, Jakub Jelinek wrote: > > Care to explain from what you gathered "recompile locally every > application"? All I (and others) said is that "linking statically > is almost always a bad idea and not the right answer for binary > compatibility", that's very different from "recompile locally everything". It is a good answer as long as kernel >= 2.6.9 is used? Or did I miss something? Well, actually, you said that ;-) -- Pat From jreiser at BitWagon.com Wed Nov 22 21:16:17 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 22 Nov 2006 13:16:17 -0800 Subject: Static linking considered harmful In-Reply-To: <20061122192526.GH6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <1164191654.31358.728.camel@laptopd505.fenrus.org> <20061122171055.GC6570@devserv.devel.redhat.com> <45649909.3030108@BitWagon.com> <20061122192526.GH6570@devserv.devel.redhat.com> Message-ID: <4564BE21.7030304@BitWagon.com> >>>... stick the shared libraries you need into the same directory as the >>>program and run it as >>>./ld-linux*.so.2 --library-path . ./the_numerical_program arguments >>Yes, the primary outputs will be the same. But the total user interface >>will be different. > So you link with -Wl,--dynamic-linker,./ld-linux.so.2,-rpath,'${ORIGIN}/lib' > or something similar, that's an implementation detail. Will "${ORIGIN}" finally be documented in the glibc documentation? -- From cleaver at redwire.net Wed Nov 22 21:24:13 2006 From: cleaver at redwire.net (Japheth J.C. Cleaver) Date: Wed, 22 Nov 2006 13:24:13 -0800 Subject: Static linking considered harmful In-Reply-To: <4564AFA1.4090103@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> Message-ID: <4564BFFD.3010809@redwire.net> Ulrich Drepper wrote: > > Before going on I want to make one thing clear: there is no problem > whatsoever if the code you're linking with statically is also controlled > by yourself. Especially if the library code comes in the same problem. > In this situation it is even a huge advantage to link statically and > avoid the silly DSO which is used just in the programs of the package. > This is something which likely applies to many of the users of > heterogeneous computing environments (numeric stuff or not). > *snip* > > There is nothing which you can do with static linking that you cannot do > with a dynamically linked executable as well. The other direction is > not true. > > As for automatic -devel-static RPM, this is wrong as well. Yes, for a > transitional period some -devel-static RPMs might be needed. But each > and every one of them must be justified (e.g., no gnome/kde package > should have them, period). And you even need to dig in deeper: each .a > file on those RPMs needs to be justified. For instance, glibs's RPMs > should not contain libpthread.a at all. This code never really worked > as well as the dynamically linked code. > *snip* > > I want to see a default policy of dropping all .a files (except special > ones like libc_nonshared.a, of course, which are needed during dynamic > linking). Everybody having problems with any specific situation will > have to make her/his point why a -devel-static package should be > provided. If the exception is granted it has to be revisited for the > next release. > I don't see how the first two paragraphs here comport with the remaining ones. If people are going to be able to compile things statically then they need to be able to. This is not dissimilar to a discussion on fedora-extras last month: https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00048.html There are cases, either when developing software YOU'VE written or when using software written with a static mindset in mind (DJB-ware comes to mind, but anything else doing a lot of exec image replacement from one tiny binary to another), where static compilation is useful and provides a not-insignificant speed improvement. (Our mail server saw a performance boost of about 20% when we statically linked our process chain.) We should not remove the ability to easily install static libraries from the Fedora/Fedora-Extras system simply due to someone's crusade against it. If a Fedora user is to be trusted with Development Packages, then they should be trusted to "know what they're doing" wrt dynamic vs. static linking. +1 for the foo-devel-static RPM concept. Regards, Japheth Cleaver, Airband Communications cleaver at redwire.net From orion at cora.nwra.com Wed Nov 22 21:31:20 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 22 Nov 2006 14:31:20 -0700 Subject: Core + Extras 2 In-Reply-To: <1164035385.6875.16.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035385.6875.16.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Mon, 2006-11-20 at 09:05 -0600, Rex Dieter wrote: >> IMO, barring policy details on how to make it work (which can be hammerred >> out later), adding new packages to Fedora after "release" is IMO absolutely >> essential. > Definitely - It's one of the essentials the current FE is based on. Agreed. My main motivation as a packager is to get an application onto the release I'm using at the moment. Yes, I can maintain my own repo (I already do for some stuff), but where's the community in that? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Wed Nov 22 21:56:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Nov 2006 15:56:59 -0600 Subject: Core + Exrtas 2 In-Reply-To: <1164168465.5059.176.camel@mccallum.corsepiu.local> References: <4561AD44.6040404@hhs.nl> <4561B088.5080203@fedoraproject.org> <200611200913.52895.jkeating@redhat.com> <1164035329.6875.13.camel@mccallum.corsepiu.local> <1164092166.6875.131.camel@mccallum.corsepiu.local> <1164123057.5059.39.camel@mccallum.corsepiu.local> <45634C98.5000501@redhat.com> <1164168465.5059.176.camel@mccallum.corsepiu.local> Message-ID: <4564C7AB.2050702@math.unl.edu> Ralf Corsepius wrote: > But, from an FE background, the situation is conversely: > People break ABIs/APIs/etc., > because they are not aware about doing so, Unfortunate, but could potentially be caught with education and updates-testing. > because they do not care about it, sad also, break out clue-stick. > because they blindly follow upstream > (and upstream doesn't care about ABI/API/etc.) I'd say maintainer's in a tough situation, if upstream neither cares, nor supports the older version, what to do? > because they think "having feature XXX outweighs ABI/API/etc.". Already addressed. Judgement call. -- Rex From thomas.canniot at laposte.net Wed Nov 22 21:50:14 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Wed, 22 Nov 2006 22:50:14 +0100 Subject: That much dependences ? (rssowl hell) Message-ID: <1164232214.10975.1.camel@localhost.localdomain> [root at localhost ~]# yum install rssowl [snip] Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: rssowl i386 1.2.2-6.fc6 extras 2.9 M Installing for dependencies: ant i386 1.6.5-2jpp.2 core 2.0 M ant-antlr i386 1.6.5-2jpp.2 core 34 k ant-apache-bcel i386 1.6.5-2jpp.2 core 36 k ant-apache-log4j i386 1.6.5-2jpp.2 core 28 k ant-apache-oro i386 1.6.5-2jpp.2 core 112 k ant-apache-regexp i386 1.6.5-2jpp.2 core 28 k ant-apache-resolver i386 1.6.5-2jpp.2 core 29 k ant-commons-logging i386 1.6.5-2jpp.2 core 29 k ant-javamail i386 1.6.5-2jpp.2 core 35 k ant-jdepend i386 1.6.5-2jpp.2 core 45 k ant-jsch i386 1.6.5-2jpp.2 core 67 k ant-junit i386 1.6.5-2jpp.2 core 162 k ant-nodeps i386 1.6.5-2jpp.2 core 795 k ant-swing i386 1.6.5-2jpp.2 core 27 k ant-trax i386 1.6.5-2jpp.2 core 159 k axis i386 1.2.1-2jpp.6 core 2.2 M bcel i386 5.1-8jpp.1 core 983 k classpathx-jaf i386 1.0-9jpp.1 core 101 k classpathx-mail i386 1.1.1-4jpp.2 core 1.1 M eclipse-ecj i386 1:3.2.1-4.fc6 core 7.9 M eclipse-platform i386 1:3.2.1-4.fc6 core 33 M eclipse-rcp i386 1:3.2.1-4.fc6 core 13 M gcc-java i386 4.1.1-30 core 2.8 M geronimo-specs i386 1.0-0.M2.2jpp.12 core 230 k geronimo-specs-compat i386 1.0-0.M2.2jpp.12 core 5.5 k itext i386 1.3-3.fc6 extras 2.6 M jakarta-commons-beanutils i386 1.7.0-5jpp.1 core 526 k jakarta-commons-codec i386 1.3-7jpp.2 core 99 k jakarta-commons-collections i386 3.1-6jpp.1 core 1.0 M jakarta-commons-daemon i386 1:1.0.1-6jpp.1 core 44 k jakarta-commons-dbcp i386 1.2.1-7jpp.1 core 243 k jakarta-commons-digester i386 1.7-5jpp.1 core 314 k jakarta-commons-discovery i386 1:0.3-4jpp.1 core 134 k jakarta-commons-el i386 1.0-7jpp.1 core 240 k jakarta-commons-fileupload i386 1:1.0-6jpp.1 core 48 k jakarta-commons-httpclient i386 1:3.0-7jpp.1 core 514 k jakarta-commons-launcher i386 0.9-6jpp.1 core 88 k jakarta-commons-modeler i386 1.1-8jpp.1 core 230 k jakarta-commons-pool i386 1.3-5jpp.1 core 128 k jakarta-oro i386 2.0.8-3jpp.1 core 173 k java-1.4.2-gcj-compat-devel i386 1.4.2.0-40jpp.110 core 49 k jdepend i386 2.6-6jpp.1 core 240 k jdom i386 1.0-4jpp.1 core 330 k jsch i386 0.1.28-1jpp.5 core 302 k junit i386 3.8.2-3jpp.1 core 305 k jzlib i386 1.0.7-4jpp.1 core 132 k ldapjdk i386 4.17-1jpp.7 core 825 k libgcj-devel i386 4.1.1-30 core 1.4 M lucene i386 1.4.3-1jpp.14 core 684 k mx4j i386 1:3.0.1-6jpp.4 core 2.5 M regexp i386 1.4-2jpp.2 core 91 k tomcat5 i386 5.5.17-6jpp.2 core 318 k tomcat5-common-lib i386 5.5.17-6jpp.2 core 195 k tomcat5-jasper i386 5.5.17-6jpp.2 core 979 k tomcat5-server-lib i386 5.5.17-6jpp.2 core 3.6 M wsdl4j i386 1.5.2-4jpp.1 core 388 k Transaction Summary ============================================================================= Install 57 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 87 M Is this ok [y/N]: I guess there are some kind of abusive dependences there ? Running up 2 date FC6 i386. -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From nicolas.mailhot at laposte.net Wed Nov 22 21:59:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Nov 2006 22:59:58 +0100 Subject: That much dependences ? (rssowl hell) In-Reply-To: <1164232214.10975.1.camel@localhost.localdomain> References: <1164232214.10975.1.camel@localhost.localdomain> Message-ID: <1164232801.19448.6.camel@rousalka.dyndns.org> Our java packaging is very fine grained (as it should). You'd have the same effect with a python or perl app on a system without any python or perl stack installed yet. -- Nicolas Mailhot From jkeating at redhat.com Wed Nov 22 22:03:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Nov 2006 17:03:56 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: <1164232214.10975.1.camel@localhost.localdomain> References: <1164232214.10975.1.camel@localhost.localdomain> Message-ID: <200611221703.57009.jkeating@redhat.com> On Wednesday 22 November 2006 16:50, Thomas Canniot wrote: > I guess there are some kind of abusive dependences there ? > > Running up 2 date FC6 i386. Welcome to java hell. The java stuff isn't really packaged well enough to have concise dependencies and instead you wind up with the whole stack. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Nov 23 00:05:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 23 Nov 2006 00:05:51 +0000 (UTC) Subject: That much dependences ? (rssowl hell) References: <1164232214.10975.1.camel@localhost.localdomain> <200611221703.57009.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > Welcome to java hell. The java stuff isn't really packaged well enough to > have concise dependencies and instead you wind up with the whole stack. Isn't this more a "let's stuff everything and the kitchen sink into the class library and make it part of the language^W'platform' definition" problem than a packaging problem? As Nicolas Mailhot says, packages are already broken up, but Java has a "let's require everything" mentality. Kevin Kofler From drepper at redhat.com Thu Nov 23 00:33:27 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 22 Nov 2006 16:33:27 -0800 Subject: Static linking considered harmful In-Reply-To: <4564BFFD.3010809@redwire.net> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> Message-ID: <4564EC57.7060707@redhat.com> Japheth J.C. Cleaver wrote: > I don't see how the first two paragraphs here comport with the remaining > ones. If people are going to be able to compile things statically then > they need to be able to. The first paragraph is about linking the code which comes from your package statically. I.e., only link those libraries statically and everything else dynamic. Static linking is no all-or-nothing decision in case you didn't know. > (Our mail server saw a > performance boost of about 20% when we statically linked our process chain.) I *very* much doubt those numbers. Using PIC and the runtime linker does not add that much overhead. Never has, never will. If you compare apples and oranges you can come up with such numbers, of course. > We should not remove the ability to easily install static libraries from > the Fedora/Fedora-Extras system simply due to someone's crusade against > it. If a Fedora user is to be trusted with Development Packages, then > they should be trusted to "know what they're doing" wrt dynamic vs. > static linking. No. And it can be proved easily: name all the libraries used in all the builds of the statically linked apps. And automate rebuilding when any of those changes. Fact is, nobody does this. Only through dynamic linking can you take immediately advantage of the new builds. And this is not "someone", it's everybody who understand a bit about this. And it's not just Fedora or Red Hat, not even only Linux. Solaris is also pushing hard to eradicate static linking with system libraries. Again, nobody is taking away the possibility to create partially statically linked apps. I'm all for that as long as no maintenance borders are crossed. This is what -Wl,-B,static and -Wl,-B-dynamic are for. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From a.badger at gmail.com Thu Nov 23 01:10:07 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Nov 2006 17:10:07 -0800 Subject: removing termcap In-Reply-To: <20061121174945.GC7982@localhost> References: <20061121174945.GC7982@localhost> Message-ID: <1164244207.32083.19.camel@localhost.localdomain> On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > - Move the most important entries in the terminfo database to > /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, > but the second option isn't much better as it will duplicate the > entries on multiarch. I'm assuming that terminfo entries are architecture independent binary files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. It would be a bit odd to find part of the terminfo database in /lib/terminfo and some in /usr/share/terminfo, though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Nov 23 01:16:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Nov 2006 20:16:17 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: References: <1164232214.10975.1.camel@localhost.localdomain> <200611221703.57009.jkeating@redhat.com> Message-ID: <200611222016.20280.jkeating@redhat.com> On Wednesday 22 November 2006 19:05, Kevin Kofler wrote: > Isn't this more a "let's stuff everything and the kitchen sink into the > class library and make it part of the language^W'platform' definition" > problem than a packaging problem? As Nicolas Mailhot says, packages are > already broken up, but Java has a "let's require everything" mentality. Sure, I meant packaged upstream, not downstream. We can only do so much with the crap we have to start with. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Thu Nov 23 01:44:56 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 22 Nov 2006 20:44:56 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: <200611221703.57009.jkeating@redhat.com> References: <1164232214.10975.1.camel@localhost.localdomain> <200611221703.57009.jkeating@redhat.com> Message-ID: <20061123014456.GA447@redhat.com> * Jesse Keating [2006-11-22 17:01]: > On Wednesday 22 November 2006 16:50, Thomas Canniot wrote: > > I guess there are some kind of abusive dependences there ? > > > > Running up 2 date FC6 i386. > > Welcome to java hell. The java stuff isn't really packaged well enough to > have concise dependencies and instead you wind up with the whole stack. Yeah right. It's not that things aren't packaged well enough, it's the the app uses all sorts of stuff which uses all sorts of other stuff. Plain and simple. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Thu Nov 23 01:48:59 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 22 Nov 2006 20:48:59 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: <1164232214.10975.1.camel@localhost.localdomain> References: <1164232214.10975.1.camel@localhost.localdomain> Message-ID: <20061123014859.GB447@redhat.com> * Thomas Canniot [2006-11-22 16:51]: > [root at localhost ~]# yum install rssowl > > [...] > > eclipse-platform i386 1:3.2.1-4.fc6 core This is because RSSOwl itself isn't technically an Eclipse RCP app. If it were, a lot of those dependencies would go away. I know Ben Pasero, the upstream author, had been working on not using stuff that wasn't part of JFace (and thus part of the RCP definition) so perhaps we should see if that bore any fruit. Please file a bug to investigate whether or not we still require the platform dep. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nmiell at comcast.net Thu Nov 23 02:04:45 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 22 Nov 2006 18:04:45 -0800 Subject: Static linking considered harmful In-Reply-To: <4564EC57.7060707@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> Message-ID: <1164247485.2806.9.camel@entropy> On Wed, 2006-11-22 at 16:33 -0800, Ulrich Drepper wrote: > Japheth J.C. Cleaver wrote: > > I don't see how the first two paragraphs here comport with the remaining > > ones. If people are going to be able to compile things statically then > > they need to be able to. > > The first paragraph is about linking the code which comes from your > package statically. I.e., only link those libraries statically and > everything else dynamic. Static linking is no all-or-nothing decision > in case you didn't know. > > > > (Our mail server saw a > > performance boost of about 20% when we statically linked our process chain.) > > I *very* much doubt those numbers. Using PIC and the runtime linker > does not add that much overhead. Never has, never will. If you compare > apples and oranges you can come up with such numbers, of course. > > > > We should not remove the ability to easily install static libraries from > > the Fedora/Fedora-Extras system simply due to someone's crusade against > > it. If a Fedora user is to be trusted with Development Packages, then > > they should be trusted to "know what they're doing" wrt dynamic vs. > > static linking. > > No. And it can be proved easily: name all the libraries used in all the > builds of the statically linked apps. And automate rebuilding when any > of those changes. Fact is, nobody does this. Only through dynamic > linking can you take immediately advantage of the new builds. Some misguided folk are still trying, though. The most recent example I can think of is OpenPKG wanting support for this in RPM. See: http://article.gmane.org/gmane.linux.redhat.rpm.devel/1695 > And this is not "someone", it's everybody who understand a bit about > this. And it's not just Fedora or Red Hat, not even only Linux. > Solaris is also pushing hard to eradicate static linking with system > libraries. They've been eliminated entirely as of Solaris 10. A explanation why is here: http://blogs.sun.com/rie/entry/static_linking_where_did_it Unsurprisingly, it repeats much of what has been said in this thread already. -- Nicholas Miell From overholt at redhat.com Thu Nov 23 02:01:20 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 22 Nov 2006 21:01:20 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: <20061123014859.GB447@redhat.com> References: <1164232214.10975.1.camel@localhost.localdomain> <20061123014859.GB447@redhat.com> Message-ID: <20061123020119.GC447@redhat.com> * Andrew Overholt [2006-11-22 20:53]: > * Thomas Canniot [2006-11-22 16:51]: > > [root at localhost ~]# yum install rssowl > > > > [...] > > > > eclipse-platform i386 1:3.2.1-4.fc6 core > > This is because RSSOwl itself isn't technically an Eclipse RCP app. If it > were, a lot of those dependencies would go away. I know Ben Pasero, the > upstream author, had been working on not using stuff that wasn't part of > JFace (and thus part of the RCP definition) so perhaps we should see if > that bore any fruit. Actually, it looks like that's fixed in CVS and will be in the forthcoming version: "- Removed the dependancy to org.eclipse.ui.forms. On Linux, the big dependancy to the Eclipse Platform is therefor no longer required. from http://www.rssowl.org/dl/Integration_Build/changelog.txt Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Nov 23 04:44:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 22 Nov 2006 23:44:16 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <20061122172342.GA23688@osiris.silug.org> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> <20061122172342.GA23688@osiris.silug.org> Message-ID: <1164257056.11115.12.camel@cutter> On Wed, 2006-11-22 at 11:23 -0600, Steven Pritchard wrote: > That's been my experience as well. For example, every system that I > have running openldap eventually corrupts the database (usually in 2-3 > months of continuous use). This is on servers that run for months > (sometimes years) at a time without a reboot. > > Luckily slapd_db_recover and slapindex has fixed the problem every > time so far, which is why I'd *really* like it if "service ldap > restart" would run both. > Do you think we should be relying on berkeley db, then? -sv From tibbs at math.uh.edu Thu Nov 23 05:33:28 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Nov 2006 23:33:28 -0600 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <1164257056.11115.12.camel@cutter> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> <20061122172342.GA23688@osiris.silug.org> <1164257056.11115.12.camel@cutter> Message-ID: >>>>> "sv" == seth vidal writes: sv> Do you think we should be relying on berkeley db, then? It would sure be nice if we didn't have to. Unfortunately there's not really an adequate replacement; sqlite works well for some things but it's not really working in the same problem space. It might work for RPM, though. - J< From laroche at redhat.com Thu Nov 23 07:02:33 2006 From: laroche at redhat.com (Florian La Roche) Date: Thu, 23 Nov 2006 08:02:33 +0100 Subject: Static linking considered harmful In-Reply-To: <4564EC57.7060707@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> Message-ID: <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> > Again, nobody is taking away the possibility to create partially > statically linked apps. I'm all for that as long as no maintenance > borders are crossed. This is what -Wl,-B,static and -Wl,-B-dynamic are for. Then we should not remove too many static libs. Some are good candidates to only keep the real core (LSB?) libs dynamically loaded. regards, Florian La Roche From jakub at redhat.com Thu Nov 23 07:14:19 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Nov 2006 02:14:19 -0500 Subject: Static linking considered harmful In-Reply-To: <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> Message-ID: <20061123071419.GK6570@devserv.devel.redhat.com> On Thu, Nov 23, 2006 at 08:02:33AM +0100, Florian La Roche wrote: > > Again, nobody is taking away the possibility to create partially > > statically linked apps. I'm all for that as long as no maintenance > > borders are crossed. This is what -Wl,-B,static and -Wl,-B-dynamic are for. > > Then we should not remove too many static libs. Some are good candidates > to only keep the real core (LSB?) libs dynamically loaded. A library that is usable with -Wl,-Bstatic -lfoo -Wl,-Bdynamic needs a) justification b) quite a lot of work on the Makefiles etc. side, particularly: - it should be built as -fPIC, because you never know into what it will be linked - make sure all global symbols are hidden (i.e. play a lot with visibility attribute and/or #pragma GCC visibility, what's worse is that you want the symbols exported for *.so but hidden in *.a) - without this, when you link it statically into some shared library, it reexports all the symbols to other libraries - make sure the library doesn't rely on something being unique per-process (e.g. libgcc's unwinder, at least when older libraries are used, must have a unique registry of loaded objects, libstdc++'s mt_allocator relies on ODR, otherwise you need to track where you allocated things and never deallocate them from a different object, etc.) So, while I think there are a few cases where keeping an *.a archive around is desirable and worth the above pain, for the vast majority of libraries the justification isn't strong enough and *.a should be just nuked. Jakub From drepper at redhat.com Thu Nov 23 07:32:09 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 22 Nov 2006 23:32:09 -0800 Subject: Static linking considered harmful In-Reply-To: <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> Message-ID: <45654E79.4060108@redhat.com> Florian La Roche wrote: > Then we should not remove too many static libs. Some are good candidates > to only keep the real core (LSB?) libs dynamically loaded. Why? This makes no sense. You have to provide arguments for each .a file. As I said, you cannot even build a graphical application without libdl. And all server apps are security relevant and should never use static linking for anything which doesn't come with the package. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From j.rink at freenet.de Thu Nov 23 07:49:42 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Thu, 23 Nov 2006 08:49:42 +0100 Subject: update from fc 5 -& gt; 6 thinkpad t23 savage, dri is disabled In-Reply-To: <21011.194.94.224.254.1164189164.squirrel@jose.freesurf.fr> References: <20061121220818.2c59f3a0.j.rink@freenet.de> <21011.194.94.224.254.1164189164.squirrel@jose.freesurf.fr> Message-ID: <20061123084942.53d23ded.j.rink@freenet.de> Am Wed, 22 Nov 2006 10:52:44 +0100 (CET) hat "Joachim Frieben" (Joachim Frieben) folgendes geschrieben: Hi Joachim, > No, the patch is not included. Current version is > "xorg-x11-drv-savage-2.1.1-5.fc6" from August 2006. I had submitted > the patch I am talking about mid-September 2006 as > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=136548 > thanks for this info and for your help. -- Nine (not 9) Never trust a hippie From giallu at gmail.com Thu Nov 23 08:08:19 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 23 Nov 2006 09:08:19 +0100 Subject: Fedora on a Norhtec MicroClient Jr. [Was: Reducing Fedora memory footprint?] Message-ID: Talking about small footprint, does anyone tried to install fedora on something like the MicroClient Jr.? http://www.norhtec.com/products/mcjr/index.html it has only 128Mb of RAM but but I could imagine a lot of applications for it at home once fedora will be up and running... From j.rink at freenet.de Thu Nov 23 08:17:32 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Thu, 23 Nov 2006 09:17:32 +0100 Subject: update from fc 5 -& gt; 6 thinkpad t23 savage, dri is disabled In-Reply-To: <20061123084942.53d23ded.j.rink@freenet.de> References: <20061121220818.2c59f3a0.j.rink@freenet.de> <21011.194.94.224.254.1164189164.squirrel@jose.freesurf.fr> <20061123084942.53d23ded.j.rink@freenet.de> Message-ID: <20061123091732.bdb0978c.j.rink@freenet.de> Am Thu, 23 Nov 2006 08:49:42 +0100 hat J?rn Rink (J?rn Rink) folgendes geschrieben: > > No, the patch is not included. Current version is > > "xorg-x11-drv-savage-2.1.1-5.fc6" from August 2006. I had submitted > > the patch I am talking about mid-September 2006 as > > > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=136548 > > > > thanks for this info and for your help. Hi, i implemented the patch, dri is active, glxgears runs one time with black windows, after that glxinfo shows no info about gl. an strace of glxinfo and glxgears shows both: open("/dev/dri/card0", O_RDWR) = 4 ioctl(4, DECODER_SET_PICTURE, 0xbfe73d90) = -1 EACCES (Permission denied) ioctl(4, DECODER_GET_CAPABILITIES, 0xbfe73d94) = 0 ioctl(4, DECODER_GET_CAPABILITIES, 0xbfe73d94) = 0 selinux is not active and xorg.conf has: Section "DRI" Group 0 Mode 0666 EndSection I have a free partition on my t23 and i make a fresh fc6 install next weekend. Perhaps it is a corrupt update, because strace after the permission denied in glxgears and glxinfo shows: stat64("/lib/i686", {st_mode=S_IFDIR| 0755, st_size=4096, ...}) = 0 open ("/lib/libtxc_dxtn.so", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib", {st_mode=S_IFDIR|0libtxc_dxtn.so755, st_size=12288, ...}) = 0 open("/usr/lib/tls/i686/libtxc_dxtn.so", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls/i686", 0xbfae4f50) = -1 ENOENT (No such file or directory) I have no libtxc_dxtn.so installed. From thomas.canniot at laposte.net Thu Nov 23 08:39:43 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Thu, 23 Nov 2006 09:39:43 +0100 Subject: Help improving translation Message-ID: <1164271183.3344.18.camel@localhost.localdomain> Hello, First, I apologise to fedora-trans-list to mail this message again. I have been translating fedora in French for few months only and i'm facing problems with contributors' translations. I used to translate po files, and, as we were very few French translators (2 *only*), it was quite easy to ask for the mate to read over the translation and to know what he is actually doing. However, now that I have less free time and now that we are more than 2 translating Fedora into French, when I take the initiative to translate 2 or 3 missing or recently added strings, I met bad translation and mistakes. There are few problems in our translation process : - People are not communicating by mailing list. The fact is that translation is often seen as a lonely activity and that you don't need any response from someone to take a po file and translate it. There is no way to know who is working on what. - The status page [1] are useful to know what has been translated, but useless to know what has been read over. - People do not use the reservation system "take" button and if they do, they don't update they reservation. What I'm planning to do : take every po file, and read over them until FC7 comes out. This is the only way I found to avoid bad translation in Fedora. Any advice to help out ? As we are changing lots of things on Fedora, wouldn't be the time to improve the translation process : - we shouldn't give anymore rights to upload CVS translation. CVS should only be accessible in read only and only people that read translation over should be allowed to update po to the CVS. - as there is mailing list for modifications on CVS docs, we need a mailing list as well for each language po modification. Mailing list are easy to set up and do not consume any ressources. - we could also use a system allowing to add a status of what has to be done with a po file : "waiting for translation", "waiting for being read over", "translation in progress" for example, are status that could be used. just my 2 cents. [1] http://i18n.redhat.com/cgi-bin/i18n-status -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From j.rink at freenet.de Thu Nov 23 09:08:01 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Thu, 23 Nov 2006 10:08:01 +0100 Subject: update from fc 5 -> 6 thinkpad t23 savage, dri is disabled In-Reply-To: <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> References: <20061121092739.8db49b0c.j.rink@freenet.de> <1480.89.50.36.84.1164108466.squirrel@jose.freesurf.fr> Message-ID: <20061123100801.114981c2.j.rink@freenet.de> Am Tue, 21 Nov 2006 12:27:46 +0100 (CET) hat "Joachim Frieben" (Joachim Frieben) folgendes geschrieben: > > https://bugs.freedesktop.org/show_bug.cgi?id=6357 , > Ok, i have recompiled the savage module only with the https://bugs.freedesktop.org/attachment.cgi?id=7041 and none of the others. Now glxgears works and i am able to open winecfg or a wine program twice and it shows the window. Thanks god (or Joachim), now i can use notes in my office. CU -- Nine (not 9) Never trust a hippie From buildsys at redhat.com Thu Nov 23 10:53:24 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 23 Nov 2006 05:53:24 -0500 Subject: rawhide report: 20061123 changes Message-ID: <200611231053.kANArORB005439@hs20-bc2-6.build.redhat.com> Updated Packages: ImageMagick-6.2.8.0-3.fc6.1 --------------------------- * Wed Nov 15 2006 Norm Murray - 6.2.8.0-3.fc6.1 - fix more overflows (#210921, CVE-2006-5456) beagle-0.2.13-1.fc7 ------------------- * Wed Nov 22 2006 Alexander Larsson - 0.2.13-1 - Update to 0.2.13 - Enable wv1 (word) support - Update key patch cadaver-0.22.3-5 ---------------- * Wed Nov 22 2006 Joe Orton 0.22.3-5 - rebuild cairo-1.3.4-1.fc7 ----------------- * Thu Nov 23 2006 Matthias Clasen 1.3.4-1 - Update to 1.3.4 * Wed Nov 15 2006 Carl Worth 1.3.2-1 - Update to 1.3.2 * Sun Nov 05 2006 Matthias Clasen 1.2.6-1 - Update to 1.2.6 compiz-0.3.4-1.fc7 ------------------ * Thu Nov 23 2006 Matthias Clasen - 0.3.4-1 - Update to 0.3.4 cups-1:1.2.7-4.fc7 ------------------ * Wed Nov 22 2006 Tim Waugh 1:1.2.7-4 - Another LSPP fix (bug #216669). - Fixed LSPP SELinux check (bug #216855). - Increased PPD timeout in copy_model() (bug #216065). dhcp-12:3.0.5-7.fc7 ------------------- * Wed Nov 22 2006 Peter Jones - 12:3.0.5-7 - Build the MD5 functions we link against. gettext-0.16-1.fc7 ------------------ * Thu Nov 23 2006 Jens Petersen - 0.16-1 - update to 0.16 release - disable openmp on ia64 (#216988) gnome-session-2.17.2-4.fc7 -------------------------- * Wed Nov 22 2006 Matthias Clasen - 2.17.2-4 - Own the /usr/share/gnome/wm-properties directory (#216514) grep-2.5.1-56.fc7 ----------------- * Wed Nov 22 2006 Tim Waugh 2.5.1-56 - Fixed count of patterns when the last is an empty string (bug #204255). * Wed Nov 22 2006 Tim Waugh 2.5.1-55 - Fix 'memory exhausted' errors by limiting in-memory buffer (bug #198165). gzip-1.3.5-11.fc7 ----------------- * Wed Nov 22 2006 Ivana Varekova - 1.3.5-11 - fix too strict uncompress function hwbrowser-0.29-1.fc7 -------------------- * Wed Nov 22 2006 Nils Philippsen - 0.29 - recognize ATA-, SATA-controllers, be more gracious about unknown device classes (#216714) less-394-6.fc7 -------------- * Wed Nov 22 2006 Ivana Varekova - 394-6 - fix permissions of debuginfo source code nautilus-2.16.2-7.fc7 --------------------- * Wed Nov 22 2006 Alexander Larsson - 2.16.2-7 - Look for beagle before tracker, because tracker autostarts This lets us support having both installed at the same time. - Remove buildreqs for beagle, as they are not necessary with the dynamic work. ntp-4.2.2p4-2.fc7 ----------------- * Wed Nov 22 2006 Miroslav Lichvar 4.2.2p4-2 - pass additional options to ntpdate (#202204) policycoreutils-1.33.4-1.fc7 ---------------------------- * Wed Nov 22 2006 Dan Walsh 1.33.4-1 - Upstream accepted my patches * Merged setsebool patch from Karl MacMillan. This fixes a bug reported by Yuichi Nakamura with always setting booleans persistently on an unmanaged system. rsync-2.6.9-1 ------------- * Wed Nov 22 2006 Florian La Roche - 2.6.9-1 - update to 2.6.9 scim-bridge-0.4.8-1.fc7 ----------------------- * Thu Nov 23 2006 Jens Petersen - 0.4.8-1 - update to 0.4.8 - add scim-bridge-0.4.8-qt-moc-path.patch to set full path to moc and scim-bridge-0.4.8-tests-dir-missing.patch to allow rebootstrap scim-pinyin-0.5.91-16.fc7 ------------------------- * Thu Nov 23 2006 Shawn Huang - 0.5.91-16 - add Obsoletes: miniChinput <= 0.3 to remove miniChinput when upgrading from RHEL4 (#211878). * Thu Nov 23 2006 Shawn Huang - 0.5.91-15 - update all .po files for all languages. setroubleshoot-1.7-1.fc7 ------------------------ * Tue Nov 21 2006 Dan Walsh - 1.7-1 * Add command line utilities * logfile scanning finally seems to work connected to browser * Additional Information section of report now includes line number information (if alert was generated from logfile) * replace database update_callback() with notify interface, a more generic solution more easily shared between components * object implementing rpc method is now explicitly attached via connect_rpc_interface() instead of walking the MRO chain with magic exclusions. explicitly connecting is more flexible and robust (no getting the wrong object by mistake) * fix handling of return args in local rpc case * fix signal connections between audit and logfile * split databae and database_properties for audit and logfile * fix initial connection state * fix lookup_local_id * Wed Nov 08 2006 Dan Walsh - 1.5-1 - Speed up startup of service * Mon Nov 06 2006 Dan Walsh - 1.4-1 - Many fixes - Changed the api sysklogd-1.4.1-40.fc7 --------------------- * Wed Nov 22 2006 Peter Vrabec 1.4.1-40 - add IPv6 support util-linux-2.13-0.45.1.fc6 -------------------------- * Wed Nov 22 2006 Karel Zak 2.13-0.45.1 - fix #216760 - mount with context or fscontext option fails (temporarily disabled the support for additional contexts -- not supported by kernel yet) vim-2:7.0.168-1 --------------- * Wed Nov 22 2006 Karsten Hopp 7.0.168-1 - patchlevel 168 - link with ncurses Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From gilboad at gmail.com Thu Nov 23 11:55:20 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Nov 2006 13:55:20 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <1164282920.22427.16.camel@gilboa-work-dev> On Wed, 2006-11-22 at 15:23 +0200, Pekka Savola wrote: > Hi, > > I'd like to reduce the memory footprint of FC6. Are there already > webpages that describe how to make Fedora more manageable on those 3-4 > year old "junk hardware"? (Some also have worried about the disk > space footprint, but let's leave that out of scope for now..) > > I think we have a problem if FC6 can't run properly on IBM ThinkPad > X30 w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are > the amount of memory, relatively slow disks, and swapping on those > relatively slow disks. > > A couple of observations: > > 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. > With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the > computer is "idle". Either ACPI is a lot worse than APM, or > something is going on. Any ideas how to debug this? I'd guess you're hitting the disk and draining the battery. > > 2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours > (just the depsolving, upgrade and cleanup -- all packages and > headers already existed on local disk). Only yum and Xorg were > running at that time. yum is a python application and as such, will always be slower and more memory intensive then c/cpp based applications (such as apt) - especially when it comes to CPU/memory intensive tasks such as dep-solving. > > 3) are there more light-weight desktops/WMs than xfce? Recently, it > seems it also has become bloated, e.g.,: [snip] > Something is wrong when when a simple battery plugin takes 80 MB of > memory.. XFCE 4.4 is a real memory hog - almost as much as KDE/GNOME do. I'm using IceWM on my PII366/256MB laptop and it works like a champ. I'll submit the RPM to extra when I'll have some free time. - Gilboa From dkovalsk at redhat.com Thu Nov 23 12:01:42 2006 From: dkovalsk at redhat.com (David Kovalsky) Date: Thu, 23 Nov 2006 13:01:42 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <45658DA6.8040607@redhat.com> Pekka Savola wrote: > 3) are there more light-weight desktops/WMs than xfce? WindowMaker It's in extras with even a few dockapps. -- ================================================== David Kovalsky dkovalsk at redhat.com Quality Engineer IRC: #brno, #errata, #qa, #urt ================================================== From jfrieben at freesurf.fr Thu Nov 23 12:06:11 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 23 Nov 2006 13:06:11 +0100 (CET) Subject: update from fc 5 -&amp; gt; 6 thinkpad t23 savage, dri is In-Reply-To: <20061123091732.bdb0978c.j.rink@freenet.de> References: <20061123091732.bdb0978c.j.rink@freenet.de> Message-ID: <1544.194.94.224.254.1164283571.squirrel@arlette.freesurf.fr> > Hi, > i implemented the patch, dri is active, glxgears runs one time with > black windows, after that glxinfo shows no info about gl. This unfortunate result is due to the fact that I had accidentally attached the unpatched, original "FC6" package "xorg-x11-drv-savage-2.1.1-5.fc6.i386.rpm" to my mail to J?rn instead of the updated one. The latter which adds the patch mentioned above and drops M. Harris' [non working] "disable dri" patch actually does the job [agreeing with J?rn's later result]. From alan at redhat.com Thu Nov 23 12:13:17 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Nov 2006 07:13:17 -0500 Subject: Static linking considered harmful In-Reply-To: <45654E79.4060108@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> Message-ID: <20061123121317.GC14710@devserv.devel.redhat.com> On Wed, Nov 22, 2006 at 11:32:09PM -0800, Ulrich Drepper wrote: > Why? This makes no sense. You have to provide arguments for each .a > file. As I said, you cannot even build a graphical application without Why do you have to provide arguments for each .a file ? > libdl. And all server apps are security relevant and should never use > static linking for anything which doesn't come with the package. And if the user happens to disagree with you... ? From kzak at redhat.com Thu Nov 23 12:52:09 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 23 Nov 2006 13:52:09 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> Message-ID: <20061123125209.GG2497@petra.dvoda.cz> I've created a new project page for readahead (with jkeating's help:-). It's fine if you edit the wiki page and contribute there. http://hosted.fedoraproject.org/projects/readahead/ Note: GIT repo will be available next week. Karel On Sun, Nov 12, 2006 at 01:57:57PM -0900, Jeff Spaleta wrote: > Okay its come to my attention that the readahead configs have a > difficult time being kept in sync as package updates roll out. For fc6 > right now for example readahead is out of sync with firefox libraries. > > Can we update readahead's implementation so we can get per package > control of the default configs? Is a readahead.d/ structure > appropriate here? > > > I want to point out that we lose significant value with read-ahead if > we can't ensure that the listings will be in-sync as package updates > are issued. And re-spinning readahead updates periodically to attempt > to sync a centralized config file is horrible inefficient and may > never be perfectly in-sync considering the churn of updates during a > release cycle. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203329 > > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Karel Zak From jkeating at redhat.com Thu Nov 23 14:00:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Nov 2006 09:00:42 -0500 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164282920.22427.16.camel@gilboa-work-dev> References: <1164282920.22427.16.camel@gilboa-work-dev> Message-ID: <200611230900.45633.jkeating@redhat.com> On Thursday 23 November 2006 06:55, Gilboa Davara wrote: > especially when it comes to CPU/memory intensive tasks such as > dep-solving. Except that the depsolving is done by rpm libraries which are C, so invalid argument. Also the "slow" process of loading metadata in from disk has an optional (installed by default) c plugin to speed that part up. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Nov 23 14:31:37 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Nov 2006 15:31:37 +0100 Subject: Static linking considered harmful In-Reply-To: <45654E79.4060108@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> Message-ID: <20061123143137.GB2778@free.fr> On Wed, Nov 22, 2006 at 11:32:09PM -0800, Ulrich Drepper wrote: > Florian La Roche wrote: > >Then we should not remove too many static libs. Some are good candidates > >to only keep the real core (LSB?) libs dynamically loaded. > > Why? This makes no sense. You have to provide arguments for each .a > file. As I said, you cannot even build a graphical application without This is too much work for the maintainers. The issue of static linking should be considered, but asking the packagers to do so much investigation work seems too much to me. It could be a should item, especially if there is a clear documentation on what to search for, but for a must it is too demanding in my opinoin. Static libraries are already discouraged in the guidelines. Does the fact that an application is linked with libdl means that it is useless if linked statically, or is it possible that some features only are unavailable? -- Pat From gilboad at gmail.com Thu Nov 23 14:33:30 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Nov 2006 16:33:30 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: <200611230900.45633.jkeating@redhat.com> References: <1164282920.22427.16.camel@gilboa-work-dev> <200611230900.45633.jkeating@redhat.com> Message-ID: <1164292410.22427.33.camel@gilboa-work-dev> On Thu, 2006-11-23 at 09:00 -0500, Jesse Keating wrote: > On Thursday 23 November 2006 06:55, Gilboa Davara wrote: > > especially when it comes to CPU/memory intensive tasks such as > > dep-solving. > > Except that the depsolving is done by rpm libraries which are C, so invalid > argument. > I stand corrected then. My mistake. > Also the "slow" process of loading metadata in from disk has an optional > (installed by default) c plugin to speed that part up. I know I'll be flogged for asking it... which one? (The only I'm aware of [and using] is fastestmirror [1]) - Gilboa [1] http://wiki.linux.duke.edu/YumPlugins From pertusus at free.fr Thu Nov 23 14:37:30 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 23 Nov 2006 15:37:30 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: References: Message-ID: <20061123143730.GC2778@free.fr> > > 3) are there more light-weight desktops/WMs than xfce? Recently, it > seems it also has become bloated, e.g.,: There is also fluxbox and openbox. Currently they lack some features available in xfce (automounting of removable devices, pager, working battery dockapp...) but that's not inherent to these apps, and has more to do with the fact that they have less users and packagers in fedora. Lately there was more interest, but it seems to have fallen down. -- Pat From jakub at redhat.com Thu Nov 23 14:39:53 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Nov 2006 09:39:53 -0500 Subject: Static linking considered harmful In-Reply-To: <20061123143137.GB2778@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123143137.GB2778@free.fr> Message-ID: <20061123143953.GM6570@devserv.devel.redhat.com> On Thu, Nov 23, 2006 at 03:31:37PM +0100, Patrice Dumas wrote: > Does the fact that an application is linked with libdl means that it > is useless if linked statically, or is it possible that some features > only are unavailable? It is useless if you want to move it between distros, as it will often just crash. Jakub From andy at warmcat.com Thu Nov 23 14:38:48 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 23 Nov 2006 14:38:48 +0000 Subject: Reducing Fedora memory footprint? In-Reply-To: <200611230900.45633.jkeating@redhat.com> References: <1164282920.22427.16.camel@gilboa-work-dev> <200611230900.45633.jkeating@redhat.com> Message-ID: <4565B278.7000201@warmcat.com> Jesse Keating wrote: > On Thursday 23 November 2006 06:55, Gilboa Davara wrote: >> especially when it comes to CPU/memory intensive tasks such as >> dep-solving. > > Except that the depsolving is done by rpm libraries which are C, so invalid > argument. I was told by JBJ that the cause of the memory bloat is rpmlib maintaining in memory two lists of filepaths from every package involved. One is apparently trying to detect symlinks by holding device and inode information along with the filepath, and the other is a btree type representation of each path level that is rapidly searchable. He had ideas for fixing both if anyone wants to reach out. I took a look at the sources and crept away with my tail between my legs. -Andy From mlichvar at redhat.com Thu Nov 23 14:51:25 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 23 Nov 2006 15:51:25 +0100 Subject: removing termcap In-Reply-To: <1164244207.32083.19.camel@localhost.localdomain> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> Message-ID: <20061123145125.GA31803@localhost> On Wed, Nov 22, 2006 at 05:10:07PM -0800, Toshio Kuratomi wrote: > On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > > - Move the most important entries in the terminfo database to > > /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, > > but the second option isn't much better as it will duplicate the > > entries on multiarch. > > I'm assuming that terminfo entries are architecture independent binary > files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. Ok. > It would be a bit odd to find part of the terminfo database > in /lib/terminfo and some in /usr/share/terminfo, though. The database in /usr/share/terminfo will have all entries as there will be a symlink for each entry moved. Ncurses will search in /lib/terminfo only when /usr partition isn't mounted. Which entries are good candidates for moving to /lib? So far I have selected these: linux dumb vt100 vt100-nav vt220 -- Miroslav Lichvar From jkeating at redhat.com Thu Nov 23 14:54:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Nov 2006 09:54:31 -0500 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164292410.22427.33.camel@gilboa-work-dev> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> Message-ID: <200611230954.31577.jkeating@redhat.com> On Thursday 23 November 2006 09:33, Gilboa Davara wrote: > I know I'll be flogged for asking it... which one? (The only I'm aware > of [and using] is fastestmirror [1]) The metaparser. yum-metadata-parser -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Thu Nov 23 15:09:48 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 23 Nov 2006 18:09:48 +0300 Subject: removing termcap In-Reply-To: <20061123145125.GA31803@localhost> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061123145125.GA31803@localhost> Message-ID: <4565B9BC.2020204@odu.neva.ru> Miroslav Lichvar wrote: >Which entries are good candidates for moving to /lib? So far I have >selected these: > >linux >dumb >vt100 >vt100-nav >vt220 > > > ascii xterm ~buc From buc at odusz.so-cdu.ru Thu Nov 23 15:14:44 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 23 Nov 2006 18:14:44 +0300 Subject: removing termcap In-Reply-To: <4565B9BC.2020204@odu.neva.ru> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061123145125.GA31803@localhost> <4565B9BC.2020204@odu.neva.ru> Message-ID: <4565BAE4.4030401@odu.neva.ru> Dmitry Butskoy wrote: >> Which entries are good candidates for moving to /lib? So far I have >> selected these: >> >> linux >> dumb >> vt100 >> vt100-nav >> vt220 >> >> >> > ascii > xterm Oops, sorry, surely "ansi", not ascii... :) ansi xterm ~buc From gilboad at gmail.com Thu Nov 23 15:30:18 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Nov 2006 17:30:18 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: <200611230954.31577.jkeating@redhat.com> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> Message-ID: <1164295818.22427.44.camel@gilboa-work-dev> On Thu, 2006-11-23 at 09:54 -0500, Jesse Keating wrote: > On Thursday 23 November 2006 09:33, Gilboa Davara wrote: > > I know I'll be flogged for asking it... which one? (The only I'm aware > > of [and using] is fastestmirror [1]) > > The metaparser. yum-metadata-parser > Oh... OK. Already have it installed. yum/FC6 is indeed faster then FC4/5. I apologize for stirring the hornet's nest, but on a low end machine (P2/366, 256MB) even with metadata-parser -and- fastestmirror, yum is slower by an order of magnitude than apt-get (both apt-rpm and Debian's apt) and slapt-get (slackware) and requires twice as much memory. I'm talking about "yum -y -C update" compared to "apt-get -y dist-upgrade" Am I the only one having this problem? Did anyone try to instrument yum in-order to solve this problem? - Gilboa From Lam at Lam.pl Thu Nov 23 17:04:05 2006 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 23 Nov 2006 18:04:05 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164295818.22427.44.camel@gilboa-work-dev> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> Message-ID: <1164301445.16256.14.camel@pensja.lam.pl> Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara napisa?(a): > yum is slower by an order of magnitude than apt-get > Am I the only one having this problem? Well, on this machine, yum -C update takes 14-18 seconds and apt-get dist-upgrade takes 9-11 seconds to resolve everything and ask me if I want to download. At this point, yum takes 7 MiB of memory (ps's SZ), while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to resolve dependencies, but 30 when you tell it to commit). I still prefer apt for lots of other reasons, but nowadays it's not so much faster and doesn't look lighter at all. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From aph at redhat.com Thu Nov 23 17:07:38 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2006 17:07:38 +0000 Subject: Static linking considered harmful In-Reply-To: <20061123121317.GC14710@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123121317.GC14710@devserv.devel.redhat.com> Message-ID: <17765.54618.892459.602177@zebedee.pink> Alan Cox writes: > On Wed, Nov 22, 2006 at 11:32:09PM -0800, Ulrich Drepper wrote: > > Why? This makes no sense. You have to provide arguments for each .a > > file. As I said, you cannot even build a graphical application without > > Why do you have to provide arguments for each .a file ? > > > libdl. And all server apps are security relevant and should never use > > static linking for anything which doesn't come with the package. > > And if the user happens to disagree with you... ? The core problem is this: more and more, the implementors of crucial system libraries are assuming that the users will not use static linkage. (There is a bunch of good reasons for this, as Uli explained.) However, many application writers still use static linkage, and these application writers either don't know or don't care that various random things are going to fail if they continue to link statically. So, we need somehow to communicate to the application writers that they need to stop linking statically. One rather brutal way to do this is simply not to provide static libraries. That would suit me. However, I can understand that no matter how much explanation we do, some people will continue to want static libraries. For them, your separate RPM solution makes sense. The fact that they have had to download a separate static library means they can't say that they weren't warned. Andrew. From thomas.canniot at laposte.net Thu Nov 23 17:46:11 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Thu, 23 Nov 2006 18:46:11 +0100 Subject: Help improving translation In-Reply-To: <1164271183.3344.18.camel@localhost.localdomain> References: <1164271183.3344.18.camel@localhost.localdomain> Message-ID: <1164303971.3342.12.camel@localhost.localdomain> Le jeudi 23 novembre 2006 ? 11:03 +0100, Xavier Conde Rueda a ?crit : > Hi Thomas, > > > > > I have been translating fedora in French for few months only and i'm > > facing problems with contributors' translations. > > > > I used to translate po files, and, as we were very few French > > translators (2 *only*), it was quite easy to ask for the mate to read > > over the translation and to know what he is actually doing. > > > > However, now that I have less free time and now that we are more than 2 > > translating Fedora into French, when I take the initiative to translate > > 2 or 3 missing or recently added strings, I met bad translation and > > mistakes. > > > > There are few problems in our translation process : > > > > - People are not communicating by mailing list. The fact is that > > translation is often seen as a lonely activity and that you don't need > > any response from someone to take a po file and translate it. There is > > no way to know who is working on what. > > -- This is bad management. You should fix that by yourself. As the > project leader, you should query the status of translations. On > voluntary projects it's important to track the status of other's work, > since they don't have an economical commitment, also people is very > selective on what they spend their free time. > I am not a project leader. I am just someone who learned English at university and who just see mistakes more than others tranlsators do. > > > > - The status page [1] are useful to know what has been translated, but > > useless to know what has been read over. > > - People do not use the reservation system "take" button and if they do, > > they don't update they reservation. > > -- You should assign translations to translators. Only one person > should have commit access for a given project. When people wants to > translate something, send them the PO file. You should manage by > yourself who is doing what. A simple spreadsheet will do. > How to step back with people who already have all the rights ? I can't *obviously* take them this right back, nor I want to. I don't want to be the one who decide, because I believe people are able enough to decide for themselves. If people want to translate something, then they do it, it's their choice. Nobody should have a word about what they would want to do, as long as it is good for the Project. > > Anyway, I find the take button completely useless, not to mention the > bunch of mails saying it's going to expire soon. I suppose people > doesn't want to get 5 mails each time they take a module, so they do > it once, but not twice :). It's not good for synchronization. > So do I. > > > What I'm planning to do : take every po file, and read over them until > > FC7 comes out. This is the only way I found to avoid bad translation in > > Fedora. > > > > Any advice to help out ? > > > > As we are changing lots of things on Fedora, wouldn't be the time to > > improve the translation process : > > - we shouldn't give anymore rights to upload CVS translation. CVS should > > only be accessible in read only and only people that read translation > > over should be allowed to update po to the CVS. > > -- As I said, only project leaders should have commit access, not everybody. > > > - as there is mailing list for modifications on CVS docs, we need a > > mailing list as well for each language po modification. Mailing list are > > easy to set up and do not consume any ressources. > > -- There is a commits list you can subscribe, it will do for you. But > it's the same thing, only you should be committing. Personally, for > Catalan we don't need it. Not sure we need it for every language. The problem of *leader* is that one day, I may not be as available as other people would like me to. We are facing this problem in France, and the leader of the GNOME translation Project is not very well seen by people. The French GNOME community is divided and does not work to its full capabilities. > > > - we could also use a system allowing to add a status of what has to be > > done with a po file : "waiting for translation", "waiting for being read > > over", "translation in progress" for example, are status that could be > > used. > > -- If Fedora provides a full web translation management environment it > would be great. However, a wiki page could be used, where each > contributor writes down the status of their current translation. If they do so, they could actually mail the list, that they don't do. Why would they write it on a wiki page ? I think we are more at a state where people should be obliged to tell the status of their translation to commit it. > > Regards! > > > just my 2 cents. > > > > [1] http://i18n.redhat.com/cgi-bin/i18n-status > > -- > > Thomas Canniot > > http://fedoraproject.org/wiki/ThomasCanniot > > > -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From gilboad at gmail.com Thu Nov 23 17:49:32 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Nov 2006 19:49:32 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164301445.16256.14.camel@pensja.lam.pl> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> Message-ID: <1164304172.22427.81.camel@gilboa-work-dev> On Thu, 2006-11-23 at 18:04 +0100, Leszek Matok wrote: > Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara napisa?(a): > > yum is slower by an order of magnitude than apt-get > > > Am I the only one having this problem? > Well, on this machine, yum -C update takes 14-18 seconds and apt-get > dist-upgrade takes 9-11 seconds to resolve everything and ask me if I > want to download. At this point, yum takes 7 MiB of memory (ps's SZ), > while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to > resolve dependencies, but 30 when you tell it to commit). I still prefer > apt for lots of other reasons, but nowadays it's not so much faster and > doesn't look lighter at all. > > Lam I'll be the first one to admit that my information is subjective and lacking. But here's a small test [1] I just conducted on my workstation (2Sx2Cx4G machine) which has Debian guest running under vmware-server. (Be aware that the guest is limited to 512MB and uses two VCPUs) Step0: Get all the recent updates for both OS. (yum -C -y update [FC6 host]; apt-get -y update && apt-get -y dist-upgade [Debian guest]) Test1: Measure the time it takes to run a clean update cycle (Read: no downloads required, minimal network interaction). Test2: Measure the time it takes to search one package. (Again from cache) Look at the numbers below: Test1: Network enabled "apt-get update; apt-get -y dist-upgrade" is twice as fast as cache based "yum -C update". Test2: Cache bases "apt-cache search" is >20 times faster then cache based "yum -c search". Again, be aware that the host machine is considerably (?) faster then the guest machine. As I said before, I'm not trying to start a flame war - I trying to raise a point. God knows I won't switch to Debian just because I find yum to be slower and resources intensive. - Gilboa [1] Actual test result. -------------------------------------------------------------------------------------- FC6/x86_64 Host: -------------------------------------------------------------------------------------- [root at gilboa-work-dev gilboa]# time yum -C -y update Loading "installonlyn" plugin Loading "fastestmirror" plugin Loading "fedorakmod" plugin Loading "kernel-module" plugin Loading "skip-broken" plugin Setting up Update Process Setting up repositories Loading mirror speeds from cached hostfile Reading repository metadata in from local files No Packages marked for Update/Obsoletion real 0m6.072s user 0m1.408s sys 0m0.232s [root at gilboa-work-dev gilboa]# yum -C search kdeartwork Loading "installonlyn" plugin Loading "fastestmirror" plugin Loading "fedorakmod" plugin Loading "kernel-module" plugin Loading "skip-broken" plugin Setting up repositories Loading mirror speeds from cached hostfile Reading repository metadata in from local files [SNIP] real 0m12.829s user 0m7.364s sys 0m1.104s -------------------------------------------------------------------------------------- Debian guest: -------------------------------------------------------------------------------------- root at gilboa-vmw-probe ~# time (apt-get update && apt-get -y dist-upgrade) Get:1 http://mirror.hamakor.org.il etch Release.gpg [378B] Hit http://mirror.hamakor.org.il etch Release Hit http://mirror.hamakor.org.il etch/main Packages/DiffIndex Hit http://mirror.hamakor.org.il etch/main Sources/DiffIndex Get:2 http://security.debian.org etch/updates Release.gpg [189B] Hit http://security.debian.org etch/updates Release Ign http://security.debian.org etch/updates/main Packages/DiffIndex Ign http://security.debian.org etch/updates/main Sources/DiffIndex Hit http://security.debian.org etch/updates/main Packages Hit http://security.debian.org etch/updates/main Sources Fetched 2B in 2s (1B/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. real 0m3.078s user 0m0.556s sys 0m0.512s root at gilboa-vmw-probe ~# time apt-cache search kdeartwork kdeartwork - themes, styles and more from the official KDE release kdeartwork-dbg - debugging symbols for kdeartwork kdeartwork-emoticons - emoticon collections for KDE chat clients kdeartwork-misc - various multimedia goodies released with KDE kdeartwork-style - widget styles released with KDE kdeartwork-theme-icon - icon themes released with KDE kdeartwork-theme-window - window decoration themes released with KDE kdewallpapers - wallpapers released with KDE kscreensaver - additional screen savers released with KDE kscreensaver-xsavers - KDE hooks for standard xscreensavers kworldclock - earth watcher for KDE real 0m0.314s user 0m0.292s sys 0m0.020s From giallu at gmail.com Thu Nov 23 18:06:55 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 23 Nov 2006 19:06:55 +0100 Subject: FC6 on a HP DC7700 Message-ID: Hi all, I just put my hands on a shiny HP DC7700, a Core 2 Duo based PC, but I can't boot the installer because it hangs right after detecting keyboard and mouse (PS/2) Does anyone experienced similar issues? googling around I already find some (scary...) info, and tried w/o luck booting with acpi=off (boot, but it seems like hanging on every screen, then eventually go on with the next after some minutes!), noapic and nolapic. any help appreciated Cheers Gianluca From admin at zapped.2y.net Thu Nov 23 18:10:09 2006 From: admin at zapped.2y.net (Erik van Pienbroek) Date: Thu, 23 Nov 2006 19:10:09 +0100 Subject: Static linking considered harmful In-Reply-To: <17765.54618.892459.602177@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123121317.GC14710@devserv.devel.redhat.com> <17765.54618.892459.602177@zebedee.pink> Message-ID: <1164305409.12571.3.camel@localhost.localdomain> Op donderdag 23-11-2006 om 17:07 uur [tijdzone +0000], schreef Andrew Haley: > However, many application writers still use static > linkage, and these application writers either don't know or don't care > that various random things are going to fail if they continue to link > statically. Okay, I get the point that static linking is evil, but what would then be the proper way to compile a application which is able to run across multiple Linux distro's ? The first thing that comes in my mind is bundling your own shared libraries with the application, but for that to work the LD_LIBRARY_PATH= hack is needed, which is also evil. Erik van Pienbroek From Lam at Lam.pl Thu Nov 23 18:27:37 2006 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 23 Nov 2006 19:27:37 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164304172.22427.81.camel@gilboa-work-dev> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> Message-ID: <1164306457.16256.31.camel@pensja.lam.pl> Now you're comparing apples and oranges. I was talking about apt from Extras, using repomd repositories. You're comparing yum with Debian's apt with their repos (different number of files and packages; should be greater, but I don't know if "main" contains all their packages, or is it something like our "Core"). apt-rpm also has its own repo format which is much faster to download and parse than repomd. You should check it out :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From arjan at fenrus.demon.nl Thu Nov 23 18:35:23 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 23 Nov 2006 19:35:23 +0100 Subject: FC6 on a HP DC7700 In-Reply-To: References: Message-ID: <1164306923.3147.1.camel@laptopd505.fenrus.org> On Thu, 2006-11-23 at 19:06 +0100, Gianluca Sforna wrote: > Hi all, > I just put my hands on a shiny HP DC7700, a Core 2 Duo based PC, but I > can't boot the installer because it hangs right after detecting > keyboard and mouse (PS/2) > > Does anyone experienced similar issues? try nmi_watchdog=0 another thing to try is disabling USB PS/2 emulation in the bios... From kevin.kofler at chello.at Thu Nov 23 21:24:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 23 Nov 2006 21:24:51 +0000 (UTC) Subject: Fedora on a Norhtec MicroClient Jr. [Was: Reducing Fedora memory footprint?] References: Message-ID: Gianluca Sforna gmail.com> writes: > Talking about small footprint, > does anyone tried to install fedora on something like the MicroClient Jr.? > > http://www.norhtec.com/products/mcjr/index.html > > it has only 128Mb of RAM but but I could imagine a lot of applications > for it at home once fedora will be up and running... I didn't try it (I don't have that piece of hardware), but if anyone wants to try it: 1. add a HDD, IMHO there's no way Fedora is going to fit on that CompactFlash card no matter how hard you try. 2. install FC5 with Slinky. 3. upgrade to FC6 using apt-rpm. That should get you up and running. I'd recommend against fighting with Anaconda with 128 MB RAM these days. Kevin Kofler From noriko at redhat.com Fri Nov 24 00:07:18 2006 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 24 Nov 2006 10:07:18 +1000 Subject: Help improving translation In-Reply-To: <1164271183.3344.18.camel@localhost.localdomain> References: <1164271183.3344.18.camel@localhost.localdomain> Message-ID: <456637B6.8070002@redhat.com> Hello~ Thomas Canniot wrote: > There are few problems in our translation process : > > - People are not communicating by mailing list. The fact is that > translation is often seen as a lonely activity and that you don't need > any response from someone to take a po file and translate it. There is > no way to know who is working on what. How are they communicating then? If they do not communicate at all, but going their own, then you can ask them, no? Assuming the mailing list pointed here is fedora-trans-fr, keep posting then people can have a chance to learn proper way. It might be also useful to copy and paste the diff, so others can easily proofread. This is what fedora-trans-ja doing and I've learn it from there. > - The status page [1] are useful to know what has been translated, but > useless to know what has been read over. > - People do not use the reservation system "take" button and if they do, > they don't update they reservation. Aman and Chester: PING! I thought that people can not commit without clicking "take" button. Can you take a look? > > What I'm planning to do : take every po file, and read over them until > FC7 comes out. This is the only way I found to avoid bad translation in > Fedora. Howabout being the maintainer, so that the mail will be sent to you if someone translated the file. cheers noriko From linux at glossolalie.org Fri Nov 24 00:21:03 2006 From: linux at glossolalie.org (Thierry Sayegh De Bellis) Date: Fri, 24 Nov 2006 00:21:03 +0000 Subject: Help improving translation In-Reply-To: <1164271183.3344.18.camel@localhost.localdomain> References: <1164271183.3344.18.camel@localhost.localdomain> Message-ID: <45663AEF.3080305@glossolalie.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Canniot wrote: > Hello, > > First, I apologise to fedora-trans-list to mail this message again. > > I have been translating fedora in French for few months only and i'm > facing problems with contributors' translations. > > I used to translate po files, and, as we were very few French > translators (2 *only*), it was quite easy to ask for the mate to read > over the translation and to know what he is actually doing. > > However, now that I have less free time and now that we are more than 2 > translating Fedora into French, when I take the initiative to translate > 2 or 3 missing or recently added strings, I met bad translation and > mistakes. > this is a classic L18N issue > There are few problems in our translation process : > > - People are not communicating by mailing list. The fact is that > translation is often seen as a lonely activity and that you don't need > any response from someone to take a po file and translate it. There is > no way to know who is working on what. > - The status page [1] are useful to know what has been translated, but > useless to know what has been read over. > - People do not use the reservation system "take" button and if they do, > they don't update they reservation. > You need to handle the process as a formal project, with translation, revision/proofreading and Q&A > > What I'm planning to do : take every po file, and read over them until > FC7 comes out. This is the only way I found to avoid bad translation in > Fedora. > > Any advice to help out ? UI stings can be messy but you need to establish a kind of 'master glossary' > > As we are changing lots of things on Fedora, wouldn't be the time to > improve the translation process : > - we shouldn't give anymore rights to upload CVS translation. CVS should > only be accessible in read only and only people that read translation > over should be allowed to update po to the CVS. > - as there is mailing list for modifications on CVS docs, we need a > mailing list as well for each language po modification. Mailing list are > easy to set up and do not consume any ressources. > - we could also use a system allowing to add a status of what has to be > done with a po file : "waiting for translation", "waiting for being read > over", "translation in progress" for example, are status that could be > used. > > just my 2 cents. > > [1] http://i18n.redhat.com/cgi-bin/i18n-status Allow me to jump in as I am a sysadmin who used to lead a translation department in another life... a localization workflow is pretty easy to set up provided you have some quick checks or milestones. I am willing to help on this as I am familiar with SCM on the one hand and CAT tools on the other. I appreciate that there is some kind of process already into place but it's never too late. I have not followed the translation lifecycle of Fedora as I use it in English (I am based in the UK) but being a French native with formal L18N experience give me a shout and we can probably formalise a way forward Thierry - -- (o< Thierry Sayegh de Bellis, RHCE //\ http://glossolalie.com V_/_ Fingerprint: 9976 11FE D9C6 8C67 6242 7BB1 6466 3F1D 56ED 7D5A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZjrvZGY/HVbtfVoRAsGQAKCt4hqzMy4xn3yT9nCGJH+H7ljGNACgtewX lD2RQ1WNitvNTl2BmtIDhXY= =5bR+ -----END PGP SIGNATURE----- From nmiell at comcast.net Fri Nov 24 02:32:37 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Thu, 23 Nov 2006 18:32:37 -0800 Subject: removing termcap In-Reply-To: <20061121174945.GC7982@localhost> References: <20061121174945.GC7982@localhost> Message-ID: <1164335557.2871.5.camel@entropy> On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > Hi, > > I would like to see termcap and libtermcap removed, and to use ncurses > everywhere. termcap is an obsolete system for describing terminal > capabilities, it has annoying size limitations for the description and > libtermcap is an old, unmaintained code. > > The ncurses library has a termcap emulation which is internally using > terminfo database. It isn't 100% accurate (see curs_termcap(3)), but > should be ok for most applications. libtermcap's API and ABI are > compatible with ncurses. So what would be required to replace > completely libtermcap with ncurses? [...] > - Rebuild packages currently using libtermcap against ncurses. It > would be good to choose one of libncurses{,w} and link all binaries > with it; linking with libncursesw will probably require more patching > of configure scripts as some of them are prepared for libncurses > already. touch libtermcap.c gcc -shared -fPIC -Wl,-soname=libtermcap.so.2 -lncurses -o libtermcap.so and then if you ship the created libtermcap.so with ncurses, you don't have to rebuild or relink anything. -- Nicholas Miell From aalam at redhat.com Fri Nov 24 06:02:23 2006 From: aalam at redhat.com (A S Alam) Date: Fri, 24 Nov 2006 11:32:23 +0530 Subject: Help improving translation In-Reply-To: <456637B6.8070002@redhat.com> References: <1164271183.3344.18.camel@localhost.localdomain> <456637B6.8070002@redhat.com> Message-ID: <45668AEF.1060507@redhat.com> Noriko Mizumoto ?? ?????: > Hello~ > > Thomas Canniot wrote: >> There are few problems in our translation process : >> >> - People are not communicating by mailing list. The fact is that >> translation is often seen as a lonely activity and that you don't need >> any response from someone to take a po file and translate it. There is >> no way to know who is working on what. > > How are they communicating then? If they do not communicate at all, but > going their own, then you can ask them, no? > Assuming the mailing list pointed here is fedora-trans-fr, keep posting > then people can have a chance to learn proper way. It might be also > useful to copy and paste the diff, so others can easily proofread. This > is what fedora-trans-ja doing and I've learn it from there. > >> - The status page [1] are useful to know what has been translated, but >> useless to know what has been read over. >> - People do not use the reservation system "take" button and if they do, >> they don't update they reservation. > > Aman and Chester: PING! > I thought that people can not commit without clicking "take" button. Can > you take a look? no, this not true, 'Take' button is not very effective, I myself commit to CVS without 'Take' Button.:) >> >> What I'm planning to do : take every po file, and read over them until >> FC7 comes out. This is the only way I found to avoid bad translation in >> Fedora. > > Howabout being the maintainer, so that the mail will be sent to you if > someone translated the file. > this is solution to get information when someone commit or change a file, for which you are Maintainer regrds -- A S Alam timezone: GMT+5:30 join us at #fedora-l10n (freenode) "Either find a way or make one" From aalam at redhat.com Fri Nov 24 06:07:14 2006 From: aalam at redhat.com (A S Alam) Date: Fri, 24 Nov 2006 11:37:14 +0530 Subject: Help improving translation In-Reply-To: <45668AEF.1060507@redhat.com> References: <1164271183.3344.18.camel@localhost.localdomain> <456637B6.8070002@redhat.com> <45668AEF.1060507@redhat.com> Message-ID: <45668C12.3040209@redhat.com> A S Alam ?? ?????: > Noriko Mizumoto ?? ?????: >> Hello~ >> >> Thomas Canniot wrote: >>> There are few problems in our translation process : >>> >>> - People are not communicating by mailing list. The fact is that >>> translation is often seen as a lonely activity and that you don't need >>> any response from someone to take a po file and translate it. There is >>> no way to know who is working on what. >> >> How are they communicating then? If they do not communicate at all, >> but going their own, then you can ask them, no? >> Assuming the mailing list pointed here is fedora-trans-fr, keep >> posting then people can have a chance to learn proper way. It might be >> also useful to copy and paste the diff, so others can easily >> proofread. This is what fedora-trans-ja doing and I've learn it from >> there. >> >>> - The status page [1] are useful to know what has been translated, but >>> useless to know what has been read over. >>> - People do not use the reservation system "take" button and if they do, >>> they don't update they reservation. >> >> Aman and Chester: PING! >> I thought that people can not commit without clicking "take" button. >> Can you take a look? > no, this not true, 'Take' button is not very effective, I myself commit to > CVS without 'Take' Button.:) > and of course as normal user (with external account) -- A S Alam timezone: GMT+5:30 join us at #fedora-l10n (freenode) "Either find a way or make one" From gilboad at gmail.com Fri Nov 24 06:42:38 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 24 Nov 2006 08:42:38 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164306457.16256.31.camel@pensja.lam.pl> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> Message-ID: <1164350558.5589.1.camel@gilboa-home-dev.localhost> On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote: > Now you're comparing apples and oranges. I was talking about apt from > Extras, using repomd repositories. You're comparing yum with Debian's > apt with their repos (different number of files and packages; should be > greater, but I don't know if "main" contains all their packages, or is > it something like our "Core"). > > apt-rpm also has its own repo format which is much faster to download > and parse than repomd. You should check it out :) > > Lam I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and last time I checked, apt has lousy bi-arch support. (Did it improve) FYI I'm using Debian unstable which has comparable number of packages. - Gilboa From rc040203 at freenet.de Fri Nov 24 08:06:22 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Nov 2006 09:06:22 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164350558.5589.1.camel@gilboa-home-dev.localhost> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> Message-ID: <1164355582.19112.259.camel@mccallum.corsepiu.local> On Fri, 2006-11-24 at 08:42 +0200, Gilboa Davara wrote: > On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote: > > Now you're comparing apples and oranges. I was talking about apt from > > Extras, using repomd repositories. You're comparing yum with Debian's > > apt with their repos (different number of files and packages; should be > > greater, but I don't know if "main" contains all their packages, or is > > it something like our "Core"). > > > > apt-rpm also has its own repo format which is much faster to download > > and parse than repomd. You should check it out :) That's true. Accessing metadata repos (aka yum repos) with apt, causes apt to regress quite significantly "memory-footprint" wise in comparison to accessing apt-native repos. If you want to try it, set up yum and apt-repos containing rpms and try to access them with FE's apt (Or find an external repo which supports both apt and yum-repos.) This apt is supposed to support both styles of repos. >From what I have tested (on an i586/166MHz with 64MB RAM and FC6 installed) both, yum and apt using yum-repos, both end up with using comparable amounts of memory, with slight advantages for yum. > I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and > last time I checked, apt has lousy bi-arch support. (Did it improve) The apt-version in FE should be able to handle bi-arched Fedora. > FYI I'm using Debian unstable which has comparable number of packages. Which doesn't mean much, because handling rpms and debs in apt are completely different code bases. Ralf From jochen.schlick at comsoft.de Fri Nov 24 08:32:19 2006 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Fri, 24 Nov 2006 09:32:19 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: <1164350558.5589.1.camel@gilboa-home-dev.localhost> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> Message-ID: <4566AE13.8020807@comsoft.de> Gilboa Davara wrote: > On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote: >> Now you're comparing apples and oranges. I was talking about apt from >> Extras, using repomd repositories. You're comparing yum with Debian's >> apt with their repos (different number of files and packages; should be >> greater, but I don't know if "main" contains all their packages, or is >> it something like our "Core"). >> >> apt-rpm also has its own repo format which is much faster to download >> and parse than repomd. You should check it out :) >> >> Lam > > I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and > last time I checked, apt has lousy bi-arch support. (Did it improve) > FYI I'm using Debian unstable which has comparable number of packages. > > - Gilboa > > To get comparable results for apt-rpm and yum try to create your own Rawhide-mirror ! So you can update using apt and/or yum. My local mirror for my home network is a rpm-apt-server for at least 1 year, because yum/kyum... are definitely not usable on older machines (<1Ghz, <256MB) whereas apt-get/synaptic are still usable. The repository creation on the server using the yum-repo-tools after rsyncing with one of the Rawhide-Servers consumed also too much time. best regards -- ------------------------------------------------------------ Jochen Schlick From pmatilai at laiskiainen.org Fri Nov 24 08:32:48 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 24 Nov 2006 10:32:48 +0200 (EET) Subject: Reducing Fedora memory footprint? In-Reply-To: <200611230900.45633.jkeating@redhat.com> References: <1164282920.22427.16.camel@gilboa-work-dev> <200611230900.45633.jkeating@redhat.com> Message-ID: On Thu, 23 Nov 2006, Jesse Keating wrote: > On Thursday 23 November 2006 06:55, Gilboa Davara wrote: >> especially when it comes to CPU/memory intensive tasks such as >> dep-solving. > > Except that the depsolving is done by rpm libraries which are C, so invalid > argument. Except that's not quite true either. Part of the depsolving is done with rpmlib calls: yum loads rpm headers into a transaction and gets lists of missing dependencies, looking for packages providing those dependencies is done by yum itself. In FC6 the hideous yum slowdown comes largely from reopening the rpmdb literally hundreds of times. Check out https://lists.dulug.duke.edu/pipermail/yum-devel/2006-November/002870.html for some metrics. Yum 3.0.1 isn't *that* bad, but 3.0 is dog slow whereas 2.9.6 was lightning fast. - Panu - From rc040203 at freenet.de Fri Nov 24 09:12:44 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Nov 2006 10:12:44 +0100 Subject: Reducing Fedora memory footprint? In-Reply-To: <4566AE13.8020807@comsoft.de> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> <4566AE13.8020807@comsoft.de> Message-ID: <1164359564.19112.290.camel@mccallum.corsepiu.local> On Fri, 2006-11-24 at 09:32 +0100, Jochen Schlick wrote: > My local mirror for my home network is a rpm-apt-server for at least > 1 year, because yum/kyum... are definitely not usable on older machines > (<1Ghz, <256MB) whereas apt-get/synaptic are still usable. Hmm, what am I running on my old i586/166MHz/64MB RAM notebook? # time yum update -y ... [d/l'ing and installing 2 average sized packages] ... real 6m49.293s user 1m56.081s sys 0m33.872s slow .. yes, but still usable ;) Running anaconda (Upgrading or installing fedora on this machine is fun) or kyum (I've never used it) probably is a different matter. Ralf From pmatilai at laiskiainen.org Fri Nov 24 09:43:47 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 24 Nov 2006 11:43:47 +0200 (EET) Subject: Reducing Fedora memory footprint? In-Reply-To: <1164301445.16256.14.camel@pensja.lam.pl> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> Message-ID: On Thu, 23 Nov 2006, Leszek Matok wrote: > Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara napisa??(a): >> yum is slower by an order of magnitude than apt-get > >> Am I the only one having this problem? > Well, on this machine, yum -C update takes 14-18 seconds and apt-get > dist-upgrade takes 9-11 seconds to resolve everything and ask me if I > want to download. You'll see a LOT bigger gap in times as the amount of depsolving increases, for example fc5 -> fc6 upgrade set. Apt will resolve that in a few additional seconds (obviously depending on installed package set, computer speed etc) compared to "empty upgrade" whereas yum is going to take minutes, even with all metadata and headers locally cached. Just try timing 'apt-cache unmet' vs 'repoclosure' (from yum-utils) :) On small sets yum can actually be faster than apt, largely due to the fact that apt calculates a full dependency tree of the available package universe, whereas yum deals with them in "solve them when needed" basis. > At this point, yum takes 7 MiB of memory (ps's SZ), > while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to > resolve dependencies, but 30 when you tell it to commit). I still prefer > apt for lots of other reasons, but nowadays it's not so much faster and > doesn't look lighter at all. Yup, apt isn't *that* light on memory use, due to various reasons: - when using repomd, it holds the whole primary.xml file in memory for a repository at a time, that can consume boatloads of memory (this is something I have plans to fix eventually) - as mentioned earlier, it keeps a precalculated dependency tree of all packages in memory at all times - Panu - From mlichvar at redhat.com Fri Nov 24 09:46:35 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 24 Nov 2006 10:46:35 +0100 Subject: removing termcap In-Reply-To: <1164335557.2871.5.camel@entropy> References: <20061121174945.GC7982@localhost> <1164335557.2871.5.camel@entropy> Message-ID: <20061124094635.GA12874@localhost> On Thu, Nov 23, 2006 at 06:32:37PM -0800, Nicholas Miell wrote: > On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > > - Rebuild packages currently using libtermcap against ncurses. It > > would be good to choose one of libncurses{,w} and link all binaries > > with it; linking with libncursesw will probably require more patching > > of configure scripts as some of them are prepared for libncurses > > already. > > touch libtermcap.c > gcc -shared -fPIC -Wl,-soname=libtermcap.so.2 -lncurses -o libtermcap.so > > and then if you ship the created libtermcap.so with ncurses, you don't > have to rebuild or relink anything. I'm not sure we want to conflict with libtermcap. There might be an application that needs the original libtermcap as the emulation ncurses provides isn't perfect. -- Miroslav Lichvar From pmatilai at laiskiainen.org Fri Nov 24 10:05:26 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 24 Nov 2006 12:05:26 +0200 (EET) Subject: Reducing Fedora memory footprint? In-Reply-To: <1164350558.5589.1.camel@gilboa-home-dev.localhost> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> Message-ID: On Fri, 24 Nov 2006, Gilboa Davara wrote: > On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote: >> Now you're comparing apples and oranges. I was talking about apt from >> Extras, using repomd repositories. You're comparing yum with Debian's >> apt with their repos (different number of files and packages; should be >> greater, but I don't know if "main" contains all their packages, or is >> it something like our "Core"). >> >> apt-rpm also has its own repo format which is much faster to download >> and parse than repomd. You should check it out :) >> >> Lam > > I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and > last time I checked, apt has lousy bi-arch support. (Did it improve) Apt works on x86_64 nowadays but can't handle some cross-arch cases like upgrading from 32bit to 64bit version (eg OOo changed from 32bit to 64bit between fc5 to fc6). Yum's bi-arch support is lightyears ahead anyway :) > FYI I'm using Debian unstable which has comparable number of packages. Debian apt is not comparable at all due to differences in package and repository metadata differences; Debian uses flat text files whereas we have rather heavyweight XML to wrestle with. - Panu - From pnasrat at redhat.com Fri Nov 24 10:08:56 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 24 Nov 2006 10:08:56 +0000 Subject: Todays Rawhide Compose Message-ID: <1164362936.1539.118.camel@enki.eridu> There seems to have been an issue with today's rawhide compose. It's been escalated, but as it's a US holiday it may not land today. Apologies for any inconvenience Paul From aph at redhat.com Fri Nov 24 10:09:58 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2006 10:09:58 +0000 Subject: Static linking considered harmful In-Reply-To: <1164305409.12571.3.camel@localhost.localdomain> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123121317.GC14710@devserv.devel.redhat.com> <17765.54618.892459.602177@zebedee.pink> <1164305409.12571.3.camel@localhost.localdomain> Message-ID: <17766.50422.240686.639120@zebedee.pink> Erik van Pienbroek writes: > Op donderdag 23-11-2006 om 17:07 uur [tijdzone +0000], schreef Andrew > Haley: > > However, many application writers still use static > > linkage, and these application writers either don't know or don't care > > that various random things are going to fail if they continue to link > > statically. > > Okay, I get the point that static linking is evil, but what > would then be the proper way to compile a application which > is able to run across multiple Linux distro's ? > The first thing that comes in my mind is bundling your > own shared libraries with the application, but for that to > work the LD_LIBRARY_PATH= hack is needed, which is also evil. I read this a couple of times, and I still don't know what problem you're referring to. The usual technique is simply to provide a wrapper script that sets up whatever environment is required and exec's the application. Andrew. From j.w.r.degoede at hhs.nl Fri Nov 24 10:15:52 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 11:15:52 +0100 Subject: unowned directory problem with /etc/logrotate.d Message-ID: <4566C658.8060307@hhs.nl> Hi all, Many packages drop config files for logrotate in /etc/logrotate.d. without requiring logrotate, which is the owner of /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d for users who don't want logrotate and thus remove it. I see 2 solutions for this: 1) Add "Requires: logrotate" to all packages which put files in /etc/logrotate.d. IMHO this is not good as the user should be able to choose if he wants logrotate or not. 2) Add /etc/logrotate.d to the filesystem package, this is my preferred solution. I would like to hear what others think, before filing a bug against filesystem requesting 2) . Regards, Hans From gilboad at gmail.com Fri Nov 24 10:37:45 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 24 Nov 2006 12:37:45 +0200 Subject: Reducing Fedora memory footprint? In-Reply-To: References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> Message-ID: <1164364665.5589.12.camel@gilboa-home-dev.localhost> On Fri, 2006-11-24 at 12:05 +0200, Panu Matilainen wrote: > On Fri, 24 Nov 2006, Gilboa Davara wrote: > > > On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote: > >> Now you're comparing apples and oranges. I was talking about apt from > >> Extras, using repomd repositories. You're comparing yum with Debian's > >> apt with their repos (different number of files and packages; should be > >> greater, but I don't know if "main" contains all their packages, or is > >> it something like our "Core"). > >> > >> apt-rpm also has its own repo format which is much faster to download > >> and parse than repomd. You should check it out :) > >> > >> Lam > > > > I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and > > last time I checked, apt has lousy bi-arch support. (Did it improve) > > Apt works on x86_64 nowadays but can't handle some cross-arch cases > like upgrading from 32bit to 64bit version (eg OOo changed from 32bit to > 64bit between fc5 to fc6). Yum's bi-arch support is lightyears ahead > anyway :) > > > FYI I'm using Debian unstable which has comparable number of packages. > > Debian apt is not comparable at all due to differences in package and > repository metadata differences; Debian uses flat text files whereas we > have rather heavyweight XML to wrestle with. > > - Panu - > Solution wise - yes, yum and apt are different - but target-wise, they both designed to serve the same purpose. Question is - can yum be optimized (E.g. by replacing the XML parser to a faster/leaner one) - bringing it to a point where the performance difference between Debian's apt and Fedora's yum is less staggering? (Especially in query tasks) - Gilboa From db-fedora at 3di.it Fri Nov 24 10:43:51 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Fri, 24 Nov 2006 11:43:51 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> References: <4566C658.8060307@hhs.nl> Message-ID: <4566CCE7.5020004@3di.it> Hans de Goede wrote: > Many packages drop config files for logrotate in /etc/logrotate.d. > without requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned > /etc/logrotate.d for users who don't want logrotate and thus remove it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be able > to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. > > I would like to hear what others think, before filing a bug against > filesystem requesting 2) . If the package drops a file in logrotate.d, it's likely that it is because something in the package is writing to some log file which the package expects logrotate to operate upon; if logrotate is not there to rotate them, there's a chance of filling /var. I would feel safer with option (1). Thank you for your consideration, Davide Bolcioni -- Paranoia is an afterthought. From j.w.r.degoede at hhs.nl Fri Nov 24 10:56:01 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 11:56:01 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566CCE7.5020004@3di.it> References: <4566C658.8060307@hhs.nl> <4566CCE7.5020004@3di.it> Message-ID: <4566CFC1.5080103@hhs.nl> Davide Bolcioni wrote: > Hans de Goede wrote: > >> Many packages drop config files for logrotate in /etc/logrotate.d. >> without requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned >> /etc/logrotate.d for users who don't want logrotate and thus remove it. >> >> I see 2 solutions for this: >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be able >> to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my >> preferred solution. >> >> I would like to hear what others think, before filing a bug against >> filesystem requesting 2) . > > If the package drops a file in logrotate.d, it's likely that it is > because something in the package is writing to some log file which the > package expects logrotate to operate upon; if logrotate is not there to > rotate them, there's a chance of filling /var. I would feel safer with > option (1). > Currently nothing is stopping me from doing rpm -e logrotate, or rpm -e cron even, thus we already have this problem for default logfiles like /var/log/messages. Now should sysklogd have a "Requires: logrotate cron", I would hate to see that happen, I'm very happy without cron and cleaning /var/log manually sometimes. The default shouldn't fill /var/log, but users shouldn't be forced to have / use logrotate if they don't want to. Regards, Hans From jfrieben at freesurf.fr Fri Nov 24 11:02:50 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Fri, 24 Nov 2006 12:02:50 +0100 (CET) Subject: Testing Fedora - small (?) suggestion. Message-ID: <45411.194.94.224.254.1164366170.squirrel@jose.freesurf.fr> > In fact, for this next development cycle, I'd like to > change how the boot.iso and such work for rawhide, in that it doesn't > KNOW about any packages, rather it just has core and extras as > preselected remote repositories. This way you can use a good > combination of kernel and anaconda to install day after day after day, > and rawhide becomes nothing more than a createrepo call. After previous successful attempts with "FC6" and out-of-sync "rawhide" rescue CDs, I have now even managed to install current "rawhide" by using the "http" install option of the original "FC5" (!) install media which is good news for people plagued by "anaconda" issues [except for very recent hardware] and also allows to lower consumption of CD media for installing "rawhide" systems :) I think the switch to the "yum" based install system with "FC5" was a huge improvement! From enrico.scholz at informatik.tu-chemnitz.de Fri Nov 24 11:17:59 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Nov 2006 12:17:59 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566CCE7.5020004@3di.it> (Davide Bolcioni's message of "Fri, 24 Nov 2006 11:43:51 +0100") References: <4566C658.8060307@hhs.nl> <4566CCE7.5020004@3di.it> Message-ID: <87zmahqejc.fsf@kosh.bigo.ensc.de> db-fedora at 3di.it (Davide Bolcioni) writes: > If the package drops a file in logrotate.d, it's likely that it is > because something in the package is writing to some log file which the > package expects logrotate to operate upon; if logrotate is not there > to rotate them, there's a chance of filling /var. There exist more ways to rotate logfiles; e.g. cfengine. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Nov 24 12:30:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Nov 2006 13:30:56 +0100 (CET) Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> References: <4566C658.8060307@hhs.nl> Message-ID: <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : > Hi all, > > Many packages drop config files for logrotate in /etc/logrotate.d. without > requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d > for users who don't want logrotate and thus remove it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be able > to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users -- Nicolas Mailhot From pmatilai at laiskiainen.org Fri Nov 24 12:52:52 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 24 Nov 2006 14:52:52 +0200 (EET) Subject: Reducing Fedora memory footprint? In-Reply-To: <1164364665.5589.12.camel@gilboa-home-dev.localhost> References: <200611230900.45633.jkeating@redhat.com> <1164292410.22427.33.camel@gilboa-work-dev> <200611230954.31577.jkeating@redhat.com> <1164295818.22427.44.camel@gilboa-work-dev> <1164301445.16256.14.camel@pensja.lam.pl> <1164304172.22427.81.camel@gilboa-work-dev> <1164306457.16256.31.camel@pensja.lam.pl> <1164350558.5589.1.camel@gilboa-home-dev.localhost> <1164364665.5589.12.camel@gilboa-home-dev.localhost> Message-ID: On Fri, 24 Nov 2006, Gilboa Davara wrote: > > Solution wise - yes, yum and apt are different - but target-wise, they > both designed to serve the same purpose. > Question is - can yum be optimized (E.g. by replacing the XML parser to > a faster/leaner one) - bringing it to a point where the performance > difference between Debian's apt and Fedora's yum is less staggering? > (Especially in query tasks) The XML is already parsed by a module written in C and is fast enough not to be a bottleneck I think. The XML files are only read during importing the data into sqlite database, which is then used for all operations (depsolving, querying etc). FWIW, I don't think 'yum search foo' and such are slow at all these days, only the depsolve stage remains a bit of a sore point speedwise. Where exactly the time is spent and how to improve things .. profiling needed :) BTW, Debian packages have far less dependency data in them than an average rpm package does because automatic dependencies and provides are not used there. Just an example: $ dpkg -f libc6_2.3.6.ds1-8_amd64.deb |grep Provides Provides: glibc-2.3.6.ds1-1, glibc-2.3.6-2 Contras that with FC6 glibc: $ rpm -qp --provides glibc-2.5-3.x86_64.rpm |wc -l 300 Looking through 300 provides for matches is more expensive than going through 2 provides :) glibc is a bit of an extreme case of course, not every package is *that* bloated with soname-provides but it adds up pretty fast and doesn't help speeding things. OTOH Debian has a larger repository... my point is that there are lots of differences between deb and rpm systems, comparing them in any sane way is not trivial. - Panu - From jonathan.underwood at gmail.com Fri Nov 24 14:44:49 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 24 Nov 2006 14:44:49 +0000 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <20061120123823.90928.qmail@web52404.mail.yahoo.com> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> Message-ID: <645d17210611240644u3851413ar87eff94223f4a604@mail.gmail.com> On 20/11/06, Otto Rey wrote: > > This sound good, but first we need to detect why rpms database got > corrupted. > It seems that the rpm guys think this issue is arising due to races and signal handling problems which are related to the repeated opening and closing of the database inherent to the latest versions of yum: See: https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/001862.html which is part of this thread on the problem: https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/001849.html Jonathan. From j.w.r.degoede at hhs.nl Fri Nov 24 14:53:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 15:53:11 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Message-ID: <45670757.7050703@hhs.nl> Nicolas Mailhot wrote: > Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : >> Hi all, >> >> Many packages drop config files for logrotate in /etc/logrotate.d. without >> requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d >> for users who don't want logrotate and thus remove it. >> >> I see 2 solutions for this: >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be able >> to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred >> solution. > > 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users > Which effectivly boils down to 1) except that it causes yum to take an extra 5-10 minutes to download file lists for all enabled repos. (on a 1 mbit link) file based dependencies usually are not the answer! Regards, Hans From jlb17 at duke.edu Fri Nov 24 15:26:39 2006 From: jlb17 at duke.edu (Joshua Baker-LePain) Date: Fri, 24 Nov 2006 10:26:39 -0500 (EST) Subject: Xlib: Maximum number of clients reached -- firefox? Message-ID: I'm rather happily running FC6 on my Thinkpad Z61t. I got even happier when I discovered that suspend works without a hitch, with no pre-suspend fiddling required. On resume, everything comes back up including my WPA-encrypted ipw3945 wireless connection, and this with my HDD in AHCI mode. All very, very shiny. So I haven't shut down or logged out in a week. Today, though I started getting errors like this upon trying to start new apps: Xlib: connection to ":0.0" refused by server Xlib: Maximum number of clients reached 'xrestop' takes an absurd amount of CPU time to run, but seems to indicate that firefox has a huge number of windows open (over 2500). I certainly don't have that many windows/taps actually open, but I also haven't shut down firefox in almost a week. Is this a firefox bug that needs reporting? If not, where should I be looking? Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From jreiser at BitWagon.com Fri Nov 24 15:52:30 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 24 Nov 2006 07:52:30 -0800 Subject: Reducing Fedora memory footprint? In-Reply-To: References: <45645D4A.9070309@draigBrady.com> Message-ID: <4567153E.8000304@BitWagon.com> >>> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours. >>> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the >>> computer is "idle". Either ACPI is a lot worse than APM, or >>> something is going on. Any ideas how to debug this? > Also, back in 7.3 time the kernel probably had HZ=100, and now it is > usually 250 or 1000. Slow laptops may not get back to sleep at all between > ticks. 'hald' polls all CD and DVD drives to detect when a disk is inserted. I see about 9 interrupts per second per drive. For example on common x86 clone boxes with CD as /dev/hdc or /dev/hdd (and no harddrives there): grep ide1 /proc/interrupts; sleep 10; grep ide1 /proc/interrupts hald ought to have a settable parameter to control this. Until then: try putting a disk into the drive(s), or kill hald-addon-storage. -- From jfrieben at freesurf.fr Fri Nov 24 17:35:05 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Fri, 24 Nov 2006 18:35:05 +0100 (CET) Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <645d17210611240644u3851413ar87eff94223f4a604@mail.gmail.com> References: <645d17210611240644u3851413ar87eff94223f4a604@mail.gmail.com> Message-ID: <57377.172.173.219.3.1164389705.squirrel@arlette.freesurf.fr> > It seems that the rpm guys think this issue is arising due to races and > signal handling problems which are related to the repeated opening and > closing of the database inherent to the latest versions of yum: > > See: > https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/001862.html > > which is part of this thread on the problem: > https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/001849.html > > > Jonathan. It might be worth reminding that in the current context, the issue appears to be kernel dependent and related to disk I/O traffic. The corruption then is a consequence of repeated system freezes during "rpm" transactions [kernel package rev. 2835 of "fc6-updates-testing" is the only one since my switch to "FC6" and recent "rawhide" which allows me to reliably avoid these problems]. From laurent.rineau__fedora_extras at normalesup.org Fri Nov 24 17:56:32 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 24 Nov 2006 18:56:32 +0100 Subject: Coding system of %doc file Message-ID: <200611241856.32910@rineau.schtroumpfette> Some usual doc files, like AUTHORS, use accented characters. The packaging guidelines do not tell anything about the coding of those files. rpmlint used to signal non-utf-8 files, but my version rpmlint-0.78-2.fc5 no longer do. Is there a policy? From Axel.Thimm at ATrpms.net Fri Nov 24 18:28:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 19:28:48 +0100 Subject: Static linking considered harmful In-Reply-To: <20061122115015.GI2799@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122115015.GI2799@free.fr> Message-ID: <20061124182848.GD31787@neu.nirvana> On Wed, Nov 22, 2006 at 12:50:15PM +0100, Patrice Dumas wrote: > On Wed, Nov 22, 2006 at 10:53:58AM +0000, Andy Green wrote: > > Patrice Dumas wrote: > > > > You could alter your build methodology so that each of the target > > boxes,eg, rebuilds an SRPM with the local library environment? You need > > the compiler and -devel bits and bobs then on the boxes. > > I am not necessarilly root on all the boxes, some may not be rpm based. > The compilation may be time consuming too. > > > Or, leaving the .a files in the packages can be a policy controlled by a > > macro on the build box? Then you can rebuild the -devel packages for > > your build box with the .a files still in how you like and go on as you are. > > Of course, but this decreases a lot the usefullness of fedora for me. Maybe > I am the only one to have these needs, but I hope not, it would be a bit > sad for fedora. No, not at all. All the scientific community is affected, it's only that there are just too few of them lurking around here. The typical situation in natural sciences is that there are more Linux versions around than there are employees, and sometimes statically linking is the only way to distribute your code to the number cruncers. FWIW there are now two of us here :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Fri Nov 24 18:31:45 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 24 Nov 2006 18:31:45 +0000 Subject: Coding system of %doc file In-Reply-To: <200611241856.32910@rineau.schtroumpfette> References: <200611241856.32910@rineau.schtroumpfette> Message-ID: <1164393105.19448.231.camel@pmac.infradead.org> On Fri, 2006-11-24 at 18:56 +0100, Laurent Rineau wrote: > Some usual doc files, like AUTHORS, use accented characters. The packaging > guidelines do not tell anything about the coding of those files. rpmlint used > to signal non-utf-8 files, but my version rpmlint-0.78-2.fc5 no longer do. > > Is there a policy? We should probably work with upstream to fix them as much as we can. Failing that, use iconv during the rpm build. -- dwmw2 From Axel.Thimm at ATrpms.net Fri Nov 24 18:52:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 19:52:30 +0100 Subject: Static linking considered harmful In-Reply-To: <4564AFA1.4090103@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> Message-ID: <20061124185230.GE31787@neu.nirvana> On Wed, Nov 22, 2006 at 12:14:25PM -0800, Ulrich Drepper wrote: > As for the "works everywhere" argument: > > - Jakub and others already pointed out that this is mostly a myth. > Every non-trivial program needs services which require dynamic > linking. glibc's dependencies (iconv, nss, idn, ...) are prominent. > But there are an increasing number of other projects which need it. > Just look for all the DSOs linked against (explicitly or implicitly) > libdl. This includes basically all GUI stuff, all security apps. > Heck, even ncurses falls in this category. All of these are out > when it comes to static linking. Sorry, that's reality, not a myth. I'm a physicist myself and have worked in/collaborated with several academic or research locations, and the picture is the same everywhere: People prefer to create statically linked applications to distribute and share with colleages. That's true for physicists, chemists, weather science stations - most probably all of natural sciences, but perhaps cs. If you take them the ability to statically link away, then Fedora (and then RHEL6) will stop being an attractive development platform for them anymore. Do we want that to happen? I don't think so, even though the scientific community isn't the largest group certainly. And please note that the target group we're talking about are simple users (even though they may be very skillful programmers), not some package monkeys that will create rpms and debs for all systems required or that even care about DSO, tarballing their runtime enviroment and scripting launchers and so on (just quoting some solutions offered in this thread). On the other hand their applications are usually quite non-trivial w/o involving iconv or nss or dlopening plugins (everyone defines non-trivial differently of course). Most numerical codes nowadays are also a mix of C, Fortran and C++, which makes portability w/o statically linking an even greater nightmare. My 0.02 contribution is to identify the wrongly statically linked bits (as done by David), fix these, and let the rest as is, e.g. all packages are themselves using DSO, but some prominent ones like the glibc/libstdc++ and firends are offering statically linked libraries *for users*. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Nov 24 19:22:49 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 20:22:49 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124185230.GE31787@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> Message-ID: <45674689.2050602@hhs.nl> Axel Thimm wrote: > On Wed, Nov 22, 2006 at 12:14:25PM -0800, Ulrich Drepper wrote: >> As for the "works everywhere" argument: >> >> - Jakub and others already pointed out that this is mostly a myth. >> Every non-trivial program needs services which require dynamic >> linking. glibc's dependencies (iconv, nss, idn, ...) are prominent. >> But there are an increasing number of other projects which need it. >> Just look for all the DSOs linked against (explicitly or implicitly) >> libdl. This includes basically all GUI stuff, all security apps. >> Heck, even ncurses falls in this category. All of these are out >> when it comes to static linking. > > Sorry, that's reality, not a myth. I'm a physicist myself and have > worked in/collaborated with several academic or research locations, > and the picture is the same everywhere: People prefer to create > statically linked applications to distribute and share with > colleages. That's true for physicists, chemists, weather science > stations - most probably all of natural sciences, but perhaps cs. > > If you take them the ability to statically link away, then Fedora (and > then RHEL6) will stop being an attractive development platform for > them anymore. Do we want that to happen? I don't think so, even though > the scientific community isn't the largest group certainly. > > And please note that the target group we're talking about are simple > users (even though they may be very skillful programmers), not some > package monkeys that will create rpms and debs for all systems > required or that even care about DSO, tarballing their runtime > enviroment and scripting launchers and so on (just quoting some > solutions offered in this thread). > > On the other hand their applications are usually quite non-trivial w/o > involving iconv or nss or dlopening plugins (everyone defines > non-trivial differently of course). Most numerical codes nowadays are > also a mix of C, Fortran and C++, which makes portability w/o > statically linking an even greater nightmare. > > My 0.02 contribution is to identify the wrongly statically linked bits > (as done by David), fix these, and let the rest as is, e.g. all > packages are themselves using DSO, but some prominent ones like the > glibc/libstdc++ and firends are offering statically linked libraries > *for users*. > +1, although it would be a good idea to put the static libs in a seperate sub package. ( /me has no need for such a beast) Regards, Hans From arjan at fenrus.demon.nl Fri Nov 24 19:28:54 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 24 Nov 2006 20:28:54 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124185230.GE31787@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> Message-ID: <1164396534.3147.42.camel@laptopd505.fenrus.org> On Fri, 2006-11-24 at 19:52 +0100, Axel Thimm wrote: > On Wed, Nov 22, 2006 at 12:14:25PM -0800, Ulrich Drepper wrote: > > As for the "works everywhere" argument: > > > > - Jakub and others already pointed out that this is mostly a myth. > > Every non-trivial program needs services which require dynamic > > linking. glibc's dependencies (iconv, nss, idn, ...) are prominent. > > But there are an increasing number of other projects which need it. > > Just look for all the DSOs linked against (explicitly or implicitly) > > libdl. This includes basically all GUI stuff, all security apps. > > Heck, even ncurses falls in this category. All of these are out > > when it comes to static linking. > > Sorry, that's reality, not a myth. ok so as an outsider I see two camps 1) "Static linking is a technical problem and should be discouraged" and 2) "We want portable-to-other distros" the 2) camp then makes a step and considers static linking as the way to go there. (probably because on other systems that was the case) these two camps are not in fundamental conflicting positions. Only once the step "static linking is the way to make things portable" is made are the positions in conflict. Maybe the real answer is something entirely different: if it was easy to automatically package up a binary and all the libs it needs into something that's self executable/self contained... that would take care of the requirement too. Maybe some answer is the real thing However I think it's very important to separate out "we want portable" and "we require static linking", since just about ALL arguments for static linking actually were not about static linking but about wanting portable. From Axel.Thimm at ATrpms.net Fri Nov 24 19:30:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:30:08 +0100 Subject: Static linking considered harmful In-Reply-To: <45674689.2050602@hhs.nl> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <45674689.2050602@hhs.nl> Message-ID: <20061124193008.GB4809@neu.nirvana> On Fri, Nov 24, 2006 at 08:22:49PM +0100, Hans de Goede wrote: > Axel Thimm wrote: > > On Wed, Nov 22, 2006 at 12:14:25PM -0800, Ulrich Drepper wrote: > >> As for the "works everywhere" argument: > >> > >> - Jakub and others already pointed out that this is mostly a myth. > >> Every non-trivial program needs services which require dynamic > >> linking. glibc's dependencies (iconv, nss, idn, ...) are prominent. > >> But there are an increasing number of other projects which need it. > >> Just look for all the DSOs linked against (explicitly or implicitly) > >> libdl. This includes basically all GUI stuff, all security apps. > >> Heck, even ncurses falls in this category. All of these are out > >> when it comes to static linking. > > > > Sorry, that's reality, not a myth. I'm a physicist myself and have > > worked in/collaborated with several academic or research locations, > > and the picture is the same everywhere: People prefer to create > > statically linked applications to distribute and share with > > colleages. That's true for physicists, chemists, weather science > > stations - most probably all of natural sciences, but perhaps cs. > > > > If you take them the ability to statically link away, then Fedora (and > > then RHEL6) will stop being an attractive development platform for > > them anymore. Do we want that to happen? I don't think so, even though > > the scientific community isn't the largest group certainly. > > > > And please note that the target group we're talking about are simple > > users (even though they may be very skillful programmers), not some > > package monkeys that will create rpms and debs for all systems > > required or that even care about DSO, tarballing their runtime > > enviroment and scripting launchers and so on (just quoting some > > solutions offered in this thread). > > > > On the other hand their applications are usually quite non-trivial w/o > > involving iconv or nss or dlopening plugins (everyone defines > > non-trivial differently of course). Most numerical codes nowadays are > > also a mix of C, Fortran and C++, which makes portability w/o > > statically linking an even greater nightmare. > > > > My 0.02 contribution is to identify the wrongly statically linked bits > > (as done by David), fix these, and let the rest as is, e.g. all > > packages are themselves using DSO, but some prominent ones like the > > glibc/libstdc++ and firends are offering statically linked libraries > > *for users*. > > > > > +1, although it would be a good idea to put the static libs in a > seperate sub package. ( /me has no need for such a beast) Have you seen Dmitry Butskoy's post on this? He has created debuginfo macros that automatically cater for that (packages are then named foo-static, but that's tunable) w/o any changes in existing specfiles. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Nov 24 19:44:47 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 24 Nov 2006 20:44:47 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124193008.GB4809@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <45674689.2050602@hhs.nl> <20061124193008.GB4809@neu.nirvana> Message-ID: <45674BAF.8010404@hhs.nl> Axel Thimm wrote: >> +1, although it would be a good idea to put the static libs in a >> seperate sub package. ( /me has no need for such a beast) > > Have you seen Dmitry Butskoy's post on this? He has created debuginfo > macros that automatically cater for that (packages are then named > foo-static, but that's tunable) w/o any changes in existing > specfiles. > Yeah I've seen that but I'm not sure if I like that, thats because I'm not sure if we should offer static libs for all packages or only for certain ones (like glibc, libstdc++, some standard X11 libs) Regards, Hans From Axel.Thimm at ATrpms.net Fri Nov 24 19:32:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:32:27 +0100 Subject: Static linking considered harmful In-Reply-To: <456479AF.10000@odu.neva.ru> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <200611220954.52939.dennis@ausil.us> <20061122161011.GA26250@devserv.devel.redhat.com> <456479AF.10000@odu.neva.ru> Message-ID: <20061124193227.GC4809@neu.nirvana> On Wed, Nov 22, 2006 at 07:24:15PM +0300, Dmitry Butskoy wrote: > Alan Cox wrote: > > >Far simpler, cleaner and more friendly will be to dump the static > >libraries into libfoo-devel-static packages which are not in the > >default install. That ensures people who need to can do static > >links and the default behaviour is that they are not there. The > >-static packages could even get dropped off the CD easily enough > >once the mechanisms for handling one srpm spitting out binary > >components for extras and core are sorted > BTW, such a "-static" subpackages might be handled the same way as > "-debuginfo". Consider some example of needed rpm macros (attached > below), written one year ago when similar topic was discussed at > fedore-extras-devel list. That's very interesting, and one could perhaps even skip the need for explicitely invoking find_static in %install, but have that doen automatically dependent on presence of any *.a lib. E.g. w/o touching the specfiles at all. Very nice idea, Dmitry! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Fri Nov 24 19:45:04 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 24 Nov 2006 14:45:04 -0500 Subject: hsqldb's long-standing packaging bug Message-ID: <883cfe6d0611241145x51b8b829u64ccf7ebce830515@mail.gmail.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166466 hsqldb has some trivial packaging bug that's been untouched for ages. Alas, we Extras maintainers can't currently touch Core packages.. Could someone step in and fix this? For some reason it's currently assigned to someone who's not a Core developer judging from the email address. Thanks, -- Michel Salim Don't worry about avoiding temptation -- as you grow older, it starts avoiding you. -- The Old Farmer's Almanac From Axel.Thimm at ATrpms.net Fri Nov 24 19:46:33 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:46:33 +0100 Subject: Static linking considered harmful In-Reply-To: <1164396534.3147.42.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> Message-ID: <20061124194633.GD4809@neu.nirvana> On Fri, Nov 24, 2006 at 08:28:54PM +0100, Arjan van de Ven wrote: > Maybe the real answer is something entirely different: if it was easy to > automatically package up a binary and all the libs it needs into > something that's self executable/self contained... that would take care > of the requirement too. Maybe some answer is the real thing you mean http://statifier.sourceforge.net/? > However I think it's very important to separate out "we want portable" > and "we require static linking", since just about ALL arguments for > static linking actually were not about static linking but about wanting > portable. That kind of argument separation and liquidation is an eloquent speaker's trick. In that sense there are no arguments in favour of dynamic linking either, Ulrich wants to have security and maintainability, he doesn't really care about dynamic linking, right? ;) FWIW again from the number crunching community, sometimes statically linking numerical libs shows performance gains (although when the problem domain is of that kind the libs tend to be headers-only with inlining), and some only commercial available libs only offer static libs. Which brings yet another argument in favour of not disallowing statically builds: ISVs love to use these in order to have one build for the whole Linux world. Not that these builds are ever a joy to the users, and some may say the noone cares about proprietary browser plugins or java vms, but I would be sad to not have a Linux way to partition HP storage for example. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Nov 24 19:48:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 20:48:15 +0100 Subject: Static linking considered harmful In-Reply-To: <45674BAF.8010404@hhs.nl> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <45674689.2050602@hhs.nl> <20061124193008.GB4809@neu.nirvana> <45674BAF.8010404@hhs.nl> Message-ID: <20061124194815.GE4809@neu.nirvana> On Fri, Nov 24, 2006 at 08:44:47PM +0100, Hans de Goede wrote: > > > Axel Thimm wrote: > >> +1, although it would be a good idea to put the static libs in a > >> seperate sub package. ( /me has no need for such a beast) > > > > Have you seen Dmitry Butskoy's post on this? He has created debuginfo > > macros that automatically cater for that (packages are then named > > foo-static, but that's tunable) w/o any changes in existing > > specfiles. > > > > Yeah I've seen that but I'm not sure if I like that, thats because I'm > not sure if we should offer static libs for all packages or only for > certain ones (like glibc, libstdc++, some standard X11 libs) The decision whether to offer static libs is still the specfile's, the intersting part is to have any remaining *.a file autopackage itself into these *-static packages w/o any hassle from a packager's POV. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nutello at sweetness.com Fri Nov 24 19:58:44 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 24 Nov 2006 20:58:44 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124182848.GD31787@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122115015.GI2799@free.fr> <20061124182848.GD31787@neu.nirvana> Message-ID: <20061124195844.GN27039@plain.rackshack.net> On Fri, Nov 24, 2006 at 07:28:48PM +0100, Axel Thimm wrote: > No, not at all. All the scientific community is affected, it's only > that there are just too few of them lurking around here. The typical > situation in natural sciences is that there are more Linux versions > around than there are employees, and sometimes statically linking is > the only way to distribute your code to the number cruncers. > > FWIW there are now two of us here :) Make that three. We just released software to support two papers that were accepted for publication. We made available binaries for Windows, a source tree for Linux with a reduced set of dependencies and a source tree for Windows and OSX with all the dependencies. We avoided Linux binaries this time around, hoping to have something sane for next release. In defence of dynamic linking, I have to mention something that goes against common wisdom. One of the tools we use is statically linked against its dependencies. When a couple of years ago we updated our cluster to a more recent Fedora, we suddenly noticed problems. I think our local LDAP servers were getting much more traffic, because the location of the nscd socket had been moved and the statically linked glibc was looking for it at the old location. Once I had tracked down the problem, it wasn't anything that cfengine couldn't take care of. Yes, we do use LDAP and, starting recently, even Kerberos within an Active Directory domain. By necessity we were early nscd adopters (been there, done that, endured all the annoying early bugs, but now it works well for us). I know that there are many examples of clusters with no user accounts, where everything is run by the root user, but that's not always the case. We even leave SELinux enabled, because its overhead on our FP-intensive jobs is lost in the statistical noise and is lower than the difference between code generated by different compilers. -- Rudi From cmadams at hiwaay.net Fri Nov 24 20:21:09 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 14:21:09 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124194633.GD4809@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> Message-ID: <20061124202109.GD1040917@hiwaay.net> Once upon a time, Axel Thimm said: > FWIW again from the number crunching community, sometimes statically > linking numerical libs shows performance gains (although when the > problem domain is of that kind the libs tend to be headers-only with > inlining), and some only commercial available libs only offer static > libs. Not all the number crunching community statically links. For example, my father works for NASA, and for his project, they rebuild from source everywhere. This is a requirement since they run the project on a number of platforms (Linux, Solaris, Windows/Cygwin, Tru64, IRIX). > Which brings yet another argument in favour of not disallowing > statically builds: ISVs love to use these in order to have one build > for the whole Linux world. Unless these vendors include object code suitable for re-linking against a different glibc, they are violating the LGPL if they link against glibc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jakub at redhat.com Fri Nov 24 20:27:54 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 24 Nov 2006 15:27:54 -0500 Subject: Static linking considered harmful In-Reply-To: <20061124194633.GD4809@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> Message-ID: <20061124202754.GP6570@devserv.devel.redhat.com> On Fri, Nov 24, 2006 at 08:46:33PM +0100, Axel Thimm wrote: > Which brings yet another argument in favour of not disallowing > statically builds: ISVs love to use these in order to have one build > for the whole Linux world. Not that these builds are ever a joy to the > users, and some may say the noone cares about proprietary browser > plugins or java vms, but I would be sad to not have a Linux way to > partition HP storage for example. In this case please reread this thread, that's exactly what we'd like ISVs to avoid and all the reasons stated in the thread why static linking is not desirable for that purpose apply to the vast majority of ISV uses of static linking. Jakub From Axel.Thimm at ATrpms.net Fri Nov 24 20:32:42 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 21:32:42 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124202754.GP6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202754.GP6570@devserv.devel.redhat.com> Message-ID: <20061124203242.GB6805@neu.nirvana> On Fri, Nov 24, 2006 at 03:27:54PM -0500, Jakub Jelinek wrote: > On Fri, Nov 24, 2006 at 08:46:33PM +0100, Axel Thimm wrote: > > Which brings yet another argument in favour of not disallowing > > statically builds: ISVs love to use these in order to have one build > > for the whole Linux world. Not that these builds are ever a joy to the > > users, and some may say the noone cares about proprietary browser > > plugins or java vms, but I would be sad to not have a Linux way to > > partition HP storage for example. > > In this case please reread this thread, that's exactly what we'd like > ISVs to avoid and all the reasons stated in the thread why static > linking is not desirable for that purpose apply to the vast majority > of ISV uses of static linking. But you will not force ISV to suddenly invest more support into this. They will just drop Fedora as a build platform and still offer static builds, now with even more issues as they will most certainly be using another distro for creating them. At the end it will mean that "HP storage solutions work under Windows 2008 (TM), Novell Linux 12, but not RHEL6 or FC8". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Nov 24 20:36:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 21:36:51 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124202109.GD1040917@hiwaay.net> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> Message-ID: <20061124203651.GC6805@neu.nirvana> On Fri, Nov 24, 2006 at 02:21:09PM -0600, Chris Adams wrote: > Once upon a time, Axel Thimm said: > > FWIW again from the number crunching community, sometimes statically > > linking numerical libs shows performance gains (although when the > > problem domain is of that kind the libs tend to be headers-only with > > inlining), and some only commercial available libs only offer static > > libs. > > Not all the number crunching community statically links. For example, > my father works for NASA, and for his project, they rebuild from source > everywhere. This is a requirement since they run the project on a > number of platforms (Linux, Solaris, Windows/Cygwin, Tru64, IRIX). You faile dot mention whether your father builds his apps statically or dynamically. Any either way, this distribution model is indeed Gentoo-like as someone else mentioned in this thread. > > Which brings yet another argument in favour of not disallowing > > statically builds: ISVs love to use these in order to have one build > > for the whole Linux world. > > Unless these vendors include object code suitable for re-linking against > a different glibc, they are violating the LGPL if they link against > glibc. Are you sure? glibc is not GPL, it's LGPL. and how would a vendor in 2006 be able to ensure that his binaries can relinked with glibc from 2010? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Fri Nov 24 20:49:38 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 14:49:38 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124203651.GC6805@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> Message-ID: <20061124204937.GF1040917@hiwaay.net> Once upon a time, Axel Thimm said: > On Fri, Nov 24, 2006 at 02:21:09PM -0600, Chris Adams wrote: > > Not all the number crunching community statically links. For example, > > my father works for NASA, and for his project, they rebuild from source > > everywhere. This is a requirement since they run the project on a > > number of platforms (Linux, Solaris, Windows/Cygwin, Tru64, IRIX). > > You faile dot mention whether your father builds his apps statically > or dynamically. Any either way, this distribution model is indeed > Gentoo-like as someone else mentioned in this thread. They build dynamic binaries. > > > Which brings yet another argument in favour of not disallowing > > > statically builds: ISVs love to use these in order to have one build > > > for the whole Linux world. > > > > Unless these vendors include object code suitable for re-linking against > > a different glibc, they are violating the LGPL if they link against > > glibc. > > Are you sure? glibc is not GPL, it's LGPL. and how would a vendor in > 2006 be able to ensure that his binaries can relinked with glibc from > 2010? Did you read what I wrote? I said LGPL, not GPL. As for how the vendor can ensure anything, that is the vendor's problem. The LGPL requires any work statically linked to the library be distributed with (or with an offer for) the source and/or object code so that the end-user can modify the library and relink the work. Any vendor distributing a binary statically linked to glibc (or any other LGPL library) without including source and/or object code (or an offer to get source and/or object code) is violating the license. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Axel.Thimm at ATrpms.net Fri Nov 24 21:01:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 22:01:05 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124204937.GF1040917@hiwaay.net> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> Message-ID: <20061124210105.GE6805@neu.nirvana> On Fri, Nov 24, 2006 at 02:49:38PM -0600, Chris Adams wrote: > > > Unless these vendors include object code suitable for re-linking against > > > a different glibc, they are violating the LGPL if they link against > > > glibc. > > > > Are you sure? glibc is not GPL, it's LGPL. and how would a vendor in > > 2006 be able to ensure that his binaries can relinked with glibc from > > 2010? > > Did you read what I wrote? I said LGPL, not GPL. Sorry, indeed you did. > As for how the vendor can ensure anything, that is the vendor's > problem. No, not legally. If any contract has unfulfillable clauses these get dropped. > The LGPL requires any work statically linked to the library be > distributed with (or with an offer for) the source and/or object code so > that the end-user can modify the library and relink the work. Can you quote that in the license, because I think you're quoting the GPL, not the LGPL. > Any vendor distributing a binary statically linked to glibc (or any > other LGPL library) without including source and/or object code (or an > offer to get source and/or object code) is violating the license. I think that's exactly the difference between GPL and LGPL ... http://www.gnu.org/licenses/why-not-lgpl.html -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Fri Nov 24 21:05:27 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 15:05:27 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124210105.GE6805@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> Message-ID: <20061124210523.GG1040917@hiwaay.net> Once upon a time, Axel Thimm said: > > > Are you sure? glibc is not GPL, it's LGPL. and how would a vendor in > > > 2006 be able to ensure that his binaries can relinked with glibc from > > > 2010? > > > > Did you read what I wrote? I said LGPL, not GPL. > > Sorry, indeed you did. > > > As for how the vendor can ensure anything, that is the vendor's > > problem. > > No, not legally. If any contract has unfulfillable clauses these get > dropped. The vendor doesn't have to make something that will work with random glibcs; just modified versions of the same glibc they used (as long as the modified version is interface-compatible). > > The LGPL requires any work statically linked to the library be > > distributed with (or with an offer for) the source and/or object code so > > that the end-user can modify the library and relink the work. > > Can you quote that in the license, because I think you're quoting the > GPL, not the LGPL. Go read it yourself; section 6a in /usr/share/doc/glibc-2*/COPYING.LIB (it is a little long to quote). > > Any vendor distributing a binary statically linked to glibc (or any > > other LGPL library) without including source and/or object code (or an > > offer to get source and/or object code) is violating the license. > > I think that's exactly the difference between GPL and LGPL ... No, the difference is that the vendor can include only object code; source code is not required. The GPL makes no mention of linking (static or dynamic). I really suggest you read the license; you have a copy (or maybe more than one) on your system. It is pretty straight forward. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Axel.Thimm at ATrpms.net Fri Nov 24 21:15:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Nov 2006 22:15:30 +0100 Subject: Static linking considered harmful In-Reply-To: <20061124210523.GG1040917@hiwaay.net> References: <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> Message-ID: <20061124211530.GG6805@neu.nirvana> On Fri, Nov 24, 2006 at 03:05:27PM -0600, Chris Adams wrote: > > > The LGPL requires any work statically linked to the library be > > > distributed with (or with an offer for) the source and/or object code so > > > that the end-user can modify the library and relink the work. > No, the difference is that the vendor can include only object code; > source code is not required. The GPL makes no mention of linking > (static or dynamic). Ah, OK, I had missed the and/or in your statement above. In that case we agree, the LGPL doesn't require source code. And what I learned is that it requires you to ship object code, not only the final executable. I wonder how many ISVs really do that. Or whether they argue that the statically build exectuable can be dismantled with binutils. > I really suggest you read the license; you have a copy (or maybe more > than one) on your system. It is pretty straight forward. OK, I admit, you were right and I need to learn to read. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Fri Nov 24 21:20:37 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 15:20:37 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124211530.GG6805@neu.nirvana> References: <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> <20061124211530.GG6805@neu.nirvana> Message-ID: <20061124212037.GH1040917@hiwaay.net> Once upon a time, Axel Thimm said: > Ah, OK, I had missed the and/or in your statement above. In that case > we agree, the LGPL doesn't require source code. And what I learned is > that it requires you to ship object code, not only the final > executable. I wonder how many ISVs really do that. Or whether they > argue that the statically build exectuable can be dismantled with > binutils. I've never tried that. I wonder just how hard it would be to get something useful. Could you decompose a statically linked binary and relink it (against the same glibc, etc.) to get a dynamically linked binary (that should then work with newer glibcs)? Once a static binary is stripped, I don't think there's enough information left, is there? > > I really suggest you read the license; you have a copy (or maybe more > > than one) on your system. It is pretty straight forward. > > OK, I admit, you were right and I need to learn to read. :) Meh, it get me something to do on a slow Friday afternoon at work. :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From drepper at redhat.com Fri Nov 24 22:03:37 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 24 Nov 2006 14:03:37 -0800 Subject: Static linking considered harmful In-Reply-To: <20061124212037.GH1040917@hiwaay.net> References: <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> <20061124211530.GG6805@neu.nirvana> <20061124212037.GH1040917@hiwaay.net> Message-ID: <45676C39.3080901@redhat.com> Chris Adams wrote: > I've never tried that. I wonder just how hard it would be to get > something useful. Could you decompose a statically linked binary and > relink it (against the same glibc, etc.) to get a dynamically linked > binary (that should then work with newer glibcs)? Once a static binary > is stripped, I don't think there's enough information left, is there? This is only possible (if ever) when all the relocations are kept in the final binary. There is a linker option to do this but it doesn't really work reliably. Regardless, the object file/source distinction is meaningless anyway. The object files encode ABI internals. Those change and make object file reuse impossible (we never guarantee compatibility of object files, only executables and DSOs). Therefore I argue that without distributing sources people linking statically are always violating the license since they don't allow relinking with later or earlier versions. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From tmus at tmus.dk Fri Nov 24 22:02:34 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 24 Nov 2006 23:02:34 +0100 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: <4566C658.8060307@hhs.nl> References: <4566C658.8060307@hhs.nl> Message-ID: Hans de Goede wrote: > Hi all, > > Many packages drop config files for logrotate in /etc/logrotate.d. > without requiring logrotate, which is the owner of > /etc/logrotate.d, thus potentially leading to an unowned > /etc/logrotate.d for users who don't want logrotate and thus remove it. > > I see 2 solutions for this: > 1) Add "Requires: logrotate" to all packages which put files in > /etc/logrotate.d. IMHO this is not good as the user should be able > to choose if he wants logrotate or not. > 2) Add /etc/logrotate.d to the filesystem package, this is my preferred > solution. > > I would like to hear what others think, before filing a bug against > filesystem requesting 2) . > > Regards, > > Hans > Requiring logrotate is not really preferred, since people may choose to remove logrotate and it does not make any real sense that you can't install httpd or cups or others without a pre-chosen log-management package (exactly as you point out). On the other hand, putting /etc/logrotate.d in the filesystem package is probably not a too much better, since we will still be installing stuff for a particular log-management package, that may not even be there. This seems wrong to me. So since we're already discussing this, what if all packages that put stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or something)... The -logrotate sub packages should require logrotate and of-course the main package (httpd in this case). Users can remove logrotate and with it, all the -logrotate subpackages from cups, httpd and the rest, but the software will still install and run just fine. This method has the added benefit of giving us a cleaner way to provide log-management for everything, based on an entirely different log-management tool. Put in extras and provide a http- package and all is good. Just my .5?s worth /Thomas From cmadams at hiwaay.net Fri Nov 24 22:16:22 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 16:16:22 -0600 Subject: Static linking considered harmful In-Reply-To: <45676C39.3080901@redhat.com> References: <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> <20061124211530.GG6805@neu.nirvana> <20061124212037.GH1040917@hiwaay.net> <45676C39.3080901@redhat.com> Message-ID: <20061124221622.GA1390281@hiwaay.net> Once upon a time, Ulrich Drepper said: > Regardless, the object file/source distinction is meaningless anyway. > The object files encode ABI internals. Those change and make object > file reuse impossible (we never guarantee compatibility of object files, > only executables and DSOs). Therefore I argue that without distributing > sources people linking statically are always violating the license since > they don't allow relinking with later or earlier versions. The LGPL doesn't talk about different versions; it only requires relinking with modified copies of the same version that maintain interface compatibility. After all, even dynamic linking doesn't guarantee compatibility with earlier versions. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From alan at redhat.com Fri Nov 24 23:19:59 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 24 Nov 2006 18:19:59 -0500 Subject: Static linking considered harmful In-Reply-To: <20061124202754.GP6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202754.GP6570@devserv.devel.redhat.com> Message-ID: <20061124231959.GA29419@devserv.devel.redhat.com> On Fri, Nov 24, 2006 at 03:27:54PM -0500, Jakub Jelinek wrote: > In this case please reread this thread, that's exactly what we'd like > ISVs to avoid and all the reasons stated in the thread why static > linking is not desirable for that purpose apply to the vast majority > of ISV uses of static linking. You persuade the ISVs to stop using static linking by proving them with more stable API's and interfaces to improve on the current LSB, along with easy ways to build a back compatible binary You persuade ISVs to drop Linux support by high-handedly dumping static support so they can't use it. Solve their problem and they'll solve yours From drepper at redhat.com Fri Nov 24 23:21:05 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 24 Nov 2006 15:21:05 -0800 Subject: Static linking considered harmful In-Reply-To: <20061124221622.GA1390281@hiwaay.net> References: <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> <20061124211530.GG6805@neu.nirvana> <20061124212037.GH1040917@hiwaay.net> <45676C39.3080901@redhat.com> <20061124221622.GA1390281@hiwaay.net> Message-ID: <45677E61.2020900@redhat.com> Chris Adams wrote: > The LGPL doesn't talk about different versions; it only requires > relinking with modified copies of the same version that maintain > interface compatibility. That's your interpretation and it makes no sense. Relinking with the same version means no change at all. Change always has to be taken into account and then the internal ABI might change. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From cmadams at hiwaay.net Fri Nov 24 23:33:22 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 17:33:22 -0600 Subject: Static linking considered harmful In-Reply-To: <45677E61.2020900@redhat.com> References: <20061124202109.GD1040917@hiwaay.net> <20061124203651.GC6805@neu.nirvana> <20061124204937.GF1040917@hiwaay.net> <20061124210105.GE6805@neu.nirvana> <20061124210523.GG1040917@hiwaay.net> <20061124211530.GG6805@neu.nirvana> <20061124212037.GH1040917@hiwaay.net> <45676C39.3080901@redhat.com> <20061124221622.GA1390281@hiwaay.net> <45677E61.2020900@redhat.com> Message-ID: <20061124233322.GB1390281@hiwaay.net> Once upon a time, Ulrich Drepper said: > Chris Adams wrote: > >The LGPL doesn't talk about different versions; it only requires > >relinking with modified copies of the same version that maintain > >interface compatibility. > > That's your interpretation and it makes no sense. Relinking with the > same version means no change at all. Change always has to be taken into > account and then the internal ABI might change. Again, I suggest you go read the license. It isn't my interpretation; the words are straight out of the LGPL, section 6. First of all, 6a includes: ... so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) Then 6b, talking about shared libraries, says: ... (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. There is nothing in there about different releases of the library used; only modified copies of the version used originally. Interface compatibility is specifically mentioned as the user's problem, not the vendor's. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Fri Nov 24 23:37:23 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Nov 2006 17:37:23 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124231959.GA29419@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> <20061124194633.GD4809@neu.nirvana> <20061124202754.GP6570@devserv.devel.redhat.com> <20061124231959.GA29419@devserv.devel.redhat.com> Message-ID: <20061124233723.GC1390281@hiwaay.net> Once upon a time, Alan Cox said: > You persuade the ISVs to stop using static linking by proving them with > more stable API's and interfaces to improve on the current LSB, along > with easy ways to build a back compatible binary It would be nice if there was an easy way to build a binary that is backwards compatible. However, ISVs that want to build such should probably build on the oldest version they want to support; how else will they know if it really even runs there? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From galibert at pobox.com Fri Nov 24 23:53:51 2006 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 25 Nov 2006 00:53:51 +0100 Subject: Static linking considered harmful In-Reply-To: <1164396534.3147.42.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164396534.3147.42.camel@laptopd505.fenrus.org> Message-ID: <20061124235351.GA58128@dspnet.fr.eu.org> On Fri, Nov 24, 2006 at 08:28:54PM +0100, Arjan van de Ven wrote: > ok so as an outsider I see two camps > > 1) "Static linking is a technical problem and should be discouraged" > and > 2) "We want portable-to-other distros" Not only other distros but also other versions of the same distro, or architectural variants (32/64bits). > the 2) camp then makes a step and considers static linking as the way to > go there. (probably because on other systems that was the case) It was the case still until the glibc devs did their best to break it. No there is no way to get any kind of portability. Packaging the .so with the application won't work either simply because the tricks used to break static linking break that too. OG. From rdieter at math.unl.edu Sat Nov 25 01:25:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 24 Nov 2006 19:25:52 -0600 Subject: unowned directory problem with /etc/logrotate.d References: <4566C658.8060307@hhs.nl> <18132.192.54.193.51.1164371456.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > > Le Ven 24 novembre 2006 11:15, Hans de Goede a ?crit : >> Hi all, >> >> Many packages drop config files for logrotate in /etc/logrotate.d. >> without requiring logrotate, which is the owner of >> /etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d >> for users who don't want logrotate and thus remove it. >> >> I see 2 solutions for this: >> 1) Add "Requires: logrotate" to all packages which put files in >> /etc/logrotate.d. IMHO this is not good as the user should be able >> to choose if he wants logrotate or not. >> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred >> solution. > > 3. add Requires: /etc/logrotate.d to /etc/logrotate.d users That's not really all that different than 1. For now, imo, the only viable alternative is 1. Requires: logrotate -- Rex From nmiell at comcast.net Sat Nov 25 01:46:45 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Fri, 24 Nov 2006 17:46:45 -0800 Subject: Xlib: Maximum number of clients reached -- firefox? In-Reply-To: References: Message-ID: <1164419205.2812.1.camel@entropy> On Fri, 2006-11-24 at 10:26 -0500, Joshua Baker-LePain wrote: > I'm rather happily running FC6 on my Thinkpad Z61t. I got even happier > when I discovered that suspend works without a hitch, with no pre-suspend > fiddling required. On resume, everything comes back up including my > WPA-encrypted ipw3945 wireless connection, and this with my HDD in AHCI > mode. All very, very shiny. > > So I haven't shut down or logged out in a week. Today, though I started > getting errors like this upon trying to start new apps: > > Xlib: connection to ":0.0" refused by server > Xlib: Maximum number of clients reached > > 'xrestop' takes an absurd amount of CPU time to run, but seems to indicate > that firefox has a huge number of windows open (over 2500). I certainly > don't have that many windows/taps actually open, but I also haven't shut > down firefox in almost a week. > > Is this a firefox bug that needs reporting? If not, where should I be > looking? > > Thanks. > Some combination of Firefox and Flash leak X connections. I think maybe it's just the Flash 9 beta, but I don't really know for sure. -- Nicholas Miell From n0dalus+redhat at gmail.com Sat Nov 25 04:29:28 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 25 Nov 2006 14:59:28 +1030 Subject: Static linking considered harmful In-Reply-To: <17766.50422.240686.639120@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123121317.GC14710@devserv.devel.redhat.com> <17765.54618.892459.602177@zebedee.pink> <1164305409.12571.3.camel@localhost.localdomain> <17766.50422.240686.639120@zebedee.pink> Message-ID: <6280325c0611242029p5c45abb7oc55e527a98237a85@mail.gmail.com> On 11/24/06, Andrew Haley wrote: > Erik van Pienbroek writes: > > > > The first thing that comes in my mind is bundling your > > own shared libraries with the application, but for that to > > work the LD_LIBRARY_PATH= hack is needed, which is also evil. > > I read this a couple of times, and I still don't know what problem > you're referring to. The usual technique is simply to provide a > wrapper script that sets up whatever environment is required and > exec's the application. > Doesn't using LD_LIBRARY_PATH have the same effect as using static linking? Since you're no longer using shared libraries provided by the system but using your own possible outdated/buggy versions, just like you would be if you linked statically. +1 for -static rpms n0dalus. From aph at redhat.com Sat Nov 25 10:16:37 2006 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 Nov 2006 10:16:37 +0000 Subject: Static linking considered harmful In-Reply-To: <6280325c0611242029p5c45abb7oc55e527a98237a85@mail.gmail.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> <20061123070233.GA4746@dudweiler.stuttgart.redhat.com> <45654E79.4060108@redhat.com> <20061123121317.GC14710@devserv.devel.redhat.com> <17765.54618.892459.602177@zebedee.pink> <1164305409.12571.3.camel@localhost.localdomain> <17766.50422.240686.639120@zebedee.pink> <6280325c0611242029p5c45abb7oc55e527a98237a85@mail.gmail.com> Message-ID: <17768.6149.580662.286974@zebedee.pink> n0dalus writes: > On 11/24/06, Andrew Haley wrote: > > Erik van Pienbroek writes: > > > > > > The first thing that comes in my mind is bundling your > > > own shared libraries with the application, but for that to > > > work the LD_LIBRARY_PATH= hack is needed, which is also evil. > > > > I read this a couple of times, and I still don't know what problem > > you're referring to. The usual technique is simply to provide a > > wrapper script that sets up whatever environment is required and > > exec's the application. > > > > Doesn't using LD_LIBRARY_PATH have the same effect as using static > linking? Not quite. If you look at Uli's page (http://people.redhat.com/drepper/no_static_linking.html) you'll see that this applies to some of the arguments but not all of them. Andrew. From buildsys at redhat.com Sat Nov 25 11:22:30 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 25 Nov 2006 06:22:30 -0500 Subject: rawhide report: 20061125 changes Message-ID: <200611251122.kAPBMUZ9017326@hs20-bc2-6.build.redhat.com> New package iprutils Utilities for the IBM Power Linux RAID adapters New package librtas Libraries to provide access to RTAS calls and RTAS events. New package ppc64-utils Linux/PPC64 specific utilities New package yaboot Linux bootloader for Power Macintosh "New World" computers. Updated Packages: autofs-1:5.0.1-0.rc2.26 ----------------------- * Sat Nov 25 2006 Ian Kent - 5.0.1-0.rc2.26 - fix parsing of bad mount mount point in master map (bz 215620). - fix use after free memory access in cache.c and lookup_yp.c (bz 208091). - eliminate use of pthread_kill to detect task completion (bz 208091). coreutils-5.97-16.fc7 --------------------- * Fri Nov 24 2006 Tim Waugh 5.97-16 - Unbreak id (bug #217177). eclipse-1:3.2.1-22.fc7 ---------------------- * Mon Nov 20 2006 Andrew Overholt 3.2.1-22 - Use ~/.eclipseplugins instead of ~/.eclipse in update site - homedir patch. - Bump release. gtk2-2.10.6-6.fc7 ----------------- * Sat Nov 25 2006 Matthias Clasen - 2.10.6-6 - Fix a recent-files related crash openoffice.org-1:2.1.0-5.1 -------------------------- * Thu Nov 23 2006 Caolan McNamara - 1:2.1.0-5.1 - next one - Resolves: rhbz#217047 i.e. replace openoffice.org-2.0.4.ooo.vcl.im_yield.patch with openoffice.org-2.0.4.ooo69992.sw.syncbackspace.patch policycoreutils-1.33.4-2.fc7 ---------------------------- * Fri Nov 24 2006 Dan Walsh 1.33.4-2 - Additional po changes - Added all booleans definitions system-config-language-1.1.16-1.fc7 ----------------------------------- * Wed Nov 22 2006 Paul Nasrat - 1.1.16-1 - Update translations (#216093) * Thu Nov 16 2006 Paul Nasrat - 1.1.15-1 - Use correct Norwegian language (#209438) - Fix traceback in text mode (#215319) - Update potfile * Fri Oct 20 2006 Paul Nasrat - 1.1.14-1 - Fix typos (#211434) tzdata-2006o-2.fc7 ------------------ * Wed Nov 22 2006 Petr Machata - 2006o-2 - Patch for Western Australia DST trial Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From thomas.canniot at laposte.net Sat Nov 25 16:08:26 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Sat, 25 Nov 2006 17:08:26 +0100 Subject: Desktop-effects In-Reply-To: <45685F93.5040604@redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> Message-ID: <1164470906.3328.10.camel@localhost.localdomain> Le dimanche 26 novembre 2006 ? 01:21 +1000, Chester Cheng a ?crit : > Hi Igor, > > The .pot file hasn't been prepared by the author. > It will be released soon and we can make po files then. I think there is translation related problems here. Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ? Question I don't have any answer for ... yet ? > > Cheers, > Chester > > Igor Pires Soares ??: > > Hello Guys! > > > > Today I was looking into my "Translate" directory and noticed that there > > is a desktop-effects folder, but there is only one po file inside. I > > would like to know how to make a po file for my language. > > > > Thanks in advance, > > Igor Pires Soares -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From pmr at pajato.com Sat Nov 25 16:26:40 2006 From: pmr at pajato.com (Paul Michael Reilly) Date: Sat, 25 Nov 2006 11:26:40 -0500 Subject: X server consuming lots of CPU cycles Message-ID: In the past few days I've noticed that the X server process is consuming 20-80% of the CPU on a regular basis as opposed to a more reasonable once in a blue moon. I haven't updated in about a week and was reluctant to do so until I saw a fix for the libXfont/xfs issues. I don't suppose anyone else is seeing unusually high X server usage recently or is aware of some change that would explain what I'm seeing. FWIW, I am running a A31p Thinkpad with 1G RAM and a 2+Ghz processor. The logs do not seem to show anything out of the ordinary. -pmr From philipp_subx at redfish-solutions.com Sat Nov 25 18:15:58 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 25 Nov 2006 11:15:58 -0700 Subject: X server consuming lots of CPU cycles In-Reply-To: References: Message-ID: <4568885E.7020804@redfish-solutions.com> Paul Michael Reilly wrote: >In the past few days I've noticed that the X server process is >consuming 20-80% of the CPU on a regular basis as opposed to a more >reasonable once in a blue moon. I haven't updated in about a week and >was reluctant to do so until I saw a fix for the libXfont/xfs issues. >I don't suppose anyone else is seeing unusually high X server usage >recently or is aware of some change that would explain what I'm >seeing. FWIW, I am running a A31p Thinkpad with 1G RAM and a 2+Ghz >processor. The logs do not seem to show anything out of the ordinary. > >-pmr > > I saw this a while ago and remembered a posting on the xorg mailing list about a change in the X server's scheduler would cause this sort of behavior in certain pathological cases on Linux (it was a while ago or I'd hunt for the citation). If you're running GDM, then you can do: cat >> /etc/gdm/custom.conf [server-Standard] priority=-10 ^D % gdm-restart and see if that works. -Philip From n0dalus+redhat at gmail.com Sat Nov 25 18:47:38 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 26 Nov 2006 05:17:38 +1030 Subject: X server consuming lots of CPU cycles In-Reply-To: References: Message-ID: <6280325c0611251047j1f31554co78b410466c65c548@mail.gmail.com> On 11/26/06, Paul Michael Reilly wrote: > In the past few days I've noticed that the X server process is > consuming 20-80% of the CPU on a regular basis as opposed to a more > reasonable once in a blue moon. I haven't updated in about a week and > was reluctant to do so until I saw a fix for the libXfont/xfs issues. > I don't suppose anyone else is seeing unusually high X server usage > recently or is aware of some change that would explain what I'm A couple of people have reported a combination of Firefox + Flash plugin to be causing various problems with high X server load lately. If you are running Firefox with flash, try disabling flash and see if the problem continues. Hope that helps, n0dalus. From steve at silug.org Sat Nov 25 19:57:32 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 25 Nov 2006 13:57:32 -0600 Subject: X server consuming lots of CPU cycles In-Reply-To: <6280325c0611251047j1f31554co78b410466c65c548@mail.gmail.com> References: <6280325c0611251047j1f31554co78b410466c65c548@mail.gmail.com> Message-ID: <20061125195732.GA18336@osiris.silug.org> On Sun, Nov 26, 2006 at 05:17:38AM +1030, n0dalus wrote: > A couple of people have reported a combination of Firefox + Flash > plugin to be causing various problems with high X server load lately. > If you are running Firefox with flash, try disabling flash and see if > the problem continues. http://flashblock.mozdev.org/ is an easy way to disable Flash until you really want it. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From green at redhat.com Sat Nov 25 23:16:53 2006 From: green at redhat.com (Anthony Green) Date: Sat, 25 Nov 2006 15:16:53 -0800 Subject: hsqldb's long-standing packaging bug In-Reply-To: <883cfe6d0611241145x51b8b829u64ccf7ebce830515@mail.gmail.com> References: <883cfe6d0611241145x51b8b829u64ccf7ebce830515@mail.gmail.com> Message-ID: <1164496614.2972.10.camel@localhost.localdomain> On Fri, 2006-11-24 at 14:45 -0500, Michel Salim wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166466 > > hsqldb has some trivial packaging bug that's been untouched for ages. > Alas, we Extras maintainers can't currently touch Core packages.. > > Could someone step in and fix this? For some reason it's currently > assigned to someone who's not a Core developer judging from the email > address. I'll forward this to fedora-devel-java-list. I'm sure one of the Core developers can clean this up quickly. Thanks, AG > Thanks, > > -- > Michel Salim > > Don't worry about avoiding temptation -- as you grow older, it starts > avoiding you. > -- The Old Farmer's Almanac > From giallu at gmail.com Sun Nov 26 00:41:21 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 26 Nov 2006 01:41:21 +0100 Subject: FC6 on a HP DC7700 In-Reply-To: <1164306923.3147.1.camel@laptopd505.fenrus.org> References: <1164306923.3147.1.camel@laptopd505.fenrus.org> Message-ID: On 11/23/06, Arjan van de Ven wrote: > On Thu, 2006-11-23 at 19:06 +0100, Gianluca Sforna wrote: > > Hi all, > > I just put my hands on a shiny HP DC7700, a Core 2 Duo based PC, but I > > can't boot the installer because it hangs right after detecting > > keyboard and mouse (PS/2) > > > > Does anyone experienced similar issues? > > > try nmi_watchdog=0 > > another thing to try is disabling USB PS/2 emulation in the bios... > Thanks Arjan, but this voodoo spell did not work... What I determined so far is: * boot stops earlier if I do not pass acpi=off * wioth acpi=off boot stops after PS/2 mouse and KB recognition * I can proceed further by either adding noapic or by switching to USB mouse _and_ keyboard ( can not find any setting in the bios for disabling PS/2 emulation). I could do a more detailed report on monday, when I will get back at work. FWIW, I could not boot also with the Linux Firmware Kit cdrom I have around here, not even with the "safe" mode. I guess this is going to be tricky installation... From caillon at redhat.com Sun Nov 26 07:30:30 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 26 Nov 2006 02:30:30 -0500 Subject: Xlib: Maximum number of clients reached -- firefox? In-Reply-To: References: Message-ID: <45694296.3080403@redhat.com> Joshua Baker-LePain wrote: > I'm rather happily running FC6 on my Thinkpad Z61t. I got even happier > when I discovered that suspend works without a hitch, with no > pre-suspend fiddling required. On resume, everything comes back up > including my WPA-encrypted ipw3945 wireless connection, and this with my > HDD in AHCI mode. All very, very shiny. > > So I haven't shut down or logged out in a week. Today, though I started > getting errors like this upon trying to start new apps: > > Xlib: connection to ":0.0" refused by server > Xlib: Maximum number of clients reached > > 'xrestop' takes an absurd amount of CPU time to run, but seems to > indicate that firefox has a huge number of windows open (over 2500). I > certainly don't have that many windows/taps actually open, but I also > haven't shut down firefox in almost a week. > > Is this a firefox bug that needs reporting? If not, where should I be > looking? It's not firefox, it's flash 9 beta. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217005 I suggest you report it to Adobe via whatever mechanism the beta program uses. From buildsys at redhat.com Sun Nov 26 11:10:02 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 26 Nov 2006 06:10:02 -0500 Subject: rawhide report: 20061126 changes Message-ID: <200611261110.kAQBA2ph011869@hs20-bc2-6.build.redhat.com> Updated Packages: NetworkManager-1:0.6.5-0.cvs20061025.fc7.1 ------------------------------------------ * Sat Nov 25 2006 Matthias Clasen - Own the /etc/NetworkManager/dispatcher.d directory - Require pkgconfig for the -devel packages - Fix compilation with dbus 1.0 compiz-0.3.4-2.fc7 ------------------ * Sat Nov 25 2006 Matthias Clasen - 0.3.4-2 - Update the fedora logo patch (#217224) cpio-2.6-20.fc7 --------------- * Sat Nov 25 2006 Peter Vrabec 2.6-20 - cpio man page provided by RedHat dbus-1.0.1-2.fc7 ---------------- * Sun Nov 26 2006 Matthias Clasen - 1.0.1-2 - Include docs, and make them show up in devhelp * Mon Nov 20 2006 Ray Strode - 1.0.1-1 - Update to 1.0.1 - Apply patch from Thiago Macieira to fix failed assertion in threading implementation - Drop some crazy looking build time speed optimization * Tue Nov 14 2006 John (J5) Palmieri - 1.0.0-2 - add patch to fix dbus_threads_init_default devhelp-0.12-9.fc7 ------------------ * Sat Nov 25 2006 Matthias Clasen - 0.12-9 - Own the /usr/share/devhelp/books directory * Fri Oct 27 2006 Christopher Aillon - 0.12-8 - Rebuild against newer gecko * Wed Oct 18 2006 Matthias Clasen - 0.12-7 - Fix scripts according to the packaging guidelines - Require pkgconfig in the -devel package findutils-1:4.2.29-1 -------------------- * Sun Nov 26 2006 Miloslav Trmac - 1:4.2.29-1 - Update to findutils-4.2.29 - Fix some rpmlint warnings gdb-6.5-18.fc7 -------------- * Sat Nov 25 2006 Jan Kratochvil - 6.5-18 - Fix readline history for input mode commands like `command' (BZ 215816). * Thu Nov 16 2006 Jan Kratochvil - 6.5-17 - Bugfix testcase typo of gdb-6.5-16. * Thu Nov 16 2006 Jan Kratochvil - 6.5-16 - Provide testcase for accessing the last address space byte. gnome-pilot-2.0.15-1.fc7 ------------------------ * Fri Nov 24 2006 Matthew Barnes - 2.0.15-1.fc7 - Update to 2.0.15 * Mon Nov 06 2006 Matthew Barnes - 2.0.14-3.fc7 - Look for conduit files under $(libdir) instead of $(datadir). gnome-pilot-conduits-2.0.15-1.fc7 --------------------------------- * Fri Nov 24 2006 Matthew Barnes - 2.0.15-1.fc7 - Update to 2.0.15 libXfont-1.2.3-4.fc7 -------------------- * Sat Nov 25 2006 Adam Jackson 1.2.3-4.fc7 - Revert the namespace whatsit until xfs is sorted out. m4-1.4.8-1 ---------- * Sun Nov 26 2006 Miloslav Trmac - 1.4.8-1 - Update to m4-1.4.8 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From bojan at rexursive.com Sun Nov 26 21:26:36 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 26 Nov 2006 21:26:36 +0000 (UTC) Subject: ifup-ipsec: Manual v. Automatic keying References: <1160109948.2620.13.camel@shrek.rexursive.com> <20061009170927.GA9892@nostromo.devel.redhat.com> <1160436050.2591.6.camel@shrek.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Thanks. I'll wait until this FC5 box becomes FC6 (any day now and if > the problem still exists (i.e. if I can't get the tunnel up without > hacks), I'll report a bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217306 -- Bojan From dominik-dated-1167177383.0e3370 at schnitzer.at Sun Nov 26 23:56:44 2006 From: dominik-dated-1167177383.0e3370 at schnitzer.at (Dominink Schnitzer) Date: Sun, 26 Nov 2006 23:56:44 +0000 (UTC) Subject: FC6 on a HP DC7700 References: <1164306923.3147.1.camel@laptopd505.fenrus.org> Message-ID: Gianluca Sforna gmail.com> writes: > > On 11/23/06, Arjan van de Ven fenrus.demon.nl> wrote: > > On Thu, 2006-11-23 at 19:06 +0100, Gianluca Sforna wrote: > > > Hi all, > > > I just put my hands on a shiny HP DC7700, a Core 2 Duo based PC, but I > > > can't boot the installer because it hangs right after detecting > > > keyboard and mouse (PS/2) > > > > > > Does anyone experienced similar issues? Hi, We've bought 5 of these desktops and and have exactly the same problems.. It seems that it's not possible to boot into any Linux System at all. Besides FC, we've tried Knoppix 4.02, 5.01, Ubuntu Breezy and Edgy 6.10. So far I've tried passing: "nolapic noapic acpi=off fb=false pci=bios" to the kernel but none of these in any combination worked. Did you have any success? > I guess this is going to be tricky installation... I hope there will be an installation at all :-) greetings, dominik. From codeshepherd at gmail.com Mon Nov 27 05:00:56 2006 From: codeshepherd at gmail.com (Deepan) Date: Mon, 27 Nov 2006 13:00:56 +0800 Subject: DriveReady SeekComplete Error Message-ID: <1164603656.4344.3.camel@codeworld> Hi All, I get this Input/Output Error while trying to copy files from my cdrom. Mounting the cdrom works fine. I can see the files. but when i try to copy them i get input/output error. I have the same problem with almost all CDs.dmesg reports the following. hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 00 02 04 00 00 01 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 2064 Buffer I/O error on device hdc, logical block 516 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 00 02 05 00 00 07 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 2068 Buffer I/O error on device hdc, logical block 517 Buffer I/O error on device hdc, logical block 518 Buffer I/O error on device hdc, logical block 519 Buffer I/O error on device hdc, logical block 520 Buffer I/O error on device hdc, logical block 521 Buffer I/O error on device hdc, logical block 522 Buffer I/O error on device hdc, logical block 523 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 00 02 04 00 00 02 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 2064 Buffer I/O error on device hdc, logical block 516 Buffer I/O error on device hdc, logical block 517 -- ----------------------------------------------- Regards Deepan Chakravarthy N http://www.codeshepherd.com/ +65-96770940 Software Developer, Nova Global Pte Ltd, Technical & Scientific Computing Solutions, #05-04 Keypoint, 371 Beach Road, Singapore. web: http://www.novaglobal.com.sg/ Have Fun, Play Sudoku :) http://sudoku-solver.net/ From rmg57 at telus.net Mon Nov 27 07:07:22 2006 From: rmg57 at telus.net (Myles Green) Date: Mon, 27 Nov 2006 00:07:22 -0700 Subject: DriveReady SeekComplete Error In-Reply-To: <1164603656.4344.3.camel@codeworld> References: <1164603656.4344.3.camel@codeworld> Message-ID: <20061127000722.078f9d40@redgreen-desktop> On Mon, 27 Nov 2006 13:00:56 +0800 Deepan wrote: > Hi All, > I get this Input/Output Error while trying to copy files from my cdrom. > Mounting the cdrom works fine. I can see the files. but when i try to > copy them i get input/output error. I have the same problem with almost > all CDs.dmesg reports the following. I've seen errors similar to this from hard drives and it's not a good sign. Time to start looking for a replacement drive I'd say. How old is this CDROM drive? -- Myles Green Geek by nature. Linux by choice. "Don't worry about the world coming to an end today. It's already tomorrow in Australia" (Charles Schultz) From giallu at gmail.com Mon Nov 27 08:17:49 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 27 Nov 2006 09:17:49 +0100 Subject: FC6 on a HP DC7700 In-Reply-To: References: <1164306923.3147.1.camel@laptopd505.fenrus.org> Message-ID: On 11/27/06, Dominink Schnitzer > We've bought 5 of these desktops and and have exactly the same problems.. It > seems that it's not possible to boot into any Linux System at all. Besides FC, > we've tried Knoppix 4.02, 5.01, Ubuntu Breezy and Edgy 6.10. I have 3 of them myself... I probably had to check: http://www.hp.com/wwsolutions/linux/certifications.html _before_ buying them... fortunately enough the Proliant server I bought along with these clients IS listed as compatible. > > > I guess this is going to be tricky installation... > > I hope there will be an installation at all :-) me too... From thuforuk at yahoo.co.uk Mon Nov 27 09:48:52 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Mon, 27 Nov 2006 09:48:52 +0000 Subject: DriveReady SeekComplete Error In-Reply-To: <1164603656.4344.3.camel@codeworld> References: <1164603656.4344.3.camel@codeworld> Message-ID: <456AB484.4080000@yahoo.co.uk> On 11/27/2006 05:00 AM, Deepan wrote: > Hi All, > I get this Input/Output Error while trying to copy files from my cdrom. > Mounting the cdrom works fine. I can see the files. but when i try to > copy them i get input/output error. I have the same problem with almost > all CDs.dmesg reports the following. [...] Try and replace the IDE cable. May very well help. Regards, Dariusz ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From buildsys at redhat.com Mon Nov 27 10:49:34 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 27 Nov 2006 05:49:34 -0500 Subject: rawhide report: 20061127 changes Message-ID: <200611271049.kARAnYEG018036@hs20-bc2-6.build.redhat.com> Updated Packages: fonts-arabic-2.0-2.fc7 ---------------------- * Mon Nov 27 2006 Parag Nemade - 2.0-2 - Fixed Bug 217336 for worng file name extension to paktype-20060712.tar.gz gaim-2:2.0.0-0.23.beta5.fc7 --------------------------- * Sun Nov 26 2006 Warren Togami - 2:2.0.0-0.23.beta5 - Debian patch 08_jabber-info-crash * Tue Nov 21 2006 Warren Togami - 2:2.0.0-0.22.beta5 - 2.0.0 beta5 - Debian patches 02_gnthistory-in-gtk 03_gconf-gstreamer 04_blist-memleak 05_url-handler-xmpp 06_jabber-registration-srv 07_msn-custom-smiley-crash - SILC Account Edit Crash * Tue Nov 21 2006 Warren Togami - 2:2.0.0-0.21.beta4 - #212817 Jabber needs cyrus-sasl plugins for authentication gettext-0.16-2.fc7 ------------------ * Mon Nov 27 2006 Jens Petersen - 0.16-2 - re-enable openmp on ia64 gnome-mime-data-2.4.3-2.fc7 --------------------------- * Sun Nov 26 2006 Matthias Clasen - 2.4.3-2 - Own the /usr/share/mime-info directory (#216922) gnome-session-2.17.2-6.fc7 -------------------------- * Mon Nov 27 2006 Ray Strode - 2.17.2-6 - don't set http_proxy variable if proxy requires password (bug 217332) libgnomeprint22-2.17.0-2.fc7 ---------------------------- * Mon Nov 27 2006 Matthias Clasen - 2.17.0-2 - Fix BuildRequires scim-1.4.5-4.fc7 ---------------- * Fri Nov 24 2006 Shawn Huang - 1.4.5-4 - add scim-turn-off-snooper.patch to turn off key snooper in im-scim, it fixed crashes when clicking during scim gtkimm preedit (#213796) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From buc at odusz.so-cdu.ru Mon Nov 27 11:23:39 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 27 Nov 2006 14:23:39 +0300 Subject: Static linking considered harmful In-Reply-To: <20061124182848.GD31787@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122115015.GI2799@free.fr> <20061124182848.GD31787@neu.nirvana> Message-ID: <456ACABB.7090309@odu.neva.ru> Axel Thimm wrote: >The typical >situation in natural sciences is that there are more Linux versions >around than there are employees, and sometimes statically linking is >the only way to distribute your code to the number cruncers. > > To look the problem more clearly, maybe determine the list of libraries used for linking such a "numeric models" (statically)? What libs are used in your case exactly? Perhaps these libraries is not so dangerous (unlike graphics/compress/crypt and friends) ... ~buc From pertusus at free.fr Mon Nov 27 11:29:29 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Nov 2006 12:29:29 +0100 Subject: Static linking considered harmful In-Reply-To: <456ACABB.7090309@odu.neva.ru> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <20061122104119.GT6570@devserv.devel.redhat.com> <20061122104904.GG2799@free.fr> <45642C46.9040803@warmcat.com> <20061122115015.GI2799@free.fr> <20061124182848.GD31787@neu.nirvana> <456ACABB.7090309@odu.neva.ru> Message-ID: <20061127112929.GB2975@free.fr> On Mon, Nov 27, 2006 at 02:23:39PM +0300, Dmitry Butskoy wrote: > To look the problem more clearly, maybe determine the list of libraries > used for linking such a "numeric models" (statically)? What libs are > used in your case exactly? > Perhaps these libraries is not so dangerous (unlike > graphics/compress/crypt and friends) ... I don't know for others, but personally I can use netcdf, the cernlib, lapack/blas/atlas, libc, the gsl. And if I someday code in C++, libstdc++ will be required. -- Pat From seg at haxxed.com Mon Nov 27 11:48:54 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 27 Nov 2006 05:48:54 -0600 Subject: Static linking considered harmful In-Reply-To: <20061124185230.GE31787@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> Message-ID: <1164628135.5452.33.camel@max.booze> On Fri, 2006-11-24 at 19:52 +0100, Axel Thimm wrote: > And please note that the target group we're talking about are simple > users (even though they may be very skillful programmers), not some > package monkeys that will create rpms and debs for all systems > required or that even care about DSO, tarballing their runtime > enviroment and scripting launchers and so on (just quoting some > solutions offered in this thread). The Second Life client is a proprietary app distributed in binary form, that's expected to run on any distribution. It commonly run on Fedora, Ubuntu, SuSe and Debian. Its the *cough* Gentoo users that seem to have problems... Its a fairly complex app with tons of library deps. So many that I'm not going to paste an ldd dump here. It is started with a wrapper script that sets LD_LIRBARY_PATH, and ships with a selection of shared libs known to be problematic: libapr-1.so.0 libaprutil-1.so.0 libcrypto.so.0.9.7 libcurl.so.3 libdb-4.2.so libexpat.so.1 libfmod-3.75.so libkdu_v42R.so libogg.so.0 libssl.so.0.9.7 libstdc++.so.6 libvorbisenc.so.0 libvorbisfile.so.0 libvorbis.so.0 libxmlrpc.so.0 Shipping a dynamically compiled app in a single tarball capable of running on multiple distributions is quite possible. It works for Linden Lab, and Google Earth is shipped in a similar manner. Your only argument seems to be that these skillful programmers, that presumably have advanced math degrees if they're programming scientific number crunching apps, and can figure out how to statically compile their app, are too retarded to write a trivial one line wrapper script, run ldd on their app, and tar up their app with the libs it needs. -------------- 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 giallu at gmail.com Mon Nov 27 11:52:29 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 27 Nov 2006 12:52:29 +0100 Subject: FC6 on a HP DC7700 In-Reply-To: References: <1164306923.3147.1.camel@laptopd505.fenrus.org> Message-ID: On 11/26/06, Gianluca Sforna wrote: > > I could do a more detailed report on monday, when I will get back at work. > As promised here is a more detailed report: right now I have attached only a USB keyboard to it; during the (PXE) boot without any kernel parameters, everything seems normal until the lines: - Freeing initrd memory: 5802 freed - HP Compaq Laptop seriers board detected. Selecting BIOS-methods for reboots. which should be harmless, but wrong nonetheless, since this is everithing but a laptop. Then it starts ACPI stuff: - ACPI: bus type pci registered - PCI: Using MMCONFIG - Setting up standard PCI resources - ACPI: interpreter enabled - ACPI: using IOAPIC for interrupt routing - ACPI: PCI Root Bridge [PCI0] (0000:00) - ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 then hangs. The same happens adding noapic; the only difference is a a couple of lines disappeared: ENABLING IO-APIC IRQs .. TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 with nolapic still hangs at the same line, but I have more scary messages: ENABLING IO-APIC IRQs BIOS bug, IO-APIC#0 ID 1 is already used!... ... fixing up to 2. (tell your hw vendor) ..TIMER: vector=0x31 apic1=-1 pin1=-1 apic2=-1 pin2=-1 ...trying to set up timer (IRQ0) through the 8259A ... failed. ...trying to set up timer as Virtual Wire IRQ... works with acpi=off I can reach anaconda, but the slowness is there despite I'm not using anymore PS/2 peripherals I hope this is somewhat useful... From pertusus at free.fr Mon Nov 27 12:26:47 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Nov 2006 13:26:47 +0100 Subject: Static linking considered harmful In-Reply-To: <1164628135.5452.33.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> Message-ID: <20061127122646.GC2975@free.fr> On Mon, Nov 27, 2006 at 05:48:54AM -0600, Callum Lerwick wrote: > > Shipping a dynamically compiled app in a single tarball capable of > running on multiple distributions is quite possible. It works for Linden > Lab, and Google Earth is shipped in a similar manner. It is a very different case, here there are people whose job is to package the application. My use case is not that one. > Your only argument seems to be that these skillful programmers, that > presumably have advanced math degrees if they're programming scientific > number crunching apps, and can figure out how to statically compile > their app, are too retarded to write a trivial one line wrapper script, > run ldd on their app, and tar up their app with the libs it needs. Of course they can, but it is less simple, why do something complicated when something simple is available? -- Pat From jkeating at redhat.com Mon Nov 27 12:40:24 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 27 Nov 2006 07:40:24 -0500 Subject: Static linking considered harmful In-Reply-To: <20061127122646.GC2975@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> Message-ID: <200611270740.27393.jkeating@redhat.com> On Monday 27 November 2006 07:26, Patrice Dumas wrote: > Of course they can, but it is less simple, why do something complicated > when something simple is available? For similar reasons that ssh is replacing telnet... Many times easier != better. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcdavey at mrao.cam.ac.uk Mon Nov 27 12:43:13 2006 From: mcdavey at mrao.cam.ac.uk (Matt Davey) Date: Mon, 27 Nov 2006 12:43:13 +0000 Subject: Static linking considered harmful In-Reply-To: <1164628135.5452.33.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> Message-ID: <1164631393.12937.123.camel@sirocco.local.corvil.com> A lot has been said already in this thread, and I'm not qualified to contribute to the technical discussion but am happy to contribute my two cents. cent #1: removing all static libs from fedora overnight would cause headaches for a sizeable chunk of fedora users. cent #2: making -static RPMs available, at least for one full fedora release cycle, but probably longer, would be a sensible migration path. It seems obvious to me that when you are considering a change such as this that you should be cautious. I think it's fair to consider static linking as a 'deprecated API'. As such, if a decision is made to move away from it, then it should hang around as an available option for a fair while, to enable people to migrate or re-architect. Anything else is just a bit rude. Forcing people to adjust overnight because suddenly a technically superior solution has been mandated will unnecessarily alienate a lot of people. Matt Matt Davey Why is it difficult to find men who are sensitive, caring and mcdavey at mrao.cam.ac.uk good looking? - They've all got boyfriends already. From Axel.Thimm at ATrpms.net Mon Nov 27 12:51:00 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 27 Nov 2006 13:51:00 +0100 Subject: Static linking considered harmful In-Reply-To: <1164628135.5452.33.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> Message-ID: <20061127125100.GC12853@neu.nirvana> On Mon, Nov 27, 2006 at 05:48:54AM -0600, Callum Lerwick wrote: > On Fri, 2006-11-24 at 19:52 +0100, Axel Thimm wrote: > > And please note that the target group we're talking about are simple > > users (even though they may be very skillful programmers), not some > > package monkeys that will create rpms and debs for all systems > > required or that even care about DSO, tarballing their runtime > > enviroment and scripting launchers and so on (just quoting some > > solutions offered in this thread). > Shipping a dynamically compiled app in a single tarball capable of > running on multiple distributions is quite possible. It works for Linden > Lab, and Google Earth is shipped in a similar manner. > > Your only argument seems to be that these skillful programmers, that > presumably have advanced math degrees if they're programming scientific > number crunching apps, and can figure out how to statically compile > their app, are too retarded to write a trivial one line wrapper script, > run ldd on their app, and tar up their app with the libs it needs. You're oversimplifying and tend to become insultive of this user group w/o neccessity. Comparing with the staff at google earth is quite unballanced. Also in order to ship a "runtime environment" in tarballs you first need to identify the changing set of needed libraries which is work to invest and which breaks from FC to FC (you need to redetect the new set of runtime libs). These people with "advanced math degrees" don't want to spend their days in linking intricacies of a Linux distribution, they want to get their work done and shared either locally or globally. If you have met this community you will know that they will go Ubuntu the next moment their static linking is not working on Fedora. That's already happening BTW, so you'll just be giving more arguments to get the last scientist off Fedora. Ask yourself: if it were as easy as you claim (a one-liner) then why do people use static linking and why is this thread so long? Are all but you blind? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Mon Nov 27 12:55:47 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 27 Nov 2006 13:55:47 +0100 Subject: Static linking considered harmful In-Reply-To: <20061127122646.GC2975@free.fr> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> Message-ID: <1164632147.3276.25.camel@laptopd505.fenrus.org> > > > Your only argument seems to be that these skillful programmers, that > > presumably have advanced math degrees if they're programming scientific > > number crunching apps, and can figure out how to statically compile > > their app, are too retarded to write a trivial one line wrapper script, > > run ldd on their app, and tar up their app with the libs it needs. > > Of course they can, but it is less simple, why do something complicated > when something simple is available? because the simple case breaks. Now the goal then should maybe be "make packaging self contained apps as easy as sticking -static on cflags".... From jakub at redhat.com Mon Nov 27 12:58:42 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 27 Nov 2006 07:58:42 -0500 Subject: Static linking considered harmful In-Reply-To: <20061127125100.GC12853@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127125100.GC12853@neu.nirvana> Message-ID: <20061127125842.GX6570@devserv.devel.redhat.com> On Mon, Nov 27, 2006 at 01:51:00PM +0100, Axel Thimm wrote: > their work done and shared either locally or globally. If you have met > this community you will know that they will go Ubuntu the next moment > their static linking is not working on Fedora. That's already > happening BTW, so you'll just be giving more arguments to get the last > scientist off Fedora. Since when does Ubuntu use a different C library from Fedora? The problems with static linking pointed out here are in no way specific to Fedora, some of the problems are completely generic things, some are related to LGPL, some to ELF, some to the GNU C Library. Jakub From Axel.Thimm at ATrpms.net Mon Nov 27 13:04:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 27 Nov 2006 14:04:24 +0100 Subject: Static linking considered harmful In-Reply-To: <20061127125842.GX6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127125100.GC12853@neu.nirvana> <20061127125842.GX6570@devserv.devel.redhat.com> Message-ID: <20061127130424.GD12853@neu.nirvana> On Mon, Nov 27, 2006 at 07:58:42AM -0500, Jakub Jelinek wrote: > On Mon, Nov 27, 2006 at 01:51:00PM +0100, Axel Thimm wrote: > > their work done and shared either locally or globally. If you have met > > this community you will know that they will go Ubuntu the next moment > > their static linking is not working on Fedora. That's already > > happening BTW, so you'll just be giving more arguments to get the last > > scientist off Fedora. > > Since when does Ubuntu use a different C library from Fedora? The problems > with static linking pointed out here are in no way specific to Fedora, > some of the problems are completely generic things, some are related > to LGPL, some to ELF, some to the GNU C Library. what is specific to Fedora is that there were suggestions in this very thread (maybe even by you or Ulrich, I don't remeber) to remove static parts of the glibc/stdlibc++ or other vital parts making it almost impossible for an end user to use the platform for statically linking. Already requiring people packaging scientific libs in Fedora go through loops to justify shipping static libs is an artificial obstacle we construct ourself and will demotivate people, both packagers and users alike. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Nov 27 13:25:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Nov 2006 14:25:34 +0100 Subject: Static linking considered harmful In-Reply-To: <200611270740.27393.jkeating@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> <200611270740.27393.jkeating@redhat.com> Message-ID: <20061127132534.GD2975@free.fr> On Mon, Nov 27, 2006 at 07:40:24AM -0500, Jesse Keating wrote: > On Monday 27 November 2006 07:26, Patrice Dumas wrote: > > Of course they can, but it is less simple, why do something complicated > > when something simple is available? > > For similar reasons that ssh is replacing telnet... Many times easier != > better. The comparison isn't relevant. ssh is really different from telnet, while static and dynamic linking are - in the use case I am speaking about - very similar. And telnet can also have use cases, for example on network isolated from internet where you trust the user who have physical access to the computers anyway and could steal your keys. -- Pat From pbruna at it-linux.cl Mon Nov 27 14:09:34 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 27 Nov 2006 11:09:34 -0300 (CLST) Subject: dbus-qt Message-ID: <10419443.371164636574387.JavaMail.root@lisa.it-linux.cl> Anyone knows if there a dbus-qt package available for FC6 and compatible with dbus-0.93? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Mon Nov 27 14:38:05 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Nov 2006 08:38:05 -0600 Subject: dbus-qt In-Reply-To: <10419443.371164636574387.JavaMail.root@lisa.it-linux.cl> References: <10419443.371164636574387.JavaMail.root@lisa.it-linux.cl> Message-ID: <200611270838.07311.dennis@ausil.us> On Monday 27 November 2006 08:09, Patricio A. Bruna wrote: > Anyone knows if there a dbus-qt package available for FC6 and compatible > with dbus-0.93? its not available as the dbus-qt bindings are un-manitained qt4 dbus bindings are part of qt and they should be compatabile. for knetworkmanager i patched in the dbus bindings -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From pbruna at it-linux.cl Mon Nov 27 14:52:06 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 27 Nov 2006 11:52:06 -0300 (CLST) Subject: dbus-qt In-Reply-To: <200611270838.07311.dennis@ausil.us> Message-ID: <26065131.431164639126802.JavaMail.root@lisa.it-linux.cl> and you have knetworkmanger working ok? mine does not. ----- Mensaje Original ----- De: Dennis Gilmore Para: Development discussions related to Fedora Core Enviados: lunes 27 de noviembre de 2006 11H38 GMT-0400 America/Santiago Asunto: Re: dbus-qt On Monday 27 November 2006 08:09, Patricio A. Bruna wrote: > Anyone knows if there a dbus-qt package available for FC6 and compatible > with dbus-0.93? its not available as the dbus-qt bindings are un-manitained qt4 dbus bindings are part of qt and they should be compatabile. for knetworkmanager i patched in the dbus bindings -- ,-._|\ Dennis Gilmore, RHCE / \ Proud Australian \_.--._/ | Aurora | Fedora | v -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From buc at odusz.so-cdu.ru Mon Nov 27 15:04:45 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 27 Nov 2006 18:04:45 +0300 Subject: Suggestion: Static libs policy, a draft (was: Re: Static linking considered harmful) In-Reply-To: <20061122100800.GQ6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> Message-ID: <456AFE8D.8050205@odu.neva.ru> There seems that some compromise might be possible here. I try to formulate certain approximate theses. First of all, static libraries (if present) must go to the separate package ("-devel-static" or just "-static"). In order to support any static link, the "main system library", libc.a, must be present anyway 1. IF a library is needed for some binary which are built static in Core, such a library must have static variant too. In other words, for all statically linked executables in Core (recovering, init/boot time etc.), all the libraries which take place in the correspond static linkage must be present. 2. ELSE IF the library hardly depends on some particular environment, it must not have static variant. For example, static linking with Gnome or KDE seems to be unuseful anyway. 3. ELSE IF the library processes any data which usually or potentially might come on a computer from an "external world", or if it designed to operate with some kind of "external world", such a library must not have static variant. Here all the wide-used binary contents (graphic, compress, crypt) and network protocols (ssl, X). (Most often security issues are related for such types of libraries). 4. ELSE IF the library seems to be useful for static linking in some specific local environments, and there are some known users (or some known kind of users) who use it, this library should have the static variant. Here, for example, all "numeric/scientific" libraries (as already discussed for portability), maybe even ncurses, etc. 5. ELSE All another libraries must not have static by default. If some user request for it, the library's maintainer may provide static variant. The library's maintainer should provide a way for user to re-compile the library statically -- for example, by rpmbuild option "--with-static" and correspond condition macros in the .spec file. In short words: 1. if Used for static linking something in Core -- yes 2. elseif Unuseful anyway -- no 3. elseif Dangerous for security -- no 4. elseif Some kind of users use it locally -- yes 5. else maybe, but default -- no Libraries of p.1 certainly should be available on CD/DVD, but libraries of p.4/p.5 must be distributed the same way as "-debuginfo" packages (i.e,, outside of the main distro trees). Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy P.S. Please note, that it is just a draft... ;) From laurent.rineau__fedora_extras at normalesup.org Mon Nov 27 15:04:22 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Mon, 27 Nov 2006 16:04:22 +0100 Subject: Equivalent of debootstrap for Fedora Message-ID: <200611271604.22312@rineau.schtroumpfette> Hi, As a Fedora Extras contributor, I would like to install parts of rawhide in a chroot (I currently run FC-5, and will upgrade to FC-6 soon). I know that I can install it with Anaconda, in a partition of my disk. But I would have prefere to do it without rebooting my computer. Is there a tool, similar to Debian's debootstrap, that allows to install a version of Fedora in a chroot? In a way, mock has this feature. Is there a practical way to use parts of mock code to do it? From dennis at ausil.us Mon Nov 27 15:15:57 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Nov 2006 09:15:57 -0600 Subject: dbus-qt In-Reply-To: <26065131.431164639126802.JavaMail.root@lisa.it-linux.cl> References: <26065131.431164639126802.JavaMail.root@lisa.it-linux.cl> Message-ID: <200611270915.58113.dennis@ausil.us> On Monday 27 November 2006 08:52, Patricio A. Bruna wrote: > and you have knetworkmanger working ok? > mine does not. yes i use it daily. What are you trying to do. what are you trying to use it with ? -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From alan at redhat.com Mon Nov 27 15:59:48 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 27 Nov 2006 10:59:48 -0500 Subject: DriveReady SeekComplete Error In-Reply-To: <1164603656.4344.3.camel@codeworld> References: <1164603656.4344.3.camel@codeworld> Message-ID: <20061127155948.GB29021@devserv.devel.redhat.com> On Mon, Nov 27, 2006 at 01:00:56PM +0800, Deepan wrote: > I get this Input/Output Error while trying to copy files from my cdrom. > Mounting the cdrom works fine. I can see the files. but when i try to > copy them i get input/output error. I have the same problem with almost > all CDs.dmesg reports the following. Video CD of some kind, or mixed audio video ? > ATAPI device hdc: > Error: Illegal request -- (Sense key=0x05) > Illegal mode for this track or incompatible medium -- (asc=0x64, > ascq=0x00) Thats normally "tried to read an audio or video track as data" From notting at redhat.com Mon Nov 27 16:03:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:03:56 -0500 Subject: Desktop-effects In-Reply-To: <1164470906.3328.10.camel@localhost.localdomain> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> Message-ID: <20061127160356.GB30000@nostromo.devel.redhat.com> Thomas Canniot (thomas.canniot at laposte.net) said: > > The .pot file hasn't been prepared by the author. > > It will be released soon and we can make po files then. > > I think there is translation related problems here. > > Why hasn't it been made BEFORE FC6 ? > Why hasn't it be done at the same time than developing desktop-effects ? > Why translation is always seen as second class interest by developers ? > Why most translators seem to accept this second class idea ? > Why bugzilla bug reports must be opened to force a developer to add > translations ? > > Question I don't have any answer for ... yet ? Can't speak to the general cases, but in this case, it's an addition to an upstream package, which makes the translating process tricky, as it requires merging multiple source control repositories. Bill From ajackson at redhat.com Mon Nov 27 16:00:37 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 27 Nov 2006 11:00:37 -0500 Subject: X server consuming lots of CPU cycles In-Reply-To: References: Message-ID: <1164643237.30629.31.camel@localhost.localdomain> On Sat, 2006-11-25 at 11:26 -0500, Paul Michael Reilly wrote: > In the past few days I've noticed that the X server process is > consuming 20-80% of the CPU on a regular basis as opposed to a more > reasonable once in a blue moon. I haven't updated in about a week and > was reluctant to do so until I saw a fix for the libXfont/xfs issues. > I don't suppose anyone else is seeing unusually high X server usage > recently or is aware of some change that would explain what I'm > seeing. FWIW, I am running a A31p Thinkpad with 1G RAM and a 2+Ghz > processor. The logs do not seem to show anything out of the ordinary. man oprofile - ajax From pbruna at it-linux.cl Mon Nov 27 16:19:05 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 27 Nov 2006 13:19:05 -0300 (CLST) Subject: dbus-qt In-Reply-To: <200611270915.58113.dennis@ausil.us> Message-ID: <14551782.521164644345940.JavaMail.root@lisa.it-linux.cl> i have FC6 with kde, but knetworkmanager does not work, im doing nothing strange, it just not work. It works with wired networks, but not wireless, i have to setup de wireless card manually. Also, im trying to compile kpowersave, so i need dbus-qt ----- Mensaje Original ----- De: Dennis Gilmore Para: Development discussions related to Fedora Core Enviados: lunes 27 de noviembre de 2006 12H15 GMT-0400 America/Santiago Asunto: Re: dbus-qt On Monday 27 November 2006 08:52, Patricio A. Bruna wrote: > and you have knetworkmanger working ok? > mine does not. yes i use it daily. What are you trying to do. what are you trying to use it with ? -- ,-._|\ Dennis Gilmore, RHCE / \ Proud Australian \_.--._/ | Aurora | Fedora | v -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstrode at redhat.com Mon Nov 27 16:18:12 2006 From: rstrode at redhat.com (Ray Strode) Date: Mon, 27 Nov 2006 11:18:12 -0500 Subject: Desktop-effects In-Reply-To: <20061127160356.GB30000@nostromo.devel.redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> Message-ID: <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> Hi, On Mon, 2006-11-27 at 11:03 -0500, Bill Nottingham wrote: > Thomas Canniot (thomas.canniot at laposte.net) said: > > > The .pot file hasn't been prepared by the author. > > > It will be released soon and we can make po files then. > > > > I think there is translation related problems here. > > > > Why hasn't it been made BEFORE FC6 ? > > Why hasn't it be done at the same time than developing desktop-effects ? > > Why translation is always seen as second class interest by developers ? > > Why most translators seem to accept this second class idea ? > > Why bugzilla bug reports must be opened to force a developer to add > > translations ? > > > > Question I don't have any answer for ... yet ? > > Can't speak to the general cases, but in this case, it's an addition > to an upstream package, which makes the translating process tricky, as > it requires merging multiple source control repositories. For those who don't know, normally the way we do this is we put the desktop file in the redhat-menus package (which is translated on elvis) and install the file into /usr/share/desktop-menu-patches. Then, we ship a symlink in, e.g., the compiz package from the file to /usr/share/applications. --Ray From notting at redhat.com Mon Nov 27 16:37:51 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:37:51 -0500 Subject: removing termcap In-Reply-To: <1164244207.32083.19.camel@localhost.localdomain> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> Message-ID: <20061127163751.GD29814@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > > > - Move the most important entries in the terminfo database to > > /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, > > but the second option isn't much better as it will duplicate the > > entries on multiarch. > > I'm assuming that terminfo entries are architecture independent binary > files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. > It would be a bit odd to find part of the terminfo database > in /lib/terminfo and some in /usr/share/terminfo, though. I'd prefer /etc, just to make it more standard (and it would require less configuration hackery.) Bill From dimi at lattica.com Mon Nov 27 16:42:46 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 27 Nov 2006 11:42:46 -0500 (EST) Subject: removing termcap In-Reply-To: <20061127163751.GD29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> Message-ID: <3812.207.245.37.34.1164645766.squirrel@lattica.com> On Mon, November 27, 2006 11:37 am, Bill Nottingham wrote: >> I'm assuming that terminfo entries are architecture independent binary >> files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. >> It would be a bit odd to find part of the terminfo database >> in /lib/terminfo and some in /usr/share/terminfo, though. > > I'd prefer /etc, just to make it more standard (and it would require > less configuration hackery.) I'm not sure it's such a good idea to stick binary databases in /etc. They are not modifiable by the user anyway, /lib/terminfo seems more appropriate. -- Dimi Paun Lattica, Inc. From dennis at ausil.us Mon Nov 27 16:47:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Nov 2006 10:47:53 -0600 Subject: dbus-qt In-Reply-To: <14551782.521164644345940.JavaMail.root@lisa.it-linux.cl> References: <14551782.521164644345940.JavaMail.root@lisa.it-linux.cl> Message-ID: <200611271047.53766.dennis@ausil.us> On Monday 27 November 2006 10:19, Patricio A. Bruna wrote: > i have FC6 with kde, but knetworkmanager does not work, im doing nothing > strange, it just not work. It works with wired networks, but not wireless, > i have to setup de wireless card manually. > > Also, im trying to compile kpowersave, so i need dbus-qt > kpowersave you will need to patch in the dbus bindings look at how i did it with knetworkmanager as an example. What wireless card are you using? i have 2 laptops one a Dell Inspiron 4150 with an intel 2200 based wireless card. everything works flawlesly. my second is a apple powerbook and NetworkManager does not work with its broadcom chipset period. in FC-5 NetworkManager would attempt to connect but failed in FC-6 it will not use the card which uses the bcm43xx kernel module. i need to use wpa_supplicant and ifup on it. Please try using nm-applet if it fails in both file a bug against NetworkManager if its only knetworkmanager file a bug against it and i will try and fix it for you. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From buc at odusz.so-cdu.ru Mon Nov 27 16:49:08 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 27 Nov 2006 19:49:08 +0300 Subject: removing termcap In-Reply-To: <3812.207.245.37.34.1164645766.squirrel@lattica.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> Message-ID: <456B1704.5060004@odu.neva.ru> Dimi Paun wrote: >>I'd prefer /etc, just to make it more standard (and it would require >>less configuration hackery.) >> >> > >I'm not sure it's such a good idea to stick binary databases in /etc. >They are not modifiable by the user anyway, /lib/terminfo seems more >appropriate. > > +1 Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From notting at redhat.com Mon Nov 27 16:57:00 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:57:00 -0500 Subject: Desktop-effects In-Reply-To: <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> Message-ID: <20061127165700.GJ29814@nostromo.devel.redhat.com> Ray Strode (rstrode at redhat.com) said: > > Can't speak to the general cases, but in this case, it's an addition > > to an upstream package, which makes the translating process tricky, as > > it requires merging multiple source control repositories. > > For those who don't know, normally the way we do this is we put the > desktop file in the redhat-menus package (which is translated on elvis) > and install the file into /usr/share/desktop-menu-patches. Then, we ship > a symlink in, e.g., the compiz package from the file > to /usr/share/applications. But desktop-effects has more strings than just the desktop file. Bill From notting at redhat.com Mon Nov 27 17:12:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 12:12:20 -0500 Subject: removing termcap In-Reply-To: <3812.207.245.37.34.1164645766.squirrel@lattica.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> Message-ID: <20061127171220.GN29814@nostromo.devel.redhat.com> Dimi Paun (dimi at lattica.com) said: > > I'd prefer /etc, just to make it more standard (and it would require > > less configuration hackery.) > > I'm not sure it's such a good idea to stick binary databases in /etc. > They are not modifiable by the user anyway, /lib/terminfo seems more > appropriate. Well, they're modifiable with tic. I submit that they're at least as modifiable as selinux policies, sendmail databases, etc. Bill From buc at odusz.so-cdu.ru Mon Nov 27 17:19:45 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 27 Nov 2006 20:19:45 +0300 Subject: removing termcap In-Reply-To: <20061127171220.GN29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> <20061127171220.GN29814@nostromo.devel.redhat.com> Message-ID: <456B1E31.9050607@odu.neva.ru> Bill Nottingham wrote: >>I'm not sure it's such a good idea to stick binary databases in /etc. >>They are not modifiable by the user anyway, /lib/terminfo seems more >>appropriate. >> >> > >Well, they're modifiable with tic. I submit that they're at least >as modifiable as selinux policies, sendmail databases, etc. > > Whether they should be modifiable as often as sendmail or selinux data? For me, it looks like the same kind of data as /lib/kbd/ stuff... ~buc From mlichvar at redhat.com Mon Nov 27 17:38:11 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 27 Nov 2006 18:38:11 +0100 Subject: removing termcap In-Reply-To: <20061127171220.GN29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> <20061127171220.GN29814@nostromo.devel.redhat.com> Message-ID: <20061127173811.GC7380@localhost> On Mon, Nov 27, 2006 at 12:12:20PM -0500, Bill Nottingham wrote: > Dimi Paun (dimi at lattica.com) said: > > > I'd prefer /etc, just to make it more standard (and it would require > > > less configuration hackery.) > > > > I'm not sure it's such a good idea to stick binary databases in /etc. > > They are not modifiable by the user anyway, /lib/terminfo seems more > > appropriate. > > Well, they're modifiable with tic. I submit that they're at least > as modifiable as selinux policies, sendmail databases, etc. We can also use more paths in ncurses, /etc/terminfo will be for local terminfo database, ncurses will search here first, and /usr/share/terminfo:/lib/terminfo will contain the packaged database. -- Miroslav Lichvar From dimi at lattica.com Mon Nov 27 18:10:10 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 27 Nov 2006 13:10:10 -0500 (EST) Subject: removing termcap In-Reply-To: <20061127171220.GN29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> <20061127171220.GN29814@nostromo.devel.redhat.com> Message-ID: <4312.207.245.37.34.1164651010.squirrel@lattica.com> On Mon, November 27, 2006 12:12 pm, Bill Nottingham wrote: > Well, they're modifiable with tic. I submit that they're at least > as modifiable as selinux policies, sendmail databases, etc. The spirit of those files is different from termcap. People are supposed to change sendmail dbs, and even selinux policies. The binary parts are just different representations of text files (which are the files of record). Termcap on the other hand it's a readonly database, and even if it can be modified with tic (somehow it must have been created :) ), people are no supposed to mess with it. -- Dimi Paun Lattica, Inc. From rstrode at redhat.com Mon Nov 27 18:21:57 2006 From: rstrode at redhat.com (Ray Strode) Date: Mon, 27 Nov 2006 13:21:57 -0500 Subject: Desktop-effects In-Reply-To: <20061127165700.GJ29814@nostromo.devel.redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> <20061127165700.GJ29814@nostromo.devel.redhat.com> Message-ID: <1164651718.3398.1.camel@halflap.boston.devel.redhat.com> On Mon, 2006-11-27 at 11:57 -0500, Bill Nottingham wrote: > Ray Strode (rstrode at redhat.com) said: > > > Can't speak to the general cases, but in this case, it's an addition > > > to an upstream package, which makes the translating process tricky, as > > > it requires merging multiple source control repositories. > > > > For those who don't know, normally the way we do this is we put the > > desktop file in the redhat-menus package (which is translated on elvis) > > and install the file into /usr/share/desktop-menu-patches. Then, we ship > > a symlink in, e.g., the compiz package from the file > > to /usr/share/applications. > > But desktop-effects has more strings than just the desktop file. Ah right...We should just upstream it at elvis, I guess. --Ray From notting at redhat.com Mon Nov 27 18:22:34 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 13:22:34 -0500 Subject: Suggestion: Static libs policy, a draft (was: Re: Static linking considered harmful) In-Reply-To: <456AFE8D.8050205@odu.neva.ru> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> Message-ID: <20061127182234.GB32187@nostromo.devel.redhat.com> Dmitry Butskoy (buc at odusz.so-cdu.ru) said: > 1. IF a library is needed for some binary which are built static in > Core, such a library must have static variant too. > In other words, for all statically linked executables in Core > (recovering, init/boot time etc.), all the libraries which take place in > the correspond static linkage must be present. Obviously. This is sort of prerequisite for self-hosting. One issue with separate, auto-generated -devel-static packages - how do you handle dependencies? Or do you just handwave around the fact that (for example) kudzu-devel requires pciutils-devel? Bill From nicolas.mailhot at laposte.net Mon Nov 27 19:18:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Nov 2006 20:18:43 +0100 Subject: removing termcap In-Reply-To: <20061127163751.GD29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> Message-ID: <1164655124.3195.1.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 11:37 -0500, Bill Nottingham a ?crit : > Toshio Kuratomi (a.badger at gmail.com) said: > > On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > > > > > - Move the most important entries in the terminfo database to > > > /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, > > > but the second option isn't much better as it will duplicate the > > > entries on multiarch. > > > > I'm assuming that terminfo entries are architecture independent binary > > files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. > > It would be a bit odd to find part of the terminfo database > > in /lib/terminfo and some in /usr/share/terminfo, though. > > I'd prefer /etc, just to make it more standard (and it would require > less configuration hackery.) Of course if our layout were logical we'd have a /share root for these kinds of needs -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Nov 27 19:18:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Nov 2006 20:18:43 +0100 Subject: removing termcap In-Reply-To: <20061127163751.GD29814@nostromo.devel.redhat.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> Message-ID: <1164655125.3195.2.camel@rousalka.dyndns.org> Le lundi 27 novembre 2006 ? 11:37 -0500, Bill Nottingham a ?crit : > Toshio Kuratomi (a.badger at gmail.com) said: > > On Tue, 2006-11-21 at 18:49 +0100, Miroslav Lichvar wrote: > > > > > - Move the most important entries in the terminfo database to > > > /etc/terminfo or /lib{,64}/terminfo. Binary files don't fit /etc well, > > > but the second option isn't much better as it will duplicate the > > > entries on multiarch. > > > > I'm assuming that terminfo entries are architecture independent binary > > files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. > > It would be a bit odd to find part of the terminfo database > > in /lib/terminfo and some in /usr/share/terminfo, though. > > I'd prefer /etc, just to make it more standard (and it would require > less configuration hackery.) Of course if our layout were logical we'd have a /share root for these kinds of needs -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From michel.salim at gmail.com Mon Nov 27 20:50:13 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 27 Nov 2006 15:50:13 -0500 Subject: Equivalent of debootstrap for Fedora In-Reply-To: <200611271604.22312@rineau.schtroumpfette> References: <200611271604.22312@rineau.schtroumpfette> Message-ID: <883cfe6d0611271250i33475397med4a7aa994a8bdae@mail.gmail.com> 2006/11/27, Laurent Rineau : > Hi, > > As a Fedora Extras contributor, I would like to install parts of rawhide in a > chroot (I currently run FC-5, and will upgrade to FC-6 soon). > > I know that I can install it with Anaconda, in a partition of my disk. But I > would have prefere to do it without rebooting my computer. > > Is there a tool, similar to Debian's debootstrap, that allows to install a > version of Fedora in a chroot? In a way, mock has this feature. Is there a > practical way to use parts of mock code to do it? > You just answered it: mock http://fedoraproject.org/wiki/Extras/MockTricks (see bottom of file) Alternatively, install Rawhide as a Xen guest? I have not tried this, since the last time I checked the Xen host kernel does not do ACPI. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From chitlesh at fedoraproject.org Mon Nov 27 21:16:34 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 27 Nov 2006 22:16:34 +0100 Subject: KDE4 being packaged Message-ID: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> Hai you all :) Well, I just started packaging kde4 based on kevinkoefler's work. Some friends are porting kde3 apps to kde4, so why not give them the minimum tools needed ? kevinkoefler SRPMS are http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdelibs4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdepimlibs4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdebase4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm My modifications : http://chitlesh.funpic.de/fedora/kde4_11_27.tar.bz2 (I don't have a place to upload the SRPMS :( ) 1. the svn snapshot are from 20061003, neither kevin nor I got the time to update the snapshots. However my priority is just first get a working set of kde4 packages. 2. the specs don't have the patches inorder to integrate these packages to the fedora desktop. ThanNgo accepted to offer his help to. 3. SRPMs from my specs haven't undergo mock till now. 4. kde4 is installed on /opt/kde4 and kevin made so to co-existe kde3 and kde4 at the same time 5. the kde4.desktop doesn't load kde4 desktop upon login because it seeks its libkde*.so.5 at /usr/lib instead of /opt/kde4/lib I would like to have more light on this #5 in order to make it just work for once :) here is my /usr/share/xsessions/kde4.desktop: [Desktop Entry] Encoding=UTF-8 Type=XSession export KDEDIR=/opt/kde4 export PATH=/opt/kde4/bin/:$PATH export KDEHOME=~/.kde4 export LD_LIBRARY_PATH=$/opt/kde4/lib/:$KDEDIR/lib:$LD_LIBRARY_PATH:/opt/kde4/lib Exec=/opt/kde4/bin/startkde TryExec=/opt/kde4/bin/startkde Name=KDE4 Comment=The K Desktop Environment. A powerful Open Source graphical desktop environment Any help will be welcome :) chitlesh -- http://clunixchit.blogspot.com From kzak at redhat.com Mon Nov 27 22:52:43 2006 From: kzak at redhat.com (Karel Zak) Date: Mon, 27 Nov 2006 23:52:43 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <1163488526.15249.230.camel@laptopd505.fenrus.org> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <1163405180.15249.105.camel@laptopd505.fenrus.org> <20061113104852.11ee30d8@yareena.int.addix.net> <1163412461.15249.125.camel@laptopd505.fenrus.org> <20061114032324.GA26706@nostromo.devel.redhat.com> <1163488526.15249.230.camel@laptopd505.fenrus.org> Message-ID: <20061127225243.GM2671@petra.dvoda.cz> On Tue, Nov 14, 2006 at 08:15:26AM +0100, Arjan van de Ven wrote: > On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote: > > Arjan van de Ven (arjan at fenrus.demon.nl) said: > > > I really like this idea; it's a simple "cat" and it can be done at a > > > time where latency doesn't matter... (even in cron.daily) > > > > > > Oh... this opens more options. This also allows the "sort by > > > blocknumber" to be done at this point and taken out of the critical > > > latency part...... > > > > > > great idea! > > > > Of course, that then makes shutdown take twice as long. Definitely no. We don't talk about full readahead. I've implemented the idea and it seems that we can use it during regular shutdown. It's very fast, because almost all files from readahead lists are already in the cache (and don't forget we don't call readahead(2) and read full files. We need open(), stat() and read first block for each file only. This is 10x faster than full readahead which we know from system start up). > if you do it at shutdown, which is again a latency path :) > cron.daily/weekly is less so ;) Well, some numbers: ./readahead --timing --verbose \ --output /etc/readahead.d/early.sorted \ --sort /etc/readahead.d/default.early List: /etc/readahead.d/default.early Time (read lists): 0 ms Create list with 850 files Time (read blocks): 103 ms <--------- Read blocks for 726/850 files (65778 KB) List: /etc/readahead.d/default.later Time (read lists): 2 ms Create list with 3757 files Time (read blocks): 281 ms <---------- Read blocks for 3056/3757 files (110159 KB) The worst numbers which I've ever seen was 2500ms (sum from both lists) and it was on an laptop with a lazy HDD. Also, the idea that we can run it as parallel process is useful. If you want to play with new readahead code, see: http://people.redhat.com/kzak/readahead/readahead-11276006.tar.gz Karel -- Karel Zak From erik at ilsw.com Mon Nov 27 23:11:36 2006 From: erik at ilsw.com (Erik LaBianca) Date: Mon, 27 Nov 2006 18:11:36 -0500 Subject: Static linking considered harmful In-Reply-To: <1164632147.3276.25.camel@laptopd505.fenrus.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> <1164632147.3276.25.camel@laptopd505.fenrus.org> Message-ID: <456B70A8.6010302@ilsw.com> Arjan van de Ven wrote: > because the simple case breaks. > > Now the goal then should maybe be "make packaging self contained apps as > easy as sticking -static on cflags".... > > +1 This is the real issue IMHO. I've been ranting about it for a while, and dug around in the lsb documentation looking for answers, and their answer is to static link! I don't know whose problem it really is, but it seems like it would be some very well spent time to add the ability to rpmbuild to make an lsb-xx compatible package by compiling against the relevant lsb stubs and then including all .so's needed to make the application run under that environment. Unfortunately I'm not adept enough with the guts of rpm's dependancy tracking to have any idea of how reasonable this solution is. At the minimum, it would require including -lsb-xx-devel versions of any runtime libraries that were going to be used, but if the system were able to compile libraries the same way as applications, it shouldn't be hard to generate those at all. Beyond scientific computing, application developers (both open source and commercial) need better ways to distribute their code in a runnable (aka binary) form. Just trying to find an mp3 player that would work on centos4 ended up taking me the better part of 4 hours since there is no livna for rhel4, and nobody packages for it. If developers had an easy way to provide me with an lsb-compatible rpm I could have tried a whole raft of packages and picked one I liked, instead of being stuck with the first one that would compile and run correctly. Just my $0.02 --erik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Mon Nov 27 23:17:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 28 Nov 2006 04:47:46 +0530 Subject: FC6: some impressions In-Reply-To: <5256d0b0611221001y4f1a690aua013e0474e25661a@mail.gmail.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <37941.74.96.19.63.1164161436.squirrel@lattica.com> <20061122114737.GB10961@devserv.devel.redhat.com> <3322.207.245.37.34.1164205986.squirrel@lattica.com> <20061122150551.GA13992@orient.maison.lan> <3528.207.245.37.34.1164209342.squirrel@lattica.com> <5256d0b0611221001y4f1a690aua013e0474e25661a@mail.gmail.com> Message-ID: <456B721A.9000704@fedoraproject.org> Peter Robinson wrote: > > I really wish they would start to merge some of the dbus port that has > been done that seems to include a lot of nice memory improvements and > stability improvements etc. I also thought that redhat was looking to > hire a full time evo hacker to help get on top of some of it (they may > well have). Yes, The current Evolution maintainer in Fedora is working full time on it. Rahul From kzak at redhat.com Tue Nov 28 00:00:03 2006 From: kzak at redhat.com (Karel Zak) Date: Tue, 28 Nov 2006 01:00:03 +0100 Subject: removing termcap In-Reply-To: <3812.207.245.37.34.1164645766.squirrel@lattica.com> References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <3812.207.245.37.34.1164645766.squirrel@lattica.com> Message-ID: <20061128000003.GO2671@petra.dvoda.cz> On Mon, Nov 27, 2006 at 11:42:46AM -0500, Dimi Paun wrote: > > On Mon, November 27, 2006 11:37 am, Bill Nottingham wrote: > >> I'm assuming that terminfo entries are architecture independent binary > >> files. If so /lib/terminfo (on 32bit and 64bit platforms) would work. > >> It would be a bit odd to find part of the terminfo database > >> in /lib/terminfo and some in /usr/share/terminfo, though. > > > > I'd prefer /etc, just to make it more standard (and it would require > > less configuration hackery.) > > I'm not sure it's such a good idea to stick binary databases in /etc. > They are not modifiable by the user anyway, /lib/terminfo seems more > appropriate. +10 -- Karel Zak From pbruna at it-linux.cl Tue Nov 28 01:26:59 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 27 Nov 2006 22:26:59 -0300 (CLST) Subject: dbus-qt In-Reply-To: <200611271047.53766.dennis@ausil.us> Message-ID: <5188460.701164677219767.JavaMail.root@lisa.it-linux.cl> Problem with NetworkManager solved, the package wpa_supplicant-0.4.9-15.fc6.at was the guilty ----- Mensaje Original ----- De: Dennis Gilmore Para: fedora-devel-list at redhat.com Enviados: lunes 27 de noviembre de 2006 13H47 GMT-0400 America/Santiago Asunto: Re: dbus-qt On Monday 27 November 2006 10:19, Patricio A. Bruna wrote: > i have FC6 with kde, but knetworkmanager does not work, im doing nothing > strange, it just not work. It works with wired networks, but not wireless, > i have to setup de wireless card manually. > > Also, im trying to compile kpowersave, so i need dbus-qt > kpowersave you will need to patch in the dbus bindings look at how i did it with knetworkmanager as an example. What wireless card are you using? i have 2 laptops one a Dell Inspiron 4150 with an intel 2200 based wireless card. everything works flawlesly. my second is a apple powerbook and NetworkManager does not work with its broadcom chipset period. in FC-5 NetworkManager would attempt to connect but failed in FC-6 it will not use the card which uses the bcm43xx kernel module. i need to use wpa_supplicant and ifup on it. Please try using nm-applet if it fails in both file a bug against NetworkManager if its only knetworkmanager file a bug against it and i will try and fix it for you. -- ,-._|\ Dennis Gilmore, RHCE / \ Proud Australian \_.--._/ | Aurora | Fedora | v -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at redwire.net Tue Nov 28 02:16:35 2006 From: cleaver at redwire.net (Japheth J.C. Cleaver) Date: Mon, 27 Nov 2006 18:16:35 -0800 Subject: Static linking considered harmful In-Reply-To: <4564EC57.7060707@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <4564BFFD.3010809@redwire.net> <4564EC57.7060707@redhat.com> Message-ID: <456B9C03.3040207@redwire.net> Ulrich Drepper wrote: > Japheth J.C. Cleaver wrote: >> (Our mail server saw a >> performance boost of about 20% when we statically linked our process >> chain.) > > I *very* much doubt those numbers. Using PIC and the runtime linker > does not add that much overhead. Never has, never will. If you compare > apples and oranges you can come up with such numbers, of course. > In the interests of correcting the record... After researching this I've realized I was mistaken. That speed gain involved not _just_ static linking, but the migration to dietlibc for some of the most heavily used portions, as well as replacing bash with a static ash for all our shell forking (lots). Those may have contributed a significant portion of that speed bump. I stand by my original point, however. Some run environments (like our qmail/vpopmail clusters) benefit from changes that this thread (and the ones regarding removing or bastardizing dietlibc on fedora-extras) proposes making more difficult. Let's be perl-like: Make the easy things easy (dynamic linking as normal) and the hard things possible (optional -devel-static packages). Regards, -jc From codeshepherd at gmail.com Tue Nov 28 03:12:37 2006 From: codeshepherd at gmail.com (Deepan) Date: Tue, 28 Nov 2006 11:12:37 +0800 Subject: DriveReady SeekComplete Error In-Reply-To: <20061127155948.GB29021@devserv.devel.redhat.com> References: <1164603656.4344.3.camel@codeworld> <20061127155948.GB29021@devserv.devel.redhat.com> Message-ID: <1164683557.3317.1.camel@codeworld> On Mon, 2006-11-27 at 10:59 -0500, Alan Cox wrote: > On Mon, Nov 27, 2006 at 01:00:56PM +0800, Deepan wrote: > > I get this Input/Output Error while trying to copy files from my cdrom. > > Mounting the cdrom works fine. I can see the files. but when i try to > > copy them i get input/output error. I have the same problem with almost > > all CDs.dmesg reports the following. > > Video CD of some kind, or mixed audio video ? Its a movie DVD. Is it possible to have some kind of lock in the file to prevent it from being copied or played. The movie rental guy says the CD can only be played on a DVD player, not on computer. > > > ATAPI device hdc: > > Error: Illegal request -- (Sense key=0x05) > > Illegal mode for this track or incompatible medium -- (asc=0x64, > > ascq=0x00) > > Thats normally "tried to read an audio or video track as data" > > -- ----------------------------------------------- Regards Deepan Chakravarthy N http://www.codeshepherd.com/ +65-96770940 Software Developer, Nova Global Pte Ltd, Technical & Scientific Computing Solutions, #05-04 Keypoint, 371 Beach Road, Singapore. web: http://www.novaglobal.com.sg/ Have Fun, Play Sudoku :) http://sudoku-solver.net/ From skvidal at linux.duke.edu Tue Nov 28 06:02:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 28 Nov 2006 01:02:16 -0500 Subject: Proposal: Consolidate yum directory usage In-Reply-To: <20061111180040.5c959414@nausicaa.camperquake.de> References: <20061111180040.5c959414@nausicaa.camperquake.de> Message-ID: <1164693736.28663.62.camel@cutter> On Sat, 2006-11-11 at 18:00 +0100, Ralf Ertzinger wrote: > Hi. > > I think the current usage of configuration files and directories > for yum has somewhat gotten out of hand. > > yum-3.0.1-1 uses one config file (yum.conf), and two configuration > directories (yum.repos.d and yum, which in turn just contains pluginconf.d) > under /etc. > > I propose to move all yum configuration files and directories to > /etc/yum (move /etc/yum.conf to /etc/yum/yum.conf, move /etc/yum.repos.d > to /etc/yum/repos.d). This could easily be done by a %post scriptlet > during an RPM transaction. Symlinks ought to be set (yum.conf -> yum/yum.conf > and yum.repos.d -> yum/repos.d) to keep other packages working which > drop files in yum.repos.d. And there are tons of documents which reference > /etc/yum.conf. > > Maybe yum ought to show warnings (after FC7, maybe) when it detects > that /etc/yum.conf or /etc/yum.repos.d still exist (even as symlinks) > and advise the user that usage of these files is deprecated. > > If there is interest in this I'll produce patches for the spec file > (to migrate the config) and for yum (to find files in the new locations > and to show deprecation warnings) I'm game for moving all of this into the better location. My only request is that we make sure it's done backward compat if there is any plans on it making it into 3.0.X. thanks! -sv From kevin.kofler at chello.at Tue Nov 28 06:21:26 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 28 Nov 2006 06:21:26 +0000 (UTC) Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > export KDEDIR=/opt/kde4 > export PATH=/opt/kde4/bin/:$PATH > export KDEHOME=~/.kde4 > export LD_LIBRARY_PATH=$/opt/kde4/lib/:$KDEDIR/lib: $LD_LIBRARY_PATH:/opt/kde4/lib > Exec=/opt/kde4/bin/startkde There are several reasons this isn't going to work that way: * a .desktop is not a shell script, you can't have export statements there * $/opt/kde4/lib/ in your LD_LIBRARY_PATH has a $ too many * startkde isn't designed to be run like that! KDEDIR=/opt/kde4 and KDEHOME=~/.kde4 shouldn't be needed, by the way. Look at my patches: * KDE 4 with the patches looks at KDE4DIR and KDE4HOME, not KDEDIR and KDEHOME, so you're setting the wrong environment variables. You're actually changing the paths for KDE 3, which is a bad idea. * The default paths for KDE4DIR and KDE4HOME are exactly the ones you're setting. There are 2 options to run KDE 4: * Run a KDE 4 desktop from the console. You need to telinit into runlevel 3, then run: LD_LIBRARY_PATH=/opt/kde4/lib /opt/kde4/bin/startkde from the terminal. But you can't do this from a running desktop, so a .desktop file is the wrong place to put that. * Run only individual KDE 4 apps in a KDE 3 or GNOME desktop. My patches are designed to allow exactly that. Try for example: LD_LIBRARY_PATH=/opt/kde4/lib /opt/kde4/bin/konqueror (Note that Konqueror 4 was pretty badly broken when I snapshotted it. I don't know how much of that has been fixed in 3.80.2 or current SVN.) As for why the LD_LIBRARY_PATH is needed in the first place, this is a side effect of disabling the rpath mechanism (-DCMAKE_SKIP_RPATH=TRUE). With the rpath, it finds the libraries. (In fact, this is exactly what the rpath is for. Rpaths are only bad when they refer to a standard path like /usr/lib or /usr/lib64.) I don't know why it didn't build for you without this option because it built just fine for me with the rpaths enabled. Kevin Kofler From drepper at redhat.com Tue Nov 28 07:09:55 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 27 Nov 2006 23:09:55 -0800 Subject: Suggestion: Static libs policy, a draft In-Reply-To: <20061127182234.GB32187@nostromo.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> Message-ID: <456BE0C3.7010308@redhat.com> Bill Nottingham wrote: >> In other words, for all statically linked executables in Core >> (recovering, init/boot time etc.), all the libraries which take place in >> the correspond static linkage must be present. > > Obviously. This is sort of prerequisite for self-hosting. Well, not so fast. There is no reason for booting to require static linking. It might even be that the static linking meanwhile increases the ramdisk size (2.7M for both binaries). In any case, we're not booting from floppy disks anymore so this is not an issue. The static linking should be removed where it is currently used for booting. As for recovery: you're a fool if you trust the binaries on the system which has to be covered. This is what the rescue mode of the boot CD is for. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From aph at redhat.com Tue Nov 28 08:55:02 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Nov 2006 08:55:02 +0000 Subject: Static linking considered harmful In-Reply-To: <456B70A8.6010302@ilsw.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> <1164632147.3276.25.camel@laptopd505.fenrus.org> <456B70A8.6010302@ilsw.com> Message-ID: <17771.63846.748608.276584@zebedee.pink> Erik LaBianca writes: > Beyond scientific computing, application developers (both open > source and commercial) need better ways to distribute their code in > a runnable (aka binary) form. Just trying to find an mp3 player > that would work on centos4 ended up taking me the better part of 4 > hours since there is no livna for rhel4, and nobody packages for > it. If developers had an easy way to provide me with an > lsb-compatible rpm I could have tried a whole raft of packages and > picked one I liked, instead of being stuck with the first one that > would compile and run correctly. Well, hold on: that problem is caused by software patents, not by packaging issues. Let's point the finger in the right direction, eh? Andrew. From alan at redhat.com Tue Nov 28 10:51:23 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Nov 2006 05:51:23 -0500 Subject: DriveReady SeekComplete Error In-Reply-To: <1164683557.3317.1.camel@codeworld> References: <1164603656.4344.3.camel@codeworld> <20061127155948.GB29021@devserv.devel.redhat.com> <1164683557.3317.1.camel@codeworld> Message-ID: <20061128105123.GB25139@devserv.devel.redhat.com> On Tue, Nov 28, 2006 at 11:12:37AM +0800, Deepan wrote: > > Video CD of some kind, or mixed audio video ? > Its a movie DVD. Is it possible to have some kind of lock in the file > to prevent it from being copied or played. The movie rental guy says the > CD can only be played on a DVD player, not on computer. Video and Audio CD need different tools for copying them. You can play both DVD and Video CD on a Linux PC wth suitable software. Alan From seg at haxxed.com Tue Nov 28 11:32:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Nov 2006 05:32:33 -0600 Subject: Static linking considered harmful In-Reply-To: <20061127125100.GC12853@neu.nirvana> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127125100.GC12853@neu.nirvana> Message-ID: <1164713553.5452.43.camel@max.booze> On Mon, 2006-11-27 at 13:51 +0100, Axel Thimm wrote: > You're oversimplifying and tend to become insultive of this user group > w/o neccessity. Actually I was trying to insinuate *you* are the one insulting the intelligence of these fine hard working people of science. -------------- 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 jamatos at fc.up.pt Tue Nov 28 11:49:17 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 28 Nov 2006 11:49:17 +0000 Subject: Static linking considered harmful In-Reply-To: <1164713553.5452.43.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061127125100.GC12853@neu.nirvana> <1164713553.5452.43.camel@max.booze> Message-ID: <200611281149.17606.jamatos@fc.up.pt> On Tuesday 28 November 2006 11:32 am, Callum Lerwick wrote: > On Mon, 2006-11-27 at 13:51 +0100, Axel Thimm wrote: > > You're oversimplifying and tend to become insultive of this user group > > w/o neccessity. > > Actually I was trying to insinuate *you* are the one insulting the > intelligence of these fine hard working people of science. Science is not different from other human endeavours in this respect, there are very smart people and very dumb people (no matter how many titles they put behind their names). :-) -- Jos? Ab?lio From rdieter at math.unl.edu Tue Nov 28 13:07:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 07:07:34 -0600 Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Well, I just started packaging kde4 based on kevinkoefler's work. Some > friends are porting kde3 apps to kde4, so why not give them the > minimum tools needed ? > > kevinkoefler SRPMS are > http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdelibs4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm > http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdepimlibs4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm > http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdebase4-3.80.2-0.1.20061003svn.fc5.kde.src.rpm Now that we have srpms, I'll see about whipping up some binary rpms and putting them in the kde-redhat repo somewhere. -- Rex From Axel.Thimm at ATrpms.net Tue Nov 28 14:06:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 28 Nov 2006 15:06:43 +0100 Subject: Static linking considered harmful In-Reply-To: <1164713553.5452.43.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127125100.GC12853@neu.nirvana> <1164713553.5452.43.camel@max.booze> Message-ID: <20061128140643.GB9632@neu.nirvana> On Tue, Nov 28, 2006 at 05:32:33AM -0600, Callum Lerwick wrote: > On Mon, 2006-11-27 at 13:51 +0100, Axel Thimm wrote: > > You're oversimplifying and tend to become insultive of this user group > > w/o neccessity. > > Actually I was trying to insinuate *you* are the one insulting the > intelligence of these fine hard working people of science. Rest assured I wouldn't insult a group I'm proud to be part of. And as written in the parts you trimmed, this group is better off working on science than on trying to avoid static linking by doing runtime package accounting, writing wrappers and so forth. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n0dalus+redhat at gmail.com Tue Nov 28 14:45:33 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 29 Nov 2006 01:15:33 +1030 Subject: Static linking considered harmful In-Reply-To: <1164628135.5452.33.camel@max.booze> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> Message-ID: <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> On 11/27/06, Callum Lerwick wrote: > > Your only argument seems to be that these skillful programmers, that > presumably have advanced math degrees if they're programming scientific > number crunching apps, and can figure out how to statically compile > their app, are too retarded to write a trivial one line wrapper script, > run ldd on their app, and tar up their app with the libs it needs. > Going through the main points on http://people.redhat.com/drepper/no_static_linking.html I don't see a lot of justification for the complete removal of static linking support in Fedora. So far the only proposed alternative to static linking is this approach of sticking the .so files in with the program and using LD_LIBRARY_PATH in a script -- which is almost just as bad as static linking. Here are the main points that Ulrich has made: * Security holes and bugs can't be fixed by just updating the library on the system This is just as much an issue when using the .so file bundle method. * No load address randomization Not an issue with the .so file bundle method. * Less efficient use of memory Same issue with the .so file bundle method. * Some libraries require dynamic linking which might try to load incompatible external code Same issue with the .so file bundle method. * Possible accidental violation of the LGPL Not an issue with shared object bundling, though I suppose for most software that Fedora users build it's not an issue either * ltrace and other tricks doesn't work Not an issue with shared object bundling. So the only advantages shared object bundling has over static linking are: - Load address randomization - ltrace and other small things don't work, and there is a (probably rare) chance of violating the LGPL. I just don't see why static linking support should be removed because of these things. While exploits involving fixed addresses do happen, it's really nothing compared to the risk involved in bundling possibly broken and insecure libraries along with the application (whether by static linking or other methods). In my opinion the strongest argument against static linking is risk of security bugs and incorrect hard-coding of system-specific actions, which is just as much an argument against bundling shared objects with a program. I'm not defending static linking, but I just think that a better alternative needs to be found for making portable binaries before we remove support for it -- there's no point in causing migration headaches for even a small number of developers/users unless we actually have something reasonably better to offer. n0dalus. From pertusus at free.fr Tue Nov 28 15:12:01 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 28 Nov 2006 16:12:01 +0100 Subject: Static linking considered harmful In-Reply-To: <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> Message-ID: <20061128151201.GB3447@free.fr> On Wed, Nov 29, 2006 at 01:15:33AM +1030, n0dalus wrote: > On 11/27/06, Callum Lerwick wrote: > > * Possible accidental violation of the LGPL > > Not an issue with shared object bundling, though I suppose for most > software that Fedora users build it's not an issue either Not sure that bundling the .so is better in this regard. I am not sure that it is legal to bundle LGPL covered .so and a proprietary app in the same tarball. It is possible to do 2 tarballs, one with apps with LGPL source compatible license, the other with non LGPL compatible license, and the user just has to unpack them in the same directory. It could also be that bundling LGPL source compatible and LGPL source incompatible apps is permitted, I haven't checked precisely. -- Pat From chitlesh at fedoraproject.org Tue Nov 28 15:34:35 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Nov 2006 16:34:35 +0100 Subject: KDE4 being packaged In-Reply-To: References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> Message-ID: <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> On 11/28/06, Kevin Kofler wrote: > There are several reasons this isn't going to work that way: > * a .desktop is not a shell script, you can't have export statements there > * $/opt/kde4/lib/ in your LD_LIBRARY_PATH has a $ too many > * startkde isn't designed to be run like that! Ah ha, ok, ill make the changes tonight. > KDEDIR=/opt/kde4 and KDEHOME=~/.kde4 shouldn't be needed, by the way. Look at > my patches: > * KDE 4 with the patches looks at KDE4DIR and KDE4HOME, not KDEDIR and KDEHOME, > so you're setting the wrong environment variables. You're actually changing the > paths for KDE 3, which is a bad idea. > * The default paths for KDE4DIR and KDE4HOME are exactly the ones you're > setting. Ok, ill remove them > There are 2 options to run KDE 4: > * Run a KDE 4 desktop from the console. You need to telinit into runlevel 3, > then run: > LD_LIBRARY_PATH=/opt/kde4/lib /opt/kde4/bin/startkde > from the terminal. But you can't do this from a running desktop, so a .desktop > file is the wrong place to put that. > * Run only individual KDE 4 apps in a KDE 3 or GNOME desktop. My patches are > designed to allow exactly that. Try for example: > LD_LIBRARY_PATH=/opt/kde4/lib /opt/kde4/bin/konqueror > (Note that Konqueror 4 was pretty badly broken when I snapshotted it. I don't > know how much of that has been fixed in 3.80.2 or current SVN.) So what's the best solution to make it work out of the box when we installed kdebase4 ? > As for why the LD_LIBRARY_PATH is needed in the first place, this is a side > effect of disabling the rpath mechanism (-DCMAKE_SKIP_RPATH=TRUE). With the > rpath, it finds the libraries. (In fact, this is exactly what the rpath is for. > Rpaths are only bad when they refer to a standard path like /usr/lib > or /usr/lib64.) I don't know why it didn't build for you without this option > because it built just fine for me with the rpaths enabled. But in my case, rpmbuild for kdebase4 fails without -DCMAKE_SKIP_RPATH=TRUE. chitlesh -- http://clunixchit.blogspot.com From jakub at redhat.com Tue Nov 28 15:44:29 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 28 Nov 2006 10:44:29 -0500 Subject: Static linking considered harmful In-Reply-To: <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> Message-ID: <20061128154429.GF6570@devserv.devel.redhat.com> On Wed, Nov 29, 2006 at 01:15:33AM +1030, n0dalus wrote: > Going through the main points on > http://people.redhat.com/drepper/no_static_linking.html I don't see a > lot of justification for the complete removal of static linking > support in Fedora. So far the only proposed alternative to static > linking is this approach of sticking the .so files in with the program > and using LD_LIBRARY_PATH in a script -- which is almost just as bad > as static linking. You misunderstood part of this thread. The bundling of shared libraries with the app was a suggested alternative for those requiring bit-wise identical results from numerical apps, it is definitely not meant as a general way how ISVs should ship their programs. Those requiring bit-wise identical result intentionally don't care about security (they even depend on bug-to-bug compatibility), they probably even can't live with randomization (but that can be turned off with setarch), etc. For programs which don't have such requirements (the vast majority), an analysis of the libraries the (dynamically linked) program links against (or dlopens) is needed. There are libraries which keep ABI stable and maintain backwards compatibility (either through symbol versioning or by strictly only adding new symbols, never changing the semantics of old entry points or removing symbols), there are libraries that do that mostly, but from time to time bump SONAME, there are libraries which change their ABI (and bump SONAME) often. For the first category (e.g. glibc, libX11), the rule of thumb is link dynamically, don't include the libraries with your program, compile and link against the oldest version you still want to support. Say by compiling/linking against glibc 2.2.0, you should cover RHL7.0 and higher (and other Fall 2000 and later released distros). I think we can re-add compat-glibc, perhaps containing several sets of headers and dummy link-only libs, to FE, then you just use some compat-gcc* together with this compat-glibc* and can build even on contemporary distros programs that run on older as well as contemporary distros. For the second category (e.g. libstdc++ especially if you want to support even really prehistoric distros), you sometimes want to optionally bundle a shared library with your program, but e.g. at install time of the program check whether the system doesn't provide that library (same SONAME and either as old or newer than what you are bundling) and in that case use the system library rather than your own - the OS vendor will then take care of security fixes in it, bugfixes too, etc. Though I guess most of the distro vendors these days have libstdc++ 3.2/3.3 and 3.4/4.0/4.1 libs around, similarly with other libs (crypto, etc.). Then there are shared libraries which have ABI of the day, in that case either bundle your own shared library always or link .a library statically (-Wl,-Bstatic -lbfd -Wl,-Bdynamic), example here is e.g. libbfd. Jakub From rdieter at math.unl.edu Tue Nov 28 15:54:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 09:54:27 -0600 Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 11/28/06, Kevin Kofler wrote: >> As for why the LD_LIBRARY_PATH is needed in the first place, this is a >> side effect of disabling the rpath mechanism (-DCMAKE_SKIP_RPATH=TRUE). >> With the rpath, it finds the libraries. (In fact, this is exactly what >> the rpath is for. Rpaths are only bad when they refer to a standard path >> like /usr/lib or /usr/lib64.) I don't know why it didn't build for you >> without this option because it built just fine for me with the rpaths >> enabled. > > But in my case, rpmbuild for kdebase4 fails without > -DCMAKE_SKIP_RPATH=TRUE. Details please. -- Rex From chitlesh at fedoraproject.org Tue Nov 28 16:01:21 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Nov 2006 17:01:21 +0100 Subject: KDE4 being packaged In-Reply-To: References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> Message-ID: <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> On 11/28/06, Rex Dieter < hidden > wrote: > > But in my case, rpmbuild for kdebase4 fails without > > -DCMAKE_SKIP_RPATH=TRUE. > > Details please. I'll try to reproduce it which might take a few hours. However it spits the same rpath error message as rpmbuilding any other kde apps with rpath issue. chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Tue Nov 28 16:05:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 10:05:59 -0600 Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 11/28/06, Rex Dieter < hidden > wrote: >> > But in my case, rpmbuild for kdebase4 fails without >> > -DCMAKE_SKIP_RPATH=TRUE. >> >> Details please. > > I'll try to reproduce it which might take a few hours. However it > spits the same rpath error message as rpmbuilding any other kde apps > with rpath issue. Ah, that's likely the mock build's check to reject anything that uses rpath. Duh. Obviously, we *want* rpath's here, so that check will need to be disabled. -- Rex From chitlesh at fedoraproject.org Tue Nov 28 16:19:42 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Nov 2006 17:19:42 +0100 Subject: KDE4 being packaged In-Reply-To: References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> Message-ID: <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> On 11/28/06, Rex Dieter wrote: > Ah, that's likely the mock build's check to reject anything that uses rpath. > Duh. hmm, i haven't used mock yet. > Obviously, we *want* rpath's here, so that check will need to be > disabled. since, my rpmbuild is failing due to rpath, what should I do to skip it ? chitlesh -- http://clunixchit.blogspot.com From orion at cora.nwra.com Tue Nov 28 16:54:18 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Nov 2006 09:54:18 -0700 Subject: unowned directory problem with /etc/logrotate.d In-Reply-To: References: <4566C658.8060307@hhs.nl> Message-ID: Thomas M Steenholdt wrote: > > So since we're already discussing this, what if all packages that put > stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or > something)... The -logrotate sub packages should require logrotate and > of-course the main package (httpd in this case). Users can remove > logrotate and with it, all the -logrotate subpackages from cups, httpd > and the rest, but the software will still install and run just fine. > This method has the added benefit of giving us a cleaner way to provide > log-management for everything, based on an entirely different > log-management tool. Put in extras and provide a > http- package and all is good. Interesting idea, but the problem is that you would want the -logrotate packages installed by default to prevent the normal use case from filling /var, and I'm not sure this is possible at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Tue Nov 28 17:01:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 11:01:13 -0600 Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 11/28/06, Rex Dieter wrote: >> Ah, that's likely the mock build's check to reject anything that uses >> rpath. Duh. > > hmm, i haven't used mock yet. Hmmm... >> Obviously, we *want* rpath's here, so that check will need to be >> disabled. > > since, my rpmbuild is failing due to rpath, what should I do to skip it ? dunno, will need to see the exact failure, if you could post the tail end of the failed build log... -- Rex From notting at redhat.com Tue Nov 28 17:28:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Nov 2006 12:28:15 -0500 Subject: Suggestion: Static libs policy, a draft In-Reply-To: <456BE0C3.7010308@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> <456BE0C3.7010308@redhat.com> Message-ID: <20061128172815.GG4246@nostromo.devel.redhat.com> Ulrich Drepper (drepper at redhat.com) said: > As for recovery: you're a fool if you trust the binaries on the system > which has to be covered. This is what the rescue mode of the boot CD is > for. Depends what you're recovering from. If it's the "I'm an idiot and removed the /lib/libc.so.6 link" problem, having sln is quicker and just as safe as rescue mode. Not that I've ever done that, of course... Bill From galibert at pobox.com Tue Nov 28 17:30:47 2006 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 28 Nov 2006 18:30:47 +0100 Subject: Static linking considered harmful In-Reply-To: <20061128154429.GF6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128154429.GF6570@devserv.devel.redhat.com> Message-ID: <20061128173047.GA57100@dspnet.fr.eu.org> On Tue, Nov 28, 2006 at 10:44:29AM -0500, Jakub Jelinek wrote: > For programs which don't have such requirements (the vast majority), > an analysis of the libraries the (dynamically linked) program links against > (or dlopens) is needed. There are libraries which keep ABI stable and > maintain backwards compatibility (either through symbol versioning or > by strictly only adding new symbols, never changing the semantics of > old entry points or removing symbols), there are libraries that do that > mostly, but from time to time bump SONAME, there are libraries which > change their ABI (and bump SONAME) often. > > For the first category (e.g. glibc, libX11), the rule of thumb is > link dynamically, don't include the libraries with your program, > compile and link against the oldest version you still want to support. Ah but you see, glibc does not maintain backwards compatilibity. ./nscube: relocation error: ./nscube: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Thankfully, that ISV also provided a statically linked version. OG. From erik at ilsw.com Tue Nov 28 17:32:39 2006 From: erik at ilsw.com (Erik LaBianca) Date: Tue, 28 Nov 2006 12:32:39 -0500 Subject: Static linking considered harmful In-Reply-To: <17771.63846.748608.276584@zebedee.pink> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <20061127122646.GC2975@free.fr> <1164632147.3276.25.camel@laptopd505.fenrus.org> <456B70A8.6010302@ilsw.com> <17771.63846.748608.276584@zebedee.pink> Message-ID: <456C72B7.30108@ilsw.com> Andrew Haley wrote: > > Well, hold on: that problem is caused by software patents, not by > packaging issues. Let's point the finger in the right direction, eh? > > Andrew. Choose to nit-pick my choice of package if you like, but the problem extends far beyond mp3 players. There are dozens of fine software packages that are not patent encumbered and aren't being compiled for fedora, rhel, or name your other favorite distribution because it isn't the developers pet distribution. I have dozens of half-baked specfiles for just such packages sitting around in my home directory that I eventually gave up on because the dependency tree was just too big. Just think of the large pain in the rear you'll have to go through to get an up-to-date browser, email client, media player (sans mp3 if you wish) on any older (rhel3?) linux distribution. Requiring every project to effectively fork in some way or another in order to get into every distributions 'extras' repository isn't a tenable long-term solution. Compare that to evil-windows... Download latest firefox build, click install, it works, on darn near any windows variant out there. Most installer creators for windows will figure out which dll's you're using that aren't 'standard' and will side-by-side install them with your application and off you go. Linux applications and distributions need to be able to support the same level of application-os decoupling in order to tackle the desktop, and fedora is in a great place to lead the way. Like Arjen said, this stuff is the reason people statically link, and they do it because they don't have tools that make doing it the 'right' way easy for them. --erik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From jakub at redhat.com Tue Nov 28 17:44:53 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 28 Nov 2006 12:44:53 -0500 Subject: Static linking considered harmful In-Reply-To: <20061128173047.GA57100@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128154429.GF6570@devserv.devel.redhat.com> <20061128173047.GA57100@dspnet.fr.eu.org> Message-ID: <20061128174453.GH6570@devserv.devel.redhat.com> On Tue, Nov 28, 2006 at 06:30:47PM +0100, Olivier Galibert wrote: > > For the first category (e.g. glibc, libX11), the rule of thumb is > > link dynamically, don't include the libraries with your program, > > compile and link against the oldest version you still want to support. > > Ah but you see, glibc does not maintain backwards compatilibity. > > ./nscube: relocation error: ./nscube: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference This is a bug in the application for which we just provided workarounds for several years, of course the ISV must compile a correct valid program, not everything that happens to link is valid. If you'd require that any buggy program keeps working, we'd need to guarantee bug to bug compatibility, that's not something any library guarantees. POSIX says that errno may be a macro (and since glibc 2.1.0 it is a macro) and that must be included when it is used, so programs that don't bother with it are out of luck. Jakub From galibert at pobox.com Tue Nov 28 18:08:42 2006 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 28 Nov 2006 19:08:42 +0100 Subject: Static linking considered harmful In-Reply-To: <20061128174453.GH6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128154429.GF6570@devserv.devel.redhat.com> <20061128173047.GA57100@dspnet.fr.eu.org> <20061128174453.GH6570@devserv.devel.redhat.com> Message-ID: <20061128180842.GB57100@dspnet.fr.eu.org> On Tue, Nov 28, 2006 at 12:44:53PM -0500, Jakub Jelinek wrote: > On Tue, Nov 28, 2006 at 06:30:47PM +0100, Olivier Galibert wrote: > > > For the first category (e.g. glibc, libX11), the rule of thumb is > > > link dynamically, don't include the libraries with your program, > > > compile and link against the oldest version you still want to support. > > > > Ah but you see, glibc does not maintain backwards compatilibity. > > > > ./nscube: relocation error: ./nscube: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference > > This is a bug in the application for which we just provided workarounds > for several years, of course the ISV must compile a correct valid program, > not everything that happens to link is valid. If you'd require that > any buggy program keeps working, we'd need to guarantee bug to bug > compatibility, that's not something any library guarantees. > POSIX says that errno may be a macro (and since glibc 2.1.0 it is a macro) > and that must be included when it is used, so programs that > don't bother with it are out of luck. Ok, so glibc maintains backwards compatibility only for bug-free programs. Show of hands, who has a bug-free program around? OG. From notting at redhat.com Tue Nov 28 18:12:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Nov 2006 13:12:35 -0500 Subject: Static linking considered harmful In-Reply-To: <20061128180842.GB57100@dspnet.fr.eu.org> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128154429.GF6570@devserv.devel.redhat.com> <20061128173047.GA57100@dspnet.fr.eu.org> <20061128174453.GH6570@devserv.devel.redhat.com> <20061128180842.GB57100@dspnet.fr.eu.org> Message-ID: <20061128181235.GI4246@nostromo.devel.redhat.com> Olivier Galibert (galibert at pobox.com) said: > Ok, so glibc maintains backwards compatibility only for bug-free > programs. Show of hands, who has a bug-free program around? Of course we maintain it for programs that actually use the API the way they're intended. Here's an example - we had a bug filed once (this was years ago) about how someone's app was segfaulting when they tried to execute a helper program. Why? Because they weren't null-terminating the arguments to execl()! They pressed, and pressed - "this worked in RHL 4.2 - you need to support this!". But, realistically, if your code only worked by accident, you can't expect it to be supported eternally. Bill From cleaver at redwire.net Tue Nov 28 18:21:22 2006 From: cleaver at redwire.net (Japheth J.C. Cleaver) Date: Tue, 28 Nov 2006 10:21:22 -0800 Subject: static RPM utils (was Re: Suggestion: Static libs policy, a draft) In-Reply-To: <20061128172815.GG4246@nostromo.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> <456BE0C3.7010308@redhat.com> <20061128172815.GG4246@nostromo.devel.redhat.com> Message-ID: <456C7E22.7060501@redwire.net> Bill Nottingham wrote: > Ulrich Drepper (drepper at redhat.com) said: >> As for recovery: you're a fool if you trust the binaries on the system >> which has to be covered. This is what the rescue mode of the boot CD is >> for. > > Depends what you're recovering from. If it's the "I'm an idiot and removed > the /lib/libc.so.6 link" problem, having sln is quicker and just as safe > as rescue mode. Not that I've ever done that, of course... > > Bill > Side question: Is rpm compiled statically? *checks* ... nope. If anything is going to remain statically compiled on the system, I'd say package management tools would be good candidates too, for this very reason. -jc From michel.salim at gmail.com Tue Nov 28 19:14:50 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 28 Nov 2006 14:14:50 -0500 Subject: FC6: some impressions In-Reply-To: <20061121230603.GA13830@devserv.devel.redhat.com> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> Message-ID: <883cfe6d0611281114n608dee83yeb768dd5b6b6e5df@mail.gmail.com> 2006/11/21, Alan Cox : > and evolution sends email (its about all that particular pile > of garbage does but thats a large upstream problem not an RH packaging one). > You might want want to investigate a better email client - eg sylpheed-claws. > Speaking of better mail clients, is there any out there that uses libebook? I don't like evolution-the-mailer but I quite like evolution-data-server, or at least the idea of having a unified address book. Otherwise I'm tempted to actually run fedora-directory-server (*gasp*) as a glorified address book.. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From chitlesh at fedoraproject.org Tue Nov 28 20:47:41 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Nov 2006 21:47:41 +0100 Subject: KDE4 being packaged In-Reply-To: References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> Message-ID: <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> On 11/28/06, Rex Dieter < hidden > wrote: > dunno, will need to see the exact failure, if you could post the tail end of > the failed build log... Here you go, the build log for kdebase4 which failed with rpath=true: http://tux.u-strasbg.fr/~chit/kdebase4_build.log chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Tue Nov 28 21:06:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 15:06:12 -0600 Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 11/28/06, Rex Dieter < hidden > wrote: >> dunno, will need to see the exact failure, if you could post the tail end >> of the failed build log... > > Here you go, the build log for kdebase4 which failed with rpath=true: > http://tux.u-strasbg.fr/~chit/kdebase4_build.log It was as I suspected: ... + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild' * to fail. To ignore these errors, you can set the '$QA_RPATHS' * environment variable which is a bitmask allowing the values * below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk ... but that's not specific to mock, it's part of rpmdevtools(?). Anyway, quick-n-dirty fix is to set QA_RPATHS=0x0003; export QA_RPATHS and try again. -- Rex From sandmann at redhat.com Tue Nov 28 21:54:19 2006 From: sandmann at redhat.com (Soeren Sandmann) Date: Tue, 28 Nov 2006 16:54:19 -0500 Subject: Desktop-effects In-Reply-To: <1164651718.3398.1.camel@halflap.boston.devel.redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> <20061127165700.GJ29814@nostromo.devel.redhat.com> <1164651718.3398.1.camel@halflap.boston.devel.redhat.com> Message-ID: <456CB00B.20500@redhat.com> Ray Strode wrote: >> But desktop-effects has more strings than just the desktop file. >> > > Ah right...We should just upstream it at elvis, I guess. > Desktop Effects is already checked into elvis. Soren From fche at redhat.com Wed Nov 29 02:38:39 2006 From: fche at redhat.com (Frank Ch. Eigler) Date: 28 Nov 2006 21:38:39 -0500 Subject: Static linking considered harmful In-Reply-To: <20061128174453.GH6570@devserv.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128154429.GF6570@devserv.devel.redhat.com> <20061128173047.GA57100@dspnet.fr.eu.org> <20061128174453.GH6570@devserv.devel.redhat.com> Message-ID: Jakub Jelinek writes: > [...] This is a bug in the application for which we just provided > workarounds for several years, of course the ISV must compile a > correct valid program, not everything that happens to link is valid. > If you'd require that any buggy program keeps working, we'd need to > guarantee bug to bug compatibility, that's not something any library > guarantees. [...] Well, there are operating systems that pride themselves on that kind of compatibility, and achieving it takes great effort. In the absence of that kind of commitment/desire in linux, exuberant promises of backward compatibility must be tempered by the reality of buggy applications. - FChE From seg at haxxed.com Wed Nov 29 02:48:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Nov 2006 20:48:33 -0600 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <45587B01.1080501@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <200611111304.14744.jkeating@redhat.com> <1163269570.7856.32.camel@rousalka.dyndns.org> <200611111334.52442.jkeating@redhat.com> <45587B01.1080501@redhat.com> Message-ID: <1164768513.5452.52.camel@max.booze> On Mon, 2006-11-13 at 09:02 -0500, Adam Jackson wrote: > (Jesse, I suspect the model you're thinking of it "oh crap, the tree has > broken deps, we can't publish _anything_". Which is wrong. You publish > the bits that are at least guaranteed by RPM requirements to install. I > mean, you want that for the updates stream for formal releases anyway, > where 'yum update' should _never_ fail, and I suspect right now the > releng team is doing that verification by hand. Trust the computer. > Let it do the boring work.) +1 A while back I recommended Extras should use this exact process. The one problem being that if we only did it in extras, updates of core could still break deps in Extras. (Like when a Mozilla/Firefox update breaks Galeon...) Now that we're merging the two, that's no longer 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 seg at haxxed.com Wed Nov 29 02:56:32 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 28 Nov 2006 20:56:32 -0600 Subject: Testing Fedora - small (?) suggestion. In-Reply-To: <200611121006.17014.jkeating@redhat.com> References: <1163170542.26941.60.camel@gilboa-home-dev.localhost> <1163323357.6043.1.camel@rousalka.dyndns.org> <20061112131854.5255bd88.fedora@wir-sind-cool.org> <200611121006.17014.jkeating@redhat.com> Message-ID: <1164768992.5452.58.camel@max.booze> On Sun, 2006-11-12 at 10:06 -0500, Jesse Keating wrote: > On Sunday 12 November 2006 07:18, Michael Schwendt wrote: > > This is the typical discuss-things-endlessly-before-even-trying type of > > conversation. Meanwhile, the "Package EVR problems in FC+FE" report [1] > > gets longer (even ".FC6" dist tags pop up in there - what the heck?!), and > > Extras packagers don't rebuild their devel packages either. Even if they > > managed to do so with a time-consuming mock build, they could not update > > their rawhide machines (or upgrade FC6 to rawhide) without trying to hack a > > long list of excludes. > > And extras people can't rebuild against packages that don't get published. Built packages would still be immediately available in the build system. They just wouldn't be pushed to the public repos until the deps are clean. In Extras terms, they'd be held in the needsign state. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Wed Nov 29 03:45:29 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 28 Nov 2006 22:45:29 -0500 Subject: rawhide report: 20061128 changes Message-ID: <200611290345.kAT3jTHs000417@hs20-bc2-6.build.redhat.com> New package arpwatch Network monitoring tools for tracking IP addresses on a network New package hunspell Hunspell is a spell checker and morphological analyzer library New package libpcap A system-independent interface for user-level packet capture Updated Packages: OpenIPMI-2.0.6-6.fc7 -------------------- * Tue Nov 28 2006 Phil Knirsch - 2.0.6-6.fc7 - Update due to new net-snmp-5.4 - Some specfile updates anaconda-11.2.0.2-1 ------------------- * Mon Nov 27 2006 Chris Lumens - 11.2.0.2 - Set the home directory correctly for ks user command (#216681). - Pull in xinf files from X driver packages on url images. audit-1.3-1.fc7 --------------- * Tue Nov 28 2006 Steve Grubb 1.3-1 - ausearch & aureport implement uid/gid caching - In ausearch & aureport, extract addr when hostname is unknown - In ausearch & aureport, test audit log presence O_RDONLY - New ausearch/aureport time keywords: recent, this-week, this-month, this-year - Added --add & --delete option to aureport - Update res parsing in config change events - Increase the size on audit daemon buffers - Parse avc_path records in ausearch/aureport - ausearch has new output mode, raw, for extracting events - ausearch/aureport can now read stdin - Rework AVC processing in ausearch/aureport - Added long options to ausearch and aureport beagle-0.2.13-2.fc7 ------------------- * Tue Nov 28 2006 Alexander Larsson - 0.2.13-2.fc7 - Fix xconnection patch to be threadsafe (#212370) checkpolicy-1.33.1-2.fc7 ------------------------ * Tue Nov 14 2006 Dan Walsh - 1.33.1-2 - Rebuild for new libraries cups-1:1.2.7-5.fc7 ------------------ * Mon Nov 27 2006 Tim Waugh 1:1.2.7-5 - Better LSPP fix for bug #216855. * Thu Nov 23 2006 Tim Waugh - Use translated string for password prompt (STR #2121). device-mapper-1.02.13-1.fc7 --------------------------- * Tue Nov 28 2006 Alasdair Kergon - 1.02.13-1 - Update dmsetup man page (setgeometry & message). - Suppress encryption key in 'dmsetup table' output unless --showkeys supplied. * Sat Oct 14 2006 Alasdair Kergon - 1.02.12-3 - Drop the release suffix. * Sat Oct 14 2006 Alasdair Kergon - 1.02.12-2.0 - Append distribution to release. dhcpv6-0.10-35.fc7 ------------------ * Mon Nov 27 2006 David Cantrell - 0.10-35 - server6_addr.conf is not required for dhcp6s - Resolves: rhbz#217309 - Man page for dhcp6s.conf should reference server-preference - Resolves: rhbz#217308 evolution-2.9.2-3.fc7 --------------------- * Tue Nov 28 2006 Matthew Barnes - 2.9.2-3.fc7 - Add patch to port evolution conduits to pilot-link 0.12. - Add patch for RH bug #215466 (optional meeting participants). - Add patch for GNOME bug #373837 (use GtkFontButton). - Remove patch for GNOME bug #343331 (fixed upstream). freetype-2.2.1-14.fc6 --------------------- * Fri Nov 24 2006 Behdad Esfahbod 2.2.1-14 - Copy non-X demos even if not compiling with_xfree86. * Fri Nov 24 2006 Behdad Esfahbod 2.2.1-13 - Step up to retag. Forgot to add patch to CVS first time :(. * Fri Nov 24 2006 Behdad Esfahbod 2.2.1-12 - Add freetype-2.2.1-zero-item-size.patch, to fix crasher. - Resolves #214048 glibc-2.5.90-8 -------------- * Tue Nov 28 2006 Jakub Jelinek 2.5.90-8 - fix svc_run (#216834, BZ#3559) - add -fasynchronous-unwind-tables to CFLAGS (#216518) - make sure there is consistent timestamp for /etc/ld.so.conf, /etc/localtime and /etc/rpc between multilib glibc rpms gnome-icon-theme-2.17.2.1-2.fc7 ------------------------------- * Tue Nov 28 2006 Matthias Clasen - 2.17.2.1-2 - Fix duplicate emblems in nautilus (#217090) gnome-pilot-2.0.15-2.fc7 ------------------------ * Mon Nov 27 2006 Matthew Barnes - 2.0.15-2.fc7 - Rebuild against pilot-link-0.12. gnome-pilot-conduits-2.0.15-2.fc7 --------------------------------- * Mon Nov 27 2006 Matthew Barnes - 2.0.15-2.fc7 - Rebuild against pilot-link 0.12. gnome-power-manager-2.17.2.1-2.fc7 ---------------------------------- * Mon Nov 27 2006 Ray Strode - 2.17.2.1-2.fc7 - fix screensaver from going blank even when configured to show a screensaver (bug 216045) gnome-python2-2.16.2-3.fc7 -------------------------- * Mon Nov 27 2006 Matthew Barnes - 2.16.2-3.fc7 - More packaging tweaks based on suggestions by Patrice Dumas. - No longer need BuildRequires for autoconf, automake, libtool. hplip-1.6.10-6.fc7 ------------------ * Thu Nov 23 2006 Tim Waugh 1.6.10-6 - Report out-of-paper and offline conditions in CUPS backend (bug #216477). initscripts-8.48-1 ------------------ * Tue Nov 28 2006 Bill Nottingham 8.48-1 - add a step to rename any temporarily renamed devices (#208740, #214817) - make sure network modules don't get accidentally reloaded (#211474) - rc.sysinit: fix dmraid test (#216334) - init.d/halt: don't unmount network filesystems - ipsec: Add a way to manually manage racoon.conf (#159343, ) - sysconfig.txt: Document ~/.i18n (#199323, ) - some translation updates jpilot-0.99.9-2.fc7 ------------------- * Tue Nov 28 2006 Ivana Varekova - 0.99.9-2 - add buildprereq (openssl-devel) (#214042) * Tue Nov 28 2006 Ivana Varekova - 0.99.9-1 - update to 0.99.9 libselinux-1.33.2-1 ------------------- * Tue Nov 14 2006 Dan Walsh - 1.33.2-1 - Upgrade to upstream * Fri Nov 03 2006 Dan Walsh - 1.33.1-2 - Add James Antill patch for login verification of MLS Levels - MLS ragnes need to be checked, Eg. login/cron. This patch adds infrastructure. libsemanage-1.9.1-1 ------------------- * Tue Nov 28 2006 Dan Walsh - 1.9.1-1 - Upgrade to latest from NSA * Merged patch to compile wit -fPIC instead of -fpic from Manoj Srivastava to prevent hitting the global offest table limit. Patch changed to include libselinux and libsemanage in addition to libsepol. * Tue Oct 17 2006 Dan Walsh - 1.8-1 - Upgrade to latest from NSA * Updated version for release. libsepol-1.15.3-1 ----------------- * Tue Nov 28 2006 Dan Walsh 1.15.3-1 - Upgrade to latest from NSA * Merged patch to compile wit -fPIC instead of -fpic from Manoj Srivastava to prevent hitting the global offest table limit. Patch changed to include libselinux and libsemanage in addition to libselinux. logwatch-7.3.1-6.fc7 -------------------- * Tue Nov 28 2006 Ivana Varekova 7.3.1-6 - add automount and mountd service patch m17n-db-1.3.3-41.fc7 -------------------- * Tue Nov 28 2006 Mayank Jain - Reverted back to upstream's tarball for m17n-db - Added si-wijesekera-with-preedit as a patch to m17n-db tarball - Updated license header in hi-remington, as-inscript, or-inscript, ta-typewriter - Resolved - 217318, 217319 * Mon Nov 27 2006 Mayank Jain - Added halant to (t) in bn-itrans.mim in m17n-indic tarball, resolves bug 217139 - Edited our own bn-itrans-t-182227.patch to resolve bug 217139 ncurses-5.5-25.20060715.fc7 --------------------------- * Mon Nov 27 2006 Miroslav Lichvar 5.5-25.20060715 - move libncurses and some terminfo entries out of /usr - drop console symlink and sparc terminfo entries net-snmp-1:5.4-1.fc7 -------------------- * Mon Nov 27 2006 Radek Vokal - 5.4-1 - upgrade to 5.4 - patch cleanup - snmpd uses /var/run/snmpd.pid (#211264) nfs-utils-1:1.0.10-4.fc7 ------------------------ * Tue Nov 28 2006 Steve Dickson 1.0.10-4 - Doing a connect on UDP sockets causes the linux network stack to reject UDP patches from multi-home server with nic on the same subnet. (bz 212471) * Wed Nov 15 2006 Steve Dickson 1.0.10-3 - Removed some old mounting versioning code that was stopping tcp mount from working (bz 212471) * Tue Oct 31 2006 Steve Dickson 1.0.10-2 - Fixed -o remount (bz 210346) - fix memory leak in rpc.idmapd (bz 212547) - fix use after free bug in dirscancb (bz 212547) - Made no_subtree_check a default export option (bz 212218) openhpi-2.4.1-7.fc7 ------------------- * Tue Nov 28 2006 Phil Knirsch - 2.4.1-7.fc7 - Rebuilt due to new net-snmp-5.4 - Small specfile updates * Fri Sep 29 2006 Phil Knirsch - 2.4.1-6 - Fixed file conflicts for openhpi-switcher (#205226) openoffice.org-1:2.1.0-5.3 -------------------------- * Tue Nov 28 2006 Caolan McNamara - 1:2.1.0-5.3 - rhbz#217361 wrong libjvm on ppc32/ppc64 multiarch installed libgcj's - rhbz#217490/ooo#72058 don't add underline to preedit if not necessary - visibility.warning.patch * Mon Nov 27 2006 Caolan McNamara - 1:2.1.0-5.2 - Resolves: rhbz#217321 openoffice.org-2.1.0.ooo72014.officecfg.malayammenu.patch - Resolves: rhbz#217234 visibility and inline local static data openssh-4.3p2-13.fc7 -------------------- * Tue Nov 28 2006 Tomas Mraz - 4.3p2-13 - improved pam_session patch so it doesn't regress, the patch is necessary for the pam_session_close to be called correctly as uid 0 openssl-0.9.8b-10.fc7 --------------------- * Thu Nov 23 2006 Tomas Mraz 0.9.8b-10 - make X509_NAME_cmp transitive otherwise certificate lookup is broken (#216050) pcre-6.7-1 ---------- * Mon Nov 27 2006 Than Ngo - 6.7-1 - update to 6.7 - fix #217303, enable-unicode-properties - sane stack limit perl-Crypt-SSLeay-0.51-12.fc7 ----------------------------- * Mon Nov 27 2006 Robin Norwood - 0.51-12 - Resolves: bug#217138 - fix a segfault on x86_64 php-5.2.0-7 ----------- * Tue Nov 28 2006 Joe Orton 5.2.0-7 - rebuild again * Tue Nov 28 2006 Joe Orton 5.2.0-6 - rebuild for net-snmp soname bump * Mon Nov 27 2006 Joe Orton 5.2.0-5 - build json and zip shared, in -common (Remi Collet, #215966) - obsolete php-json and php-pecl-zip - build readline extension into /usr/bin/php* (#210585) - change module subpackages to require php-common not php (#177821) pilot-link-2:0.12.1-3.fc7 ------------------------- * Tue Nov 28 2006 Ivana Varekova 2:0.12.1-3 - add enable-conduits option * Mon Nov 27 2006 Ivana Varekova - 2:0.12.1-2 - Add epoch - Delete useless patches - Add Buildrequires autoconf, automake and libtool * Wed Sep 06 2006 Matthew Barnes - 0.12.1-1.fc6 - Update to 0.12.1 - Disable all patches for 0.11. policycoreutils-1.33.5-2.fc7 ---------------------------- * Tue Nov 28 2006 Dan Walsh 1.33.5-2 - Fix -q qualifier on load_policy Resolves: #214827 * Tue Nov 28 2006 Dan Walsh 1.33.5-1 - Merge to upstream - Fix makefile line Resolves: #208838 privoxy-3.0.6-2 --------------- * Tue Nov 28 2006 Karsten Hopp 3.0.6-2 - fix download URL - cleanups pygtk2-2.10.3-5.fc7 ------------------- * Mon Nov 27 2006 Matthew Barnes - 2.10.3-5.fc7 - Add patch for RH bug #217430 (missing gtk-extrafuncs.defs). redhat-lsb-3.1-12.1 ------------------- * Wed Nov 29 2006 Lawrence Lim - 3.1-12.1 - rebuild package * Wed Nov 29 2006 Lawrence Lim - 3.1-12 - Resolves: #217566 - replaced aliases with functions in /lib/lsb/init-functions s390utils-2:1.5.4-1.fc7 ----------------------- * Tue Nov 28 2006 Phil Knirsch 2:1.5.4-1.fc7 - Some small specfile updates * Tue Nov 28 2006 Phil Knirsch 2:1.5.4-1 - Update to s390-tools-1.5.4 selinux-policy-2.4.5-4.fc7 -------------------------- * Tue Nov 21 2006 Dan Walsh 2.4.5-4 - Fix context for helix players file_context #216942 sendmail-8.13.8-3 ----------------- * Tue Nov 28 2006 Thomas Woerner 8.13.8-3 - added missing LDAP_DEPRECATED flag (#206288) setup-2.6.1-1.fc7 ----------------- * Tue Nov 28 2006 Phil Knirsch 2.6.1-1.fc7 - Update version and rebuilt * Tue Nov 28 2006 Phil Knirsch 2.5.57-1 - Revert change for umask in /etc/bashrc (#217523) swig-1.3.31-0.fc7 ----------------- * Tue Nov 28 2006 Adam Tkac 1.31.1-0.fc7 - updated to 1.2.31 (#216991) system-config-printer-0.7.40-1.fc7 ---------------------------------- * Tue Nov 21 2006 Tim Waugh 0.7.40-1 - 0.7.40: - Removed username:password from hint string because we add that in afterwards. - Don't set button widths in create-printer dialog (bug #217025). system-config-soundcard-2.0.5-1.fc7 ----------------------------------- * Mon Nov 27 2006 Martin Stransky 2.0.5-1 - updated translations vnc-4.1.2-7.fc7 --------------- * Thu Nov 23 2006 Adam Tkac 4.1.2-7.fc7 - Xvnc now starts with render extensions. We need test it. Disable with -render option - vncserver requires xorg-x11-xauth wireshark-0.99.4-4.fc7 ---------------------- * Tue Nov 28 2006 Radek Vokal 0.99.4-4 - rebuilt for new libpcap and net-snmp xorg-x11-xinit-1.0.2-15.fc7 --------------------------- * Mon Nov 27 2006 Adam Jackson 1.0.2-15 - Bump EVR to fix 6 to 7 updates. ypbind-3:1.19-6 --------------- * Mon Nov 27 2006 Dan Walsh - 3:1.19-6 - Correct ordering of turning off SELinux boolean Broken deps for i386 ---------------------------------------------------------- freeradius - 1.1.3-1.i386 requires libsnmp.so.10 kdepim - 6:3.5.5-0.2.fc6.i386 requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.i386 requires libnetsnmp.so.10 nut - 2.0.3-2.1.i386 requires libnetsnmp.so.10 Broken deps for ppc64 ---------------------------------------------------------- freeradius - 1.1.3-1.ppc64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.ppc64 requires libpisock.so.8()(64bit) kdeutils - 6:3.5.5-0.1.fc6.ppc64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.ppc64 requires libnetsnmp.so.10()(64bit) Broken deps for x86_64 ---------------------------------------------------------- freeradius - 1.1.3-1.x86_64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.x86_64 requires libpisock.so.8()(64bit) kdepim - 6:3.5.5-0.2.fc6.i386 requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.x86_64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.x86_64 requires libnetsnmp.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- freeradius - 1.1.3-1.ppc requires libsnmp.so.10 kdepim - 6:3.5.5-0.2.fc6.ppc requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.ppc requires libnetsnmp.so.10 nut - 2.0.3-2.1.ppc requires libnetsnmp.so.10 Broken deps for s390 ---------------------------------------------------------- freeradius - 1.1.3-1.s390 requires libsnmp.so.10 kdeutils - 6:3.5.5-0.1.fc6.s390 requires libnetsnmp.so.10 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- freeradius - 1.1.3-1.ia64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.ia64 requires libpisock.so.8()(64bit) kdeutils - 6:3.5.5-0.1.fc6.ia64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.ia64 requires libnetsnmp.so.10()(64bit) Broken deps for s390x ---------------------------------------------------------- freeradius - 1.1.3-1.s390x requires libsnmp.so.10()(64bit) kdeutils - 6:3.5.5-0.1.fc6.s390x requires libnetsnmp.so.10()(64bit) From mituc at activemediatech.com Wed Nov 29 07:25:04 2006 From: mituc at activemediatech.com (Tarhon-Onu Victor) Date: Wed, 29 Nov 2006 09:25:04 +0200 (EET) Subject: static RPM utils (was Re: Suggestion: Static libs policy, a draft) In-Reply-To: <456C7E22.7060501@redwire.net> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> <456BE0C3.7010308@redhat.com> <20061128172815.GG4246@nostromo.devel.redhat.com> <456C7E22.7060501@redwire.net> Message-ID: On Tue, 28 Nov 2006, Japheth J.C. Cleaver wrote: > Side question: Is rpm compiled statically? *checks* ... nope. If > anything is going to remain statically compiled on the system, I'd say > package management tools would be good candidates too, for this very > reason. Well, I think it's a little bit complicated that that. RPM manipulates the same database as yum does. That database (I'm talking about the files in /var/lib/rpm/) is in Berkley DB format. So if something changes in the Berkley DB API for some reason (version/format change as it was from 3 to 4?) then all the tools should still be able to open those files. In order to accomplish this and also to have the RPM utils statically compiled you will have to compile statically (or at least to compile statically the BDB support) a lot of tools like Python, used by yum. And this is not feasible, I think. Keeping a statically compiled python binary (and maybe some other libraries and/or binaries) somewhere on the filesystem could be a solution, but it's more like an ugly hack than a feature. Moreover, I think that static linking might be a step backwards in time. If you remove or by some stupid or good reason (and there are so few reasons for this to happen in real life...) some important libraries (like libc.so.6) in your system are damaged then... that's life: boot from a CD and rpm -Uhv --force -r /mount/point or rpm2cpio are your friends. -- Victor Tarhon-Onu Lead Systems Administrator ActiveMedia Technology http://www.activemediatech.com ............................................................................. This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error kindly notify the sender immediately and delete it from your system. From benny+usenet at amorsen.dk Wed Nov 29 10:32:30 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 29 Nov 2006 11:32:30 +0100 Subject: Static linking considered harmful References: <20061122100800.GQ6570@devserv.devel.redhat.com> <20061122102428.GD2799@free.fr> <4564AFA1.4090103@redhat.com> <20061124185230.GE31787@neu.nirvana> <1164628135.5452.33.camel@max.booze> <6280325c0611280645p24d6bf22ybc9c83510229c467@mail.gmail.com> <20061128151201.GB3447@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> Not sure that bundling the .so is better in this regard. I am not PD> sure that it is legal to bundle LGPL covered .so and a proprietary PD> app in the same tarball. It is. The requirement for the LGPL is that you have to be able to relink the proprietary application with new libraries, and that method fulfills the requirement. PD> It is possible to do 2 tarballs, one with apps with LGPL source PD> compatible license, the other with non LGPL compatible license, PD> and the user just has to unpack them in the same directory. The Lesser GPL seems to be even more misunderstood than the GPL. To get around the full GPL you could try the method you describe here -- it's called "user does the link", and its legality is debated (the FSF says that it's illegal). Remember that in all cases, if you ship something under a LGPL or GPL license as object code, you have to ship either the source or a written offer to provide the source. If Fedora makes it easy to create bundles of libraries and applications, it should make sure that the source code of LGPL or GPL libraries is always included in such bundles. /Benny From benny+usenet at amorsen.dk Wed Nov 29 10:38:51 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 29 Nov 2006 11:38:51 +0100 Subject: removing termcap References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Of course if our layout were logical we'd have a /share root for NM> these kinds of needs If our layout was logical we would not have /usr in the first place. Does anyone still mount /usr later? If so, why? /Benny From d.lesca at solinos.it Wed Nov 29 10:50:06 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 29 Nov 2006 11:50:06 +0100 Subject: cpio: the folder is make not conform to umask setting Message-ID: <1164797406.8177.42.camel@lesca.home.solinos.it> Hi, the GNU cpio (http://www.gnu.org/software/cpio/) in some case (when the folder's property is not contained into package) not set the folder's access conforme to umask setting. % find /tmp/some-folder -type f -depth |cpio -pvdmu /var/tmp the some-folder and your subfolders copy into var/tmp have the access set to "rwx------" (700), not in compliance with umask's setting (as an example 0022). The tar in these cases behaves itself correctly, creating the folders (not contained in the package) compliance with umask's setting. Is this a feature or a little bugs? I have migrate some SCO unix to Linux and this "feature" is annoying. I have watched into fc6's cpio-2.6-19.src.rpm and I have see witch some patch has been added to the original version. But unfortunately I am not a 'C' programmer and I not able to setup a specific patch witch set the folder's access to umask's setting ... What I can do? Is possible add another patch for resolve this problem? I must fill a bug into Bugzilla? Pleas, give me some suggest .... Many thanks to all, and sorry for my bad English -- Dario Lesca From harald at redhat.com Wed Nov 29 11:08:46 2006 From: harald at redhat.com (Harald Hoyer) Date: Wed, 29 Nov 2006 12:08:46 +0100 Subject: FC6: some impressions In-Reply-To: <20061122093249.3c619f41.j.rink@freenet.de> References: <2002.207.245.37.34.1164148251.squirrel@lattica.com> <20061121230603.GA13830@devserv.devel.redhat.com> <20061122093249.3c619f41.j.rink@freenet.de> Message-ID: <456D6A3E.4090304@redhat.com> J?rn Rink schrieb: > Am Tue, 21 Nov 2006 18:06:03 -0500 > hat Alan Cox (Alan Cox) folgendes geschrieben: > > >> You assume everyone has the same experience you do - FC6 for me for >> example burns CDs fine and evolution sends email (its about all that >> particular pile of garbage does but thats a large upstream problem >> not an RH packaging one). You might want want to investigate a better >> email client - eg sylpheed-claws. >> > > The DVD fc6 iso i burned with fc5 (double click in nautilus) does not go > through the chksum test and failed in anaconda ;-) > > I burned it with nero :) This is because the chksum test does not honour the iso size and just reads /dev/cdrom until the end.. $ rpm -qf $(which isosize ) util-linux-2.13-0.45.fc6 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3621 bytes Desc: S/MIME Cryptographic Signature URL: From giallu at gmail.com Wed Nov 29 11:41:37 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 29 Nov 2006 12:41:37 +0100 Subject: 100% CPU on idling Message-ID: I am curious if anyone else is seeing it's processor at 100% when the machine is supposed to idling (I do not use fancy screensavers, just go to a blank screen after 10 minutes). I noticed because this is a laptop and the fan is triggered by cpu temperature raising. As soon as I touch the mouse, the CPU stops processing, but I can see it was at 100% in the system monitor applet. I suspect this is the inteded behavior of something but, nonetheless, I would like to know what actually is (and eventually kill it...) cheers Gianluca From jan.kratochvil at redhat.com Wed Nov 29 12:02:46 2006 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 29 Nov 2006 13:02:46 +0100 Subject: 100% CPU on idling In-Reply-To: References: Message-ID: <20061129120246.GA14304@host0.dyn.jankratochvil.net> On Wed, 29 Nov 2006 12:41:37 +0100, Gianluca Sforna wrote: > I am curious if anyone else is seeing it's processor at 100% ... > I would like to know what actually is (and eventually kill it...) Leave running: top -b >top.log OR top -b|tee top.log Regards, Lace From hughsient at gmail.com Wed Nov 29 12:25:15 2006 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 29 Nov 2006 12:25:15 +0000 Subject: 100% CPU on idling In-Reply-To: References: Message-ID: <1164803115.5731.1.camel@hughsie-laptop> On Wed, 2006-11-29 at 12:41 +0100, Gianluca Sforna wrote: > I suspect this is the inteded behavior of something but, nonetheless, > I would like to know what actually is (and eventually kill it...) For me, beadgled keeps one processor busy (100%) when idle on my laptop - I assume indexing data. I can imagine the electrical power this uses. Richard. From jdieter at gmail.com Wed Nov 29 12:30:30 2006 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 29 Nov 2006 14:30:30 +0200 Subject: 100% CPU on idling In-Reply-To: References: Message-ID: <1164803430.5002.8.camel@jndwidescreen.lesbg.loc> On Wed, 2006-11-29 at 12:41 +0100, Gianluca Sforna wrote: > I am curious if anyone else is seeing it's processor at 100% when the > machine is supposed to idling (I do not use fancy screensavers, just > go to a blank screen after 10 minutes). > I noticed because this is a laptop and the fan is triggered by cpu > temperature raising. > As soon as I touch the mouse, the CPU stops processing, but I can see > it was at 100% in the system monitor applet. > > I suspect this is the inteded behavior of something but, nonetheless, > I would like to know what actually is (and eventually kill it...) > > cheers > > Gianluca > +1 (on FC6) I believe the problem has to do with beagle. If you don't mind completely redoing your index, try removing ~/.beagle (when logged out of X). The problem only cropped up for me when I switched from Thunderbird (which isn't indexed by beagle) to Evolution (which is). When I disable indexing, the problem disappears, and it seems that it also goes when you remove the ~/.beagle directory. Jonathan -------------- 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 giallu at gmail.com Wed Nov 29 12:34:15 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 29 Nov 2006 13:34:15 +0100 Subject: 100% CPU on idling In-Reply-To: <1164803430.5002.8.camel@jndwidescreen.lesbg.loc> References: <1164803430.5002.8.camel@jndwidescreen.lesbg.loc> Message-ID: On 11/29/06, Jonathan Dieter wrote: > > I believe the problem has to do with beagle. If you don't mind > completely redoing your index, try removing ~/.beagle (when logged out > of X). The problem only cropped up for me when I switched from > Thunderbird (which isn't indexed by beagle) to Evolution (which is). > When I disable indexing, the problem disappears, and it seems that it > also goes when you remove the ~/.beagle directory. interesting... since this is a fresh FC6 install BUT my home dir come from the previous FC5, I think I will try this. From ajackson at redhat.com Wed Nov 29 13:52:46 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 29 Nov 2006 08:52:46 -0500 Subject: Desktop-effects In-Reply-To: <456CB00B.20500@redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> <20061127165700.GJ29814@nostromo.devel.redhat.com> <1164651718.3398.1.camel@halflap.boston.devel.redhat.com> <456CB00B.20500@redhat.com> Message-ID: <1164808366.7683.25.camel@localhost.localdomain> On Tue, 2006-11-28 at 16:54 -0500, Soeren Sandmann wrote: > Ray Strode wrote: > >> But desktop-effects has more strings than just the desktop file. > >> > > > > Ah right...We should just upstream it at elvis, I guess. > > > Desktop Effects is already checked into elvis. Since we're on the subject, it was pointed out to me the other day that the desktop-effects source is missing copyright and authorship statements. We can assume Red Hat owns the copyright, but it would be nice to know who wrote it too. - ajax From buc at odusz.so-cdu.ru Wed Nov 29 14:02:33 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 29 Nov 2006 17:02:33 +0300 Subject: Suggestion: Static libs policy, a draft In-Reply-To: <20061127182234.GB32187@nostromo.devel.redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> Message-ID: <456D92F9.1070501@odu.neva.ru> Bill Nottingham wrote: >One issue with separate, auto-generated -devel-static packages - how >do you handle dependencies? Or do you just handwave around the fact >that (for example) kudzu-devel requires pciutils-devel? > > "foo-devel-static" always requires "foo-devel" . "foo-devel" itself can require some another "-devel" packages, for example "bar-devel". But it does not mean that "foo-devel-static" strongly requires "bar-devel-static", because the user might want to link statically just some of the libraries... If someone does static linking (a "non-standard" and "non-recommended" thing), we may assume that either such a user, or his/her admin are "advanced enough", therefore it was not too hard for them to pre-install all the static libs they need. BTW, what about "-debug" subpackages? Are there a way to install all "-debug" stuff automatically? ~buc From buildsys at redhat.com Wed Nov 29 15:22:14 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 29 Nov 2006 10:22:14 -0500 Subject: rawhide report: 20061129 changes Message-ID: <200611291522.kATFME48007418@hs20-bc2-6.build.redhat.com> Updated Packages: desktop-file-utils-0.12-1.fc7 ----------------------------- * Tue Nov 28 2006 Ray Strode - 0.12-1 - Update to 0.12 eruby-1.0.5-7 ------------- * Wed Nov 29 2006 Akira TAGOH - 1.0.5-7 - fix library permissions (#215912) hexedit-1.2.12-4.fc7 -------------------- * Wed Nov 29 2006 Jindrich Novy 1.2.12-4 - fix URL, add dist tag openoffice.org-1:2.1.0-5.4 -------------------------- * Tue Nov 28 2006 Caolan McNamara - 1:2.1.0-5.4 - drop unneeded openoffice.org-2.0.4.oooXXXXX.solenv.warnnoterror.patch - Resolves: rhbz#217521 extend grapheme cluster on ranges \u0c01-\u0c03 \u0c41-\u0c44 - use system hunspell planner-0.14.2-1.fc7 -------------------- * Tue Nov 28 2006 Caolan McNamara - 0.14.2-1.fc7 - next version pycairo-1.2.6-1.fc7 ------------------- * Tue Nov 28 2006 Matthew Barnes - 1.2.6-1.fc7 - Update to 1.2.6 - Clean up the spec file. tzdata-2006p-1.fc7 ------------------ * Wed Nov 29 2006 Petr Machata - 2006p-1 - Upstream 2006p - Official version of Western Australia DST trial changes - Latitude/longitude changes for Europe/Jersey and Europe/Podgorica Broken deps for ppc64 ---------------------------------------------------------- freeradius - 1.1.3-1.ppc64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.ppc64 requires libpisock.so.8()(64bit) kdeutils - 6:3.5.5-0.1.fc6.ppc64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.ppc64 requires libnetsnmp.so.10()(64bit) Broken deps for i386 ---------------------------------------------------------- freeradius - 1.1.3-1.i386 requires libsnmp.so.10 kdepim - 6:3.5.5-0.2.fc6.i386 requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.i386 requires libnetsnmp.so.10 nut - 2.0.3-2.1.i386 requires libnetsnmp.so.10 Broken deps for ppc ---------------------------------------------------------- freeradius - 1.1.3-1.ppc requires libsnmp.so.10 kdepim - 6:3.5.5-0.2.fc6.ppc requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.ppc requires libnetsnmp.so.10 nut - 2.0.3-2.1.ppc requires libnetsnmp.so.10 Broken deps for ia64 ---------------------------------------------------------- freeradius - 1.1.3-1.ia64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.ia64 requires libpisock.so.8()(64bit) kdeutils - 6:3.5.5-0.1.fc6.ia64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.ia64 requires libnetsnmp.so.10()(64bit) Broken deps for x86_64 ---------------------------------------------------------- freeradius - 1.1.3-1.x86_64 requires libsnmp.so.10()(64bit) kdepim - 6:3.5.5-0.2.fc6.x86_64 requires libpisock.so.8()(64bit) kdepim - 6:3.5.5-0.2.fc6.i386 requires libpisock.so.8 kdeutils - 6:3.5.5-0.1.fc6.x86_64 requires libnetsnmp.so.10()(64bit) nut - 2.0.3-2.1.x86_64 requires libnetsnmp.so.10()(64bit) Broken deps for s390 ---------------------------------------------------------- freeradius - 1.1.3-1.s390 requires libsnmp.so.10 kdeutils - 6:3.5.5-0.1.fc6.s390 requires libnetsnmp.so.10 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- freeradius - 1.1.3-1.s390x requires libsnmp.so.10()(64bit) kdeutils - 6:3.5.5-0.1.fc6.s390x requires libnetsnmp.so.10()(64bit) From cmadams at hiwaay.net Wed Nov 29 15:49:24 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 29 Nov 2006 09:49:24 -0600 Subject: removing termcap In-Reply-To: References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> Message-ID: <20061129154924.GC1478292@hiwaay.net> Once upon a time, Benny Amorsen said: > If our layout was logical we would not have /usr in the first place. > > Does anyone still mount /usr later? If so, why? On my servers, I still typically have a separate /usr that is mounted read-only. I figure since no writes can occur (not even things like atime updates), there's little chance of seeing any filesystem corruption from anything (and it never needs fsck or journal recovery on an unclean shutdown). Also, this way / is a lot smaller; again, less likely to have errors and fsck/journal replay have much less to do (so less chance for error). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From david at fubar.dk Wed Nov 29 18:04:07 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 29 Nov 2006 13:04:07 -0500 Subject: Desktop-effects In-Reply-To: <456CB00B.20500@redhat.com> References: <1164460522.5043.4.camel@axp2600> <45685F93.5040604@redhat.com> <1164470906.3328.10.camel@localhost.localdomain> <20061127160356.GB30000@nostromo.devel.redhat.com> <1164644292.2668.6.camel@halflap.boston.devel.redhat.com> <20061127165700.GJ29814@nostromo.devel.redhat.com> <1164651718.3398.1.camel@halflap.boston.devel.redhat.com> <456CB00B.20500@redhat.com> Message-ID: <1164823447.2474.8.camel@zelda.fubar.dk> On Tue, 2006-11-28 at 16:54 -0500, Soeren Sandmann wrote: > Ray Strode wrote: > >> But desktop-effects has more strings than just the desktop file. > >> > > > > Ah right...We should just upstream it at elvis, I guess. > > > Desktop Effects is already checked into elvis. Is there no upstream effort to provide such a capplet / control panel as part of say... compiz? It seems very wrong to me that each distribution is doing their own thing here. Besides, if this lived on cvs.gnome.org it would probably already be translated into a myriad of languages already... Am I missing something? David From tonynelson at georgeanelson.com Wed Nov 29 20:42:07 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 29 Nov 2006 15:42:07 -0500 Subject: 100% CPU on idling In-Reply-To: References: <1164803430.5002.8.camel@jndwidescreen.lesbg.loc> Message-ID: At 1:34 PM +0100 11/29/06, Gianluca Sforna wrote: >On 11/29/06, Jonathan Dieter wrote: >> >> I believe the problem has to do with beagle. If you don't mind >> completely redoing your index, try removing ~/.beagle (when logged out >> of X). The problem only cropped up for me when I switched from >> Thunderbird (which isn't indexed by beagle) to Evolution (which is). >> When I disable indexing, the problem disappears, and it seems that it >> also goes when you remove the ~/.beagle directory. > >interesting... since this is a fresh FC6 install BUT my home dir come >from the previous FC5, I think I will try this. In the past, on FC5 it has been reported that restarting beagled was sufficient to correct the problem. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From tonynelson at georgeanelson.com Wed Nov 29 21:03:03 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 29 Nov 2006 16:03:03 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: Message-ID: At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote: >Content-Type: multipart/signed; > boundary="=_mimegpg-commodore.email-scan.com-5984-1163991009-0001"; > micalg=pgp-sha1; protocol="application/pgp-signature" > >Tony Nelson writes: > >> I propose that there should be a nightly cron task to check the RPM > >I proposed this several years ago, and got poo-poohed. OK, now I've been pooh-poohed as well. >I now just have a cron.daily script that just makes a copy of /var/lib/rpm >on a five day rotation. You might take a look at my rpm_verifydb package at , as it only saves the RPM database if it passes "rpm --verifydb". -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From tonynelson at georgeanelson.com Wed Nov 29 21:02:50 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 29 Nov 2006 16:02:50 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> Message-ID: At 9:43 AM +0200 11/21/06, Panu Matilainen wrote: >On Tue, 21 Nov 2006, seth vidal wrote: > >> On Mon, 2006-11-20 at 17:49 -0600, Steven Pritchard wrote: >>> On Mon, Nov 20, 2006 at 04:38:23AM -0800, Otto Rey wrote: >>>> This sound good, but first we need to detect why rpms database >>>> got corrupted. >>> >>> It's Berkeley DB. Corruption should be expected. :-/ >>> >> >> I guess I'm a little confused here, actually. >> >> Let's take bsddb out of the example. >> >> If I'm a client of an oracle db and I repeatedly open, read, close the >> database using the interface available, for small amounts of data that >> might not be the most efficient use of the database connection. >> >> However, if as a result of open-read-close the database is corrupted >> and/or rendered unusable where would you say the bug lies? >> >> To me it seems like a valid client connection should not be able to >> corrupt a database simply by open-read-closing no matter how many times. >> And if it can then clearly there is something wrong with the database >> code. > >Well, obviously. I think that's exactly what Steven means... Personal >experience with both subversion repos using Berkeley DB storage and rpmdb >has made me too expect nothing else but eventual corruption from BDB :-/ It would be a good idea to find out how many Fedora users have corrupt RPM databases. My rpm_verifydb package at is a start, but it won't report problems back to you guys. ISTM that if yum were to (possibly temporarily) verify the RPM database with the only tool available in RPM, "rpm --verifydb" (or its synonym "rpmdb_verify"), and then report only broken databases to Fedora, that this would not be the sort of privacy invasion that is causing so much angst. If RPM's developer, Jeff Johnson, is correct, you won't receive any reports, and the issue can be dropped. See the thread I started at Redhat's rpm-list, "SUG: Automatic RPM database verification and repair", for his take on the whole matter. If you want me to do some of this, ask. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From skvidal at linux.duke.edu Wed Nov 29 21:39:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 29 Nov 2006 16:39:04 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> Message-ID: <1164836344.7311.81.camel@cutter> On Wed, 2006-11-29 at 16:02 -0500, Tony Nelson wrote: > It would be a good idea to find out how many Fedora users have corrupt RPM > databases. My rpm_verifydb package at > is a start, but it won't report > problems back to you guys. ISTM that if yum were to (possibly temporarily) > verify the RPM database with the only tool available in RPM, "rpm > --verifydb" (or its synonym "rpmdb_verify"), and then report only broken > databases to Fedora, that this would not be the sort of privacy invasion > that is causing so much angst. If RPM's developer, Jeff Johnson, is > correct, you won't receive any reports, and the issue can be dropped. See > the thread I started at Redhat's rpm-list, "SUG: Automatic RPM database > verification and repair", for his take on the whole matter. > > If you want me to do some of this, ask. Tony, We'd like for the problem to be fixed 'correctly' where correctly means not just papering over it. However, I definitely understand wanting to fix problems for users one way or the other. So the best I can say is that if this problem isn't fixed properly before Fedora 8 then I'll push hard for something similar to the work-around solution you've described to be implemented. -sv From kevin.kofler at chello.at Wed Nov 29 22:48:41 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 29 Nov 2006 22:48:41 +0000 (UTC) Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> Message-ID: Rex Dieter math.unl.edu> writes: > Now that we have srpms, I'll see about whipping up some binary rpms and > putting them in the kde-redhat repo somewhere. WARNING: I have _NOT_ tested these in Mock yet. You may have to add BuildRequires. It's also a pretty old snapshot, but I guess it's better than nothing... Still, if I can get it updated to 3.80.2 soon, that would be better. Maybe this weekend, but I'm pretty busy unfortunately. Kevin Kofler From tonynelson at georgeanelson.com Wed Nov 29 22:53:49 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 29 Nov 2006 17:53:49 -0500 Subject: SUG: RPM database verification / repair, nightly and in Anaconda In-Reply-To: <1164836344.7311.81.camel@cutter> References: <20061120123823.90928.qmail@web52404.mail.yahoo.com> <20061120234954.GA2324@osiris.silug.org> <1164091190.13465.32.camel@cutter> <1164836344.7311.81.camel@cutter> Message-ID: At 4:39 PM -0500 11/29/06, seth vidal wrote: >On Wed, 2006-11-29 at 16:02 -0500, Tony Nelson wrote: > >> It would be a good idea to find out how many Fedora users have corrupt RPM >> databases. My rpm_verifydb package at >> is a start, but it won't report >> problems back to you guys. ISTM that if yum were to (possibly temporarily) >> verify the RPM database with the only tool available in RPM, "rpm >> --verifydb" (or its synonym "rpmdb_verify"), and then report only broken >> databases to Fedora, that this would not be the sort of privacy invasion >> that is causing so much angst. If RPM's developer, Jeff Johnson, is >> correct, you won't receive any reports, and the issue can be dropped. See >> the thread I started at Redhat's rpm-list, "SUG: Automatic RPM database >> verification and repair", for his take on the whole matter. >> >> If you want me to do some of this, ask. > >Tony, > We'd like for the problem to be fixed 'correctly' where correctly means >not just papering over it. ... Measuring a problem does not paper over it. You did not understand my post. Please ask me about anything in it that is unclear. -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From kevin.kofler at chello.at Wed Nov 29 22:56:16 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 29 Nov 2006 22:56:16 +0000 (UTC) Subject: KDE4 being packaged References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > Here you go, the build log for kdebase4 which failed with rpath=true: > http://tux.u-strasbg.fr/~chit/kdebase4_build.log There's 2 problems here: * The rpath check considers '/opt/kde4/lib' to be an invalid rpath. I'm not sure what is supposed to be "invalid" about that rpath. It's not a standard search path, and it _is_ an absolute path. So we'll have to disable the rpath checks, but they really ought to be fixed. * KDE is putting in rpaths to '/lib' and '/usr/local/lib'. This is bad. I'm not sure where the '/usr/local/lib' is coming from (none of the linked libraries should be there!), and '/lib' is also bad (there's probably a filter for '/usr/lib', but not plain '/lib' in cmake). A possible workaround for this issue would be to use -DCMAKE_DISABLE_RPATH=TRUE as you did and to add: -Wl,--rpath,/opt/kde4/lib to the LDFLAGS instead (so we'd set the rpath manually rather than automatically). Kevin Kofler From chitlesh at fedoraproject.org Wed Nov 29 23:49:06 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 30 Nov 2006 00:49:06 +0100 Subject: KDE4 being packaged In-Reply-To: References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> Message-ID: <13dbfe4f0611291549u65e15e32k30a3c5ce097cf3d6@mail.gmail.com> > There's 2 problems here: > * The rpath check considers '/opt/kde4/lib' to be an invalid rpath. I'm not > sure what is supposed to be "invalid" about that rpath. It's not a standard > search path, and it _is_ an absolute path. So we'll have to disable the rpath > checks, but they really ought to be fixed. > * KDE is putting in rpaths to '/lib' and '/usr/local/lib'. This is bad. I'm not > sure where the '/usr/local/lib' is coming from (none of the linked libraries > should be there!), and '/lib' is also bad (there's probably a filter > for '/usr/lib', but not plain '/lib' in cmake). A possible workaround for this > issue would be to use -DCMAKE_DISABLE_RPATH=TRUE as you did and to add: > -Wl,--rpath,/opt/kde4/lib > to the LDFLAGS instead (so we'd set the rpath manually rather than > automatically). Right now, I'm building kdelibs4 with: QA_RPATHS=0x0003; export QA_RPATHS; rpmbuild -ba kdelibs4.spec -- http://clunixchit.blogspot.com From zrchrn at gmail.com Thu Nov 30 06:09:00 2006 From: zrchrn at gmail.com (Ahm ed) Date: Thu, 30 Nov 2006 01:09:00 -0500 Subject: The "recent" proposals. Message-ID: Hello, I am Ahmed. I just wanted to voice to the devs my excitement at the recent news (recent for me) of merging extras and core, as well as the news about pungi and pilgrim (especially about pilgrim). I think these tools will provide us with more versatility. I have also heard of a sysv replacement that may or may not be in FC7 (any news?) also sounds like an excellent advancement. I understand that many of these are currently just being tossed around and I wanted to voice that yes indeed these tools all sound very useful and I believe they would be an excellent addition to fedora core (or is it Fedora Complete?). In general I believe you guys have done a great job, and I applaud your resolve in continuing to provide an excellent distro based on FOSS and free of the binary proprietary junk that other distros are starting to pump into the kernel. (I have found that it leads to far greater stability.) Good luck to you all and thank you for your hard work. p.s. Sorry for the lack of order in this, I am currently swamped w/ school, I just felt it necessary to voice my support for the recent "developments". -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzak at redhat.com Thu Nov 30 10:18:46 2006 From: kzak at redhat.com (Karel Zak) Date: Thu, 30 Nov 2006 11:18:46 +0100 Subject: removing termcap In-Reply-To: References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> Message-ID: <20061130101846.GA31756@petra.dvoda.cz> On Wed, Nov 29, 2006 at 11:38:51AM +0100, Benny Amorsen wrote: > >>>>> "NM" == Nicolas Mailhot writes: > > NM> Of course if our layout were logical we'd have a /share root for > NM> these kinds of needs > > If our layout was logical we would not have /usr in the first place. > > Does anyone still mount /usr later? If so, why? rescue mode The root partition has to be useful and consistent in itself. Karel -- Karel Zak From buildsys at redhat.com Thu Nov 30 11:04:54 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 30 Nov 2006 06:04:54 -0500 Subject: rawhide report: 20061130 changes Message-ID: <200611301104.kAUB4sQn012599@hs20-bc2-6.build.redhat.com> Updated Packages: avahi-0.6.15-3.fc7 ------------------ * Mon Nov 27 2006 Martin Bacovsky - 0.6.15-3 - automake-1.10 required for building * Mon Nov 27 2006 Martin Bacovsky - 0.6.15-2 - automake-1.9 required for building * Fri Nov 24 2006 Martin Bacovsky - 0.6.15-1 - Upgrade to 0.6.15 - patches revision cpuspeed-1:1.2.1-1.45.fc7 ------------------------- * Wed Nov 29 2006 Jarod Wilson - Fix busted config file sourcing * Mon Nov 27 2006 Jarod Wilson - Spec tweaks to bring in line with Fedora packaging guidelines - Add docs to package - Mark config file as noreplace - Be sure to stop service before uninstall dbus-glib-0.71-3.fc7 -------------------- * Wed Nov 29 2006 David Zeuthen - 0.71-3.fc7 - Add dbus-glib-0.70-fix-info-leak.patch - Resolves: #216034 dhcp-12:3.0.5-8.fc7 ------------------- * Wed Nov 29 2006 David Cantrell - 12:3.0.5-8 - Roll md5 patch in to libdhcp4client patch since it's related - Do not overwrite /etc/ntp/step-tickers (#217663) - Resolves: rhbz#217663 * Wed Nov 22 2006 Peter Jones - 12:3.0.5-7 - Build the MD5 functions we link against. * Thu Nov 16 2006 David Cantrell - 12:3.0.5-6 - Set permission of libdhcp4client.so.1 to 0755 (#215910) gaim-2:2.0.0-0.25.beta5.fc7 --------------------------- * Wed Nov 29 2006 Warren Togami - 2:2.0.0-0.25.beta5 - GTK File dialog blanked fix (#217768) - Disable cyrus-sasl-md5 patch, it needs more work * Tue Nov 28 2006 Warren Togami - 2:2.0.0-0.24.beta5 - Debian patch 10_text-arrow-keys - Debian patch 11_reread-resolvconf - Jabber cyrus-sasl-md5 plugin crash (#217335 ari, kingant) gnome-panel-2.16.1-8.fc7 ------------------------ * Wed Nov 29 2006 Ray Strode - 2.16.1-8 - don't ask user if they want to logout if they've set the preference not to * Wed Nov 29 2006 Stepan Kasal - 2.16.1-7 - Add BuildRequires: libtool; without it, the aclocal call failed. * Tue Nov 21 2006 Matthias Clasen - 2.16.1-6 - Support tracker hunspell-1.1.4-2.fc7 -------------------- isdn4k-utils-3.2-53.fc7 ----------------------- * Wed Nov 29 2006 Karsten Hopp 3.2-53.fc7 - rebuild with new libpcap kdepim-6:3.5.5-1.fc7 -------------------- * Wed Nov 29 2006 Karsten Hopp 3.5.5-1.fc7 - rebuild with new pilot-link libs - fix automake version check kdeutils-6:3.5.5-1.fc7 ---------------------- * Wed Nov 29 2006 Karsten Hopp 3.5.5-1 - rebuild with new net-snmp-libs - fix automake version check kudzu-1.2.64-1 -------------- * Wed Nov 29 2006 Bill Nottingham - 1.2.64-1 - treat qla4xxx devices as HBAs, even if their PCI class is network (#216881) - correctly set device for ttyACM USB devices (#217051, ) - don't leak fds in scsi probe (#214878, #191521, #217742) - fix segfault (#217818) libvirt-0.1.9-1.fc7 ------------------- * Wed Nov 29 2006 Daniel Veillard 0.1.9-1 - better error reporting - python bindings fixes and extensions - add support for shareable drives - add support for non-bridge style networking - hot plug device support - added support for inactive domains - API to dump core of domains - various bug fixes, cleanups and improvements - updated the localization libxslt-1.1.19-1 ---------------- * Wed Nov 29 2006 Daniel Veillard - upstream release 1.1.19 see http://xmlsoft.org/XSLT/news.html logwatch-7.3.1-7.fc7 -------------------- * Wed Nov 29 2006 Ivana Varekova 7.3.1-7 - add postfix service patch (#208909) - add vsftpd service patch (#217226) mod_auth_kerb-5.3-3 ------------------- * Wed Nov 29 2006 Joe Orton 5.3-3 - fix r->user caching (Enrico Scholz, #214207) - update to 5.3 (CVE-2006-5989, #215443) nut-2.0.4-2 ----------- * Wed Nov 29 2006 Karsten Hopp 2.0.4-2 - rebuild with new net-snmp-libs - disable nut-2.0.1-bad.patch, not required * Tue Nov 21 2006 Than Ngo - 2.0.4-1 - add IPv6 support, thanks to Dan Kope??ek (#198394) openoffice.org-1:2.1.0-5.5 -------------------------- * Wed Nov 29 2006 Caolan McNamara - 1:2.1.0-5.5 - Resolves: rhbz#217269/rhbz#190515/rhbz#212134 disable sequence by default policycoreutils-1.33.5-4.fc7 ---------------------------- * Wed Nov 29 2006 Dan Walsh 1.33.5-4 - Fixing the Makefile line again to build with LSPP support Resolves: #208838 * Wed Nov 29 2006 Dan Walsh 1.33.5-3 - Don't report errors on restorecond when file system does not support XATTRS Resolves: #217694 rhpxl-0.41-1.fc7 ---------------- * Wed Nov 29 2006 Chris Lumens 0.41-1 - Trust kudzu to give us the right video driver instead of using readDrivers to trim the list of what's available (#211977). * Mon Nov 06 2006 Adam Jackson 0.40-1 - Allow for very large resolutions. (#212695) s390utils-2:1.5.4-2.fc7 ----------------------- * Wed Nov 29 2006 Phil Knirsch 2:1.5.4-2.fc7 - Update to cmsfs-1.1.8c - Included specfile fixes from bugzilla #217718 selinux-policy-2.4.6-1.fc7 -------------------------- * Tue Nov 28 2006 Dan Walsh 2.4.6-1 - Dontaudit appending hal_var_lib files Resolves: #217452 Resolves: #217571 Resolves: #217611 Resolves: #217640 Resolves: #217725 tcpdump-14:3.9.5-1.fc7 ---------------------- * Wed Nov 29 2006 Miroslav Lichvar - 14:3.9.5-1 - split off libpcap and arpwatch (#193657) - update to 3.9.5 - force linking with system libpcap ttmkfdir-3.0.9-24.fc7 --------------------- * Thu Nov 30 2006 Lingning Zhang - 3.0.9-24.fc7 - add ttmkfdir-3.0.9-font-scale.patch to fix bug #209102. - Patch from Akira TAGOH. Broken deps for i386 ---------------------------------------------------------- freeradius - 1.1.3-1.i386 requires libsnmp.so.10 Broken deps for ppc64 ---------------------------------------------------------- freeradius - 1.1.3-1.ppc64 requires libsnmp.so.10()(64bit) Broken deps for s390 ---------------------------------------------------------- freeradius - 1.1.3-1.s390 requires libsnmp.so.10 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- freeradius - 1.1.3-1.ia64 requires libsnmp.so.10()(64bit) Broken deps for x86_64 ---------------------------------------------------------- freeradius - 1.1.3-1.x86_64 requires libsnmp.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- freeradius - 1.1.3-1.ppc requires libsnmp.so.10 Broken deps for s390x ---------------------------------------------------------- freeradius - 1.1.3-1.s390x requires libsnmp.so.10()(64bit) From docs-list at fedoralinks.org Thu Nov 30 10:58:44 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Thu, 30 Nov 2006 04:58:44 -0600 Subject: Call for Updates - Release Notes Message-ID: <456EB964.7040506@fedoralinks.org> In about 1 week we would like to push a snapshot of the release notes beats on the wiki to translation. If you have a beat on the wiki please try to get any updates completed by Dec 7 23:59 UTC. The snapshot should be going to Translation by Dec 9 23:59 UTC. Translations will be due back 10 days later (Dec 19 23:59 UTC) for packaging and publishing. -- Robert 'Bob' Jensen * * http://fedoraproject.org/wiki/BobJensen gpg fingerprint: F9F4 7243 4243 0043 2C45 97AF E8A4 C3AE 42EB 0BC6 Fedora Docs Projects FDSCo http://fedoraproject.org/wiki/DocsProject From chitlesh at fedoraproject.org Thu Nov 30 13:59:21 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 30 Nov 2006 14:59:21 +0100 Subject: KDE4 being packaged In-Reply-To: <13dbfe4f0611291549u65e15e32k30a3c5ce097cf3d6@mail.gmail.com> References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280734m7b42c8b9peab8f314096836e7@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> <13dbfe4f0611291549u65e15e32k30a3c5ce097cf3d6@mail.gmail.com> Message-ID: <13dbfe4f0611300559s547dedegaef3757f78c9a24f@mail.gmail.com> > Right now, I'm building kdelibs4 with: > QA_RPATHS=0x0003; export QA_RPATHS; rpmbuild -ba kdelibs4.spec I'll successfully mock kdelibs4. Build.log and rpms can be found here: http://tux.u-strasbg.fr/~chit/KDE4_mock/ chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Thu Nov 30 14:50:39 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 30 Nov 2006 15:50:39 +0100 Subject: KDE4 being packaged In-Reply-To: <13dbfe4f0611300559s547dedegaef3757f78c9a24f@mail.gmail.com> References: <13dbfe4f0611271316p7b11f9a0k1abcd9c8df6688ab@mail.gmail.com> <13dbfe4f0611280801i29e9d40al7437256c76925f97@mail.gmail.com> <13dbfe4f0611280819t3f7ee5b3j80ff4e2382eff632@mail.gmail.com> <13dbfe4f0611281247m79f20095pfcd45340012e4d11@mail.gmail.com> <13dbfe4f0611291549u65e15e32k30a3c5ce097cf3d6@mail.gmail.com> <13dbfe4f0611300559s547dedegaef3757f78c9a24f@mail.gmail.com> Message-ID: <13dbfe4f0611300650j1ddfdba5h6a7c2283065697d0@mail.gmail.com> On 11/30/06, Chitlesh GOORAH wrote: QA_RPATHS=0x0003; export QA_RPATHS; rpmbuild -ba x.spec Thanks that works; Some screenshots: 1. http://www.flickr.com/photo_zoom.gne?id=310286171&size=o 2. http://www.flickr.com/photo_zoom.gne?id=310276750&size=o 3. http://www.flickr.com/photo_zoom.gne?id=310286173&size=o TODO: - update snapshot - add kde4.desktop file to /usr/share/xsessions - add ThanNgo's patches - [...] I'm uploading those rpms right now. for the moment to login: on GDM session - failsafe terminal /opt/kde4/bin/startkde chitlesh -- http://clunixchit.blogspot.com From jfrieben at freesurf.fr Thu Nov 30 15:39:16 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 30 Nov 2006 16:39:16 +0100 (CET) Subject: Xorg 7.2 RC2 and rawhide Message-ID: <57815.172.182.91.15.1164901156.squirrel@arlette.freesurf.fr> >Adam Jackson ajax at nwnk.net >Mon Nov 13 15:51:56 PST 2006 > >I've seen distressingly few reports against 7.2. It looks good to >me, but I have notoriously poor judgement, so I would appreciate >other people with poor judgement chiming in and saying it works >for them as well. Referring to the above citation from the Xorg mailing list I wonder wether/when we can expect Xorg 7.2 RC2 [RC3] to hit rawhide. It would multiply feedback before the final release dramatically, so it's a pity that we are still stuck with Xorg 7.1. Anything in the pipeline? From bernie at develer.com Thu Nov 30 16:04:05 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 30 Nov 2006 17:04:05 +0100 Subject: rawhide report: 20061128 changes In-Reply-To: <200611290345.kAT3jTHs000417@hs20-bc2-6.build.redhat.com> References: <200611290345.kAT3jTHs000417@hs20-bc2-6.build.redhat.com> Message-ID: <456F00F5.4030209@develer.com> buildsys at redhat.com wrote: > ncurses-5.5-25.20060715.fc7 > --------------------------- > * Mon Nov 27 2006 Miroslav Lichvar 5.5-25.20060715 > - move libncurses and some terminfo entries out of /usr > - drop console symlink and sparc terminfo entries Package installation fails if you have /usr mounted separately because /lib/terminfo/v/vt-220 is hardlinked with /lib/terminfo/v/vt220 . -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From sundaram at fedoraproject.org Thu Nov 30 18:43:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Dec 2006 00:13:04 +0530 Subject: Call for Updates - Release Notes In-Reply-To: <456EB964.7040506@fedoralinks.org> References: <456EB964.7040506@fedoralinks.org> Message-ID: <456F2638.5000500@fedoraproject.org> Robert 'Bob' Jensen wrote: > In about 1 week we would like to push a snapshot of the release notes > beats on the wiki to translation. If you have a beat on the wiki please > try to get any updates completed by Dec 7 23:59 UTC. The snapshot should > be going to Translation by Dec 9 23:59 UTC. Translations will be due > back 10 days later (Dec 19 23:59 UTC) for packaging and publishing. > Is this a errata for the FC6 release notes? We would need more information. Rahul From sundaram at fedoraproject.org Thu Nov 30 18:44:22 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Dec 2006 00:14:22 +0530 Subject: The "recent" proposals. In-Reply-To: References: Message-ID: <456F2686.5030804@fedoraproject.org> Ahm ed wrote: > Hello, I am Ahmed. I just wanted to voice to the devs my excitement at > the recent news (recent for me) of merging extras and core, as well as > the news about pungi and pilgrim (especially about pilgrim). I think > these tools will provide us with more versatility. I have also heard of > a sysv replacement that may or may not be in FC7 (any news?) also sounds > like an excellent advancement. I understand that many of these are > currently just being tossed around and I wanted to voice that yes indeed > these tools all sound very useful and I believe they would be an > excellent addition to fedora core (or is it Fedora Complete?). In > general I believe you guys have done a great job, and I applaud your > resolve in continuing to provide an excellent distro based on FOSS and > free of the binary proprietary junk that other distros are starting to > pump into the kernel. (I have found that it leads to far greater > stability.) Good luck to you all and thank you for your hard work. > > p.s. Sorry for the lack of order in this, I am currently swamped w/ > school, I just felt it necessary to voice my support for the recent > "developments". Thank you for the feedback and support. If you would like to contribute, take a look at http://fedoraproject.org/wiki/HelpWanted Rahul From ajackson at redhat.com Thu Nov 30 18:48:10 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 30 Nov 2006 13:48:10 -0500 Subject: Xorg 7.2 RC2 and rawhide In-Reply-To: <57815.172.182.91.15.1164901156.squirrel@arlette.freesurf.fr> References: <57815.172.182.91.15.1164901156.squirrel@arlette.freesurf.fr> Message-ID: <1164912491.7683.80.camel@localhost.localdomain> On Thu, 2006-11-30 at 16:39 +0100, Joachim Frieben wrote: > >Adam Jackson ajax at nwnk.net > >Mon Nov 13 15:51:56 PST 2006 > > > >I've seen distressingly few reports against 7.2. It looks good to > >me, but I have notoriously poor judgement, so I would appreciate > >other people with poor judgement chiming in and saying it works > >for them as well. > > Referring to the above citation from the Xorg mailing list I wonder > wether/when we can expect Xorg 7.2 RC2 [RC3] to hit rawhide. It would > multiply feedback before the final release dramatically, so it's a pity > that we are still stuck with Xorg 7.1. Anything in the pipeline? Yeah, working on it. I think rawhide has all the libs updated anyway, just no server yet. - ajax From jfrieben at freesurf.fr Thu Nov 30 19:59:53 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 30 Nov 2006 20:59:53 +0100 (CET) Subject: Xorg 7.2 RC2 and rawhide In-Reply-To: <1164912491.7683.80.camel@localhost.localdomain> References: <1164912491.7683.80.camel@localhost.localdomain> Message-ID: <1226.89.50.36.24.1164916793.squirrel@arlette.freesurf.fr> > Yeah, working on it. I think rawhide has all the libs updated anyway, > just no server yet. > > - ajax Well, there is more missing than just the server, I guess, e.g. driver updates which should fix some of the pending bugs including the "savage" bug reported (and solved) in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 but still affecting both "FC6" and "rawhide". Thanks for your info! From overholt at redhat.com Thu Nov 30 22:20:00 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 30 Nov 2006 17:20:00 -0500 Subject: Eclipse on Linux Distributions eclipse.org project approved Message-ID: <20061130222000.GM16792@redhat.com> Hi, At EclipseCon 2006, Ben Konrath and I met Matt Ryan from Novell. We talked about the general issues hurting Eclipse adoption in the Linux and FOSS communities. Matt took the lead out of our conversations and along with ?Eclipse people? from other major distros, we proposed [1] the ?Eclipse on Linux Distributions? project at eclipse.org. Last week, the project had its Creation Review [2] and it was a success! I?d like to see most, if not all, of the work that our group is doing ? ChangeLog, autotools, specfile editing, packaging tools, etc. ? get more visibility as part of this project. We?re also looking forward to collaborating with developers and packagers from other distributions. Having this work under the eclipse.org umbrella will give it better exposure and hopefully help in achieving our goal of bringing Eclipse technology to Linux distribution users. As usual, everyone is invited to join in our work. We hope to see some of you on IRC (#fedora-java), fedora-devel-java-list at redhat.com, the upstream mailing lists (linux-distros-dev at eclipse.org ... at least for now - it may change to be linuxtools-dev at eclipse.org but that's yet to be finalized), etc. Thanks, Andrew [1] http://www.eclipse.org/proposals/linux-distro/ [2] http://www.eclipse.org/proposals/linux-distro/LinuxDistrosCreationReview.pdf