From lightsolphoenix at gmail.com Sat Sep 1 00:16:54 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Fri, 31 Aug 2007 20:16:54 -0400 Subject: KDE 4.0 Delayed Message-ID: <200708312016.55058.lightsolphoenix@gmail.com> I imagine everyone here either knows this or will know this at some point, but I'll mention it for those that don't; the KDE 4.0 release is being pushed back to December. I guess this means that F8 should ship KDE 3.5 after all. http://lists.kde.org/?l=kde-devel&m=118856887429944&w=2 -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From markg85 at gmail.com Sat Sep 1 00:26:36 2007 From: markg85 at gmail.com (Mark) Date: Sat, 1 Sep 2007 02:26:36 +0200 Subject: KDE 4.0 Delayed In-Reply-To: <200708312016.55058.lightsolphoenix@gmail.com> References: <200708312016.55058.lightsolphoenix@gmail.com> Message-ID: <6e24a8e80708311726h64520da0i7032d31c4d461489@mail.gmail.com> well.. judging from the kde 4 status threads it was nearly 0% likely that it would make it's way in Fedora but now with this news i (sadly) expect it to be left out of KDE 8. But than again i expect it to be in Fedora 9!! From bbbush.yuan at gmail.com Sat Sep 1 01:23:34 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 1 Sep 2007 09:23:34 +0800 Subject: Python 3.0 In-Reply-To: <1188589985.4464.14.camel@localhost.localdomain> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <1188589864.3151.13.camel@ignacio.lan> <1188589985.4464.14.camel@localhost.localdomain> Message-ID: <76e72f800708311823p25c1a8aud5d71fb818ba49c4@mail.gmail.com> Migrating from python 2.4 => 2.5 is easier than 2.5 => 2.6 => 3.0 but vendors do not want to migrate, so we cannot recommend both plone and fedora together. Is it fedora who is unfriendly to python fans? no, but... (it happens) -- bbbush ^_^ From debarshi.ray at gmail.com Sat Sep 1 02:27:04 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 1 Sep 2007 07:57:04 +0530 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <1188577744.4620.2.camel@localhost.localdomain> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> Message-ID: <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> > Just do > > gconftool-2 --type string --set /apps/gnome-screensaver/lock_dialog_theme system > > to get that dialog. I just did it, and it looks really nice on my Rawhide desktop. > We turned it off by default, since some people were confused by it. How can one be confused by such a thing? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From notting at redhat.com Sat Sep 1 03:52:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 31 Aug 2007 23:52:07 -0400 Subject: changelogs in packages and space use In-Reply-To: <46D88A99.7050707@filteredperception.org> References: <1188528437.27085.304.camel@cutter> <20070831202559.GA15707@nostromo.devel.redhat.com> <46D88A99.7050707@filteredperception.org> Message-ID: <20070901035207.GA13798@nostromo.devel.redhat.com> Douglas McClendon (dmc.fedora at filteredperception.org) said: > So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed* > saved?) only helps for one release cycle. Then for a release cycle or two > you have to sacrifice shipping every language in the world on the same cd, > and go with regional spins. That's my point, though - how is a release method where each release you offer *less* functionality to the user a good thing? Bill From tgl at redhat.com Sat Sep 1 04:30:11 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 01 Sep 2007 00:30:11 -0400 Subject: changelogs in packages and space use In-Reply-To: <20070901035207.GA13798@nostromo.devel.redhat.com> References: <1188528437.27085.304.camel@cutter> <20070831202559.GA15707@nostromo.devel.redhat.com> <46D88A99.7050707@filteredperception.org> <20070901035207.GA13798@nostromo.devel.redhat.com> Message-ID: <7499.1188621011@sss.pgh.pa.us> Bill Nottingham writes: > That's my point, though - how is a release method where each release > you offer *less* functionality to the user a good thing? Are we offering *less* functionality, or *different* functionality? There's certainly a zero-sum game involved when you're discussing what you can put on a given-size CD. I'm +1 for dropping blow-by-blow changelogs out of that limited footprint --- the people who care about those details probably care about access to the source code too, and I don't see anyone insisting that we ship full source on livecd. I'm also +1 for the discipline of packing as much functionality as possible onto limited space. But detailed changelogs seem to me to not qualify as critical functionality. regards, tom lane From rc040203 at freenet.de Sat Sep 1 04:41:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 01 Sep 2007 06:41:27 +0200 Subject: changelogs in packages and space use In-Reply-To: <20070901035207.GA13798@nostromo.devel.redhat.com> References: <1188528437.27085.304.camel@cutter> <20070831202559.GA15707@nostromo.devel.redhat.com> <46D88A99.7050707@filteredperception.org> <20070901035207.GA13798@nostromo.devel.redhat.com> Message-ID: <1188621687.20314.11.camel@mccallum.corsepiu.local> On Fri, 2007-08-31 at 23:52 -0400, Bill Nottingham wrote: > Douglas McClendon (dmc.fedora at filteredperception.org) said: > > So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed* > > saved?) only helps for one release cycle. Then for a release cycle or two > > you have to sacrifice shipping every language in the world on the same cd, > > and go with regional spins. > > That's my point, though - how is a release method where each release > you offer *less* functionality to the user a good thing? Of cause not, but ... All this is based on the assumption "media technology doesn't evolve". Fact is it does. We once had "Linux on 5 floppies", then "Linux on CD", then "Linux on X CDs", then "Linux on DVD", now we're gradually approaching the "Linux on online media-age". That said, I don't see much sense in spinning "crippled distros on ". Instead we should have a very small "minimum installation/loader ", which should redirect users either to further "add-on " or directly send them on-line. In an ideal world, I would like to see something like a set of CDs/DVDs, one of which is "the installer CD", and a loosely coupled set of CDs containing all packages Fedora consists of. Not a "Gnome-edition", not a "KDE-edition", not a "gamers', engineer's or whatever edition". Actually, I thought that this would be what you (rel-eng) guys would be working on. Ralf From abo at kth.se Sat Sep 1 05:14:10 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 01 Sep 2007 07:14:10 +0200 Subject: Fedora Crypto Consolidation Project In-Reply-To: <200708220832.32831.sgrubb@redhat.com> References: <200708220832.32831.sgrubb@redhat.com> Message-ID: <1188623650.16306.11.camel@home.alexander.bostrom.net> On Wed, 2007-08-22 at 08:32 -0400, Steve Grubb wrote: > If the crypto boundary was completely contained within the library and the > library has been FIPS 140-2 certified, many applications will gain the cert > just by linking to it. Its that simple. I assume that for an app to get the implicit certification, all the crypto libraries it links to needs to be certified. Let's see... These might contain crypto code: MIT Kerberos IcedTea (Free Sun Java) glibc Wrong? Anything else? (I'm sure there's plenty of it in the distro...) /abo From abo at kth.se Sat Sep 1 05:53:24 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 01 Sep 2007 07:53:24 +0200 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <200708220832.32831.sgrubb@redhat.com> References: <200708220832.32831.sgrubb@redhat.com> Message-ID: <1188626004.16306.49.camel@home.alexander.bostrom.net> This reminds me... I've been meaning to propose a Better Kerberos Integration Project. Is there anyone else out there who's dissatisfied with the lack of simple and pervasive integration and support for Kerberos in the free operating systems, applications and protocols? If there's any interest, I'm happy to expand on what Kerberos is, why it's a good thing and where the support is lacking. In many ways, I'm afraid it would be about catching up to Microsoft again, because they grabbed Kerberos and ran with it, integrating it everywhere, because they understand its usefulness, but I'm sure talented free software hackers can do it even better. :) /abo From buildsys at redhat.com Sat Sep 1 07:01:08 2007 From: buildsys at redhat.com (Build System) Date: Sat, 1 Sep 2007 03:01:08 -0400 Subject: rawhide report: 20070901 changes Message-ID: <200709010701.l81718x0021764@porkchop.devel.redhat.com> Removed package kdemultimedia-extras Removed package kdeartwork-extras Removed package kdegraphics-extras Removed package sturmbahnfahrer Updated Packages: anaconda-11.3.0.26-1 -------------------- * Fri Aug 31 2007 Jeremy Katz - 11.3.0.26-1 - Some kickstart fixes (clumens, #269721) - More libraries (clumens) fedora-logos-7.92.0-3.fc8 ------------------------- * Fri Aug 31 2007 Jeremy Katz - 7.92.0-3 - fix grub splash image to be an actual image mkinitrd-6.0.14-1.fc8 --------------------- * Fri Aug 31 2007 Peter Jones - 6.0.14-1 - Don't probe loop devices as boot disks or in mkblkdevs - Minor performance improvements. pykickstart-1.10-1.fc8 ---------------------- * Fri Aug 31 2007 Chris Lumens 1.10-1 - Add network --ipv6=. system-config-firewall-1.0.5-3.fc8 ---------------------------------- * Fri Aug 31 2007 Thomas Woerner 1.0.5-3 - fixed problem if IP*TABLES_MODULES is not set in config files * Fri Aug 31 2007 Thomas Woerner 1.0.5-2 - fixed lokkit problem if selinux configuration is not available (rhbz#269601) * Thu Aug 30 2007 Thomas Woerner 1.0.5-1 - more translations - fixed IPsec description - fixed po file generation to use xgettext only tk-1:8.4.15-4.fc8 ----------------- * Fri Aug 31 2007 Jeremy Katz - 1:8.4.15-4 - BR gawk to unbreak things * Thu Aug 09 2007 Marcela Maslanova - 1:8.4.15-3 - check licence, build for mass rebuild * Thu Aug 09 2007 Marcela Maslanova - 1:8.4.15-2 - Resolves: rhbz#251411 Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 grig - 0.7.2-2.fc8.i386 requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE libreadline-java - 0.8.0-19.fc8.i386 requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.i386 requires libedit.so.0 moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) grig - 0.7.2-2.fc8.x86_64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) pygsl-devel - 0.9.1-4.fc8.x86_64 requires gsl.devel pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 grig - 0.7.2-2.fc8.ppc requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp libreadline-java - 0.8.0-19.fc8.ppc requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.ppc requires libedit.so.0 moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.ppc requires gsl.devel pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 grig - 0.7.2-2.fc8.ppc64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From benny+usenet at amorsen.dk Sat Sep 1 07:34:29 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 01 Sep 2007 09:34:29 +0200 Subject: Services automaticly change firewall rules to open access to themselfs. References: <46C9BF64.9040103@hi.is> <1187628043.7085.106.camel@localhost.localdomain> <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> Message-ID: >>>>> "AP" == Arthur Pemberton writes: AP> On 8/31/07, Alexander Bostr?m wrote: >> That would be a checkbox. >> >> [ ] Trust all enabled services. >> >> Basically, what this means is, "don't allow incoming traffic except >> where root says it's ok", which might sometimes be what you want to >> achieve. >> AP> By the way, I still think that tis is a good idea. It would be nicer if the bind() failed in the application. At least the application would have a chance at telling the user what went wrong, instead of just not working properly. /Benny From opensource at till.name Sat Sep 1 08:12:00 2007 From: opensource at till.name (Till Maas) Date: Sat, 1 Sep 2007 10:12:00 +0200 Subject: changelogs in packages and space use In-Reply-To: <1188621687.20314.11.camel@mccallum.corsepiu.local> References: <1188528437.27085.304.camel@cutter> <20070901035207.GA13798@nostromo.devel.redhat.com> <1188621687.20314.11.camel@mccallum.corsepiu.local> Message-ID: <200709011012.08472.opensource@till.name> On Saturday 01 September 2007 06:41:27 Ralf Corsepius wrote: > We once had "Linux on 5 floppies", then "Linux on CD", then "Linux on X > CDs", then "Linux on DVD", now we're gradually approaching the "Linux on > online media-age". > > That said, I don't see much sense in spinning "crippled distros on > ". Instead we should have a very small "minimum I guess this is true for Western Europe and other developed countries, but Fedora targets for a world-wide domination and e.g. in development or newly industrialising countries, there may not be cheap access to even DVDs or usb devices of a useful capacity. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pemboa at gmail.com Sat Sep 1 08:12:47 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 1 Sep 2007 03:12:47 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: References: <46C9BF64.9040103@hi.is> <1187628043.7085.106.camel@localhost.localdomain> <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> Message-ID: <16de708d0709010112k45e67f27g1bdb851d324dcd8f@mail.gmail.com> On 9/1/07, Benny Amorsen wrote: > >>>>> "AP" == Arthur Pemberton writes: > > AP> On 8/31/07, Alexander Bostr?m wrote: > > >> That would be a checkbox. > >> > >> [ ] Trust all enabled services. > >> > >> Basically, what this means is, "don't allow incoming traffic except > >> where root says it's ok", which might sometimes be what you want to > >> achieve. > >> > > AP> By the way, I still think that tis is a good idea. > > It would be nicer if the bind() failed in the application. At least > the application would have a chance at telling the user what went > wrong, instead of just not working properly. > > > /Benny Starting services don't normally give error messages. Certainly not if you use s-c-services -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From abo at kth.se Sat Sep 1 08:33:40 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 01 Sep 2007 10:33:40 +0200 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: References: <46C9BF64.9040103@hi.is> <1187628043.7085.106.camel@localhost.localdomain> <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> Message-ID: <1188635620.16306.97.camel@home.alexander.bostrom.net> On Sat, 2007-09-01 at 09:34 +0200, Benny Amorsen wrote: > It would be nicer if the bind() failed in the application. At least > the application would have a chance at telling the user what went > wrong, instead of just not working properly. I think using SELinux instead of ip(6)tables here would achieve that. /abo From pertusus at free.fr Sat Sep 1 08:38:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Sep 2007 10:38:07 +0200 Subject: Python 3.0 In-Reply-To: <20070831143511.23586a7f@weaponx.rchland.ibm.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> Message-ID: <20070901083807.GA25737@free.fr> On Fri, Aug 31, 2007 at 02:35:11PM -0500, Josh Boyer wrote: > On Fri, 31 Aug 2007 15:02:37 -0400 > Ignacio Vazquez-Abrams wrote: > > > Anyone working on a package for this yet? > > > > http://www.python.org/download/releases/3.0/ > > You really want to have a parallel installable alpha package of > python? I think that would be a no-no. If we allowed that, the we > should allow a parallel installable compat-python package. Do we disallow that? In my opinion there shouldn't be a possibility for anybody to disallow a free software package to enter devel. And a package of enough quality to enter stable releases. -- Pat From nicolas.mailhot at laposte.net Sat Sep 1 09:08:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 01 Sep 2007 11:08:41 +0200 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <1188626004.16306.49.camel@home.alexander.bostrom.net> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> Message-ID: <1188637721.14108.9.camel@rousalka.dyndns.org> Le samedi 01 septembre 2007 ? 07:53 +0200, Alexander Bostr?m a ?crit : > This reminds me... > > I've been meaning to propose a Better Kerberos Integration Project. Is > there anyone else out there who's dissatisfied with the lack of simple > and pervasive integration and support for Kerberos in the free operating > systems, applications and protocols? IMHO kerberos app support is the wrong level to tackle. We all know active directory is just kerberos+ldap, we've been shipping kerberos & ldap infrastructure for years (and the fedora directory server is supposed to be even better), and yet somehow few (if any) ever use it. Contrast it with the widely reviled active directory infrastructure every windows user just uses by default. Making kerberos+ldap a breeze to setup should be the priority. Once there users will pressure app writers themselves to get kerberos support built-in (and Red Hat has erred spending many years maintaining its own kerberized forks and ignoring the setup problem). This BTW would also kill all the poor man ldap clones app writers are so fond of (because it's easier writting your own contact db implementation than explaining to users how to setup an actual ldap server) -- 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 pertusus at free.fr Sat Sep 1 09:09:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Sep 2007 11:09:19 +0200 Subject: List of sponsors cannot be seen by outsiders In-Reply-To: <46D34E09.7050105@redhat.com> References: <20070827220940.GD24132@free.fr> <46D34E09.7050105@redhat.com> Message-ID: <20070901090919.GB25737@free.fr> On Mon, Aug 27, 2007 at 05:19:53PM -0500, Mike McGrath wrote: > Patrice Dumas wrote: >> Hello, >> >> Linked from >> http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored >> there is a List of sponsors >> https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html >> but one need an account to see the page... >> >> Chicken and egg situation... >> >> Moreover somebody with knowledge of the new review process urls shuold >> edit the page. >> > > Not quite chicken and egg. You don't need to be in the group to read the > group, you just need an account. I was not thinking about the sponsors group, but the cvsextras group. There is a remark "List of sponsors is only visible to contributions with a Fedora Account." Does people need to be in cvsextras to look at the page, or not in any group? I was under the impression that ' contributions with a Fedora Account' was for people having signed the cla and sponsored. But it may also be for people having signed the cla only, in that case, maybe it could be said like that? -- Pat From pemboa at gmail.com Sat Sep 1 09:28:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 1 Sep 2007 04:28:00 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <1188635620.16306.97.camel@home.alexander.bostrom.net> References: <46C9BF64.9040103@hi.is> <1187628043.7085.106.camel@localhost.localdomain> <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> Message-ID: <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> On 9/1/07, Alexander Bostr?m wrote: > On Sat, 2007-09-01 at 09:34 +0200, Benny Amorsen wrote: > > > It would be nicer if the bind() failed in the application. At least > > the application would have a chance at telling the user what went > > wrong, instead of just not working properly. > > I think using SELinux instead of ip(6)tables here would achieve that. > > /abo Not everyone uses SELinux. Everyone (almost) uses iptables. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From abo at kth.se Sat Sep 1 09:42:26 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 01 Sep 2007 11:42:26 +0200 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <1188637721.14108.9.camel@rousalka.dyndns.org> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> Message-ID: <1188639746.16306.102.camel@home.alexander.bostrom.net> On Sat, 2007-09-01 at 11:08 +0200, Nicolas Mailhot wrote: > > Making kerberos+ldap a breeze to setup should be the priority. Once > there users will pressure app writers themselves to get kerberos support > built-in (and Red Hat has erred spending many years maintaining its own > kerberized forks and ignoring the setup problem). Absolutely. I guess I should start making a list of all places where I think setup could be improved, integrated with LDAP and so on. /abo From gilboad at gmail.com Sat Sep 1 10:15:45 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 01 Sep 2007 13:15:45 +0300 Subject: icewm devel cvs - sources file In-Reply-To: <20070830111650.3b21b0c7@ghistelwchlohm.scrye.com> References: <46D55D4F.8010102@linux-kernel.at> <20070830111650.3b21b0c7@ghistelwchlohm.scrye.com> Message-ID: <1188641745.21800.41.camel@gilboa-home-dev.localdomain> On Thu, 2007-08-30 at 11:16 -0600, Kevin Fenzi wrote: > On Wed, 29 Aug 2007 13:49:35 +0200 > oliver at linux-kernel.at (Oliver Falk) wrote: > > > Can please someone kick the sources file from icewm... > > > > [oliver at gosa icewm]$ file sources > > sources: gzip compressed data, from Unix, last modified: Tue Aug 7 > > 07:12:36 2007, max compression > > > > [oliver at gosa icewm]$ gunzip -c sources | tar tfv -|tail > > -rw-rw-r-- mark/mark 1004 2007-08-07 07:12 > > icewm-1.2.32/lib/winoptions -rw-rw-r-- mark/mark 1241 2007-08-07 > > 07:12 icewm-1.2.32/README.wm-session > > -rw-rw-r-- mark/mark 268 2007-08-07 07:12 > > icewm-1.2.32/sysdep.os2 -rw-r--r-- mark/mark 4281 2007-08-07 > > 07:12 icewm-1.2.32/Makefile.in -rwxrwxr-x mark/mark 5603 > > 2007-08-07 07:12 icewm-1.2.32/install-sh -rw-rw-r-- mark/mark > > 3424 2007-08-07 07:12 icewm-1.2.32/icewm.spec -rw-rw-r-- > > mark/mark 577 2007-08-07 07:12 icewm-1.2.32/icewm.lsm > > -rw-rw-r-- mark/mark 607 2007-08-07 07:12 > > icewm-1.2.32/aclocal.m4 -rwxrwxr-x mark/mark 416280 2007-08-07 > > 07:12 icewm-1.2.32/configure -rw-rw-r-- mark/mark 4509 > > 2007-08-07 07:12 icewm-1.2.32/Makefile > > > > Maybe I can do that myself, but if so, I would like to get permission > > to do so first! > > Yikes. I can fix it... but where is the maintainer? Have you tried > contacting them? > > I will send them an email now too. > > kevin > > > > Thx, > > Oliver Sorry for the late reply. Was in a vacation for a couple of days with lousy 'net connection. Problem fixed in FC-6 and F-7. (-devel build waiting for broken deps. [1]) Kevin, Thanks for head's up & help. - Gilboa [1] Error: Missing Dependency: libpolkit-grant.so.1 is needed by package PolicyKit-gnome... From email.ahmedkamal at googlemail.com Sat Sep 1 10:23:26 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 1 Sep 2007 13:23:26 +0300 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <1188639746.16306.102.camel@home.alexander.bostrom.net> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> <1188639746.16306.102.camel@home.alexander.bostrom.net> Message-ID: <3da3b5b40709010323m468046f1h5a2a41bbab5e62a9@mail.gmail.com> I think http://www.freeipa.org/ is a very good first step to make setting up a kerberized network easy and managing it painless. Can we build over that, and start integrating more services. On 9/1/07, Alexander Bostr?m wrote: > > On Sat, 2007-09-01 at 11:08 +0200, Nicolas Mailhot wrote: > > > > Making kerberos+ldap a breeze to setup should be the priority. Once > > there users will pressure app writers themselves to get kerberos support > > built-in (and Red Hat has erred spending many years maintaining its own > > kerberized forks and ignoring the setup problem). > > Absolutely. > > I guess I should start making a list of all places where I think setup > could be improved, integrated with LDAP and so on. > > /abo > > > -- > 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 mschwendt.tmp0701.nospam at arcor.de Sat Sep 1 10:28:16 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 1 Sep 2007 12:28:16 +0200 Subject: rpms/g-wrap/FC-6 Makefile, 1.2, 1.3 g-wrap-1.9.6-shaddup.patch, 1.2, 1.3 g-wrap-info.patch, 1.2, 1.3 g-wrap.spec, 1.41, 1.42 sources, 1.7, 1.8 .cvsignore, 1.6, 1.7 dead.package, 1.1, NONE In-Reply-To: <200708311959.l7VJxFwU013074@cvs-int.fedora.redhat.com> References: <200708311959.l7VJxFwU013074@cvs-int.fedora.redhat.com> Message-ID: <20070901122816.92043e71.mschwendt.tmp0701.nospam@arcor.de> On Fri, 31 Aug 2007 15:59:15 -0400, Xavier LAMIEN (laxathom) wrote: > Author: laxathom > > Update of /cvs/pkgs/rpms/g-wrap/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13040/FC-6 > > Modified Files: > .cvsignore > Added Files: > Makefile g-wrap-1.9.6-shaddup.patch g-wrap-info.patch > g-wrap.spec sources > Removed Files: > dead.package > Log Message: > Imported new source > +Name: g-wrap > +Version: 1.9.9 > +Release: 3%{?dist} Removing dead.package files in old dists actually is a dangerous thing. In FC-6 g-wrap is a core (!) package. Your upgrade breaks gnucash with ABI-incompatible sonames. For now it is blacklisted. From eric.tanguy at univ-nantes.fr Sat Sep 1 11:07:23 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 01 Sep 2007 13:07:23 +0200 Subject: Compilation problem with rawhide In-Reply-To: References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> Message-ID: <1188644843.3089.0.camel@bureau.maison> Le vendredi 31 ao?t 2007 ? 11:48 -0500, Rex Dieter a ?crit : > Tanguy Eric wrote: > > > It seems this not the problem. > > The problem is : > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../upnp/inc -I./inc > > -I../threadutil/inc > > -I../ixml/inc -I./src/inc -pthread -O2 -g -pipe -Wall > > -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > > -march=i386 > > -mtune=generic -fasynchronous-unwind-tables -Os -MT > > src/genlib/net/http/libupnp_la-httpreadwrite.lo -MD -MP -MF > > src/genlib/net/http/.deps/libupnp_la-httpreadwrite.Tpo -c > > src/genlib/net/http/httpreadwrite.c -fPIC -DPIC -o > > src/genlib/net/http/.libs/libupnp_la-httpreadwrite.o > > src/genlib/net/http/httpreadwrite.c: In function 'http_SendMessage': > > src/genlib/net/http/httpreadwrite.c:352: error: expected identifier > > before '(' token > > make[3]: *** [src/genlib/net/http/libupnp_la-httpreadwrite.lo] Error 1 > > > > The same srpm compile fine with F-7 so i can't understand where the > > problem come from. > > Look in httpreadwrite.c, I'll bet there is an "open" call near/before > line 352. You'll likely need to patch to change > open > to > (open) > > glibc macro/posix ickiness goin on. > > -- Rex > Thanks Rex, I tried to change : if( Instr && Instr->IsVirtualFile ) Fp = virtualDirCallback.open( filename, UPNP_READ ); else Fp = fopen( filename, "rb" ); by if( Instr && Instr->IsVirtualFile ) Fp = virtualDirCallback.(open)( filename, UPNP_READ ); else Fp = fopen( filename, "rb" ); but the same error stil remain. An idea ? Thanks Eric From jkeating at redhat.com Sat Sep 1 11:09:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 1 Sep 2007 07:09:19 -0400 Subject: rawhide report: 20070901 changes In-Reply-To: <200709010701.l81718x0021764@porkchop.devel.redhat.com> References: <200709010701.l81718x0021764@porkchop.devel.redhat.com> Message-ID: <20070901070919.10bbbddd@ender> On Sat, 1 Sep 2007 03:01:08 -0400 Build System wrote: > pykickstart-1.10-1.fc8 > ---------------------- > * Fri Aug 31 2007 Chris Lumens 1.10-1 > - Add network --ipv6=. There is a typo in this and the compose failed. Installation would have failed too. Will try to get this fixed for tomorrow's rawhide. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From abo at kth.se Sat Sep 1 11:29:01 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 01 Sep 2007 13:29:01 +0200 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <3da3b5b40709010323m468046f1h5a2a41bbab5e62a9@mail.gmail.com> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> <1188639746.16306.102.camel@home.alexander.bostrom.net> <3da3b5b40709010323m468046f1h5a2a41bbab5e62a9@mail.gmail.com> Message-ID: <1188646141.16306.106.camel@home.alexander.bostrom.net> On Sat, 2007-09-01 at 13:23 +0300, Ahmed Kamal wrote: > I think http://www.freeipa.org/ is a very good first step to make > setting up a kerberized network easy and managing it painless. Can we > build over that, and start integrating more services. Yes, sounds like a plan. Thanks for reminding me about that project! /abo From jakub at redhat.com Sat Sep 1 11:32:37 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 1 Sep 2007 07:32:37 -0400 Subject: Compilation problem with rawhide In-Reply-To: <1188644843.3089.0.camel@bureau.maison> References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> <1188644843.3089.0.camel@bureau.maison> Message-ID: <20070901113237.GO2063@devserv.devel.redhat.com> On Sat, Sep 01, 2007 at 01:07:23PM +0200, Tanguy Eric wrote: > I tried to change : > > if( Instr && Instr->IsVirtualFile ) > Fp = virtualDirCallback.open( filename, UPNP_READ ); > else > Fp = fopen( filename, "rb" ); > > by > > if( Instr && Instr->IsVirtualFile ) > Fp = virtualDirCallback.(open)( filename, UPNP_READ ); > else > Fp = fopen( filename, "rb" ); > > but the same error stil remain. Use Fp = (virtualDirCallback.open)( filename, UPNP_READ ); or Fp = (*virtualDirCallback.open)( filename, UPNP_READ ); Jakub From ivazqueznet at gmail.com Sat Sep 1 11:34:05 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 01 Sep 2007 07:34:05 -0400 Subject: Python 3.0 In-Reply-To: <1188586957.3151.7.camel@ignacio.lan> References: <1188586957.3151.7.camel@ignacio.lan> Message-ID: <1188646446.3151.23.camel@ignacio.lan> http://ivazquez.livejournal.com/2436.html -- Ignacio Vazquez-Abrams -------------- 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 fedoraproject.org Sat Sep 1 11:41:19 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 1 Sep 2007 07:41:19 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-01 Message-ID: <20070901114119.1B8A9152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 16 cobbler-0.6.1-2.fc6 codeblocks-1.0-0.27.20070828svn4413.fc6 emacs-vm-8.0.3.495-3.fc6 gallery2-2.2-0.7.svn20070831.fc6 geomview-1.9.4-2.fc6 gq-1.2.2-6.fc6 icewm-1.2.32-3.fc6 koan-0.6.1-2.fc6 maxima-5.13.0-4.fc6 perl-Text-Quoted-2.02-3.fc6 NEW pharosc-8.3-1.fc6 : VLSI and ASIC Technology Standard Cell Libraries NEW php-pecl-memcache-2.1.2-1.fc6 : Extension to work with the Memcached caching daemon (!) puppet-0.23.2-1.fc6 : INVALID rebuild, not published! NEW python-boto-0.9b-1.fc6 : A simple lightweight interface to Amazon Web Services sbcl-1.0.9-1.fc6 yumex-2.0.1-1.fc6 Changes in Fedora Extras 6: cobbler-0.6.1-2.fc6 ------------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) codeblocks-1.0-0.27.20070828svn4413.fc6 --------------------------------------- * Wed Aug 29 2007 Dan Horak 1.0-0.27.20070828svn4413 - update to revision 4413 - update the License tag * Wed Aug 29 2007 Fedora Release Engineering - 1.0-0.26.20070718svn4280 - Rebuild for selinux ppc32 issue (F8). emacs-vm-8.0.3.495-3.fc6 ------------------------ * Thu Aug 30 2007 Jonathan G. Underwood - 8.0.3.495-3 - Fix problem with vm-autoloads.el RH BZ #262361 gallery2-2.2-0.7.svn20070831.fc6 -------------------------------- * Fri Aug 31 2007 John Berninger - 2.2-0.7.svn20070831 - update to 2.2.3 SVN snapshot to fix security vuln's - bz 267421 geomview-1.9.4-2.fc6 -------------------- * Mon Aug 27 2007 Rex Dieter 1.9.4-2 - BR: gawk * Mon Aug 27 2007 Rex Dieter 1.9.4-1 - geomview-1.9.4 * Sat Aug 11 2007 Rex Dieter 1.9.3-3 - License: LGPLv2+ * Mon Jul 16 2007 Rex Dieter 1.9.3-2 - geomview.desktop: Categories=-Education (#241441) gq-1.2.2-6.fc6 -------------- * Tue Aug 21 2007 Terje R?sten - 1.2.2-6 - Tag problem * Sun Aug 19 2007 Terje R?sten - 1.2.2-5 - Fix license tag * Mon Jun 25 2007 Terje R?sten - 1.2.2-4 - Fix categories in desktop file * Sun May 20 2007 Terje R?sten - 1.2.2-3 - Add auth patch icewm-1.2.32-3.fc6 ------------------ * Sat Sep 01 2007 - 1.2.32-3 - Fix missing BR: libXinerama-devel. - Fix broken source file. * Mon Aug 27 2007 - 1.2.32-2 - Fix bad %{_fedora} if/else. * Sun Aug 26 2007 - 1.2.32-1 - Fixed license tag. - Fixed F8 BR - popt-devel. - Remove APMstatus fix. - 1.2.32 * Mon Apr 09 2007 - 1.2.30-13 - APMStatus crash fix. (Icewm #1696182) koan-0.6.1-2.fc6 ---------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) maxima-5.13.0-4.fc6 ------------------- * Thu Aug 30 2007 Rex Dieter 5.13.0-4 - (re)--enable-gcl, f8+ (#256281) - fix inadvertant Obsoletes: maxima-runtime-gcl (f7) * Mon Aug 27 2007 Rex Dieter 5.13.0-3 - until it is unborked, disable gcl support, f8+ (#256281) - --with-default-lisp=sbcl (was gcl) * Sun Aug 26 2007 Rex Dieter 5.13.0-2 - rebuild against sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 5.13.0-1 - maxima-5.13.0 * Sun Aug 19 2007 Rex Dieter 5.12.99-0.5.rc2 - maxima-5.12.99rc2 * Thu Aug 09 2007 Rex Dieter 5.12.99-0.4.rc1 - maxima-5.12.99rc1 - enable langpacks: es, pt, pt_BR * Sat Jul 28 2007 Rex Dieter 5.12.0-6 - respin for sbcl-1.0.8 * Fri Jul 20 2007 Rex Dieter 5.12.0-5 - disable clisp/ppc, still awol (#166347) - respin for sbcl-1.0.7 * Thu Jul 12 2007 Rex Dieter 5.12.0-4 - enable clisp/ppc (#166347) - revert koji hack. perl-Text-Quoted-2.02-3.fc6 --------------------------- * Fri Aug 31 2007 Ralf Cors?pius - 2.02-3 - BR: perl(Test::More). - Update license tag. * Mon Mar 12 2007 Ralf Cors?pius - 2.02-2 - BR: perl(ExtUtils::MakeMaker). pharosc-8.3-1.fc6 ----------------- * Sun Jul 08 2007 Chitlesh Goorah - 8.3-1 - Initial Package php-pecl-memcache-2.1.2-1.fc6 ----------------------------- * Mon Aug 20 2007 Remi Collet 2.1.2-1 - initial RPM puppet-0.23.2-1.fc6 ------------------- * Wed Aug 22 2007 David Lutterkort - 0.23.2-1 - New version python-boto-0.9b-1.fc6 ---------------------- * Thu Aug 30 2007 Robert Scheck 0.9b-1 - Upgrade to 0.9b - Initial spec file for Fedora and Red Hat Enterprise Linux sbcl-1.0.9-1.fc6 ---------------- * Sun Aug 26 2007 Rex Dieter 1.0.9-1 - sbcl-1.0.9 * Sat Aug 25 2007 Rex Dieter 1.0.8-3 - respin (ppc32) * Fri Aug 10 2007 Rex Dieter 1.0.8-2 - ExclusiveArch: i386 (#251689) - License: BSD * Sat Jul 28 2007 Rex Dieter 1.0.8-1 - sbcl-1.0.8 * Wed Jun 27 2007 Rex Dieter 1.0.7-1 - sbcl-1.0.7 yumex-2.0.1-1.fc6 ----------------- * Wed Aug 22 2007 Tim Lauridsen - 2.0.1-1 - Release 2.0.1 * Thu Aug 16 2007 Tim Lauridsen - 2.0-1 - Release 2.0 GA - Updated license tag to apply to Fedora guidelines. * Sun Jul 08 2007 Tim Lauridsen - 1.9.11-1 - Development Release 1.9.11-1 * Sun Jul 08 2007 Tim Lauridsen - 1.9.10-2.0 - Development Release 1.9.10-2.0 * Sat Jul 07 2007 Tim Lauridsen - 1.9.10-1.0 - Development Release 1.9.10-1.0 * Tue Jun 12 2007 Tim Lauridsen - 1.9.9-1.0 - Development Release 1.9.9-1.0 * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-2.0 - Development Release 1.9.8-2.0 - Forgot to update changelog * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-1.0 - Development Release 1.9.8-1.0 * Tue May 29 2007 Tim Lauridsen - 1.9.7-1.0 - Development Release 1.9.7-1.0 * Tue Apr 17 2007 Tim Lauridsen - 1.9.6-1.0 - Development Release 1.9.6-1.0 * Tue Mar 20 2007 Tim Lauridsen - 1.9.5-1.0 - Development Release 1.9.5-1.0 * Mon Mar 19 2007 Tim Lauridsen - 1.9.4-1.0 - Development Release 1.9.4-1.0 * Fri Feb 16 2007 Tim Lauridsen - 1.9.3-1.0 - Development Release 1.9.3-1.0 * Tue Jan 30 2007 Tim Lauridsen - 1.9.2-1.1 - Development Release 1.9.2-1.1 * Mon Jan 29 2007 Tim Lauridsen - 1.9.2-1.0 - Development Release 1.9.2-1.0 * Mon Jan 08 2007 Tim Lauridsen - 1.9.2-0.1.pre1 - Development Release 1.9.2-0.1.pre1 * Sun Jan 07 2007 Tim Lauridsen - 1.9.1-1.0 - Development Release 1.9.1-1.0 From benny+usenet at amorsen.dk Sat Sep 1 12:07:17 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 01 Sep 2007 14:07:17 +0200 Subject: Services automaticly change firewall rules to open access to themselfs. References: <46C9BF64.9040103@hi.is> <1187628043.7085.106.camel@localhost.localdomain> <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> Message-ID: >>>>> "AP" == Arthur Pemberton writes: AP> Not everyone uses SELinux. Everyone (almost) uses iptables. Applications already know how to ask for incoming connections. It's generally done by calling bind(). Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless. The whole point of firewalling is to explicitly specify what should be allowed and denied. If you take away that control, there is no reason to have firewalling. /Benny From sgrubb at redhat.com Sat Sep 1 12:19:45 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 1 Sep 2007 08:19:45 -0400 Subject: Fedora Crypto Consolidation Project In-Reply-To: <1188623650.16306.11.camel@home.alexander.bostrom.net> References: <200708220832.32831.sgrubb@redhat.com> <1188623650.16306.11.camel@home.alexander.bostrom.net> Message-ID: <200709010819.45635.sgrubb@redhat.com> On Saturday 01 September 2007 01:14:10 Alexander Bostr?m wrote: > > If the crypto boundary was completely contained within the library and > > the library has been FIPS 140-2 certified, many applications will gain > > the cert just by linking to it. Its that simple. > > I assume that for an app to get the implicit certification, all the > crypto libraries it links to needs to be certified. The Fedora Project being a volunteer project has no money to pay for a certification of all these libraries. Its expensive. In addition, the certification process can last longer than any release's Fedora's support cycle. So, if Fedora is going to have certified crypto, we have to use what has already been certified and restructure things to use it. Another point I'd like to make is that simply linking against nss is not sufficient. The app also has to obey the system crypto policy. The strategy wrt crypto libraries is to 1) update the app if possible to use nss directly and then the maintainer sets the --with-nss configure option, 2) create abstraction layer so that the API of the library being linked against calls nss eventually. This also requires changing the linking but is less invasive than option 1. We probably won't be able to tackle all of Fedora. But the plan is to get the core set of apps that are used by most people. -Steve From jwboyer at jdub.homelinux.org Sat Sep 1 12:25:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 1 Sep 2007 07:25:59 -0500 Subject: Python 3.0 In-Reply-To: <20070901083807.GA25737@free.fr> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> Message-ID: <20070901072559.51664309@vader.jdub.homelinux.org> On Sat, 1 Sep 2007 10:38:07 +0200 Patrice Dumas wrote: > On Fri, Aug 31, 2007 at 02:35:11PM -0500, Josh Boyer wrote: > > On Fri, 31 Aug 2007 15:02:37 -0400 > > Ignacio Vazquez-Abrams wrote: > > > > > Anyone working on a package for this yet? > > > > > > http://www.python.org/download/releases/3.0/ > > > > You really want to have a parallel installable alpha package of > > python? I think that would be a no-no. If we allowed that, the we > > should allow a parallel installable compat-python package. > > Do we disallow that? In my opinion there shouldn't be a possibility for > anybody to disallow a free software package to enter devel. And a > package of enough quality to enter stable releases. We do. FESCo has gone over this at least twice. No parallel installable python packages have been allowed. For a very long and agonizing read, see the zope/plone thread from a year or so ago. josh From sgrubb at redhat.com Sat Sep 1 12:25:34 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 1 Sep 2007 08:25:34 -0400 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: References: <46C9BF64.9040103@hi.is> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> Message-ID: <200709010825.35407.sgrubb@redhat.com> On Saturday 01 September 2007 03:34:29 Benny Amorsen wrote: > >> Basically, what this means is, "don't allow incoming traffic except > >> where root says it's ok", which might sometimes be what you want to > >> achieve. > > AP> By the way, I still think that tis is a good idea. > > It would be nicer if the bind() failed in the application. We now have rsyslog in the distribution. It should be simple to create a configuration command that greps for iptables events and notifies the user in realtime kind of the way that setroubleshoot does. As a matter of fact, what might be even more useful is a command that watches for disk drive errors and tells the user that its starting to see the hard drive fail. But from a security point of view, I don't think its a good idea for apps to be able to punch a hole in the firewall. -Steve From jamatos at fc.up.pt Sat Sep 1 13:00:29 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 1 Sep 2007 14:00:29 +0100 Subject: Python 3.0 In-Reply-To: <20070901072559.51664309@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> Message-ID: <200709011400.29248.jamatos@fc.up.pt> On Saturday 01 September 2007 13:25:59 Josh Boyer wrote: > We do. ?FESCo has gone over this at least twice. ?No parallel > installable python packages have been allowed. ?For a very long and > agonizing read, see the zope/plone thread from a year or so ago. > > josh This is different in the sense that it refers to a software preview and not to a compat issue. This is more on the line of the long talked and proposed "branches" where some packages previews could be found. We have discussed this in several contexts, the last I remember is related with kde4, but this has appeared before related with other packages. So I think that this should be viewed in a different light. And I certainly imagine that we will have at some point python-3.x and compat-python2x (with x being 6 or even possibly 7). So this is clearly a different subject. :-) -- Jos? Ab?lio From eric.tanguy at univ-nantes.fr Sat Sep 1 14:32:45 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 01 Sep 2007 16:32:45 +0200 Subject: Compilation problem with rawhide In-Reply-To: <20070901113237.GO2063@devserv.devel.redhat.com> References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> <1188644843.3089.0.camel@bureau.maison> <20070901113237.GO2063@devserv.devel.redhat.com> Message-ID: <1188657165.2854.3.camel@bureau.maison> Le samedi 01 septembre 2007 ? 07:32 -0400, Jakub Jelinek a ?crit : > On Sat, Sep 01, 2007 at 01:07:23PM +0200, Tanguy Eric wrote: > > I tried to change : > > > > if( Instr && Instr->IsVirtualFile ) > > Fp = virtualDirCallback.open( filename, UPNP_READ ); > > else > > Fp = fopen( filename, "rb" ); > > > > by > > > > if( Instr && Instr->IsVirtualFile ) > > Fp = virtualDirCallback.(open)( filename, UPNP_READ ); > > else > > Fp = fopen( filename, "rb" ); > > > > but the same error stil remain. > > Use > Fp = (virtualDirCallback.open)( filename, UPNP_READ ); > or > Fp = (*virtualDirCallback.open)( filename, UPNP_READ ); > > Jakub > Thanks the first one do the trick. Is this problem specific to our version of the compiler because an upstream developer answer me this : "so that I can decide the best way to patch it. I would rather not patch it, because it is too weird and seems to be a problem of a specific version of the compiler. It does not happen with two different versions of gcc, namely 4.1.2 and 4.1.3 from Suse." Eric From eric.tanguy at univ-nantes.fr Sat Sep 1 06:59:42 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 01 Sep 2007 08:59:42 +0200 Subject: Compilation problem with rawhide In-Reply-To: References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> Message-ID: <1188629982.2877.1.camel@bureau.maison> Le vendredi 31 ao?t 2007 ? 11:48 -0500, Rex Dieter a ?crit : > Tanguy Eric wrote: > > > It seems this not the problem. > > The problem is : > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../upnp/inc -I./inc > > -I../threadutil/inc > > -I../ixml/inc -I./src/inc -pthread -O2 -g -pipe -Wall > > -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 > > -march=i386 > > -mtune=generic -fasynchronous-unwind-tables -Os -MT > > src/genlib/net/http/libupnp_la-httpreadwrite.lo -MD -MP -MF > > src/genlib/net/http/.deps/libupnp_la-httpreadwrite.Tpo -c > > src/genlib/net/http/httpreadwrite.c -fPIC -DPIC -o > > src/genlib/net/http/.libs/libupnp_la-httpreadwrite.o > > src/genlib/net/http/httpreadwrite.c: In function 'http_SendMessage': > > src/genlib/net/http/httpreadwrite.c:352: error: expected identifier > > before '(' token > > make[3]: *** [src/genlib/net/http/libupnp_la-httpreadwrite.lo] Error 1 > > > > The same srpm compile fine with F-7 so i can't understand where the > > problem come from. > > Look in httpreadwrite.c, I'll bet there is an "open" call near/before > line 352. You'll likely need to patch to change > open > to > (open) > > glibc macro/posix ickiness goin on. > > -- Rex > Thanks Rex, I tried to change : if( Instr && Instr->IsVirtualFile ) Fp = virtualDirCallback.open( filename, UPNP_READ ); else Fp = fopen( filename, "rb" ); by if( Instr && Instr->IsVirtualFile ) Fp = virtualDirCallback.(open)( filename, UPNP_READ ); else Fp = fopen( filename, "rb" ); but the same error stil remain. An idea ? Thanks Eric From mtasaka at ioa.s.u-tokyo.ac.jp Sat Sep 1 14:59:03 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 01 Sep 2007 23:59:03 +0900 Subject: Compilation problem with rawhide In-Reply-To: <1188657165.2854.3.camel@bureau.maison> References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> <1188644843.3089.0.camel@bureau.maison> <20070901113237.GO2063@devserv.devel.redhat.com> <1188657165.2854.3.camel@bureau.maison> Message-ID: <46D97E37.8010705@ioa.s.u-tokyo.ac.jp> Tanguy Eric wrote, at 09/01/2007 11:32 PM +9:00: > Le samedi 01 septembre 2007 ? 07:32 -0400, Jakub Jelinek a ?crit : >> On Sat, Sep 01, 2007 at 01:07:23PM +0200, Tanguy Eric wrote: >>> I tried to change : >>> >>> if( Instr && Instr->IsVirtualFile ) >>> Fp = virtualDirCallback.open( filename, UPNP_READ ); >>> else >>> Fp = fopen( filename, "rb" ); >>> >>> by >>> >>> if( Instr && Instr->IsVirtualFile ) >>> Fp = virtualDirCallback.(open)( filename, UPNP_READ ); >>> else >>> Fp = fopen( filename, "rb" ); >>> >>> but the same error stil remain. >> Use >> Fp = (virtualDirCallback.open)( filename, UPNP_READ ); >> or >> Fp = (*virtualDirCallback.open)( filename, UPNP_READ ); >> >> Jakub >> > > Thanks the first one do the trick. > Is this problem specific to our version of the compiler because an > upstream developer answer me this : > "so that I can decide the best way to patch it. I would rather not patch > it, because it is too weird and seems to be a problem of a specific > version of the compiler. It does not happen with two different versions > of gcc, namely 4.1.2 and 4.1.3 from Suse." AFAIK, this is due to glibc side change. Mamoru From markg85 at gmail.com Sat Sep 1 15:05:26 2007 From: markg85 at gmail.com (Mark) Date: Sat, 1 Sep 2007 17:05:26 +0200 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> Message-ID: <6e24a8e80709010805i649aadc1rc621d0581b73ac00@mail.gmail.com> > I just did it, and it looks really nice on my Rawhide desktop. I just did it as well and the theme didn't change at all here.. just plain default (ugly) > > We turned it off by default, since some people were confused by it. > > How can one be confused by such a thing? Exactly what i'm wondering.. i'm confused that someone can get confused by that ^_- Will there be any changes for this in Fedora 8? From lsof at nodata.co.uk Sat Sep 1 15:17:28 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 01 Sep 2007 17:17:28 +0200 Subject: changelogs in packages and space use In-Reply-To: <1188528437.27085.304.camel@cutter> References: <1188528437.27085.304.camel@cutter> Message-ID: <1188659848.3615.0.camel@sb-home> Am Donnerstag, den 30.08.2007, 22:47 -0400 schrieb seth vidal: > > 1yr old What about one year older than the lifetime of the package? On RHEL I'd like to see the changelogs for the entire life of the platform plus that year (so that the changelogs aren't empty on a new install). From lsof at nodata.co.uk Sat Sep 1 15:17:28 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 01 Sep 2007 17:17:28 +0200 Subject: changelogs in packages and space use In-Reply-To: <1188528437.27085.304.camel@cutter> References: <1188528437.27085.304.camel@cutter> Message-ID: <1188659848.3615.0.camel@sb-home> Am Donnerstag, den 30.08.2007, 22:47 -0400 schrieb seth vidal: > > 1yr old What about one year older than the lifetime of the package? On RHEL I'd like to see the changelogs for the entire life of the platform plus that year (so that the changelogs aren't empty on a new install). From a.badger at gmail.com Sat Sep 1 15:30:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 01 Sep 2007 08:30:50 -0700 Subject: Python 3.0 In-Reply-To: <20070901072559.51664309@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> Message-ID: <46D985AA.5000405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh Boyer wrote: > On Sat, 1 Sep 2007 10:38:07 +0200 > Patrice Dumas wrote: > >> On Fri, Aug 31, 2007 at 02:35:11PM -0500, Josh Boyer wrote: >>> On Fri, 31 Aug 2007 15:02:37 -0400 >>> Ignacio Vazquez-Abrams wrote: >>> >>>> Anyone working on a package for this yet? >>>> >>>> http://www.python.org/download/releases/3.0/ >>> You really want to have a parallel installable alpha package of >>> python? I think that would be a no-no. If we allowed that, the we >>> should allow a parallel installable compat-python package. >> Do we disallow that? In my opinion there shouldn't be a possibility for >> anybody to disallow a free software package to enter devel. And a >> package of enough quality to enter stable releases. > > We do. FESCo has gone over this at least twice. No parallel > installable python packages have been allowed. For a very long and > agonizing read, see the zope/plone thread from a year or so ago. > We don't disallow it. (current, ongoing, made into policy) We have (almost) disallowed it. (One time decision, made in the past, specific circumstances) I make this distinction because it's a definite case-by-case basis. Jeremy as the python maintainer wanted to outright ban compat-python. The zope/plone maintainer wanted to have a compat-python so that zope/plone could run. FESCo disagreed as to whether we should ban or not. We could all agree that the compat-python maintainer would have to show that they had both the time and the ability to maintain such a package for it to be allowed in. This is for several reasons: 1) python is a "framework": other modules extend its functionality using the API it provides and would need separate packaging for the compat-python package. It you wanted docutils for both the mainline and compat python, you would need to have two binary packages, one for each version. 2) python is central to our distro. If parallel installing was not done correctly, it could cause breakage for a lot of thing. FESCo decided that we needed to ask the zope plone maintainer to make an honest decision of whether he had the time to devote to maintaining the compat-python package for the life of the distro releases he wanted to support. He had, meanwhile, decided that he wanted to take one of the other options: maintain python2.4 and zope/plone in a 3rd party repo until zope/plone could run on Fedora. So in the end, we actually did not have to make a decision. After some thinking on this, I think we should be whole heartedly for a parallel installable python3.0 *on rawhide*. Why? 1)python3.0 is a major break from python2.x. It's almost guaranteed that every python package we have is going to break. 2) Python upstream is planning to release 2.6.x and 3.x packages in parallel for a reasonably long time. We need to gain experience with python3.x so we know whether we want to jump to 3.x when it comes out, parallel install python-2.6 and python-3.x, or stick with python-2.6 until the distro as a whole has a chance to migrate to 3.x. Having a parallel installable package on rawhide allows us to make a better decision when we need to decide how we're going to move to python-3.x for the rest of the distribution. One of the arguments against compat-python packages were that they contradicted our nature as a "bleeding edge distro" where we should be working to port code forward from python2.4 to python2.5 instead of creating python2.4 packages as a crutch for software to rely upon. That argument does not apply to python3.0 packages. As for letting python3 into a release, I think that depends on some of the same factors as the compat- package. Who wants to maintain it? Does that person (or team of people) have the time to deal with issues? One thing about python3 being a preview instead of a compat package is that the job of a compat package is to make things run. If it breaks, it's a direct contradiction of its reason for existing. A preview package is to show people what the future is going to look like. If it breaks, it hurts one of its purposes (allowing people to make their code run on the new version) but doesn't compromise all of its value in the same way as a compat package. - -Toshio - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG2YWqX6yAic2E7kgRApj3AJ9/fhiycIa9uRl7XQpaJvGsl4o3wgCeMhzE sOZ2J4wVb62DiPCjKz7+91Q= =vHh7 -----END PGP SIGNATURE----- From bruno at wolff.to Sat Sep 1 15:32:42 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 1 Sep 2007 10:32:42 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <200709010825.35407.sgrubb@redhat.com> References: <46C9BF64.9040103@hi.is> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <200709010825.35407.sgrubb@redhat.com> Message-ID: <20070901153242.GB16761@wolff.to> On Sat, Sep 01, 2007 at 08:25:34 -0400, Steve Grubb wrote: > > We now have rsyslog in the distribution. It should be simple to create a > configuration command that greps for iptables events and notifies the user in > realtime kind of the way that setroubleshoot does. As a matter of fact, what > might be even more useful is a command that watches for disk drive errors and > tells the user that its starting to see the hard drive fail. For the disk drive part of this, it already exists. smartd does self tests on disks and logs the messages. These messages get reported by logwatch in an email message once a day. From bruno at wolff.to Sat Sep 1 15:29:42 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 1 Sep 2007 10:29:42 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: References: <1187628864.3382.27.camel@localhost.localdomain> <1187629942.6784.0.camel@sb-home> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> Message-ID: <20070901152942.GA16761@wolff.to> On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen wrote: > > Administrators sometimes want to limit which traffic can reach > applications, and perhaps limit the risk when accidentally starting > applications. Automating firewall setup makes that useless. That is probably the main reason. And having apps undo restrictions seems like a really really bad idea. Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces. I think the idea of having some way to help people who want a service available to the internet at large or some local ip addresses is a good idea, but it needs to be an add on step that can be skipped, not some invisible change behind the scenes. From pemboa at gmail.com Sat Sep 1 17:05:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 1 Sep 2007 12:05:00 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070901152942.GA16761@wolff.to> References: <1187628864.3382.27.camel@localhost.localdomain> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> Message-ID: <16de708d0709011005l387b38e2y674641aac9b91255@mail.gmail.com> On 9/1/07, Bruno Wolff III wrote: > On Sat, Sep 01, 2007 at 14:07:17 +0200, > Benny Amorsen wrote: > > > > Administrators sometimes want to limit which traffic can reach > > applications, and perhaps limit the risk when accidentally starting > > applications. Automating firewall setup makes that useless. > > That is probably the main reason. And having apps undo restrictions seems > like a really really bad idea. So being able to easily disable this wouldn't be enough? > Plus I have no confidence that apps can properly rewrite iptables rules > correctly. iptables setups can have complications which will make it > hard to change them. I have used subroutines for checking reserved ip > ranges and have had services configured to only be available to local > ip addresses or specific interfaces. This is something that would/should work only if you're using system-config-firewall > I think the idea of having some way to help people who want a service > available to the internet at large or some local ip addresses is a good > idea, but it needs to be an add on step that can be skipped, not some > invisible change behind the scenes. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From skvidal at fedoraproject.org Sat Sep 1 19:09:10 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 01 Sep 2007 15:09:10 -0400 Subject: changelogs in packages and space use In-Reply-To: <1188659848.3615.0.camel@sb-home> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> Message-ID: <1188673750.29226.47.camel@cutter> On Sat, 2007-09-01 at 17:17 +0200, nodata wrote: > Am Donnerstag, den 30.08.2007, 22:47 -0400 schrieb seth vidal: > > > 1yr old > > What about one year older than the lifetime of the package? > > On RHEL I'd like to see the changelogs for the entire life of the > platform plus that year (so that the changelogs aren't empty on a new > install). This has nothing to do with RHEL. This is only about fedora. -sv From pertusus at free.fr Sat Sep 1 19:23:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Sep 2007 21:23:52 +0200 Subject: Python 3.0 In-Reply-To: <20070901072559.51664309@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> Message-ID: <20070901192352.GA27309@free.fr> On Sat, Sep 01, 2007 at 07:25:59AM -0500, Josh Boyer wrote: > > We do. FESCo has gone over this at least twice. No parallel > installable python packages have been allowed. For a very long and > agonizing read, see the zope/plone thread from a year or so ago. Hopefully, Toshio mail shows that this wasn't the kind of decision you describe, something like a one way decision of FESCo, but instead a reasoned decision taking into account the time people could devote to the compat- package. I don't know if it matters, but if FESCo can limit the packages one can add to fedora with technical reasons accepted by the packagers themselves, then I don't think Fedora is for me. And I hope that other contributors value their freedom of packaging whatever they want which is within the scope of Fedora. -- Pat From jwboyer at jdub.homelinux.org Sat Sep 1 19:35:26 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 1 Sep 2007 14:35:26 -0500 Subject: Python 3.0 In-Reply-To: <20070901192352.GA27309@free.fr> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> Message-ID: <20070901143526.0a56ca1d@vader.jdub.homelinux.org> On Sat, 1 Sep 2007 21:23:52 +0200 Patrice Dumas wrote: > On Sat, Sep 01, 2007 at 07:25:59AM -0500, Josh Boyer wrote: > > > > We do. FESCo has gone over this at least twice. No parallel > > installable python packages have been allowed. For a very long and > > agonizing read, see the zope/plone thread from a year or so ago. > > Hopefully, Toshio mail shows that this wasn't the kind of > decision you describe, something like a one way decision of > FESCo, but instead a reasoned decision taking into account > the time people could devote to the compat- package. Yes, Toshio is correct in that it was a per-case basis for a compat-python package. Not a unilateral decision. josh From pertusus at free.fr Sat Sep 1 19:37:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Sep 2007 21:37:50 +0200 Subject: Python 3.0 In-Reply-To: <20070901192352.GA27309@free.fr> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> Message-ID: <20070901193750.GB27309@free.fr> On Sat, Sep 01, 2007 at 09:23:52PM +0200, Patrice Dumas wrote: > On Sat, Sep 01, 2007 at 07:25:59AM -0500, Josh Boyer wrote: > > > > We do. FESCo has gone over this at least twice. No parallel > > installable python packages have been allowed. For a very long and > > agonizing read, see the zope/plone thread from a year or so ago. > > Hopefully, Toshio mail shows that this wasn't the kind of > decision you describe, something like a one way decision of > FESCo, but instead a reasoned decision taking into account > the time people could devote to the compat- package. > I don't know if it matters, but if FESCo can limit the > packages one can add to fedora with technical reasons without > accepted by the packagers themselves, then I don't think > Fedora is for me. And I hope that other contributors value > their freedom of packaging whatever they want which is > within the scope of Fedora. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From opensource at till.name Sat Sep 1 19:41:39 2007 From: opensource at till.name (Till Maas) Date: Sat, 1 Sep 2007 21:41:39 +0200 Subject: changelogs in packages and space use In-Reply-To: <1188673750.29226.47.camel@cutter> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> <1188673750.29226.47.camel@cutter> Message-ID: <200709012141.49915.opensource@till.name> On Saturday 01 September 2007 21:09:10 seth vidal wrote: > On Sat, 2007-09-01 at 17:17 +0200, nodata wrote: > > On RHEL I'd like to see the changelogs for the entire life of the > > platform plus that year (so that the changelogs aren't empty on a new > > install). > > This has nothing to do with RHEL. This is only about fedora. Maybe he also meant Fedora EPEL, Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dmc.fedora at filteredperception.org Sat Sep 1 19:43:37 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 01 Sep 2007 14:43:37 -0500 Subject: changelogs in packages and space use In-Reply-To: <20070901035207.GA13798@nostromo.devel.redhat.com> References: <1188528437.27085.304.camel@cutter> <20070831202559.GA15707@nostromo.devel.redhat.com> <46D88A99.7050707@filteredperception.org> <20070901035207.GA13798@nostromo.devel.redhat.com> Message-ID: <46D9C0E9.3070703@filteredperception.org> Bill Nottingham wrote: > Douglas McClendon (dmc.fedora at filteredperception.org) said: >> So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed* >> saved?) only helps for one release cycle. Then for a release cycle or two >> you have to sacrifice shipping every language in the world on the same cd, >> and go with regional spins. > > That's my point, though - how is a release method where each release > you offer *less* functionality to the user a good thing? I guess the rest of my reply that you didn't quote, failed to make an impression. I consider it in the language of economics and utility. Pain will be felt during the decision to remove languages or other actual functionality. That pain will, in general, tend to cause more thought towards other decisions that could be made, that would keep the size down, without losing actual functionality. In the absence of having a clear 700M bottom edge, that pain, leading to those thoughts, will never happen, and bloat will happen unrestrained, thus at a faster pace. Sort of like how the 4th ammendment slows the descent into fascism. Sure, it seems inevitable that with technological progress, the 4th ammendment, just like the 700MB fully functional distro, will fall by the wayside. But the longer it is there, and annoying people cling to the value of it, the slower the actual descent into hell. -dmc From sundaram at fedoraproject.org Sat Sep 1 19:50:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 02 Sep 2007 01:20:14 +0530 Subject: Python 3.0 In-Reply-To: <20070901192352.GA27309@free.fr> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> Message-ID: <46D9C276.60103@fedoraproject.org> Patrice Dumas wrote: I > don't know if it matters, but if FESCo can limit the > packages one can add to fedora with technical reasons > accepted by the packagers themselves, then I don't think > Fedora is for me. If you want to consider the broader impact of things, there are things like alternative kernels or kernel modules or compatibility libraries etc that are being excluded or being considered for exclusion by reasons other than just the willingness of package maintainers. This isn't something new and we shouldn't be pretending that it is. Rahul From pertusus at free.fr Sat Sep 1 19:59:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 1 Sep 2007 21:59:17 +0200 Subject: Python 3.0 In-Reply-To: <46D9C276.60103@fedoraproject.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> Message-ID: <20070901195916.GC27309@free.fr> On Sun, Sep 02, 2007 at 01:20:14AM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > I >> don't know if it matters, but if FESCo can limit the packages one can add >> to fedora with technical reasons >> accepted by the packagers themselves, then I don't think >> Fedora is for me. > > If you want to consider the broader impact of things, there are things like > alternative kernels or kernel modules or compatibility libraries etc that > are being excluded or being considered for exclusion by reasons other than > just the willingness of package maintainers. This isn't something new and > we shouldn't be pretending that it is. I am not saying that the willingness of package maintainers should be enough to have a package in. But technical reasons, implementation or quality should guide the rejection of the package, not FESCo willingness. FESCo of course can make a final decision, but only when there is indeed a disagreement and a side has a sound rational. -- Pat From bruno at wolff.to Sat Sep 1 19:23:59 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 1 Sep 2007 14:23:59 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <16de708d0709011005l387b38e2y674641aac9b91255@mail.gmail.com> References: <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709011005l387b38e2y674641aac9b91255@mail.gmail.com> Message-ID: <20070901192359.GA28479@wolff.to> On Sat, Sep 01, 2007 at 12:05:00 -0500, Arthur Pemberton wrote: > On 9/1/07, Bruno Wolff III wrote: > > On Sat, Sep 01, 2007 at 14:07:17 +0200, > > Benny Amorsen wrote: > > > > > > Administrators sometimes want to limit which traffic can reach > > > applications, and perhaps limit the risk when accidentally starting > > > applications. Automating firewall setup makes that useless. > > > > That is probably the main reason. And having apps undo restrictions seems > > like a really really bad idea. > > So being able to easily disable this wouldn't be enough? I don't think so. I thought making it easy for people to shoot themselves in the foot was the Microsoft way. > > Plus I have no confidence that apps can properly rewrite iptables rules > > correctly. iptables setups can have complications which will make it > > hard to change them. I have used subroutines for checking reserved ip > > ranges and have had services configured to only be available to local > > ip addresses or specific interfaces. > > This is something that would/should work only if you're using > system-config-firewall And how is the code going to determine that? From ajackson at redhat.com Sat Sep 1 19:54:34 2007 From: ajackson at redhat.com (Adam Jackson) Date: Sat, 01 Sep 2007 15:54:34 -0400 Subject: ubuntu bulletproof x In-Reply-To: <46D75259.8070208@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> Message-ID: <1188676474.1175.720.camel@localhost.localdomain> On Thu, 2007-08-30 at 18:27 -0500, Douglas McClendon wrote: > Dave Airlie wrote: > > Really if you have to ask the user you've already lost.... > > > > The main use this gives is you can let a user try the binary driver, and > > if it tanks, you can use the GUI to go back to the open source or vice > > versa, > > > > Really though a simple ordering like: > > 1. Users current xorg.conf > > 2. No x.org conf - default driver > > 3. Try another driver in list (like fglrx or radeon) > > 4. Try vesa. > > 5. lose. > > > > I'm not sure what asking the user in-between really gives you.. > > RTFA... > > " > One of the most impressive new features in Ubuntu's BulletProof-X > implementation is support for reading monitor settings from a Windows > driver CD. "Unfortunately, it doesn't work to select just any of the > generic monitors, so users may find they need to trial-and-error a > solution. Fortunately, there is a cool new feature?Add Model which > allows users to add a new monitor by using the Windows driver CD that > comes with their monitor," Harrington writes. "This uses a script to > parse the Windows *.inf file to get the hsync, vsync, edid, dpms, and > other info to update the database locally." > " Hilariously, they're using inf2mondb.py for this. You know, the one msw wrote like five years ago, that's in our hwdata CVS, and that we use to construct /usr/share/hwdata/MonitorsDB. The whole reason we're _not_ using this very much - and that I've effectively stopped updating MonitorsDB - is because the inf files don't give you useful information. They give you sync ranges and that's about it. So you end up in some pretty hilarious situations, because X prefers width over height, so even though your monitor's 1600x1200, the sync range is big enough to fit 1680x1050, so you'll try to fit that, and lose. There does happen to be a variable in inf2mondb that's named 'edid', but it's not actually the full EDID block. It's a tuple of the EISA vendor ID and a model number. This, it turns out, is not useful for configuration. So while Bryce might have read the script with the best of intentions, he clearly hasn't tried to use it in anger. So yeah, hooray, they have a feature that doesn't work. Good for them. Now, you can get most of the way to right by just adding maximum pixel clock to the available configuration options in xorg.conf's Monitor section, which fixes the width problem I mentioned above. I've (very, very slowly) been pushing s-c-d in this direction, which is why it now hides the big brutal list of vendor/model monitor combos and only shows generic sizes by default, so it can (eventually) compute the sync ranges and max pixel clock from the size and the appropriate timing formula for the display type. It still gets some things wrong and I happily accept patches, in particular it won't actually write out Option "MaxPixClock" anywhere. But it's a way more correct approach than what the article describes. If I were being cynical, I'd say a large part of the reason they'll be moderately successful at this whole 'bulletproof' thing is due to work I've already put in to fixing autoconfiguration within X itself, and that the press releases are just so much propaganda. Don't get me wrong, Fedora sucks at self-publicity, we should do better, but all I see in that project is prettier UI and not technical correctness. If you do it _right_, you don't ever have to admit failure. Asking for the inf file is admitting failure. - ajax From ajackson at redhat.com Sat Sep 1 19:57:25 2007 From: ajackson at redhat.com (Adam Jackson) Date: Sat, 01 Sep 2007 15:57:25 -0400 Subject: rawhide report: 20070830 changes In-Reply-To: <46D87388.9030100@fedoraproject.org> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> Message-ID: <1188676645.1175.722.camel@localhost.localdomain> On Sat, 2007-09-01 at 01:31 +0530, Rahul Sundaram wrote: > Build System wrote: > > > > New package java-1.7.0-icedtea > > IcedTea Runtime Environment > > Good to see this. Is there any chance we can provide this for Fedora 7? That seems like a lot of work for little gain. I would much prefer the IcedTea developers spend their time on making it really great for F8, instead of making it mediocre for both F8 and F7. - ajax From jwboyer at jdub.homelinux.org Sat Sep 1 20:23:13 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 1 Sep 2007 15:23:13 -0500 Subject: rawhide report: 20070830 changes In-Reply-To: <1188676645.1175.722.camel@localhost.localdomain> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> <1188676645.1175.722.camel@localhost.localdomain> Message-ID: <20070901152313.080ac26c@vader.jdub.homelinux.org> On Sat, 01 Sep 2007 15:57:25 -0400 Adam Jackson wrote: > On Sat, 2007-09-01 at 01:31 +0530, Rahul Sundaram wrote: > > Build System wrote: > > > > > > New package java-1.7.0-icedtea > > > IcedTea Runtime Environment > > > > Good to see this. Is there any chance we can provide this for Fedora 7? > > That seems like a lot of work for little gain. I would much prefer the > IcedTea developers spend their time on making it really great for F8, > instead of making it mediocre for both F8 and F7. Agreed. Very much so. josh From sundaram at fedoraproject.org Sat Sep 1 20:26:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 02 Sep 2007 01:56:46 +0530 Subject: rawhide report: 20070830 changes In-Reply-To: <1188676645.1175.722.camel@localhost.localdomain> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> <1188676645.1175.722.camel@localhost.localdomain> Message-ID: <46D9CB06.30303@fedoraproject.org> Adam Jackson wrote: > On Sat, 2007-09-01 at 01:31 +0530, Rahul Sundaram wrote: >> Build System wrote: >>> New package java-1.7.0-icedtea >>> IcedTea Runtime Environment >> Good to see this. Is there any chance we can provide this for Fedora 7? > > That seems like a lot of work for little gain. I would much prefer the > IcedTea developers spend their time on making it really great for F8, > instead of making it mediocre for both F8 and F7 There are already Fedora 7 SRPMS available. Why would putting it in the repository make it mediocre for Fedora 8? Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Sep 1 20:55:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 1 Sep 2007 22:55:10 +0200 Subject: changelogs in packages and space use In-Reply-To: <200709012141.49915.opensource@till.name> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> <1188673750.29226.47.camel@cutter> <200709012141.49915.opensource@till.name> Message-ID: <20070901225510.b831776d.mschwendt.tmp0701.nospam@arcor.de> On Sat, 1 Sep 2007 21:41:39 +0200, Till Maas wrote: > On Saturday 01 September 2007 21:09:10 seth vidal wrote: > > On Sat, 2007-09-01 at 17:17 +0200, nodata wrote: > > > > On RHEL I'd like to see the changelogs for the entire life of the > > > platform plus that year (so that the changelogs aren't empty on a new > > > install). > > > > This has nothing to do with RHEL. This is only about fedora. > > Maybe he also meant Fedora EPEL, Doesn't matter. Basically, every package maintainer is free to drop irrelevant changelog entries from a spec file when they become old -- unless a policy forbids that. And many packages really contain dozens of non-interesting entries, such as - update to 1.2.3 - rebuilt - update to 1.2.2 - rebuilt - rebuilt - update to 1.2.1 - rebuilt - sync with devel - minor spec changes - update to 1.2.0 ... - mass-rebuild - rebuilt - patch merged upstream <-- in a comment from 1999 - uh? - update to 0.3.0 which go back several years. In 2007, nobody has any interest in whether a package was at 0.3.0 eight years ago or whether the packager at that time had to patch an early release every week because of lack of code stability. It also doesn't matter whether a package started with a different packager, because the majority of spec files are straight-forward to write from scratch. Perhaps only if over time somebody has created a spec file of extra-ordinary size and complexity credits are due. But solely based on reading a spec changelog one usually cannot see who has written exactly what lines in the file. For the user, the interesting entries are those that comment on - differences between the package as it was included on distribution media and later official updates, - all comments on patches, which are still included in the package, and - comments on past packaging mistakes/pitfalls, which shall be avoided in the future (preferably these are inline comments, though). Everything other than than and older than that is likely of very limited value. From dmc.fedora at filteredperception.org Sat Sep 1 21:03:49 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 01 Sep 2007 16:03:49 -0500 Subject: ubuntu bulletproof x In-Reply-To: <1188676474.1175.720.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> Message-ID: <46D9D3B5.6080305@filteredperception.org> Adam Jackson wrote: > If I were being cynical, I'd say a large part of the reason they'll be > moderately successful at this whole 'bulletproof' thing is due to work > I've already put in to fixing autoconfiguration within X itself, and > that the press releases are just so much propaganda. Don't get me > wrong, Fedora sucks at self-publicity, we should do better, but all I > see in that project is prettier UI and not technical correctness. If > you do it _right_, you don't ever have to admit failure. Asking for the > inf file is admitting failure. I suspect you'll tell me why I'm wrong- But aren't there (a significant number of) situations where autodetect fails, and in fact due to hardware limitations can't succeed, but the process of the user specifying the monitor type, and info, from the driver CD, will cause success? Even if those situations account for 1/10,000 users, those are precisely the cases that need to be covered to market something as "bulletproof". Now of course, it won't solve the problem of the user getting confused and using the wrong CD for the monitor... -dmc From s.adam at diffingo.com Sat Sep 1 21:38:56 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sat, 01 Sep 2007 17:38:56 -0400 Subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use) In-Reply-To: <20070901225510.b831776d.mschwendt.tmp0701.nospam@arcor.de> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> <1188673750.29226.47.camel@cutter> <200709012141.49915.opensource@till.name> <20070901225510.b831776d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1188682736.29069.15.camel@Diffingo.localdomain> On Sat, 2007-09-01 at 22:55 +0200, Michael Schwendt wrote: >[snip] > And many packages really contain dozens > of non-interesting entries, such as > > - update to 1.2.3 > - rebuilt > - update to 1.2.2 > - rebuilt > - rebuilt > - update to 1.2.1 > - rebuilt > - sync with devel > - minor spec changes > - update to 1.2.0 > ... > - mass-rebuild > - rebuilt > - patch merged upstream <-- in a comment from 1999 - uh? > - update to 0.3.0 >[snip] Reading this reminded me of something - It's really annoying to have to download in many cases 100-200MB of packages to find that the changelog contained 'rebuild' or some other minor change that might not affect you at all. Many people have a cap on bandwidth so it's a shame to waste that 200MB, not to mention that time for those on dial-up. A configurable option in Pirut that would display the changelog entries of a package from the currently installed version to the updated version in the 'Update Details' window would be very useful. I'm just not sure how hard it would be to integrate into Pirut / if the metadata contains that information so I'll say sorry in advance if this is completely unfeasible/unreasonable. A workaround would be deltaRPMs in which case that 200MB becomes something more like 10MB, but even then the changelog view is still nice ;) Regards, Stewart From mschwendt.tmp0701.nospam at arcor.de Sat Sep 1 21:58:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 1 Sep 2007 23:58:33 +0200 Subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use) In-Reply-To: <1188682736.29069.15.camel@Diffingo.localdomain> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> <1188673750.29226.47.camel@cutter> <200709012141.49915.opensource@till.name> <20070901225510.b831776d.mschwendt.tmp0701.nospam@arcor.de> <1188682736.29069.15.camel@Diffingo.localdomain> Message-ID: <20070901235833.177aacfb.mschwendt.tmp0701.nospam@arcor.de> On Sat, 01 Sep 2007 17:38:56 -0400, Stewart Adam wrote: > Reading this reminded me of something - It's really annoying to have to > download in many cases 100-200MB of packages to find that the changelog > contained 'rebuild' or some other minor change that might not affect you > at all. Many people have a cap on bandwidth so it's a shame to waste > that 200MB, not to mention that time for those on dial-up. It may be a _required_ rebuild, e.g. due to changes in the compiler or libraries, and the changelog just doesn't give any details. What should not happen is what has happened recently. Packagers rebuilding their packages for FC-6 with just an increased release value "to keep NVR in sync" with the mass-rebuild in devel, or package rebuilds for the old dists for just an updated "License" field. I agree that such rebuilds are annoying (especially when they trigger .rpmsave/.rpmnew actions). In general, IMHO, packagers should refrain from doing "rebuilds without details in changelog" in stable branches of the distribution. For devel, such rebuilds are normal (although the packager could also explain the need for the rebuild when it is not just a trial-and-error rebuild against the latest build env). From mackay_d at bellsouth.net Sun Sep 2 02:13:52 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Sat, 01 Sep 2007 21:13:52 -0500 Subject: Python 3.0 In-Reply-To: <46D9C276.60103@fedoraproject.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> Message-ID: <1188699232.24368.12.camel@vorpal.macdev.com> On Sun, 2007-09-02 at 01:20 +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > I > > don't know if it matters, but if FESCo can limit the > > packages one can add to fedora with technical reasons > > accepted by the packagers themselves, then I don't think > > Fedora is for me. > > If you want to consider the broader impact of things, there are things > like alternative kernels or kernel modules or compatibility libraries > etc that are being excluded or being considered for exclusion by reasons > other than just the willingness of package maintainers. This isn't > something new and we shouldn't be pretending that it is. And, perhaps FESCO would feel differently about the impact of things if THEY relied upon Fedora. I refer to minutes from one of the FESCO meetings where they discussed the issue. The point was raised that Fedora Infrastructure utilized Zope. But, the counter was that Fedora Infrastructure servers use RHEL5, so no problem. Sounds like the U. S. Congress making sure that they aren't impacted by their own decisions. Dave From sundaram at fedoraproject.org Sun Sep 2 02:15:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 02 Sep 2007 07:45:12 +0530 Subject: Python 3.0 In-Reply-To: <1188699232.24368.12.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> Message-ID: <46DA1CB0.7080509@fedoraproject.org> David G. Mackay wrote: > > And, perhaps FESCO would feel differently about the impact of things if > THEY relied upon Fedora. I refer to minutes from one of the FESCO > meetings where they discussed the issue. The point was raised that > Fedora Infrastructure utilized Zope. But, the counter was that Fedora > Infrastructure servers use RHEL5, so no problem. Sounds like the U. S. > Congress making sure that they aren't impacted by their own decisions. Fedora infrastructure team is not the same group as FESCo. Fedora infrastructure team runs Fedora or RHEL depending on their needs. That has nothing to do with FESCo. Rahul From vonbrand at inf.utfsm.cl Sun Sep 2 02:26:07 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 01 Sep 2007 22:26:07 -0400 Subject: changelogs in packages and space use In-Reply-To: <46D82F15.40108@redhat.com> References: <1188528437.27085.304.camel@cutter> <1188540071.31789.169.camel@localhost.localdomain> <1188540873.27085.396.camel@cutter> <1188541817.6422.370.camel@mccallum.corsepiu.local> <1188541965.27085.400.camel@cutter> <20070831104634.aa4ae768.dcantrell@redhat.com> <46D82F15.40108@redhat.com> Message-ID: <10646.1188699967@laptop13.inf.utfsm.cl> Eric Sandeen wrote: > David Cantrell wrote: > > > Arbitrarily deciding to remove all changelog entries older than 1 > > year is stupid. For some packages you'll end up with one entry (or > > none!) and for some packages you probably won't make a dent > > (kernel?). ;-) > It seems reasonable to me, as a simple starting point, to ask > maintainers to trim changelogs to information that is relevant to that > %{VERSION}. (maybe last 2 versions). Ideally that changelog would > contain documentation for all patches still carried, and go back to the > changelog entry that bumped the version (or 2). Perhaps if that version > bump caused patches to be removed, that should also be in the changelog, > with rationale ("patch FOO removed, now upstream"). Problem is that I've got changelog entries like: - Update to new version - Carry patch NN forward - Fix SPEC for guidelines - New/changed configuration file XYZ - ... You can't just keep it all or none, and editing out "now uninteresting bits" and keeping all elsewhere makes the exercise rather pointless IMHO. -- 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 pemboa at gmail.com Sun Sep 2 03:30:12 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 1 Sep 2007 22:30:12 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070901192359.GA28479@wolff.to> References: <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709011005l387b38e2y674641aac9b91255@mail.gmail.com> <20070901192359.GA28479@wolff.to> Message-ID: <16de708d0709012030g5a77b08cl417dd46c52d098ad@mail.gmail.com> On 9/1/07, Bruno Wolff III wrote: > On Sat, Sep 01, 2007 at 12:05:00 -0500, > Arthur Pemberton wrote: > > On 9/1/07, Bruno Wolff III wrote: > > > On Sat, Sep 01, 2007 at 14:07:17 +0200, > > > Benny Amorsen wrote: > > > > > > > > Administrators sometimes want to limit which traffic can reach > > > > applications, and perhaps limit the risk when accidentally starting > > > > applications. Automating firewall setup makes that useless. > > > > > > That is probably the main reason. And having apps undo restrictions seems > > > like a really really bad idea. > > > > So being able to easily disable this wouldn't be enough? > > I don't think so. I thought making it easy for people to shoot themselves > in the foot was the Microsoft way. I do not see a parallel here, please explain > > > Plus I have no confidence that apps can properly rewrite iptables rules > > > correctly. iptables setups can have complications which will make it > > > hard to change them. I have used subroutines for checking reserved ip > > > ranges and have had services configured to only be available to local > > > ip addresses or specific interfaces. > > > > This is something that would/should work only if you're using > > system-config-firewall > > And how is the code going to determine that? By having the init script ask s-c-firewall to open the port as has been suggested. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jwboyer at jdub.homelinux.org Sun Sep 2 03:43:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 1 Sep 2007 22:43:20 -0500 Subject: Python 3.0 In-Reply-To: <46DA1CB0.7080509@fedoraproject.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> Message-ID: <20070901224320.77fdd46a@vader.jdub.homelinux.org> On Sun, 02 Sep 2007 07:45:12 +0530 Rahul Sundaram wrote: > David G. Mackay wrote: > > > > > And, perhaps FESCO would feel differently about the impact of things if > > THEY relied upon Fedora. I refer to minutes from one of the FESCO > > meetings where they discussed the issue. The point was raised that > > Fedora Infrastructure utilized Zope. But, the counter was that Fedora > > Infrastructure servers use RHEL5, so no problem. Sounds like the U. S. > > Congress making sure that they aren't impacted by their own decisions. > > Fedora infrastructure team is not the same group as FESCo. Fedora > infrastructure team runs Fedora or RHEL depending on their needs. That > has nothing to do with FESCo. And for the record, I do use Fedora. Rawhide at home, latest release at work. On every machine I own. That covers the gamut of primary arches Fedora has (i686, x86_64, ppc, ppc64). josh From loganjerry at gmail.com Sun Sep 2 03:59:21 2007 From: loganjerry at gmail.com (Jerry James) Date: Sat, 1 Sep 2007 21:59:21 -0600 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <1188637721.14108.9.camel@rousalka.dyndns.org> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> Message-ID: <870180fe0709012059n6253857cj1045f1d87ab69f19@mail.gmail.com> On 9/1/07, Nicolas Mailhot wrote: > We all know active directory is just kerberos+ldap, we've been shipping > kerberos & ldap infrastructure for years (and the fedora directory > server is supposed to be even better), and yet somehow few (if any) ever > use it. Let me tell you my experience. Around the first of this year, I decided to use kerberos+ldap to manage the machines in my research lab. After spending hours reading documentation and experimenting with kerberos and ldap separately, I got everything configured. It was only then that I discovered that libuser doesn't support kerberos+ldap. Not wanting to waste all that time, I eventually went with the solution to be found at http://jjames.fedorapeople.org/libuser/ (note to libuser maintainer: there is likely a bug in libuser that can and should be fixed; see that URL for a hint). However, there don't appear to be any warning signs anywhere telling people to watch out for the kerberos+ldap+libuser combination. At least, I've never seen any. Have you? I didn't try Fedora Directory Server; if I'm reading the web page correctly, I went through all this in the month before it hit Fedora Extras. The question is moot now since I no longer manage a research lab. -- Jerry James http://jjames.fedorapeople.org/ From laroche at redhat.com Sun Sep 2 07:04:50 2007 From: laroche at redhat.com (Florian La Roche) Date: Sun, 2 Sep 2007 09:04:50 +0200 Subject: Making "upstream" tarballs available In-Reply-To: <46D86D98.6090207@fedoraproject.org> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> Message-ID: <20070902070450.GA4396@dudweiler.stuttgart.redhat.com> > L10N folks are moving from elvis to public cvs too. Maybe we can stop > using it entirely for Fedora. elvis is a public cvs server already. The big item missing is that e.g. translations are not fully automated yet if you move away from elvis. regards, Florian La Roche From buildsys at redhat.com Sun Sep 2 07:14:37 2007 From: buildsys at redhat.com (Build System) Date: Sun, 2 Sep 2007 03:14:37 -0400 Subject: rawhide report: 20070902 changes Message-ID: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 grig - 0.7.2-2.fc8.i386 requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE libreadline-java - 0.8.0-19.fc8.i386 requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.i386 requires libedit.so.0 moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) grig - 0.7.2-2.fc8.x86_64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) pygsl-devel - 0.9.1-4.fc8.x86_64 requires gsl.devel pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 grig - 0.7.2-2.fc8.ppc requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp libreadline-java - 0.8.0-19.fc8.ppc requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.ppc requires libedit.so.0 moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.ppc requires gsl.devel pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 grig - 0.7.2-2.fc8.ppc64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From ville.skytta at iki.fi Sun Sep 2 07:38:04 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 2 Sep 2007 10:38:04 +0300 Subject: rawhide report: 20070902 changes In-Reply-To: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> Message-ID: <200709021038.04496.ville.skytta@iki.fi> On Sunday 02 September 2007, Build System wrote: > Broken deps for [...] > ---------------------------------------------------------- Looks like this report hasn't caught all broken deps. For example, I can't build xine-lib at the moment (have tried a couple of times since yesterday) because of: Error: Missing Dependency: libpolkit-dbus.so.1()(64bit) is needed by package PolicyKit-gnome Error: Missing Dependency: libpolkit-grant.so.1()(64bit) is needed by package PolicyKit-gnome Error: Missing Dependency: libpolkit.so.1()(64bit) is needed by package PolicyKit-gnome http://koji.fedoraproject.org/koji/getfile?taskID=144801&name=root.log From eric.tanguy at univ-nantes.fr Sun Sep 2 07:45:18 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 02 Sep 2007 09:45:18 +0200 Subject: Compilation problem with rawhide In-Reply-To: <46D97E37.8010705@ioa.s.u-tokyo.ac.jp> References: <1188553987.3804.1.camel@bureau.maison> <1188561538.3804.4.camel@bureau.maison> <1188644843.3089.0.camel@bureau.maison> <20070901113237.GO2063@devserv.devel.redhat.com> <1188657165.2854.3.camel@bureau.maison> <46D97E37.8010705@ioa.s.u-tokyo.ac.jp> Message-ID: <1188719118.2882.0.camel@bureau.maison> Le samedi 01 septembre 2007 ? 23:59 +0900, Mamoru Tasaka a ?crit : > Tanguy Eric wrote, at 09/01/2007 11:32 PM +9:00: > > Le samedi 01 septembre 2007 ? 07:32 -0400, Jakub Jelinek a ?crit : > >> On Sat, Sep 01, 2007 at 01:07:23PM +0200, Tanguy Eric wrote: > >>> I tried to change : > >>> > >>> if( Instr && Instr->IsVirtualFile ) > >>> Fp = virtualDirCallback.open( filename, UPNP_READ ); > >>> else > >>> Fp = fopen( filename, "rb" ); > >>> > >>> by > >>> > >>> if( Instr && Instr->IsVirtualFile ) > >>> Fp = virtualDirCallback.(open)( filename, UPNP_READ ); > >>> else > >>> Fp = fopen( filename, "rb" ); > >>> > >>> but the same error stil remain. > >> Use > >> Fp = (virtualDirCallback.open)( filename, UPNP_READ ); > >> or > >> Fp = (*virtualDirCallback.open)( filename, UPNP_READ ); > >> > >> Jakub > >> > > > > Thanks the first one do the trick. > > Is this problem specific to our version of the compiler because an > > upstream developer answer me this : > > "so that I can decide the best way to patch it. I would rather not patch > > it, because it is too weird and seems to be a problem of a specific > > version of the compiler. It does not happen with two different versions > > of gcc, namely 4.1.2 and 4.1.3 from Suse." > > AFAIK, this is due to glibc side change. > > Mamoru > > Thanks Now with mock, i have this error which seems to be due to tar : /etc/profile: line 38: /bin/hostname: No such file or directory Installing /builddir/build/SRPMS/libupnp-1.6.0-2.fc8.src.rpm Building target platforms: i386 Building for target i386 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.71172 + umask 022 + cd /builddir/build/BUILD + LANG=C + export LANG + unset DISPLAY + cd /builddir/build/BUILD + rm -rf libupnp-1.6.0 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2 + tar -xf - tar: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory bzip2: I/O or other error, bailing out. Possible reason follows. bzip2: Broken pipe Input file = /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2, output file = (stdout) error: Bad exit status from /var/tmp/rpm-tmp.71172 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.71172 (%prep) Error building package from libupnp-1.6.0-2.fc8.src.rpm, See build log ending done Where the problem come from ? Eric From trever.adams at gmail.com Sun Sep 2 08:01:20 2007 From: trever.adams at gmail.com (Trever L. Adams) Date: Sun, 02 Sep 2007 02:01:20 -0600 Subject: Spins and other development issues Message-ID: <46DA6DD0.9040508@gmail.com> I am wanting to develop some RPM packages that hopefully will eventually become part of Fedora. For the time being I would like to make them, publish them and possibly make Spins based on them. I am wondering what build tools, spec file editing tools, and spin tools there are. I will be using git, which may or may not be an issue. I am looking for tools that are automatic (like a build tree tool) and that will help do the process (spec and spin tools). Thank you, Trever Adams From valent.turkovic at gmail.com Sun Sep 2 09:02:01 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 2 Sep 2007 11:02:01 +0200 Subject: iwl3945 - kill switch issue - how do I contribute Message-ID: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. It doesn't work under rawhide and I get a message after loading iwl3945 module that my RF Kill Switch is ON even if it is OFF ! Where can I contribute my time and feedback? It fedora-devel an appropriate mailing list or should I go upstream (where is iwl3945 project page?!?) ? Thank you. ps I have a but posted here: https://bugzilla.redhat.com/show_bug.cgi?id=240116 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From mschwendt.tmp0701.nospam at arcor.de Sun Sep 2 09:23:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 2 Sep 2007 11:23:32 +0200 Subject: rawhide report: 20070902 changes In-Reply-To: <200709021038.04496.ville.skytta@iki.fi> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> <200709021038.04496.ville.skytta@iki.fi> Message-ID: <20070902112332.d958201c.mschwendt.tmp0701.nospam@arcor.de> On Sun, 2 Sep 2007 10:38:04 +0300, Ville Skytt? wrote: > On Sunday 02 September 2007, Build System wrote: > > > Broken deps for [...] > > ---------------------------------------------------------- > > Looks like this report hasn't caught all broken deps. For example, I can't > build xine-lib at the moment (have tried a couple of times since yesterday) > because of: > > Error: Missing Dependency: libpolkit-dbus.so.1()(64bit) is needed by package > PolicyKit-gnome > Error: Missing Dependency: libpolkit-grant.so.1()(64bit) is needed by package > PolicyKit-gnome > Error: Missing Dependency: libpolkit.so.1()(64bit) is needed by package > PolicyKit-gnome > > http://koji.fedoraproject.org/koji/getfile?taskID=144801&name=root.log That's because PolicyKit-0.5-3 in koji has not been pushed to rawhide yet, most likely because of the test2 freeze: http://koji.fedoraproject.org/koji/packageinfo?packageID=4838 It introduces new soname versions and breaks deps. From drago01 at gmail.com Sun Sep 2 09:19:45 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 02 Sep 2007 11:19:45 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> Message-ID: <46DA8031.3050509@gmail.com> Valent Turkovic wrote: > Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. > > It doesn't work under rawhide and I get a message after loading > iwl3945 module that my RF Kill Switch is ON even if it is OFF ! > > maybe you are just confused here killswitch ON means card OFF killswitch OFF means card ON btw works for me (iwl3945; kernel-2.6.22.4-65.fc7; hw killswitch) does your card have an software or hardware killswitch? also what do you mean by "device list" does networkmanager not detect it? I submitted patches for upstream hal to support iwl3945/4965 and ipw* killswitch so that nm works with them (patches are in hal 0.5.10-rcX which is in rawhide). > Where can I contribute my time and feedback? It fedora-devel an > appropriate mailing list or should I go upstream (where is iwl3945 > project page?!?) ? > > http://intellinuxwireless.org/ If you want to bring it upstream post to ipw3945-devel https://lists.sourceforge.net/lists/listinfo/ipw3945-devel PS: please stop using ! and ?!? all over the place try to be objective. From valent.turkovic at gmail.com Sun Sep 2 10:59:24 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 2 Sep 2007 12:59:24 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <46DA8031.3050509@gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> Message-ID: <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> On 9/2/07, dragoran wrote: > Valent Turkovic wrote: > > Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. > > > > It doesn't work under rawhide and I get a message after loading > > iwl3945 module that my RF Kill Switch is ON even if it is OFF ! > > > > > > maybe you are just confused here > killswitch ON means card OFF > killswitch OFF means card ON My killswitch is OFF this means that card should be ON, but it shows as the switch is ON and therefore card if OFF no matter what I do. # cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill 2 AFAIK there are 4 value for rf_kill, like the following, 0 -- means both software/hardware rf_kill are disabled; 1 -- means software rf_kill is enable; 2 -- means hardware rf_kill is enable; 3 -- means both software/hardware rf_kill are disabled > btw works for me (iwl3945; kernel-2.6.22.4-65.fc7; hw killswitch) > > does your card have an software or hardware killswitch? I have hardware killswitch as you can see: # cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill 2 AFAIK "2" stands for hardware switch - which I disable but kernel doesn't register it and is says that it is still enabled. In previous versions of fedora it worked as it shouls. When I enable my wifi (disable kill swithc) it works... and vice versa - not it just doesn't work. > also what do you mean by "device list" does networkmanager not detect it? how can I check for this? see for your self: # iwconfig lo no wireless extensions. eth0 no wireless extensions. > I submitted patches for upstream hal to support iwl3945/4965 and ipw* > killswitch so that nm works with them (patches are in hal 0.5.10-rcX > which is in rawhide). > > Where can I contribute my time and feedback? It fedora-devel an > > appropriate mailing list or should I go upstream (where is iwl3945 > > project page?!?) ? > > > > > http://intellinuxwireless.org/ > If you want to bring it upstream post to ipw3945-devel > https://lists.sourceforge.net/lists/listinfo/ipw3945-devel is this mailing list apropriate for iwl3945 or only for ipw3945? Thank you for your feedback. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From alcapcom at gmail.com Sun Sep 2 11:08:38 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Sun, 02 Sep 2007 13:08:38 +0200 Subject: rawhide report: 20070902 changes In-Reply-To: <20070902112332.d958201c.mschwendt.tmp0701.nospam@arcor.de> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> <200709021038.04496.ville.skytta@iki.fi> <20070902112332.d958201c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DA99B6.20607@gmail.com> Michael Schwendt a ?crit : > On Sun, 2 Sep 2007 10:38:04 +0300, Ville Skytt? wrote: > >> On Sunday 02 September 2007, Build System wrote: >> >>> Broken deps for [...] >>> ---------------------------------------------------------- >> Looks like this report hasn't caught all broken deps. For example, I can't >> build xine-lib at the moment (have tried a couple of times since yesterday) >> because of: >> >> Error: Missing Dependency: libpolkit-dbus.so.1()(64bit) is needed by package >> PolicyKit-gnome >> Error: Missing Dependency: libpolkit-grant.so.1()(64bit) is needed by package >> PolicyKit-gnome >> Error: Missing Dependency: libpolkit.so.1()(64bit) is needed by package >> PolicyKit-gnome >> >> http://koji.fedoraproject.org/koji/getfile?taskID=144801&name=root.log > > That's because PolicyKit-0.5-3 in koji has not been pushed to rawhide > yet, most likely because of the test2 freeze: > > http://koji.fedoraproject.org/koji/packageinfo?packageID=4838 > > It introduces new soname versions and breaks deps. > Have the same problem to built a eclipse plugin, any idea when that should be solved? From drago01 at gmail.com Sun Sep 2 11:16:47 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 02 Sep 2007 13:16:47 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> Message-ID: <46DA9B9F.2050907@gmail.com> Valent Turkovic wrote: > On 9/2/07, dragoran wrote: > >> Valent Turkovic wrote: >> >>> Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. >>> >>> It doesn't work under rawhide and I get a message after loading >>> iwl3945 module that my RF Kill Switch is ON even if it is OFF ! >>> >>> >>> >> maybe you are just confused here >> killswitch ON means card OFF >> killswitch OFF means card ON >> > > My killswitch is OFF this means that card should be ON, but it shows > as the switch is ON and therefore card if OFF no matter what I do. > > ok >> btw works for me (iwl3945; kernel-2.6.22.4-65.fc7; hw killswitch) >> >> does your card have an software or hardware killswitch? >> > > I have hardware killswitch as you can see: > > # cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill > 2 > > AFAIK "2" stands for hardware switch - which I disable but kernel > doesn't register it and is says that it is still enabled. In previous > versions of fedora it worked as it shouls. When I enable my wifi > (disable kill swithc) it works... and vice versa - not it just doesn't > work. > > previous fedora versions did not ship a driver for this card at all.. do you mean the ipw3945 driver? >> also what do you mean by "device list" does networkmanager not detect it? >> > > how can I check for this? > > see for your self: > > # iwconfig > lo no wireless extensions. > eth0 no wireless extensions. > > ok >> I submitted patches for upstream hal to support iwl3945/4965 and ipw* >> killswitch so that nm works with them (patches are in hal 0.5.10-rcX >> which is in rawhide). >> >>> Where can I contribute my time and feedback? It fedora-devel an >>> appropriate mailing list or should I go upstream (where is iwl3945 >>> project page?!?) ? >>> >>> >>> >> http://intellinuxwireless.org/ >> If you want to bring it upstream post to ipw3945-devel >> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel >> > > is this mailing list apropriate for iwl3945 or only for ipw3945? > > yes it is. From mcepl at redhat.com Sun Sep 2 12:24:06 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 02 Sep 2007 14:24:06 +0200 Subject: ubuntu bulletproof x References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> Message-ID: On 2007-09-01, 21:03 GMT, Douglas McClendon wrote: > Even if those situations account for 1/10,000 users, those are > precisely the cases that need to be covered to market something > as "bulletproof". People who are able to find all necessary numbers will most likely have no problem with the most mature front-end for the X configuration -- you know, the know which name consists only from letters "v" and "i" (in this order ;-)). No really, what I read in Adam's email (and what's my experience from reading hundreds of Xorg bugs, being bugmaster for RH desktop I read a lot of them), the problems we have are not in not having enough information about hardware (take a look at /var/log/Xorg.0.log -- there is plenty of information there) -- it's that quite often the information provided by hardware is plainly wrong, or that xorg drivers suck. Concerning the former, I don't understand how would information provided to Windows by the vendor was that much better than information they provide via hardware. And concerning the latter, I don't see any relation to "bulletproof X" whatsoever. Please, correct me if I am wrong. Matej From skvidal at fedoraproject.org Sun Sep 2 12:33:51 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 02 Sep 2007 08:33:51 -0400 Subject: Making "upstream" tarballs available In-Reply-To: <1188597404.19370.25.camel@junko.usersys.redhat.com> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> <46D87E9D.5070701@gmail.com> <46D88284.90305@fedoraproject.org> <46D8866F.5010208@gmail.com> <1188597404.19370.25.camel@junko.usersys.redhat.com> Message-ID: <1188736431.29226.49.camel@cutter> On Fri, 2007-08-31 at 17:56 -0400, John Dennis wrote: > On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote: > > That's true. Although there are a few things that hosted definitely > > lacks before we're ready to take it out of beta. Off the top of my head: > > > > * free form web space. That allows hosting yum repos for the projects, > > download sites, non-trac-wiki space, etc. > > Unless I'm mistaken currently the only way to put a tarball for a > project on hosted.fp.o at the moment is to add the tarball as an > attachment to Trac. > > That's a less than wonderful way to manage the tarballs especially when > the SCM repository for the project is already on hosted.fp.o. It should > be easy to create the tarball from the SCM and then export it on > hosted.fp.o without a lot of gymnastics. I think we can find a way to simplify this problem. Thanks, -sv From tcallawa at redhat.com Sun Sep 2 13:11:58 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 02 Sep 2007 09:11:58 -0400 Subject: Spins and other development issues In-Reply-To: <46DA6DD0.9040508@gmail.com> References: <46DA6DD0.9040508@gmail.com> Message-ID: <1188738718.7665.27.camel@new-host> On Sun, 2007-09-02 at 02:01 -0600, Trever L. Adams wrote: > I am wanting to develop some RPM packages that hopefully will eventually > become part of Fedora. For the time being I would like to make them, > publish them and possibly make Spins based on them. > > I am wondering what build tools, spec file editing tools, and spin tools > there are. I will be using git, which may or may not be an issue. > > I am looking for tools that are automatic (like a build tree tool) and > that will help do the process (spec and spin tools). Build Tree tool: pungi Spin tool: mock As for the spec files, well... you might want to write those yourself. :) ~spot From chitlesh at fedoraproject.org Sun Sep 2 13:27:19 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 2 Sep 2007 15:27:19 +0200 Subject: Spins and other development issues In-Reply-To: <1188738718.7665.27.camel@new-host> References: <46DA6DD0.9040508@gmail.com> <1188738718.7665.27.camel@new-host> Message-ID: <13dbfe4f0709020627r166fc1eerf3198ed8c6909560@mail.gmail.com> On 9/2/07, Tom spot Callaway wrote: > Build Tree tool: pungi > Spin tool: mock > > As for the spec files, well... you might want to write those > yourself. :) spec templates can be created by some scripts from rpmdevtools. chitlesh -- http://clunixchit.blogspot.com From alcapcom at gmail.com Sun Sep 2 13:41:11 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Sun, 02 Sep 2007 15:41:11 +0200 Subject: Spins and other development issues In-Reply-To: <13dbfe4f0709020627r166fc1eerf3198ed8c6909560@mail.gmail.com> References: <46DA6DD0.9040508@gmail.com> <1188738718.7665.27.camel@new-host> <13dbfe4f0709020627r166fc1eerf3198ed8c6909560@mail.gmail.com> Message-ID: <46DABD77.5060905@gmail.com> Chitlesh GOORAH a ?crit : > On 9/2/07, Tom spot Callaway wrote: >> Build Tree tool: pungi >> Spin tool: mock >> >> As for the spec files, well... you might want to write those >> yourself. :) > > spec templates can be created by some scripts from rpmdevtools. There is also a Eclipse Specfile Editor that use rpmdevtools to write specfile template using a wizard. The package should be available soon in rawhide. If you wan make a try now you can build the plugin from the fedora-cvs repo. The package name is eclipse-rpm-editor. Alphonse From skvidal at fedoraproject.org Sun Sep 2 13:56:25 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 02 Sep 2007 09:56:25 -0400 Subject: Spins and other development issues In-Reply-To: <46DABD77.5060905@gmail.com> References: <46DA6DD0.9040508@gmail.com> <1188738718.7665.27.camel@new-host> <13dbfe4f0709020627r166fc1eerf3198ed8c6909560@mail.gmail.com> <46DABD77.5060905@gmail.com> Message-ID: <1188741385.29226.52.camel@cutter> On Sun, 2007-09-02 at 15:41 +0200, Alphonse Van Assche wrote: > Chitlesh GOORAH a ?crit : > > On 9/2/07, Tom spot Callaway wrote: > >> Build Tree tool: pungi > >> Spin tool: mock > >> > >> As for the spec files, well... you might want to write those > >> yourself. :) > > > > spec templates can be created by some scripts from rpmdevtools. > There is also a Eclipse Specfile Editor that use rpmdevtools to write > specfile template using a wizard. The package should be available soon > in rawhide. If you wan make a try now you can build the plugin from the > fedora-cvs repo. The package name is eclipse-rpm-editor. and gedit - included with the gnome desktop supports syntax highlighting for spec files. -sv From valent.turkovic at gmail.com Sun Sep 2 14:01:30 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 2 Sep 2007 16:01:30 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <46DA9B9F.2050907@gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> Message-ID: <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> On 9/2/07, dragoran wrote: > Valent Turkovic wrote: > > On 9/2/07, dragoran wrote: > > > >> Valent Turkovic wrote: > >> > >>> Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. > >>> > >>> It doesn't work under rawhide and I get a message after loading > >>> iwl3945 module that my RF Kill Switch is ON even if it is OFF ! > >>> > >>> > >>> > >> maybe you are just confused here > >> killswitch ON means card OFF > >> killswitch OFF means card ON > >> > > > > My killswitch is OFF this means that card should be ON, but it shows > > as the switch is ON and therefore card if OFF no matter what I do. > > > > > ok > >> btw works for me (iwl3945; kernel-2.6.22.4-65.fc7; hw killswitch) > >> > >> does your card have an software or hardware killswitch? > >> > > > > I have hardware killswitch as you can see: > > > > # cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill > > 2 > > > > AFAIK "2" stands for hardware switch - which I disable but kernel > > doesn't register it and is says that it is still enabled. In previous > > versions of fedora it worked as it shouls. When I enable my wifi > > (disable kill swithc) it works... and vice versa - not it just doesn't > > work. > > > > > previous fedora versions did not ship a driver for this card at all.. do > you mean the ipw3945 driver? I use rawhide (fedora devel version) with kernel 2.6.23-0.149.rc4.fc8 (latest for fedora rawhide) and it has iwl3945 modules. /lib/modules/2.6.23-0.149.rc4.fc8/kernel/drivers/net/wireless/iwl3945.ko > >> also what do you mean by "device list" does networkmanager not detect it? > >> > > > > how can I check for this? > > > > see for your self: > > > > # iwconfig > > lo no wireless extensions. > > eth0 no wireless extensions. > > > > > ok > >> I submitted patches for upstream hal to support iwl3945/4965 and ipw* > >> killswitch so that nm works with them (patches are in hal 0.5.10-rcX > >> which is in rawhide). > >> > >>> Where can I contribute my time and feedback? It fedora-devel an > >>> appropriate mailing list or should I go upstream (where is iwl3945 > >>> project page?!?) ? > >>> > >>> > >>> > >> http://intellinuxwireless.org/ > >> If you want to bring it upstream post to ipw3945-devel > >> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel > >> > > > > is this mailing list apropriate for iwl3945 or only for ipw3945? > > > > > yes it is. > Ok, thanks So any ideas? Any help from you or anybody else? From chitlesh at fedoraproject.org Sun Sep 2 14:22:44 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 2 Sep 2007 16:22:44 +0200 Subject: Spins and other development issues In-Reply-To: <1188741385.29226.52.camel@cutter> References: <46DA6DD0.9040508@gmail.com> <1188738718.7665.27.camel@new-host> <13dbfe4f0709020627r166fc1eerf3198ed8c6909560@mail.gmail.com> <46DABD77.5060905@gmail.com> <1188741385.29226.52.camel@cutter> Message-ID: <13dbfe4f0709020722o5f6ca89chb2642173a7ef29e9@mail.gmail.com> On 9/2/07, seth vidal wrote: > and gedit - included with the gnome desktop supports syntax highlighting > for spec files. so does kate and kwrite on KDE. Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Sun Sep 2 14:33:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 2 Sep 2007 10:33:41 -0400 Subject: Making "upstream" tarballs available In-Reply-To: <46D8866F.5010208@gmail.com> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> <46D87E9D.5070701@gmail.com> <46D88284.90305@fedoraproject.org> <46D8866F.5010208@gmail.com> Message-ID: <20070902103341.0f229700@ender> On Fri, 31 Aug 2007 14:21:51 -0700 Toshio Kuratomi wrote: > * free form web space. That allows hosting yum repos for the > projects, download sites, non-trac-wiki space, etc. > > * Move the repositories to a separate server from the one that hosts > our package SCM. (Waiting on hardware for this) Agreed. These are the major two issues that have kept us from lifting Hosted from a Beta program to a Production environment and advertising it and actively seeking developers to host their projects with us. fedorapeople.org is proving a great test run for providing webspace to contributors, and we can learn from it when creating such a thing for hosted.fp.o. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ngompa13 at gmail.com Sun Sep 2 15:21:06 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 2 Sep 2007 10:21:06 -0500 Subject: Windows based installation of Fedora Linux? Message-ID: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> Hello, I recently discovered a very interesting project called Wubi ( http://wubi-installer.org/) which permits installation of Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and makes the appropriate boot entry changes to allow booting to Linux from the disk image file in the Windows partition. Ubuntu Gutsy plans to add it to the official methods of installation, and I was wondering what you guys think about having something similar in Fedora? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Sun Sep 2 15:22:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 02 Sep 2007 10:22:26 -0500 Subject: Making "upstream" tarballs available In-Reply-To: <1188597404.19370.25.camel@junko.usersys.redhat.com> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> <46D87E9D.5070701@gmail.com> <46D88284.90305@fedoraproject.org> <46D8866F.5010208@gmail.com> <1188597404.19370.25.camel@junko.usersys.redhat.com> Message-ID: <46DAD532.7010407@redhat.com> John Dennis wrote: > On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote: > >> That's true. Although there are a few things that hosted definitely >> lacks before we're ready to take it out of beta. Off the top of my head: >> >> * free form web space. That allows hosting yum repos for the projects, >> download sites, non-trac-wiki space, etc. >> > > Unless I'm mistaken currently the only way to put a tarball for a > project on hosted.fp.o at the moment is to add the tarball as an > attachment to Trac. > This actually seems reasonable to me (uploading a tarball as an attachment that can be linked to later) I've been doing this with smolt. There's two issues currently though. 1) For some reason the system doesn't work in FireFox and 2) The link to the actual download page includes variables like &action=raw or something like that and RPM hates it. -Mike From mackay_d at bellsouth.net Sun Sep 2 15:51:19 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Sun, 02 Sep 2007 10:51:19 -0500 Subject: Python 3.0 In-Reply-To: <46DA1CB0.7080509@fedoraproject.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> Message-ID: <1188748279.26358.3.camel@vorpal.macdev.com> On Sun, 2007-09-02 at 07:45 +0530, Rahul Sundaram wrote: > David G. Mackay wrote: > > > > > And, perhaps FESCO would feel differently about the impact of things if > > THEY relied upon Fedora. I refer to minutes from one of the FESCO > > meetings where they discussed the issue. The point was raised that > > Fedora Infrastructure utilized Zope. But, the counter was that Fedora > > Infrastructure servers use RHEL5, so no problem. Sounds like the U. S. > > Congress making sure that they aren't impacted by their own decisions. > > Fedora infrastructure team is not the same group as FESCo. Fedora > infrastructure team runs Fedora or RHEL depending on their needs. That > has nothing to do with FESCo. You do love to split hairs. It's clear from the minutes that FESCO was concerned that the functionality supplied by Zope should be available to Fedora Infrastructure, and didn't have to rely on F7 to supply it. The rest of us mortals didn't fare so well. Dave From mackay_d at bellsouth.net Sun Sep 2 15:59:28 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Sun, 02 Sep 2007 10:59:28 -0500 Subject: Python 3.0 In-Reply-To: <20070901224320.77fdd46a@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> Message-ID: <1188748768.26358.6.camel@vorpal.macdev.com> > And for the record, I do use Fedora. Rawhide at home, latest release > at work. On every machine I own. That covers the gamut of primary > arches Fedora has (i686, x86_64, ppc, ppc64). > > josh And what do you do when you require functionality that's not in Fedora? Dave From bruno at wolff.to Sun Sep 2 15:52:28 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 2 Sep 2007 10:52:28 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <16de708d0709012030g5a77b08cl417dd46c52d098ad@mail.gmail.com> References: <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709011005l387b38e2y674641aac9b91255@mail.gmail.com> <20070901192359.GA28479@wolff.to> <16de708d0709012030g5a77b08cl417dd46c52d098ad@mail.gmail.com> Message-ID: <20070902155228.GA9656@wolff.to> On Sat, Sep 01, 2007 at 22:30:12 -0500, Arthur Pemberton wrote: > On 9/1/07, Bruno Wolff III wrote: > > On Sat, Sep 01, 2007 at 12:05:00 -0500, > > Arthur Pemberton wrote: > > > On 9/1/07, Bruno Wolff III wrote: > > > > On Sat, Sep 01, 2007 at 14:07:17 +0200, > > > > Benny Amorsen wrote: > > > > > > > > > > Administrators sometimes want to limit which traffic can reach > > > > > applications, and perhaps limit the risk when accidentally starting > > > > > applications. Automating firewall setup makes that useless. > > > > > > > > That is probably the main reason. And having apps undo restrictions seems > > > > like a really really bad idea. > > > > > > So being able to easily disable this wouldn't be enough? > > > > I don't think so. I thought making it easy for people to shoot themselves > > in the foot was the Microsoft way. > > I do not see a parallel here, please explain Microsoft makes things convenient even when what is being made convenient is a dumb idea from a security perspective. Think email clients that run programs to view attachments of type other than plain/text without even asking. > > > > Plus I have no confidence that apps can properly rewrite iptables rules > > > > correctly. iptables setups can have complications which will make it > > > > hard to change them. I have used subroutines for checking reserved ip > > > > ranges and have had services configured to only be available to local > > > > ip addresses or specific interfaces. > > > > > > This is something that would/should work only if you're using > > > system-config-firewall > > > > And how is the code going to determine that? > > By having the init script ask s-c-firewall to open the port as has > been suggested. Does the init script know that s-c-firewall is what wrote the current set of firewall rules? If so, I'd be curious to know how it does. Because if s-c-firewall didn't write the rules, it is possible that the changes it makes will cause problems. From a.badger at gmail.com Sun Sep 2 16:50:52 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 02 Sep 2007 09:50:52 -0700 Subject: Python 3.0 In-Reply-To: <1188748279.26358.3.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <1188748279.26358.3.camel@vorpal.macdev.com> Message-ID: <46DAE9EC.6000001@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David G. Mackay wrote: > On Sun, 2007-09-02 at 07:45 +0530, Rahul Sundaram wrote: >> David G. Mackay wrote: >> >>> And, perhaps FESCO would feel differently about the impact of things if >>> THEY relied upon Fedora. I refer to minutes from one of the FESCO >>> meetings where they discussed the issue. The point was raised that >>> Fedora Infrastructure utilized Zope. But, the counter was that Fedora >>> Infrastructure servers use RHEL5, so no problem. Sounds like the U. S. >>> Congress making sure that they aren't impacted by their own decisions. >> Fedora infrastructure team is not the same group as FESCo. Fedora >> infrastructure team runs Fedora or RHEL depending on their needs. That >> has nothing to do with FESCo. > > You do love to split hairs. It's clear from the minutes that FESCO was > concerned that the functionality supplied by Zope should be available to > Fedora Infrastructure, and didn't have to rely on F7 to supply it. The > rest of us mortals didn't fare so well. > Heh. If you really want your hairs split, it's really the Fedora Documentation Project that wants to use Zope/Plone. Infrastructure just manages the services. :-) Since that's not really the information you want, let's look at it this another way: Do you have a team of people who are maintaining zope/plone/python2.4 right now? Is it going well? How do they decide which python modules to build for python2.4? Do they limit the bug reports they deal with to bug reports against zope/plone or do they handle bugs from people who are running python2.4 for other reasons? Most importantly, are they willing to commit to maintaining this stack of packages for the life of F-7? I'm no longer on FESCo but these were some of the questions that were asked that have a technical justification and I highly suspect that the current FESCo will listen to the answers to these questions as well when deciding whether compat-python can exist within Fedora without putting too much extra work on the rest of the distro. Finally, I want to keep stressing that FESCo did not ban zope or plone. They discussed what the standard of commitment should be for a person or team to maintain a compat-python package in Fedora. We wanted to allow this goal to be met: "[including] a wide range of packages that fits into the various different needs of the users." But not at the expense of: "[being] on the leading edge of free and open source technology, by adopting and helping develop new features and version upgrades." and "[providing] a robust development platform for building software and robust general integrated set of software that balances the needs for both desktop and server users." The questions we wanted answered were to ensure that there was a commitment by the packager(s) involved in compat-python2.4 to meet the robustness goal for the life of the packages so that people working on the leading edge goal didn't have to stop what they were doing and fix problems with the compat- packages. * Goals copied from: http://fedoraproject.org/wiki/Objectives * Note: when Jeremy has a chance to reply to these messages he may have a different perspective on FESCo's discussions as he was arguing the opposite point of view as I was. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG2unsX6yAic2E7kgRAr0/AJ9Cqm7EuiaZ5JYPpTr2NaUQfzy6dACgs+K4 lx0yfHyO2lvnDWB/lvPCnuE= =i5MB -----END PGP SIGNATURE----- From andy at warmcat.com Sun Sep 2 17:54:06 2007 From: andy at warmcat.com (Andy Green) Date: Sun, 02 Sep 2007 18:54:06 +0100 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> Message-ID: <46DAF8BE.4040405@warmcat.com> Somebody in the thread at some point said: >>>>> Hi, I have HP nx7300 laptop with Intel 3945ABG wifi card. >>>>> >>>>> It doesn't work under rawhide and I get a message after loading >>>>> iwl3945 module that my RF Kill Switch is ON even if it is OFF ! > So any ideas? Any help from you or anybody else? I have an nx7400 which works fine... on that there is a pushbutton on the keyboard above F2/F3 which toggles the kill state, and a blue LED inset in the button is lit when the kill is off / device is enabled. Sometimes the button is ignored for a while after changing the kill state. Did you check any possible BIOS settings about enabling or disabling the wifi? -Andy From jon at fedoraunity.org Sun Sep 2 18:30:40 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sun, 02 Sep 2007 12:30:40 -0600 Subject: Windows based installation of Fedora Linux? In-Reply-To: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> Message-ID: <46DB0150.30701@fedoraunity.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 King InuYasha wrote: > Hello, > > I recently discovered a very interesting project called Wubi ( > http://wubi-installer.org/) which permits installation of > Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and makes the > appropriate boot entry changes to allow booting to Linux from the disk image > file in the Windows partition. Ubuntu Gutsy plans to add it to the official > methods of installation, and I was wondering what you guys think about > having something similar in Fedora? > > This would be neat and I've looked into it before. From the Virtual FUDCon, I've taken that a user needing a windows installer is not in our target audience (at least not right now.) With regards to making it an "unofficial" installer to prove it's viability, I'm all for it. Fedora sponsored/official live images were sparked by community initiative, a 'from windows' installer might be an example in the future. I don't particularly like the way Wubi gets things done, but give the concept merit. I'd look at helping to do something similar, but using anaconda to do the install among other changes. Jonathan Steffan daMaestro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG2wFQrRJs5w2Gr1kRAu5bAKDvROISl5jBb2N4EpN1D8Tqij5kZACgw+DX g8b0AyHWL5xUa+Pw+o4JRHM= =NTx3 -----END PGP SIGNATURE----- From ngompa13 at gmail.com Sun Sep 2 18:47:55 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 2 Sep 2007 13:47:55 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <46DB0150.30701@fedoraunity.org> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> Message-ID: <8278b1b0709021147w7e5483aesdf5a6993d21663fc@mail.gmail.com> Would it be possible to do with anaconda? And I think its better to start out as an unofficial thing, because that tends to garner more testing. If it works out well, then I think it should be possible to be included as part of the +1 release of what the unofficial one was intended for. Suppose it is done for Fedora 8, then if all goes well, it should be supplemented into available official methods of install in Fedora 9. I suppose it would be pretty important to use anaconda, because of the management tools available for anaconda... On 9/2/07, Jonathan Steffan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > King InuYasha wrote: > > Hello, > > > > I recently discovered a very interesting project called Wubi ( > > http://wubi-installer.org/) which permits installation of > > Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and makes > the > > appropriate boot entry changes to allow booting to Linux from the disk > image > > file in the Windows partition. Ubuntu Gutsy plans to add it to the > official > > methods of installation, and I was wondering what you guys think about > > having something similar in Fedora? > > > > > > This would be neat and I've looked into it before. From the Virtual > FUDCon, I've taken that a user needing a windows installer is not in our > target audience (at least not right now.) With regards to making it an > "unofficial" installer to prove it's viability, I'm all for it. Fedora > sponsored/official live images were sparked by community initiative, a > 'from windows' installer might be an example in the future. I don't > particularly like the way Wubi gets things done, but give the concept > merit. I'd look at helping to do something similar, but using anaconda > to do the install among other changes. > > Jonathan Steffan > daMaestro > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFG2wFQrRJs5w2Gr1kRAu5bAKDvROISl5jBb2N4EpN1D8Tqij5kZACgw+DX > g8b0AyHWL5xUa+Pw+o4JRHM= > =NTx3 > -----END PGP SIGNATURE----- > > -- > 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 redhat at olen.net Sun Sep 2 19:28:59 2007 From: redhat at olen.net (Ola Thoresen) Date: Sun, 02 Sep 2007 21:28:59 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> Message-ID: <46DB0EFB.5080107@olen.net> Valent Turkovic wrote: > > Ok, thanks > > So any ideas? Any help from you or anybody else? No ideas, I'm afraid, but I believe I have the same problem. No matter what position the kill switch is set - and no matter if I boot or just rmmod/modprobe the module I get the "Kill switch is on"-message. There is a thread over at the Ubuntu-forums where I have made a few postings: http://ubuntuforums.org/showthread.php?t=246074 Rgds. Ola Thoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From dmc.fedora at filteredperception.org Sun Sep 2 19:52:07 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 14:52:07 -0500 Subject: ubuntu bulletproof x In-Reply-To: References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> Message-ID: <46DB1467.1060905@filteredperception.org> Matej Cepl wrote: > On 2007-09-01, 21:03 GMT, Douglas McClendon wrote: >> Even if those situations account for 1/10,000 users, those are >> precisely the cases that need to be covered to market something >> as "bulletproof". > > People who are able to find all necessary numbers will most > likely have no problem with the most mature front-end for the > X configuration -- you know, the know which name consists only > from letters "v" and "i" (in this order ;-)). Very funny. Obviously the ubuntu tool is designed specifically for people who are not put off by inserting a hardware vendors windows driver cd into the cdrom, but are put off by using vi. > > No really, what I read in Adam's email (and what's my experience > from reading hundreds of Xorg bugs, being bugmaster for RH > desktop I read a lot of them), the problems we have are not in > not having enough information about hardware (take a look at > /var/log/Xorg.0.log -- there is plenty of information there) -- > it's that quite often the information provided by hardware is > plainly wrong, or that xorg drivers suck. Concerning the former, > I don't understand how would information provided to Windows by > the vendor was that much better than information they provide via > hardware. Umm... Please think about this a bit more. If the data provided by the hardware is "plainly wrong" or "broken", then that is precisely the time when data provided on the winblowz driver CD might be right. Honestly I can't vouch that this is ever the case. It is pure speculation on my part. But I for one get sick of hearing "you're hardware is broken, go suck an egg", when clearly that hardware is not broken enough to not work on windows, using the mechanisms they have in place (e.g. presumably reading the data from the driver cd). (and again, for the sake of argument, lets pretend that doing anything from a command line, or editing a text file, or researching obscure specs about your monitor, is not an option for the users in question) And concerning the latter, I don't see any relation to > "bulletproof X" whatsoever. correct, nothing in the thread I started, has to do with xorg drivers sucking. It only has to do with monitor configuration, when presumably the monitor hardware is failing to provide the correct info to the xorg driver. (though I suppose the same situation could occur if there was a bug in the xorg driver reading the information). But again, this is speculation on my part. Please correct me if I'm wrong. :) -dmc From galibert at pobox.com Sun Sep 2 19:59:25 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sun, 2 Sep 2007 21:59:25 +0200 Subject: ubuntu bulletproof x In-Reply-To: References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> Message-ID: <20070902195925.GA20581@dspnet.fr.eu.org> On Sun, Sep 02, 2007 at 02:24:06PM +0200, Matej Cepl wrote: > Concerning the former, I don't understand how would information > provided to Windows by the vendor was that much better than > information they provide via hardware. "Hey, the tester says that the new monitor doesn't work with his video card, it says 'out of range'" "Oh, indeed, we broke EDID. Don't worry, we'll fix it on the driver CD" OG. From konrad at tylerc.org Sun Sep 2 20:01:51 2007 From: konrad at tylerc.org (Konrad Meyer) Date: Sun, 2 Sep 2007 13:01:51 -0700 Subject: Spins and other development issues In-Reply-To: <1188741385.29226.52.camel@cutter> References: <46DA6DD0.9040508@gmail.com> <46DABD77.5060905@gmail.com> <1188741385.29226.52.camel@cutter> Message-ID: <200709021301.52106.konrad@tylerc.org> On Sunday 02 September 2007 06:56:25 am seth vidal wrote: > > On Sun, 2007-09-02 at 15:41 +0200, Alphonse Van Assche wrote: > > Chitlesh GOORAH a ?crit : > > > On 9/2/07, Tom spot Callaway wrote: > > >> Build Tree tool: pungi > > >> Spin tool: mock > > >> > > >> As for the spec files, well... you might want to write those > > >> yourself. :) > > > > > > spec templates can be created by some scripts from rpmdevtools. > > There is also a Eclipse Specfile Editor that use rpmdevtools to write > > specfile template using a wizard. The package should be available soon > > in rawhide. If you wan make a try now you can build the plugin from the > > fedora-cvs repo. The package name is eclipse-rpm-editor. > > and gedit - included with the gnome desktop supports syntax highlighting > for spec files. > > -sv Almost anything does. But just because they havn't been mentioned yet, (g)Vim does as well. -- Konrad Meyer http://konrad.sobertillnoon.com/ -------------- 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 mmahut at fedoraproject.org Sun Sep 2 20:05:32 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 02 Sep 2007 22:05:32 +0200 Subject: application layer packet classifier in Fedora? Message-ID: <46DB178C.7080201@fedoraproject.org> Hello list, Today, when building my QoS script for my home-made router, I found that there's none packer classifier in Fedora. I'm looking for something like l7-filter[1] or ipp2p[2]. Any hint for something similar already in Fedora? Or someone who can help me to package and build l7-filter for Fedora? Thanks! [1] http://l7-filter.sourceforge.net/ [2] http://ipp2p.org/ -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From dmc.fedora at filteredperception.org Sun Sep 2 20:08:34 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 15:08:34 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <46DB0150.30701@fedoraunity.org> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> Message-ID: <46DB1842.2060702@filteredperception.org> Jonathan Steffan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > King InuYasha wrote: >> Hello, >> >> I recently discovered a very interesting project called Wubi ( >> http://wubi-installer.org/) which permits installation of >> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and makes the >> appropriate boot entry changes to allow booting to Linux from the disk image >> file in the Windows partition. Ubuntu Gutsy plans to add it to the official >> methods of installation, and I was wondering what you guys think about >> having something similar in Fedora? >> >> > > This would be neat and I've looked into it before. From the Virtual > FUDCon, I've taken that a user needing a windows installer is not in our > target audience (at least not right now.) With regards to making it an > "unofficial" installer to prove it's viability, I'm all for it. Fedora > sponsored/official live images were sparked by community initiative, a > 'from windows' installer might be an example in the future. I don't > particularly like the way Wubi gets things done, but give the concept > merit. I'd look at helping to do something similar, but using anaconda > to do the install among other changes. I think this is merely a matter of ressurrecting a long-dead feature. Wasn't anaconda historically able to install to a file on a vfat partition? Naturally during those dark ages when a RW ntfs driver was unavailable, and the vast majority of windows users used ntfs rather than vfat, this was not possible. The instant that an rw-ntfs driver was in fedora, I was drooling in anticipation of this feature returning. Of course, having a native win32 installer would be pretty cool too, for all the reasons wubi is doing it. Interestingly, I can see a simple win32 installer that just installs the livecd ext3 image as is, and then lets you run anaconda from an RW version of the livecd image once rebooted into linux. In fact, the changes to get that incarnation of anaconda to do the right thing, are nearly identical to the changes I have been kicking around to support rebootless installation. (i.e. the stuff anaconda tweaks neads to be the stuff from /, and not /mnt/sysimage). bwa ha ha.... -dmc From ngompa13 at gmail.com Sun Sep 2 20:16:04 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 2 Sep 2007 15:16:04 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <46DB1842.2060702@filteredperception.org> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> <46DB1842.2060702@filteredperception.org> Message-ID: <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> I dunno about booting a RW version of the livecd ext3 image and then finish installation that way, it might be simpler just to go ahead and do normal installation but instead to a file on the Windows partition within Windows. Simply to not have the redundancy..... It could invoke firstboot though.... On 9/2/07, Douglas McClendon wrote: > > Jonathan Steffan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > King InuYasha wrote: > >> Hello, > >> > >> I recently discovered a very interesting project called Wubi ( > >> http://wubi-installer.org/) which permits installation of > >> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and > makes the > >> appropriate boot entry changes to allow booting to Linux from the disk > image > >> file in the Windows partition. Ubuntu Gutsy plans to add it to the > official > >> methods of installation, and I was wondering what you guys think about > >> having something similar in Fedora? > >> > >> > > > > This would be neat and I've looked into it before. From the Virtual > > FUDCon, I've taken that a user needing a windows installer is not in our > > target audience (at least not right now.) With regards to making it an > > "unofficial" installer to prove it's viability, I'm all for it. Fedora > > sponsored/official live images were sparked by community initiative, a > > 'from windows' installer might be an example in the future. I don't > > particularly like the way Wubi gets things done, but give the concept > > merit. I'd look at helping to do something similar, but using anaconda > > to do the install among other changes. > > I think this is merely a matter of ressurrecting a long-dead feature. > Wasn't anaconda historically able to install to a file on a vfat > partition? > > Naturally during those dark ages when a RW ntfs driver was unavailable, > and the vast majority of windows users used ntfs rather than vfat, this > was not possible. > > The instant that an rw-ntfs driver was in fedora, I was drooling in > anticipation of this feature returning. > > Of course, having a native win32 installer would be pretty cool too, for > all the reasons wubi is doing it. Interestingly, I can see a simple > win32 installer that just installs the livecd ext3 image as is, and then > lets you run anaconda from an RW version of the livecd image once > rebooted into linux. In fact, the changes to get that incarnation of > anaconda to do the right thing, are nearly identical to the changes I > have been kicking around to support rebootless installation. (i.e. the > stuff anaconda tweaks neads to be the stuff from /, and not > /mnt/sysimage). > > bwa ha ha.... > > -dmc > > -- > 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 dmc.fedora at filteredperception.org Sun Sep 2 20:34:40 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 15:34:40 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> <46DB1842.2060702@filteredperception.org> <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> Message-ID: <46DB1E60.4070100@filteredperception.org> King InuYasha wrote: > I dunno about booting a RW version of the livecd ext3 image and then finish > installation that way, it might be simpler just to go ahead and do normal > installation but instead to a file on the Windows partition within Windows. > Simply to not have the redundancy..... It could invoke firstboot though.... My theory, was that it would be less work to get ananconda to handle that*, than it would be to port anaconda to windows. Again, this is only from the perspective of allowing the user to download an installer in windows, and then reboot straight to their installed linux, without the intermediary step of burning a bootable install cd, and booting from it. From the perspective that I think you are talking about, of just doing a 'normal installation' (e.g. download bootable installable iso, then boot from it), it is indeed much simpler, and perhaps just a matter of ressurrecting functionality that existed many years ago. -dmc * (especially if for personal rebootless reasons I was going to do most of the foundation work anyway) > > On 9/2/07, Douglas McClendon wrote: >> Jonathan Steffan wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> King InuYasha wrote: >>>> Hello, >>>> >>>> I recently discovered a very interesting project called Wubi ( >>>> http://wubi-installer.org/) which permits installation of >>>> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and >> makes the >>>> appropriate boot entry changes to allow booting to Linux from the disk >> image >>>> file in the Windows partition. Ubuntu Gutsy plans to add it to the >> official >>>> methods of installation, and I was wondering what you guys think about >>>> having something similar in Fedora? >>>> >>>> >>> This would be neat and I've looked into it before. From the Virtual >>> FUDCon, I've taken that a user needing a windows installer is not in our >>> target audience (at least not right now.) With regards to making it an >>> "unofficial" installer to prove it's viability, I'm all for it. Fedora >>> sponsored/official live images were sparked by community initiative, a >>> 'from windows' installer might be an example in the future. I don't >>> particularly like the way Wubi gets things done, but give the concept >>> merit. I'd look at helping to do something similar, but using anaconda >>> to do the install among other changes. >> I think this is merely a matter of ressurrecting a long-dead feature. >> Wasn't anaconda historically able to install to a file on a vfat >> partition? >> >> Naturally during those dark ages when a RW ntfs driver was unavailable, >> and the vast majority of windows users used ntfs rather than vfat, this >> was not possible. >> >> The instant that an rw-ntfs driver was in fedora, I was drooling in >> anticipation of this feature returning. >> >> Of course, having a native win32 installer would be pretty cool too, for >> all the reasons wubi is doing it. Interestingly, I can see a simple >> win32 installer that just installs the livecd ext3 image as is, and then >> lets you run anaconda from an RW version of the livecd image once >> rebooted into linux. In fact, the changes to get that incarnation of >> anaconda to do the right thing, are nearly identical to the changes I >> have been kicking around to support rebootless installation. (i.e. the >> stuff anaconda tweaks neads to be the stuff from /, and not >> /mnt/sysimage). >> >> bwa ha ha.... >> >> -dmc >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From opensource at till.name Sun Sep 2 21:23:48 2007 From: opensource at till.name (Till Maas) Date: Sun, 02 Sep 2007 23:23:48 +0200 Subject: application layer packet classifier in Fedora? In-Reply-To: <46DB178C.7080201@fedoraproject.org> References: <46DB178C.7080201@fedoraproject.org> Message-ID: <200709022323.57295.opensource@till.name> On So September 2 2007, Marek Mahut wrote: > Today, when building my QoS script for my home-made router, I found that > there's none packer classifier in Fedora. I'm looking for something like > l7-filter[1] or ipp2p[2]. Any hint for something similar already in > Fedora? Or someone who can help me to package and build l7-filter for > Fedora? Is the l7-filter userspace version good enough for you? The kernel version and ipp2p may not make it into Fedora, because external kernel modules may be banned in the future. To be on the safe side, it would be better to try to integrate it into one of the other repositories. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From debarshi.ray at gmail.com Sun Sep 2 21:28:34 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 3 Sep 2007 02:58:34 +0530 Subject: rawhide report: 20070902 changes In-Reply-To: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> Message-ID: <3170f42f0709021428h6f42d350re3b55dea773e64f1@mail.gmail.com> > libreadline-java - 0.8.0-19.fc8.i386 requires libedit >= 0:2.9 > libreadline-java - 0.8.0-19.fc8.i386 requires libedit.so.0 > [...] > libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit.so.0()(64bit) > libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit >= 0:2.9 > [...] > libreadline-java - 0.8.0-19.fc8.ppc requires libedit >= 0:2.9 > libreadline-java - 0.8.0-19.fc8.ppc requires libedit.so.0 > [...] > libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit.so.0()(64bit) > libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit >= 0:2.9 I see that libedit is lying orphaned for a few months. I have just finished creating a package for it and will be submitting a review request as soon as I can access Bugzilla (http://debarshiray.multiply.com/journal/item/102/Can_not_access_bugzilla_anymore ). For the time being, Spec: http://rishi.fedorapeople.org/libedit.spec SRPM: http://rishi.fedorapeople.org/libedit-2.10-1.20070831cvs.fc8.src.rpm Koji log: http://koji.fedoraproject.org/koji/taskinfo?taskID=145172 By the way, after creating the package I noticed that libedit's devel branch in CVS is not 'marked' dead.package. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From opensource at till.name Sun Sep 2 21:41:06 2007 From: opensource at till.name (Till Maas) Date: Sun, 02 Sep 2007 23:41:06 +0200 Subject: rawhide report: 20070902 changes In-Reply-To: <3170f42f0709021428h6f42d350re3b55dea773e64f1@mail.gmail.com> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> <3170f42f0709021428h6f42d350re3b55dea773e64f1@mail.gmail.com> Message-ID: <200709022341.11930.opensource@till.name> On So September 2 2007, Debarshi 'Rishi' Ray wrote: > Spec: http://rishi.fedorapeople.org/libedit.spec One issue at first sight: The -devel szbpackage contains a .pc file: - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dominik at greysector.net Sun Sep 2 21:41:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 2 Sep 2007 23:41:36 +0200 Subject: ubuntu bulletproof x In-Reply-To: <46DB1467.1060905@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> Message-ID: <20070902214136.GA4438@ryvius.pekin.waw.pl> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: [...] > (and again, for the sake of argument, lets pretend that doing anything > from a command line, or editing a text file, or researching obscure > specs about your monitor, is not an option for the users in question) I think that for majority of monitors out there, you can find the specs in 5 minutes using Google. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ssorce at redhat.com Sun Sep 2 22:13:02 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 02 Sep 2007 18:13:02 -0400 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <1188646141.16306.106.camel@home.alexander.bostrom.net> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> <1188639746.16306.102.camel@home.alexander.bostrom.net> <3da3b5b40709010323m468046f1h5a2a41bbab5e62a9@mail.gmail.com> <1188646141.16306.106.camel@home.alexander.bostrom.net> Message-ID: <1188771182.6201.53.camel@localhost.localdomain> On Sat, 2007-09-01 at 13:29 +0200, Alexander Bostr?m wrote: > On Sat, 2007-09-01 at 13:23 +0300, Ahmed Kamal wrote: > > I think http://www.freeipa.org/ is a very good first step to make > > setting up a kerberized network easy and managing it painless. Can we > > build over that, and start integrating more services. > > Yes, sounds like a plan. Thanks for reminding me about that project! Alexander, I am working on the FreeIPA project and any contribution there is _very_ welcome. We have a long task ahead before we can reach substantially the same amount of integration and features that AD has, but we are doing something that, eventually, may get use there, or as I hope, have something even better for us so that it can better suite our needs. Contrary to what some say, AD is not "just" kerberos + ldap, it is also that of course, but it is also a lot of other things, and, unfortunately our apps are not as kerberos/ldap friendly as they could be. But with some help from other people we can quickly get a lot more out of IPA so that Fedora can be a very good Identity Management solution out of the box soon. Simo. From ssorce at redhat.com Sun Sep 2 22:17:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 02 Sep 2007 18:17:05 -0400 Subject: Kerberos Integration (Was: Fedora Crypto Consolidation Project) In-Reply-To: <870180fe0709012059n6253857cj1045f1d87ab69f19@mail.gmail.com> References: <200708220832.32831.sgrubb@redhat.com> <1188626004.16306.49.camel@home.alexander.bostrom.net> <1188637721.14108.9.camel@rousalka.dyndns.org> <870180fe0709012059n6253857cj1045f1d87ab69f19@mail.gmail.com> Message-ID: <1188771425.6201.58.camel@localhost.localdomain> On Sat, 2007-09-01 at 21:59 -0600, Jerry James wrote: > Let me tell you my experience. Around the first of this year, I > decided to use kerberos+ldap to manage the machines in my research > lab. After spending hours reading documentation and experimenting > with kerberos and ldap separately, I got everything configured. It > was only then that I discovered that libuser doesn't support > kerberos+ldap. James, I made some patches to make libuser a bit more friendly to SASL/GSSAPI recently, but the problem with libuser is that it is built around the /etc/passwd and its 5 fields |(+ shadow and its few more fields) only. Libuser lacks the breadth to manage anything based on ldap, which is extensible and more complex even with the current very basic objectClasses available. In FreeIPA we are try to come up with better tools to deal with the specifics of an extensible infrastructure. Simo. From jwboyer at jdub.homelinux.org Sun Sep 2 22:24:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 2 Sep 2007 17:24:06 -0500 Subject: Python 3.0 In-Reply-To: <1188748768.26358.6.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> Message-ID: <20070902172406.2ac86ab9@vader.jdub.homelinux.org> On Sun, 02 Sep 2007 10:59:28 -0500 "David G. Mackay" wrote: > > And for the record, I do use Fedora. Rawhide at home, latest release > > at work. On every machine I own. That covers the gamut of primary > > arches Fedora has (i686, x86_64, ppc, ppc64). > > > > josh > > And what do you do when you require functionality that's not in Fedora? Depends. If it's outside the scope of Fedora, such as codecs, etc I certainly don't expect Fedora to fill that need. If it's within the realm of Fedora, and it's not present yet I package it up myself. If it's already in Fedora and it's lacking something I need, I work with upstream to get it in place so it will follow naturally to Fedora. josh From kanarip at kanarip.com Sun Sep 2 22:24:43 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 00:24:43 +0200 Subject: application layer packet classifier in Fedora? In-Reply-To: <46DB178C.7080201@fedoraproject.org> References: <46DB178C.7080201@fedoraproject.org> Message-ID: <46DB382B.3070301@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marek Mahut wrote: > Hello list, > > Today, when building my QoS script for my home-made router, I found that > there's none packer classifier in Fedora. I'm looking for something like > l7-filter[1] or ipp2p[2]. Any hint for something similar already in > Fedora? Or someone who can help me to package and build l7-filter for > Fedora? > > Thanks! > > [1] http://l7-filter.sourceforge.net/ > [2] http://ipp2p.org/ > Marek, I'm certainly interested in (helping) packaging l7-filter. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG2zgqKN6f2pNCvwgRAhPiAJsGD2TMS1ikLcKDz4z3Hx7QI6vutgCfbQrR YcU8QIbPVqR3Si1pkGJU5Xs= =vj7A -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Sun Sep 2 22:36:08 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 17:36:08 -0500 Subject: ubuntu bulletproof x In-Reply-To: <20070902214136.GA4438@ryvius.pekin.waw.pl> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> Message-ID: <46DB3AD8.6040006@filteredperception.org> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: > [...] >> (and again, for the sake of argument, lets pretend that doing anything >> from a command line, or editing a text file, or researching obscure >> specs about your monitor, is not an option for the users in question) > > I think that for majority of monitors out there, you can find the specs > in 5 minutes using Google. And that is relevent to this thread how? -dmc From jonathan.underwood at gmail.com Sun Sep 2 22:44:20 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Sep 2007 23:44:20 +0100 Subject: Python 3.0 In-Reply-To: <1188748768.26358.6.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> Message-ID: <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> On 02/09/07, David G. Mackay wrote: > > And for the record, I do use Fedora. Rawhide at home, latest release > > at work. On every machine I own. That covers the gamut of primary > > arches Fedora has (i686, x86_64, ppc, ppc64). > > > > josh > > And what do you do when you require functionality that's not in Fedora? You do realize there is a currently supported Fedora release which includes Zope, Plone and python 2.4? From lesmikesell at gmail.com Sun Sep 2 22:47:41 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 02 Sep 2007 17:47:41 -0500 Subject: ubuntu bulletproof x In-Reply-To: <20070902214136.GA4438@ryvius.pekin.waw.pl> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> Message-ID: <46DB3D8D.9060309@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: > [...] >> (and again, for the sake of argument, lets pretend that doing anything >> from a command line, or editing a text file, or researching obscure >> specs about your monitor, is not an option for the users in question) > > I think that for majority of monitors out there, you can find the specs > in 5 minutes using Google. And then translate that into a modeline with another 3 days of googling. -- Les Mikesell lesmikesell at gmail.com From skvidal at fedoraproject.org Sun Sep 2 23:19:29 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 02 Sep 2007 19:19:29 -0400 Subject: Making "upstream" tarballs available In-Reply-To: <20070902103341.0f229700@ender> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> <46D87E9D.5070701@gmail.com> <46D88284.90305@fedoraproject.org> <46D8866F.5010208@gmail.com> <20070902103341.0f229700@ender> Message-ID: <1188775169.29226.61.camel@cutter> On Sun, 2007-09-02 at 10:33 -0400, Jesse Keating wrote: > On Fri, 31 Aug 2007 14:21:51 -0700 > Toshio Kuratomi wrote: > > > * free form web space. That allows hosting yum repos for the > > projects, download sites, non-trac-wiki space, etc. > > > > * Move the repositories to a separate server from the one that hosts > > our package SCM. (Waiting on hardware for this) > > Agreed. These are the major two issues that have kept us from lifting > Hosted from a Beta program to a Production environment and advertising > it and actively seeking developers to host their projects with us. > > fedorapeople.org is proving a great test run for providing webspace to > contributors, and we can learn from it when creating such a thing for > hosted.fp.o. Yes, at this point we could make a releases.fp.o with similar restrictions as fedorapeople.o, but we need: 1. a host/instance to run it on 2. the disk space behind it - probably not that much 20-30gb I don't think there is that resource available atm in a place where we can allow ssh logins. I'll ask. -sv From jspaleta at gmail.com Sun Sep 2 23:30:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 2 Sep 2007 15:30:57 -0800 Subject: ubuntu bulletproof x In-Reply-To: <46DB1467.1060905@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> Message-ID: <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> On 9/2/07, Douglas McClendon wrote: > Honestly I can't vouch that this is ever the case. It is pure > speculation on my part. But I for one get sick of hearing "you're > hardware is broken, go suck an egg", when clearly that hardware is not > broken enough to not work on windows, using the mechanisms they have in > place (e.g. presumably reading the data from the driver cd). Okay.... here is where the conversation stops. If this is complete speculation..then there is no constructive way forward. Adam Jackson has already commented that in his opinion what is provided in the inf files is not enough to fix the problem. I strongly suggest that you go re-read everything that he wrote concerning the history of Fedora's usage of the code Ubuntu is relying on now to parse inf files. Read it... read it again.. and then when you think you understand it...read it again. Now.. it is up to anyone who disagrees with Mr. Jackson's informed historical account of the usefulness of inf parsing.. to dig out an inf file for a specific piece of hardware that doesn't currently work with Fedora's auto-detection and show...specifically..that the information provided in the inf file is enough to fix the issues that Mr. Jackson has stated can't be resolved with information from the inf file. Stop arguing that the inf should have the information necessary.. .and start showing that they do. > > (and again, for the sake of argument, lets pretend that doing anything > from a command line, or editing a text file, or researching obscure > specs about your monitor, is not an option for the users in question) I FORBID arguments for arguments sake. If you want to argue with me about that, i suggest we open up a fedora-arguments-list. > But again, this is speculation on my part. Please correct me if I'm > wrong. :) Adam Jackson has previously done just that... he wrote quite succinctly that information in inf files is not enough to solve the underlying problems. -jef From lesmikesell at gmail.com Sun Sep 2 23:51:19 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 02 Sep 2007 18:51:19 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> Message-ID: <46DB4C77.6060108@gmail.com> Jeff Spaleta wrote: > Now.. it is up to anyone who disagrees with Mr. Jackson's informed > historical account of the usefulness of inf parsing.. to dig out an > inf file for a specific piece of hardware that doesn't currently work > with Fedora's auto-detection and show...specifically..that the > information provided in the inf file is enough to fix the issues that > Mr. Jackson has stated can't be resolved with information from the inf > file. Stop arguing that the inf should have the information > necessary.. .and start showing that they do. Isn't the fact that windows works with them a pretty good demonstration? > I FORBID arguments for arguments sake. If you want to argue with me > about that, i suggest we open up a fedora-arguments-list. OK, where do we sign up? > Adam Jackson has previously done just that... he wrote quite > succinctly that information in inf files is not enough to solve the > underlying problems. Is he suggesting that windows uses magic? I thought he meant instead that X doesn't use the information sensibly. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Mon Sep 3 00:46:47 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 2 Sep 2007 16:46:47 -0800 Subject: ubuntu bulletproof x In-Reply-To: <46DB4C77.6060108@gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB4C77.6060108@gmail.com> Message-ID: <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> On 9/2/07, Les Mikesell wrote: > Isn't the fact that windows works with them a pretty good demonstration? Sadly we don't have access to that source code now do we. Please keep the rhetorical comments to a minimum. Go back and read what Mr. Jackson wrote...again. There is a specific piece of code involved in the parsing of inf files that Ubuntu is making use of. The scope of the discussion is grounded in how that piece of code parses inf files and whether or not the information it parses out of the file in sufficient to solve the problems linux users maybe having with hardware detection. Show specifically that the information THAT piece of code pulls out of the inf file is enough to solve the problems needed to make things work like you expect inside X. If there is information in the inf file that piece of code doesn't make use of correctly... feel free to point that. If you run across in bugs in Xorg's X11 server in the process feel free to point those out as well. > Is he suggesting that windows uses magic? I thought he meant instead > that X doesn't use the information sensibly. Are you asking me to-reinterpret Mr. Jackson's statements for additional implied meaning? Let me humbly suggest that making it a point to ask 3rd parties to read implied meanings into other people's comments is a sure way to create continued miscommunication and is not an inherently constructive activity. Stop trolling for divisive commentary, and start bringing technical specifics to the table. If you actually care about the user experience, more than you care about arguing about the user experience, you will start addressing the technical limitations of the codebase in question. -jef"the wheels on the bus go 'round and 'round, 'round and 'round, 'round and 'round. The pointlessly long discussion with no technical merit go 'round and 'round, 'round and 'round"spaleta From airlied at redhat.com Mon Sep 3 10:49:10 2007 From: airlied at redhat.com (Dave Airlie) Date: Mon, 03 Sep 2007 20:49:10 +1000 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB4C77.6060108@gmail.com> <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> Message-ID: <1188816551.6085.19.camel@clockmaker.usersys.redhat.com> On Sun, 2007-09-02 at 16:46 -0800, Jeff Spaleta wrote: > On 9/2/07, Les Mikesell wrote: > > Isn't the fact that windows works with them a pretty good demonstration? > > Sadly we don't have access to that source code now do we. Please keep > the rhetorical comments to a minimum. > Jeff I think you missed the point.... which can best be described as: OMG!! Ubuntu OMG!! Dave. From lesmikesell at gmail.com Mon Sep 3 01:34:38 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 02 Sep 2007 20:34:38 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB4C77.6060108@gmail.com> <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> Message-ID: <46DB64AE.6000001@gmail.com> Jeff Spaleta wrote: > On 9/2/07, Les Mikesell wrote: >> Isn't the fact that windows works with them a pretty good demonstration? > > Sadly we don't have access to that source code now do we. Please keep > the rhetorical comments to a minimum. Seems pretty objective to me... >> Is he suggesting that windows uses magic? I thought he meant instead >> that X doesn't use the information sensibly. > > Are you asking me to-reinterpret Mr. Jackson's statements for > additional implied meaning? Yes, in particular: "So you end up in some pretty hilarious situations, because X prefers width over height, so even though your monitor's 1600x1200, the sync range is big enough to fit 1680x1050, so you'll try to fit that, and lose." I interpret that as an X issue, not a lack of information in the inf file. > Stop trolling for divisive commentary, Telling other people what to do is about as divisive as you can get - and it doesn't work. -- Les Mikesell lesmikesell at gmail.com From dmc.fedora at filteredperception.org Mon Sep 3 01:41:15 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 20:41:15 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> Message-ID: <46DB663B.8060805@filteredperception.org> Jeff Spaleta wrote: > On 9/2/07, Douglas McClendon wrote: >> Honestly I can't vouch that this is ever the case. It is pure >> speculation on my part. But I for one get sick of hearing "you're >> hardware is broken, go suck an egg", when clearly that hardware is not >> broken enough to not work on windows, using the mechanisms they have in >> place (e.g. presumably reading the data from the driver cd). > > Okay.... here is where the conversation stops. If this is complete > speculation..then there is no constructive way forward. Adam Jackson > has already commented that in his opinion what is provided in the inf > files is not enough to fix the problem. I strongly suggest that you > go re-read everything that he wrote concerning the history of Fedora's > usage of the code Ubuntu is relying on now to parse inf files. Read > it... read it again.. and then when you think you understand it...read > it again. Here is the part that confuses me- " The whole reason we're _not_ using this very much - and that I've effectively stopped updating MonitorsDB - is because the inf files don't give you useful information. They give you sync ranges and that's about it. So you end up in some pretty hilarious situations, because X prefers width over height, so even though your monitor's 1600x1200, the sync range is big enough to fit 1680x1050, so you'll try to fit that, and lose. " This, please correct me if I'm wrong, is the relevant portion of the indisputable Mr Jackson's claim. I personally focus on this portion- " They give you sync ranges and that's about it. " To me, that seems like it might be enough. The fact that ubuntu is investing so much energy in this, makes me suggest that there might be something to it. The indisputable Mr. Jackson's followup as to why this is useless is " So you end up in some pretty hilarious situations, because X prefers width over height, so even though your monitor's 1600x1200, the sync range is big enough to fit 1680x1050, so you'll try to fit that, and lose. " Which sounds really stupid to me. It sounds like a trivial thing to me, to modify X so that it doesn't exclusively prefer width over height, resulting in the "hilarious situation" described. Honestly it doesn't sound very hard at all to modify X so that it understands that 1600x1200 is more preferable than 1680x1050. With that improvement, going only by my speculation, and the indisputable opinions/facts provided by Mr Jackson, I suspect there is room for value in the ubuntu-bulletproof-x method. Now, I didn't reread the indisputable Mr. Jackson's claims the 5 times that you suggested. Please feel free to ban me from this list, if you feel that I have nothing to offer the technical discussion. Regards, -dmc From jspaleta at gmail.com Mon Sep 3 02:17:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 2 Sep 2007 18:17:20 -0800 Subject: ubuntu bulletproof x In-Reply-To: <46DB663B.8060805@filteredperception.org> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> Message-ID: <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> On 9/2/07, Douglas McClendon wrote: > To me, that seems like it might be enough. The fact that ubuntu is > investing so much energy in this, makes me suggest that there might be > something to it. We've no idea how much "energy" Ubuntu is investing in this. We do know they are re-using code available in hwdata as seen in rhl/fedora. > Which sounds really stupid to me. It sounds like a trivial thing to me, > to modify X so that it doesn't exclusively prefer width over height, > resulting in the "hilarious situation" described. > Honestly it doesn't sound very hard at all to modify X so that it > understands that 1600x1200 is more preferable than 1680x1050. Go back and read what Mr. Jackson wrote..again...specifically the on-going work concerning using the maximum pixel clock setting to discriminate modes. > With that improvement, going only by my speculation, and the > indisputable opinions/facts provided by Mr Jackson, I suspect there is > room for value in the ubuntu-bulletproof-x method. Or perhaps there's none at all, and the work being done to expose inf file reading is a dead-end. Until we have a specific example inf file situation to discuss, it's impossible to go any further in this discussion. In any event I look forward to seeing Ubuntu supplied patches to Xorg to "fix" X so that we can all benefit from better hardware detection. -jef From dmc.fedora at filteredperception.org Mon Sep 3 02:40:36 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 21:40:36 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> Message-ID: <46DB7424.3020003@filteredperception.org> Jeff Spaleta wrote: > On 9/2/07, Douglas McClendon wrote: >> To me, that seems like it might be enough. The fact that ubuntu is >> investing so much energy in this, makes me suggest that there might be >> something to it. > > We've no idea how much "energy" Ubuntu is investing in this. We do > know they are re-using code available in hwdata as seen in rhl/fedora. Cmon man. The fact that you see so much press about 'bulletproof-x' does give you "an idea" about how much "energy" ubuntu is investing in this. No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you something. > >> Which sounds really stupid to me. It sounds like a trivial thing to me, >> to modify X so that it doesn't exclusively prefer width over height, >> resulting in the "hilarious situation" described. > >> Honestly it doesn't sound very hard at all to modify X so that it >> understands that 1600x1200 is more preferable than 1680x1050. > > Go back and read what Mr. Jackson wrote..again...specifically the > on-going work concerning using the maximum pixel clock setting to > discriminate modes. Why? Is there something in there describing how that work can automagically recreate the information that cannot be retrieved from a 'broken' edid hardware implementation, in which the data in the inf is correct? Going beyond 'speculation', I did a little googling, and found these two posts, which seem to suggest that the situation Olivier Galibert described, and which I have speculated, is a real scenario- http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html http://www.nvnews.net/vbulletin/showthread.php?t=83575 Again, I don't claim to be an X hacker, but it sounds like there are legitimate situations in which there is *NO* way for the X driver to autodetect the monitor specs, while *AT THE SAME TIME* it is possible to get useful information from inf files. Again, I could be wrong, but I really do think your telling me to STFU was uncalled for. > >> With that improvement, going only by my speculation, and the >> indisputable opinions/facts provided by Mr Jackson, I suspect there is >> room for value in the ubuntu-bulletproof-x method. > > Or perhaps there's none at all, and the work being done to expose inf > file reading is a dead-end. Until we have a specific example inf file > situation to discuss, it's impossible to go any further in this > discussion. In any event I look forward to seeing Ubuntu supplied > patches to Xorg to "fix" X so that we can all benefit from better > hardware detection. And perhaps, if fedora actually respected ubuntu, and kept up with their advances, rather than exclusively playing catch up, they wouldn't be having their asses handed to them. Yes, I know redhat has learned well from microsoft, that the way to be successful is to let others do the expensive trailblazing, and then only copy the trails that led to success, rather than those that led to failure. I have no problem with that attitude, I think it is intelligent. But please, this is just a mailinglist where people routinely talk about blowing goats. So don't tell me to STFU like the rest of the people on this list can't handle the signal/noise ratio. -dmc From airlied at redhat.com Mon Sep 3 03:25:40 2007 From: airlied at redhat.com (Dave Airlie) Date: Mon, 03 Sep 2007 13:25:40 +1000 Subject: ubuntu bulletproof x In-Reply-To: <46DB7424.3020003@filteredperception.org> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> Message-ID: <1188789940.20073.1.camel@localhost.localdomain> On Sun, 2007-09-02 at 21:40 -0500, Douglas McClendon wrote: > Jeff Spaleta wrote: > > On 9/2/07, Douglas McClendon wrote: > >> To me, that seems like it might be enough. The fact that ubuntu is > >> investing so much energy in this, makes me suggest that there might be > >> something to it. > > > > We've no idea how much "energy" Ubuntu is investing in this. We do > > know they are re-using code available in hwdata as seen in rhl/fedora. > > > Cmon man. The fact that you see so much press about 'bulletproof-x' > does give you "an idea" about how much "energy" ubuntu is investing in this. > > No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you > something. > > > > > >> Which sounds really stupid to me. It sounds like a trivial thing to me, > >> to modify X so that it doesn't exclusively prefer width over height, > >> resulting in the "hilarious situation" described. > > > >> Honestly it doesn't sound very hard at all to modify X so that it > >> understands that 1600x1200 is more preferable than 1680x1050. > > > > Go back and read what Mr. Jackson wrote..again...specifically the > > on-going work concerning using the maximum pixel clock setting to > > discriminate modes. > > Why? > > Is there something in there describing how that work can automagically > recreate the information that cannot be retrieved from a 'broken' edid > hardware implementation, in which the data in the inf is correct? Going > beyond 'speculation', I did a little googling, and found these two > posts, which seem to suggest that the situation Olivier Galibert > described, and which I have speculated, is a real scenario- > > http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html > > http://www.nvnews.net/vbulletin/showthread.php?t=83575 > > Again, I don't claim to be an X hacker, but it sounds like there are > legitimate situations in which there is *NO* way for the X driver to > autodetect the monitor specs, while *AT THE SAME TIME* it is possible to > get useful information from inf files. > > Again, I could be wrong, but I really do think your telling me to STFU > was uncalled for. > > > > > >> With that improvement, going only by my speculation, and the > >> indisputable opinions/facts provided by Mr Jackson, I suspect there is > >> room for value in the ubuntu-bulletproof-x method. > > > > Or perhaps there's none at all, and the work being done to expose inf > > file reading is a dead-end. Until we have a specific example inf file > > situation to discuss, it's impossible to go any further in this > > discussion. In any event I look forward to seeing Ubuntu supplied > > patches to Xorg to "fix" X so that we can all benefit from better > > hardware detection. > > > And perhaps, if fedora actually respected ubuntu, and kept up with their > advances, rather than exclusively playing catch up, they wouldn't be > having their asses handed to them. > > Yes, I know redhat has learned well from microsoft, that the way to be > successful is to let others do the expensive trailblazing, and then only > copy the trails that led to success, rather than those that led to > failure. I have no problem with that attitude, I think it is > intelligent. But please, this is just a mailinglist where people > routinely talk about blowing goats. So don't tell me to STFU like the > rest of the people on this list can't handle the signal/noise ratio. > You obviously don't know much about Ubuntu's development model or where most of their innovations actually come from, yes there is a problem here with Fedora, but it isn't the problem you think it is... Dave. From pemboa at gmail.com Mon Sep 3 03:42:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 2 Sep 2007 22:42:18 -0500 Subject: ubuntu bulletproof x In-Reply-To: <46DB7424.3020003@filteredperception.org> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> Message-ID: <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> On 9/2/07, Douglas McClendon wrote: > Jeff Spaleta wrote: > > On 9/2/07, Douglas McClendon wrote: > >> To me, that seems like it might be enough. The fact that ubuntu is > >> investing so much energy in this, makes me suggest that there might be > >> something to it. > > > > We've no idea how much "energy" Ubuntu is investing in this. We do > > know they are re-using code available in hwdata as seen in rhl/fedora. > > > Cmon man. The fact that you see so much press about 'bulletproof-x' > does give you "an idea" about how much "energy" ubuntu is investing in this. > > No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you > something. I'm not much a fan of the "pop" thing, more interested in the "right" thing. [ snip ] > And perhaps, if fedora actually respected ubuntu, and kept up with their > advances, rather than exclusively playing catch up, they wouldn't be > having their asses handed to them. What exactly are you talking about? Besides the fact that Fedora and Ubuntu aren't in competition, you seem to have something in mind. Please share. > Yes, I know redhat has learned well from microsoft, that the way to be > successful is to let others do the expensive trailblazing, and then only > copy the trails that led to success, rather than those that led to > failure. Feel free to ask some kernel maintainer how much Canonical contributes to the kernel. >I have no problem with that attitude, I think it is > intelligent. But please, this is just a mailinglist where people > routinely talk about blowing goats. That's way beyond an exaggeration. >So don't tell me to STFU like the > rest of the people on this list can't handle the signal/noise ratio. I can't. There's way too much noise on this particular thread. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sankarshan.mukhopadhyay at gmail.com Mon Sep 3 03:48:34 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 03 Sep 2007 09:18:34 +0530 Subject: ubuntu bulletproof x In-Reply-To: <46DB7424.3020003@filteredperception.org> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> Message-ID: <46DB8412.5030208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > And perhaps, if fedora actually respected ubuntu, and kept up with their > advances, rather than exclusively playing catch up, they wouldn't be > having their asses handed to them. I sense something amiss here when you say "respect". The fact remains that there are almost always more than one way to resolve a particular problem and according what I interpret of ajax's mail the way of choosing .inf files is kind of tricky. At a very broad level there would be considerable overlap in terms of work, innovation being pushed by various distributions into the upstream. I believe that reading the infrequent mails on this from Max, Rahul et al would be self explanatory. Let me share a personal experience here - for the better part of the first 3 years of using Linux (and constantly shifting between newer releases from Red Hat, Mandrake and SuSE) I was stuck with a X that refused to behave as expected all because of a SiS card. Would an .inf file reading "Bulletproof" idea helped then ? If you had asked me then I'd have mostly agreed. Now, I don't think so. There are multiple reasons why, but barring the technical ones which ajax is qualified to comment on, the reason I see is that we would send a strong signal to outside ODMs that it is proper not to do code push for Linux and software engineers on Linux can reverse engineer the black box. That is what I perceive as a very slippery slope. It starts off from X (and monitor configuration) which impacts the end user - but it has the potential to reacher deeper invasive depths at various levels where drivers and driver CDs for Windows just solve the problem while Linux struggles. *That* is something we really don't want. > Yes, I know redhat has learned well from microsoft, that the way to be > successful is to let others do the expensive trailblazing, and then only > copy the trails that led to success, rather than those that led to > failure. I have no problem with that attitude, I think it is > intelligent. But please, this is just a mailinglist where people > routinely talk about blowing goats. So don't tell me to STFU like the > rest of the people on this list can't handle the signal/noise ratio. I did not read it as people asking you to STFU. I'd rather say it was more of a request to step back and reasonably assess the choice. More often than not these days I see this choice between being pragmatic (let's just get this darn thing to work and shunt aside some of the niggling worries related to licenses and the like) and being dogmatic (let's not forget that there is only way to solve the issue and that is by collaborating with upstream in a transparent manner). I'd have to say that over the years I have been using Linux, I am happy to see that being dogmatic does help. - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw www.linkedin.com/in/sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG24QSXQZpNTcrCzMRAhGyAKCHavmz/5f9AbNhQYfW5NM5mePdwACfXoTB W02Qmn5XW/6pioCSjmzRc+0= =hd91 -----END PGP SIGNATURE----- From jspaleta at gmail.com Mon Sep 3 03:57:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 2 Sep 2007 19:57:00 -0800 Subject: ubuntu bulletproof x In-Reply-To: <46DB7424.3020003@filteredperception.org> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> Message-ID: <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> On 9/2/07, Douglas McClendon wrote: > Cmon man. The fact that you see so much press about 'bulletproof-x' > does give you "an idea" about how much "energy" ubuntu is investing in this. Nope. > > No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you > something. Yes, it tells me that people are interested in the problem space.. and that perception counts for a lot. > Is there something in there describing how that work can automagically > recreate the information that cannot be retrieved from a 'broken' edid > hardware implementation, in which the data in the inf is correct? Going > beyond 'speculation', I did a little googling, and found these two > posts, which seem to suggest that the situation Olivier Galibert > described, and which I have speculated, is a real scenario- > > http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html Perhaps you missed some very important points in this specific url you posted. First of all that post is from Mike Harris, who was employed by red hat at the time of that post. So approximately 2 years ago at least one redhatter, who was working with Xorg upstream development was thinking hard about this problem. This is noteworthy and significant concerning the history of developing a solution in the problem space. Again I'll point out that Mike references the same inf parsing script that Adam referenced. More importantly he said in that very posting that you qoute that using the inf information in the specific case being looked at in the thread didn't actually solve the issue. Because the information in the inf file is not sufficient to correct the issue being experienced. And that's the main thrust here in this thread. Inf information is not sufficient. Mr. Jackson is working to solve the issue of dealing with hardware detection, even working around broken EDID, in a more general way..as part of the ongoing Xorg development process. > > http://www.nvnews.net/vbulletin/showthread.php?t=83575 Please avoid referencing binary only drivers. It only complicates matters because we can't actually examine the code. > Again, I could be wrong, but I really do think your telling me to STFU > was uncalled for. I asked you to bring technical arguments to the discussion so that we can move it forward. Continuing to re-iterate that you feel a certain technical implementation is appropriate doesn't move things forward. I did not ask you to shut up... I asked you to start providing information which moves the discussion forward. > And perhaps, if fedora actually respected ubuntu, and kept up with their > advances, rather than exclusively playing catch up, they wouldn't be > having their asses handed to them. I'm not convinced Fedora is playing catch-up in technical achievements. What we are playing catch-up in is perception, no doubts about that. And for all the Fedora developers who are currently reading this thread. I want to take this opportunity to make sure I stress the importance of making the time to use the evolving Fedora Feature Roadmapping process, for as much of the work that you are doing in Fedora and upstream. I realize that some of you may consider the Feature roadmapping process as a distraction from getting the hard technical work done. But its one of our best tools to praise the work you are doing in the context of the larger distribution goals. -jef From dmc.fedora at filteredperception.org Mon Sep 3 04:15:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 23:15:25 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> Message-ID: <46DB8A5D.6070400@filteredperception.org> Jeff Spaleta wrote: >> http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html > > More importantly he said in that very posting that you qoute that > using the inf information in the specific case being looked at in the > thread didn't actually solve the issue. Which part of the message says this? Because the information in the > inf file is not sufficient to correct the issue being experienced. And > that's the main thrust here in this thread. Again, please elaborate. I'm not seeing this at all. What I see is this- " >> building monitors that "just work" will get that reputation, and >> be rewarded... and those that don't... Well, they'll learn or perish. > > And... market forces being what they are, the manufacturers > > You think Dell is going to perish? I'd put my money on the > opposite. I'll go as far as to claim that Dell could probably > make their monitor EDID information random numbers and only > affect their sales slightly if at all. Well.. That may be true for other reasons. Windows drivers look ^^^^^^^^^^^^^^^^^^^^^ at the shipped .inf files, or the .inf files fetch off the internet. ^^^^^^^^^^^^^^^^^^^^^^^^^ They are heavily invested into the Windows market: it's a large part of their sales share. But assuming they weren't: shipping bad EDID information would be a real hit for them. " and this " > > Even if such monitors are rare, they're not so rare when they're > shipped by one of the largest computer manufacturers in mass > volume. Even if only 10000 users experience such a problem, that > is about 1000 bug reports to wade through from angry users who > have hardware that "just works fine in Windows, and in all previous > X releases". Ok.... so... we should come up with a .inf file parser... :-( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ " > > Inf information is not sufficient. Mr. Jackson is working to solve > the issue of dealing with hardware detection, even working around > broken EDID, in a more general way..as part of the ongoing Xorg > development process. Another technical aspect, that I can point out regarding my understanding of Mr Jackson's point is this- His solution involves the user selecting generic monitors based on resolutions. I would argue, that there is (perhaps only valid for the users ubuntu is targeting) a signifigant number of users, that don't want to a) try to figure out the exact model number of their monitor or b) figure out the exact resolution their monitor supports when if they could instead just pop the windows driver cd that came with the monitor into the cdrom. -dmc From ngompa13 at gmail.com Mon Sep 3 04:19:37 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 2 Sep 2007 23:19:37 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <46DB1E60.4070100@filteredperception.org> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> <46DB1842.2060702@filteredperception.org> <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> <46DB1E60.4070100@filteredperception.org> Message-ID: <8278b1b0709022119y35a387a4n762a127e0c7bd1a7@mail.gmail.com> I'm talking about using a fully Win32-based installer to install Fedora into a disk image file and then run firstboot onward from the Linux side. I guess that would mean extending anaconda yet again to include more functionality... On 9/2/07, Douglas McClendon wrote: > > King InuYasha wrote: > > I dunno about booting a RW version of the livecd ext3 image and then > finish > > installation that way, it might be simpler just to go ahead and do > normal > > installation but instead to a file on the Windows partition within > Windows. > > Simply to not have the redundancy..... It could invoke firstboot > though.... > > > My theory, was that it would be less work to get ananconda to handle > that*, than it would be to port anaconda to windows. > > Again, this is only from the perspective of allowing the user to > download an installer in windows, and then reboot straight to their > installed linux, without the intermediary step of burning a bootable > install cd, and booting from it. > > From the perspective that I think you are talking about, of just doing > a 'normal installation' (e.g. download bootable installable iso, then > boot from it), it is indeed much simpler, and perhaps just a matter of > ressurrecting functionality that existed many years ago. > > -dmc > > * (especially if for personal rebootless reasons I was going to do most > of the foundation work anyway) > > > > > > On 9/2/07, Douglas McClendon wrote: > >> Jonathan Steffan wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> King InuYasha wrote: > >>>> Hello, > >>>> > >>>> I recently discovered a very interesting project called Wubi ( > >>>> http://wubi-installer.org/) which permits installation of > >>>> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and > >> makes the > >>>> appropriate boot entry changes to allow booting to Linux from the > disk > >> image > >>>> file in the Windows partition. Ubuntu Gutsy plans to add it to the > >> official > >>>> methods of installation, and I was wondering what you guys think > about > >>>> having something similar in Fedora? > >>>> > >>>> > >>> This would be neat and I've looked into it before. From the Virtual > >>> FUDCon, I've taken that a user needing a windows installer is not in > our > >>> target audience (at least not right now.) With regards to making it an > >>> "unofficial" installer to prove it's viability, I'm all for it. Fedora > >>> sponsored/official live images were sparked by community initiative, a > >>> 'from windows' installer might be an example in the future. I don't > >>> particularly like the way Wubi gets things done, but give the concept > >>> merit. I'd look at helping to do something similar, but using anaconda > >>> to do the install among other changes. > >> I think this is merely a matter of ressurrecting a long-dead feature. > >> Wasn't anaconda historically able to install to a file on a vfat > >> partition? > >> > >> Naturally during those dark ages when a RW ntfs driver was unavailable, > >> and the vast majority of windows users used ntfs rather than vfat, this > >> was not possible. > >> > >> The instant that an rw-ntfs driver was in fedora, I was drooling in > >> anticipation of this feature returning. > >> > >> Of course, having a native win32 installer would be pretty cool too, > for > >> all the reasons wubi is doing it. Interestingly, I can see a simple > >> win32 installer that just installs the livecd ext3 image as is, and > then > >> lets you run anaconda from an RW version of the livecd image once > >> rebooted into linux. In fact, the changes to get that incarnation of > >> anaconda to do the right thing, are nearly identical to the changes I > >> have been kicking around to support rebootless installation. (i.e. the > >> stuff anaconda tweaks neads to be the stuff from /, and not > >> /mnt/sysimage). > >> > >> bwa ha ha.... > >> > >> -dmc > >> > >> -- > >> 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 dmc.fedora at filteredperception.org Mon Sep 3 04:18:32 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 23:18:32 -0500 Subject: ubuntu bulletproof x In-Reply-To: <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> Message-ID: <46DB8B18.3010404@filteredperception.org> Arthur Pemberton wrote: > On 9/2/07, Douglas McClendon wrote: > [ snip ] > >> And perhaps, if fedora actually respected ubuntu, and kept up with their >> advances, rather than exclusively playing catch up, they wouldn't be >> having their asses handed to them. > > > What exactly are you talking about? Besides the fact that Fedora and > Ubuntu aren't in competition, you seem to have something in mind. > Please share. Fedora and Ubuntu aren't in competition? You really don't think there are a significant number of linux users, who make a choice between installing and using fedora, vs installing and using ubuntu? Really? I'll admit that every project/enterprise can be a non-zero-sum game where users are attracted that were not previously using a similar product/project. But to claim that there is no competition for users between fedora and ubunutu is ludicrous, IM-not-as-humble-as-it-ought-to-be-O. > > >> Yes, I know redhat has learned well from microsoft, that the way to be >> successful is to let others do the expensive trailblazing, and then only >> copy the trails that led to success, rather than those that led to >> failure. > > > Feel free to ask some kernel maintainer how much Canonical contributes > to the kernel. And what percentage of lines of code in fedora is the kernel? kernel != distro. I'm not saying you don't have a valid point. But in the open source world, where everybody is sharing yesterday's work equally, because that is the beauty of it, the question is "what have you done for me lately?" It would seem... that going by the number of users ubuntu is pulling in, that they have been doing something for their users. Something that IMO, fedora would be wise to respect and emulate. I don't care if you disagree, that is just what I think. Note, I don't mean emulate to the point of changing what fedora has learned to do right, over it's long history. I just mean that ajax's original response, sounded an aweful lot like "these ubuntu folks are just marketing work that we did". When in fact, after a little digging at the real issue, it becomes apparent that in order to make something "bulletproof", you have to be willing to do some things that for perhaps quite valid reasons, ajax and fedora seem quite unwilling to do. (i.e. use data from inf file on windows driver cd, at the expense of that tactic lowering the pressure on monitor manufacturers to not ship monitors with non existent, or non working edid implementations). > > >> I have no problem with that attitude, I think it is >> intelligent. But please, this is just a mailinglist where people >> routinely talk about blowing goats. > > > That's way beyond an exaggeration. Yes, but it was kind of funny wasn't it :) > > >> So don't tell me to STFU like the >> rest of the people on this list can't handle the signal/noise ratio. > > > I can't. There's way too much noise on this particular thread. And you are participating, rather than ignoring it because...? I presume you do use a threaded email reader? Or at least can visually ignore a topic based on subject line? -dmc From jspaleta at gmail.com Mon Sep 3 04:22:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 2 Sep 2007 20:22:55 -0800 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> References: <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> Message-ID: <604aa7910709022122q769bf351p71d9c74d2f914ee2@mail.gmail.com> On 9/2/07, Jeff Spaleta wrote: > Perhaps you missed some very important points in this specific url you > posted. First of all that post is from Mike Harris, who was employed > by red hat at the time of that post. So approximately 2 years ago at > least one redhatter, who was working with Xorg upstream development > was thinking hard about this problem. This is noteworthy and > significant concerning the history of developing a solution in the > problem space. Again I'll point out that Mike references the same inf > parsing script that Adam referenced. Correction.... I should have said: the thread from which your url comes from. I've inadvertently confused things with my mis-statement. Start reading the thread from: http://lists.freedesktop.org/pipermail/xorg/2005-October/010706.html and that should provide enough context. Though you are free to read all of the thread starting at: http://lists.freedesktop.org/pipermail/xorg/2005-October/010673.html -jef From dmc.fedora at filteredperception.org Mon Sep 3 04:29:17 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 23:29:17 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <8278b1b0709022119y35a387a4n762a127e0c7bd1a7@mail.gmail.com> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> <46DB1842.2060702@filteredperception.org> <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> <46DB1E60.4070100@filteredperception.org> <8278b1b0709022119y35a387a4n762a127e0c7bd1a7@mail.gmail.com> Message-ID: <46DB8D9D.2060001@filteredperception.org> King InuYasha wrote: > I'm talking about using a fully Win32-based installer to install Fedora into > a disk image file and then run firstboot onward from the Linux side. I guess > that would mean extending anaconda yet again to include more > functionality... Whether you put the logic in a (non-anaconda) fully win-32 based installer, or anaconda, or firstboot, it has to go somewhere. I think that the ideal answer would be the ability to modularize things like timezone selection, so that they could be easily moved between anaconda and firstboot (as has been mentioned in other recent threads). Basically the configuration has to happen somewhere. You can either ask the user a) in windows, during install b) in firstboot c) in anaconda running on the installed system d) assume and install a default configuration (i.e. like what people see on the livecd currently), and make sure the user knows the system-config-* tool to change the default. I'm not really partial to any of them. I say hack together a proof of concept asap, and then work on whatever seems to be the lowest hanging fruit for improving the user experience. -dmc > > On 9/2/07, Douglas McClendon wrote: >> King InuYasha wrote: >>> I dunno about booting a RW version of the livecd ext3 image and then >> finish >>> installation that way, it might be simpler just to go ahead and do >> normal >>> installation but instead to a file on the Windows partition within >> Windows. >>> Simply to not have the redundancy..... It could invoke firstboot >> though.... >> >> >> My theory, was that it would be less work to get ananconda to handle >> that*, than it would be to port anaconda to windows. >> >> Again, this is only from the perspective of allowing the user to >> download an installer in windows, and then reboot straight to their >> installed linux, without the intermediary step of burning a bootable >> install cd, and booting from it. >> >> From the perspective that I think you are talking about, of just doing >> a 'normal installation' (e.g. download bootable installable iso, then >> boot from it), it is indeed much simpler, and perhaps just a matter of >> ressurrecting functionality that existed many years ago. >> >> -dmc >> >> * (especially if for personal rebootless reasons I was going to do most >> of the foundation work anyway) >> >> >>> On 9/2/07, Douglas McClendon wrote: >>>> Jonathan Steffan wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> King InuYasha wrote: >>>>>> Hello, >>>>>> >>>>>> I recently discovered a very interesting project called Wubi ( >>>>>> http://wubi-installer.org/) which permits installation of >>>>>> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and >>>> makes the >>>>>> appropriate boot entry changes to allow booting to Linux from the >> disk >>>> image >>>>>> file in the Windows partition. Ubuntu Gutsy plans to add it to the >>>> official >>>>>> methods of installation, and I was wondering what you guys think >> about >>>>>> having something similar in Fedora? >>>>>> >>>>>> >>>>> This would be neat and I've looked into it before. From the Virtual >>>>> FUDCon, I've taken that a user needing a windows installer is not in >> our >>>>> target audience (at least not right now.) With regards to making it an >>>>> "unofficial" installer to prove it's viability, I'm all for it. Fedora >>>>> sponsored/official live images were sparked by community initiative, a >>>>> 'from windows' installer might be an example in the future. I don't >>>>> particularly like the way Wubi gets things done, but give the concept >>>>> merit. I'd look at helping to do something similar, but using anaconda >>>>> to do the install among other changes. >>>> I think this is merely a matter of ressurrecting a long-dead feature. >>>> Wasn't anaconda historically able to install to a file on a vfat >>>> partition? >>>> >>>> Naturally during those dark ages when a RW ntfs driver was unavailable, >>>> and the vast majority of windows users used ntfs rather than vfat, this >>>> was not possible. >>>> >>>> The instant that an rw-ntfs driver was in fedora, I was drooling in >>>> anticipation of this feature returning. >>>> >>>> Of course, having a native win32 installer would be pretty cool too, >> for >>>> all the reasons wubi is doing it. Interestingly, I can see a simple >>>> win32 installer that just installs the livecd ext3 image as is, and >> then >>>> lets you run anaconda from an RW version of the livecd image once >>>> rebooted into linux. In fact, the changes to get that incarnation of >>>> anaconda to do the right thing, are nearly identical to the changes I >>>> have been kicking around to support rebootless installation. (i.e. the >>>> stuff anaconda tweaks neads to be the stuff from /, and not >>>> /mnt/sysimage). >>>> >>>> bwa ha ha.... >>>> >>>> -dmc >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From dmc.fedora at filteredperception.org Mon Sep 3 04:44:40 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 02 Sep 2007 23:44:40 -0500 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709022122q769bf351p71d9c74d2f914ee2@mail.gmail.com> References: <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <604aa7910709022057y6165ad2gcb6ed3a44b1b36d2@mail.gmail.com> <604aa7910709022122q769bf351p71d9c74d2f914ee2@mail.gmail.com> Message-ID: <46DB9138.1020706@filteredperception.org> Jeff Spaleta wrote: > On 9/2/07, Jeff Spaleta wrote: >> Perhaps you missed some very important points in this specific url you >> posted. First of all that post is from Mike Harris, who was employed >> by red hat at the time of that post. So approximately 2 years ago at >> least one redhatter, who was working with Xorg upstream development >> was thinking hard about this problem. This is noteworthy and >> significant concerning the history of developing a solution in the >> problem space. Again I'll point out that Mike references the same inf >> parsing script that Adam referenced. > > Correction.... I should have said: > the thread from which your url comes from. > I've inadvertently confused things with my mis-statement. > > Start reading the thread from: > http://lists.freedesktop.org/pipermail/xorg/2005-October/010706.html > and that should provide enough context. I still remain unconvinced. In this post, Mike Harris is not claiming that the info from the .inf file is *NEVER* useful. Only that in this "particular" case, it is of no help. In fact, I find his use of quotation in 'or "can work" in X' to indicate that he understands that what he is saying is not an absolute. Specifically- " In general, you can expect that just because something works in Windows, doesn't mean anything about wether or not it works in X, or "can work" in X, because the source code for the driver in Windows is not the same source code for the driver in X. You can make the drivers in X do anything they can do in Windows, by fixing the driver to not have bugs. " What I read from that is *NOT* that there is *ZERO* potential use of linux reading .inf files. Maybe that is how you read it. Again, I have a feeling that you and I are arguing far too much about something that is outside each of our areas of expertise. But again, when people say something like this to me- " Okay.... here is where the conversation stops. " I tend to not shut up. I feel that even my 'speculation' was valid content for this mailinglist, and you stated otherwise. I disagreed. Good night. -dmc Though you are free to read > all of the thread > starting at: > http://lists.freedesktop.org/pipermail/xorg/2005-October/010673.html > > -jef > From pemboa at gmail.com Mon Sep 3 05:04:55 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Sep 2007 00:04:55 -0500 Subject: ubuntu bulletproof x In-Reply-To: <46DB8B18.3010404@filteredperception.org> References: <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> <46DB8B18.3010404@filteredperception.org> Message-ID: <16de708d0709022204g1b2392e9g5aa9f3ee5400848a@mail.gmail.com> On 9/2/07, Douglas McClendon wrote: > Arthur Pemberton wrote: > > On 9/2/07, Douglas McClendon wrote: > > > [ snip ] > > > >> And perhaps, if fedora actually respected ubuntu, and kept up with their > >> advances, rather than exclusively playing catch up, they wouldn't be > >> having their asses handed to them. > > > > > > What exactly are you talking about? Besides the fact that Fedora and > > Ubuntu aren't in competition, you seem to have something in mind. > > Please share. > > > Fedora and Ubuntu aren't in competition? I would say not. Unless the Ubuntu people think they are competing against Fedora. > You really don't think there are a significant number of linux users, > who make a choice between installing and using fedora, vs installing and > using ubuntu? They might be. But I wouldn't consider that competition. I've never gone "darn" I wish user Joe had gone with Fedora. The only real problem I have with a user choosing Fedora is that I cannot help them much if they do, since I've never used it, nor really intend to. > Really? Yes really. > I'll admit that every project/enterprise can be a non-zero-sum game > where users are attracted that were not previously using a similar > product/project. But to claim that there is no competition for users > between fedora and ubunutu is ludicrous, > IM-not-as-humble-as-it-ought-to-be-O. Well I don't really see competition for users as a real competition. And I certainty don't see any effort on Fedora side being put in to attract users (for better or worse) Maybe Ubuntu team really thinks there is some serious competition going on, I guess that would explain some things. > >> Yes, I know redhat has learned well from microsoft, that the way to be > >> successful is to let others do the expensive trailblazing, and then only > >> copy the trails that led to success, rather than those that led to > >> failure. > > > > > > Feel free to ask some kernel maintainer how much Canonical contributes > > to the kernel. > > And what percentage of lines of code in fedora is the kernel? > > kernel != distro. I'm glad you point that out. Seems like things Fedora do are more globally useful than what Ubuntu does. Since, for example, advancements to the kernel help everyone, advancements to the Ubuntu distro help mostly Ubuntu. > I'm not saying you don't have a valid point. But in the open source > world, where everybody is sharing yesterday's work equally, because that > is the beauty of it, the question is "what have you done for me lately?" Ok > It would seem... that going by the number of users ubuntu is pulling > in, that they have been doing something for their users. Something that > IMO, fedora would be wise to respect and emulate. Respect maybe... I'm not really sure about the emulate part. > I don't care if you > disagree, that is just what I think. Ok > Note, I don't mean emulate to the > point of changing what fedora has learned to do right, over it's long > history. I just mean that ajax's original response, sounded an aweful > lot like "these ubuntu folks are just marketing work that we did". When > in fact, after a little digging at the real issue, it becomes apparent > that in order to make something "bulletproof", you have to be willing to > do some things that for perhaps quite valid reasons, ajax and fedora > seem quite unwilling to do. (i.e. use data from inf file on windows > driver cd, at the expense of that tactic lowering the pressure on > monitor manufacturers to not ship monitors with non existent, or non > working edid implementations). Ok... I guessing calling it "bulletproof" anything just screams marketing to some people > >> I have no problem with that attitude, I think it is > >> intelligent. But please, this is just a mailinglist where people > >> routinely talk about blowing goats. > > > > > > That's way beyond an exaggeration. > > Yes, but it was kind of funny wasn't it :) It wasn't a very picture for my mind actually. > >> So don't tell me to STFU like the > >> rest of the people on this list can't handle the signal/noise ratio. > > > > > > I can't. There's way too much noise on this particular thread. > > And you are participating, rather than ignoring it because...? I ignored it at first, that's why the noise got to high. Should have made attention from the start. The subject didn't seem constructive, but the lifespan of the thread got me interesting > I presume you do use a threaded email reader? Or at least can visually > ignore a topic based on subject line? Yes and Yes > -dmc -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From fedora at leemhuis.info Mon Sep 3 05:43:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Sep 2007 07:43:29 +0200 Subject: globally useful vs. useful for the distribution (was: Re: ubuntu bulletproof x) In-Reply-To: <16de708d0709022204g1b2392e9g5aa9f3ee5400848a@mail.gmail.com> References: <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> <46DB8B18.3010404@filteredperception.org> <16de708d0709022204g1b2392e9g5aa9f3ee5400848a@mail.gmail.com> Message-ID: <46DB9F01.9000601@leemhuis.info> On 03.09.2007 07:04, Arthur Pemberton wrote: > On 9/2/07, Douglas McClendon wrote: >> Arthur Pemberton wrote: >>> On 9/2/07, Douglas McClendon wrote: > [...] >>>> Yes, I know redhat has learned well from microsoft, that the way to be >>>> successful is to let others do the expensive trailblazing, and then only >>>> copy the trails that led to success, rather than those that led to >>>> failure. >>> Feel free to ask some kernel maintainer how much Canonical contributes >>> to the kernel. >> And what percentage of lines of code in fedora is the kernel? >> kernel != distro. > I'm glad you point that out. Seems like things Fedora do are more > globally useful than what Ubuntu does. +1 And that's at least *afaics* not only true for Kernel-Space, but for other areas as well. > Since, for example, > advancements to the kernel help everyone, advancements to the Ubuntu > distro help mostly Ubuntu. Agreed as well. But I think we in Fedora-Land should put "advancements to the Fedora distro" *a bit higher* on our todo-List as well, as especially those things are what make a distro cool and "nice to use" (and thus influence the decision what distro to use). Faster system-start comes to my mind (which in parts is globally useful as well), support for encrypted filesystems in the installer, real "minimal"-installs, avoiding unnecessary dependencies/bloat , avoiding broken deps in the repo, Partition resizing in the installer and lots of (often small) similar things. CU knurd From nicolas.mailhot at laposte.net Mon Sep 3 05:47:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Sep 2007 07:47:48 +0200 Subject: ubuntu bulletproof x In-Reply-To: <46DB663B.8060805@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> Message-ID: <1188798468.3686.0.camel@rousalka.dyndns.org> Le dimanche 02 septembre 2007 ? 20:41 -0500, Douglas McClendon a ?crit : > Honestly it doesn't sound very hard at all to modify X so that it > understands that 1600x1200 is more preferable than 1680x1050. Is it? Widescreen owners would differ -- 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 Sep 3 05:49:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Sep 2007 07:49:53 +0200 Subject: ubuntu bulletproof x In-Reply-To: <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> Message-ID: <1188798593.3686.3.camel@rousalka.dyndns.org> Le dimanche 02 septembre 2007 ? 18:17 -0800, Jeff Spaleta a ?crit : > Or perhaps there's none at all, and the work being done to expose inf > file reading is a dead-end. Anyway people concerned about inf files better mount a task force and get info about the main screen manufacturers in the hardwaredb before the release. That's so much friendlier than having users do the parsing themselves. -- 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 chitlesh at fedoraproject.org Mon Sep 3 05:52:02 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 3 Sep 2007 07:52:02 +0200 Subject: request : manual override for interdependent package In-Reply-To: <20070821123350.5712ac5d@mentok.boston.redhat.com> References: <13dbfe4f0708060324x4ad5aa08led858a5b0613ba11@mail.gmail.com> <20070806090505.6c4c911e@ender> <13dbfe4f0708210914g5745ec1bjae71e2f84702333a@mail.gmail.com> <20070821123350.5712ac5d@mentok.boston.redhat.com> Message-ID: <13dbfe4f0709022252s4ab107d6p173d7506467d348c@mail.gmail.com> On 8/21/07, Jesse Keating wrote: > Done. Thanks, Now, I need "libgeda-20070902-1.fc7" for other geda packages in dist-fc7-build :) chitlesh -- http://clunixchit.blogspot.com From debarshi.ray at gmail.com Mon Sep 3 06:27:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 3 Sep 2007 11:57:55 +0530 Subject: rawhide report: 20070902 changes In-Reply-To: <200709022341.11930.opensource@till.name> References: <200709020714.l827EbQu031680@porkchop.devel.redhat.com> <3170f42f0709021428h6f42d350re3b55dea773e64f1@mail.gmail.com> <200709022341.11930.opensource@till.name> Message-ID: <3170f42f0709022327w4babe48by8b7c0ede235cd1bf@mail.gmail.com> > The -devel szbpackage contains a .pc file: > - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' > (for directory ownership and usability). Done. I have modified the original Spec & SRPM, and submitted a formal review request (https://bugzilla.redhat.com/show_bug.cgi?id=274891). Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tsmetana at redhat.com Mon Sep 3 07:10:17 2007 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Mon, 3 Sep 2007 09:10:17 +0200 Subject: source file audit - 2007-08-26 In-Reply-To: <20070827134237.5cde7f33@ghistelwchlohm.scrye.com> References: <20070827134237.5cde7f33@ghistelwchlohm.scrye.com> Message-ID: <20070903091017.50ee2b24.tsmetana@redhat.com> On Mon, 27 Aug 2007 13:42:37 -0600 Kevin Fenzi wrote: > Please do let me know if anyone spots false positives or issues... These three are OK in fact: > tsmetana:BADURL:ast-base-locale.2007-03-28.tgz:ksh > tsmetana:BADURL:ast-ksh.2007-06-28.tgz:ksh > tsmetana:BADURL:INIT.2007-06-28.tgz:ksh I guess the script must have received 403, because one has to login prior to downloading the khs sources (with "I accept www.opensource.org/licenses/cpl" as an username and "." as a password...). -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os From buildsys at redhat.com Mon Sep 3 07:12:49 2007 From: buildsys at redhat.com (Build System) Date: Mon, 3 Sep 2007 03:12:49 -0400 Subject: rawhide report: 20070903 changes Message-ID: <200709030712.l837CnJY022662@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 grig - 0.7.2-2.fc8.i386 requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE libreadline-java - 0.8.0-19.fc8.i386 requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.i386 requires libedit.so.0 moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) grig - 0.7.2-2.fc8.x86_64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) pygsl-devel - 0.9.1-4.fc8.x86_64 requires gsl.devel pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 grig - 0.7.2-2.fc8.ppc requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp libreadline-java - 0.8.0-19.fc8.ppc requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.ppc requires libedit.so.0 moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.ppc requires gsl.devel pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 grig - 0.7.2-2.fc8.ppc64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From mmahut at fedoraproject.org Mon Sep 3 07:43:39 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Mon, 03 Sep 2007 09:43:39 +0200 Subject: application layer packet classifier in Fedora? In-Reply-To: <200709022323.57295.opensource@till.name> References: <46DB178C.7080201@fedoraproject.org> <200709022323.57295.opensource@till.name> Message-ID: <46DBBB2B.6090703@fedoraproject.org> Hi Till, Till Maas wrote: > On So September 2 2007, Marek Mahut wrote: > >> Today, when building my QoS script for my home-made router, I found that >> there's none packer classifier in Fedora. I'm looking for something like >> l7-filter[1] or ipp2p[2]. Any hint for something similar already in >> Fedora? Or someone who can help me to package and build l7-filter for >> Fedora? > > Is the l7-filter userspace version good enough for you? The kernel version and > ipp2p may not make it into Fedora, because external kernel modules may be > banned in the future. To be on the safe side, it would be better to try to > integrate it into one of the other repositories. Yes, userspace version is good too. > Regards, > Till -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From radekvokal at gmail.com Mon Sep 3 10:19:18 2007 From: radekvokal at gmail.com (=?UTF-8?B?UmFkZWsgVm9rw6Fs?=) Date: Mon, 03 Sep 2007 12:19:18 +0200 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> Message-ID: <46DBDFA6.8080008@gmail.com> Debarshi 'Rishi' Ray wrote: >> Just do >> >> gconftool-2 --type string --set /apps/gnome-screensaver/lock_dialog_theme system >> >> to get that dialog. > > I just did it, and it looks really nice on my Rawhide desktop. > >> We turned it off by default, since some people were confused by it. > I'd rather see it configurable in gnome-screensaver-preferences. Radek From snecklifter at gmail.com Mon Sep 3 10:36:45 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 3 Sep 2007 11:36:45 +0100 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <46DBDFA6.8080008@gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <46DBDFA6.8080008@gmail.com> Message-ID: <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> On 03/09/07, Radek Vok?l wrote: > > Debarshi 'Rishi' Ray wrote: > >> Just do > >> > >> gconftool-2 --type string --set > /apps/gnome-screensaver/lock_dialog_theme system > >> > >> to get that dialog. > > > > I just did it, and it looks really nice on my Rawhide desktop. > > > >> We turned it off by default, since some people were confused by it. > > > > I'd rather see it configurable in gnome-screensaver-preferences. > I'd rather just see it configured as the default - it is certainly more pleasant to look at than the current method. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu_fedora at nicubunu.ro Mon Sep 3 10:48:43 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 03 Sep 2007 13:48:43 +0300 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <46DBDFA6.8080008@gmail.com> <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> Message-ID: <46DBE68B.70203@nicubunu.ro> Christopher Brown wrote: > > I'd rather just see it configured as the default - it is certainly more > pleasant to look at than the current method. If there is will to make it default, I am sure it will be trivial to get one with the Infinity look made by the Art Team -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From snecklifter at gmail.com Mon Sep 3 10:59:39 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 3 Sep 2007 11:59:39 +0100 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <46DBE68B.70203@nicubunu.ro> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <46DBDFA6.8080008@gmail.com> <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> <46DBE68B.70203@nicubunu.ro> Message-ID: <364d303b0709030359q36423cd2h9450b94cbd7c679a@mail.gmail.com> On 03/09/07, Nicu Buculei wrote: > > Christopher Brown wrote: > > > > I'd rather just see it configured as the default - it is certainly more > > pleasant to look at than the current method. > > If there is will to make it default, I am sure it will be trivial to get > one with the Infinity look made by the Art Team I've just enabled it and it brings up F7 artwork no problem. So either the artwork team have been making these and they have not been used or the code uses some standard image to generate the look. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Mon Sep 3 11:19:41 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 03 Sep 2007 13:19:41 +0200 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <1188577744.4620.2.camel@localhost.localdomain> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> Message-ID: <46DBEDCD.70501@gmail.com> Matthias Clasen wrote: > We turned it off by default, since some people were confused by it. > how is this confusing? +1 from me for turning it on by default. From nicu_fedora at nicubunu.ro Mon Sep 3 11:24:04 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 03 Sep 2007 14:24:04 +0300 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <364d303b0709030359q36423cd2h9450b94cbd7c679a@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <46DBDFA6.8080008@gmail.com> <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> <46DBE68B.70203@nicubunu.ro> <364d303b0709030359q36423cd2h9450b94cbd7c679a@mail.gmail.com> Message-ID: <46DBEED4.1010703@nicubunu.ro> Christopher Brown wrote: > > I've just enabled it and it brings up F7 artwork no problem. So either > the artwork team have been making these and they have not been used or > the code uses some standard image to generate the look. Of course, but I was talking about F8, where this dialog was not on the "To Do" list. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From fedora at camperquake.de Mon Sep 3 11:53:35 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 3 Sep 2007 13:53:35 +0200 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070901153242.GB16761@wolff.to> References: <46C9BF64.9040103@hi.is> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <200709010825.35407.sgrubb@redhat.com> <20070901153242.GB16761@wolff.to> Message-ID: <20070903135335.4172fcd8@lain.camperquake.de> Hi. On Sat, 1 Sep 2007 10:32:42 -0500, Bruno Wolff III wrote > For the disk drive part of this, it already exists. smartd does self > tests on disks and logs the messages. These messages get reported by > logwatch in an email message once a day. It would be nicer if smartd could call out to the notify daemon to make a window appear on the users desktop. Users do not read logwatch reports, the usually do not even get them. From sgrubb at redhat.com Mon Sep 3 12:08:48 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 3 Sep 2007 08:08:48 -0400 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070903135335.4172fcd8@lain.camperquake.de> References: <46C9BF64.9040103@hi.is> <20070901153242.GB16761@wolff.to> <20070903135335.4172fcd8@lain.camperquake.de> Message-ID: <200709030808.49370.sgrubb@redhat.com> On Monday 03 September 2007 07:53:35 Ralf Ertzinger wrote: > > For the disk drive part of this, it already exists. smartd does self > > tests on disks and logs the messages. These messages get reported by > > logwatch in an email message once a day. Does this only work for smart drives or all drives? What if you don't have smartd installed? rsyslog has its hands on all the interesting data. Its in a position to make these kind of alerts no matter what is installed on a system. > It would be nicer if smartd could call out to the notify daemon to make > a window appear on the users desktop. > > Users do not read logwatch reports, the usually do not even get them. Agreed. Besides, I've seen drives go from good to crap within an hour. A daily report would be too late to be of use. I'd rather see us develop the infrastructure for messaging around rsyslog so that each daemon does not need to be modified if there was something that an admin wanted to be alerted for. -Steve From jkeating at redhat.com Mon Sep 3 12:14:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Sep 2007 08:14:51 -0400 Subject: request : manual override for interdependent package In-Reply-To: <13dbfe4f0709022252s4ab107d6p173d7506467d348c@mail.gmail.com> References: <13dbfe4f0708060324x4ad5aa08led858a5b0613ba11@mail.gmail.com> <20070806090505.6c4c911e@ender> <13dbfe4f0708210914g5745ec1bjae71e2f84702333a@mail.gmail.com> <20070821123350.5712ac5d@mentok.boston.redhat.com> <13dbfe4f0709022252s4ab107d6p173d7506467d348c@mail.gmail.com> Message-ID: <20070903081451.5e8e723b@ender> On Mon, 3 Sep 2007 07:52:02 +0200 "Chitlesh GOORAH" wrote: > Thanks, Now, > I need "libgeda-20070902-1.fc7" for other geda packages in > dist-fc7-build :) Done. These really need to go to rel-eng at fedoraproject.org as I may not get to a thread on a mailing list for days at a time. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johannbg at hi.is Mon Sep 3 12:25:52 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Mon, 03 Sep 2007 12:25:52 +0000 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... Message-ID: <46DBFD50.5020505@hi.is> Faster system-start/shutdown! Service need to start on demand rather then during the boot up process or at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, printer service sis etc. ) It's better to have the user to go through setup/installation/initializations process ( they are used to it ) and have faster startup than enable lots of unwanted/unneeded service during startup "for everything works solution"! Application need to be able to adjust firewall to allow access for them selves. We don't like it but they noob user will and if your arguments are, the application will mess up my highly complicated netfilter/iptables firewall, routing rules than your smart enough to be able to *hash* an check box who would disable this feature in system-config-security, or at least offer a wider selection of services to open in s-c-s especially those who need more than just an port opening ( protocol 47 48 50 51 etc.. ). The noob user is not able to create there own *Custom* firewall rules. Service should be bound to certain interface ( lo eth* ) instead being configured default to listen to *. Let the majority fedora user community decide what should be the default application to use in gnome/kde to open/play/view etc files and which application will come with default installation ( in gnome/kde ), do research in what people are adding/changing/replacing to get better hint of what should be used as default app behavior or better yet let fedora user vote what should be used in new release in fedora ( browser pluggin maybe that would ask user to vote on what ( apps/fetures ) they want to see in next release of fedora vote counted and implemented after dev freeze? ). Application user interface should be kept simple and simple to use with advanced menu feature for the advanced user. Things should work as much as possible out of the box . 99% what normal user is doing ( surfing the web, reading his email, writing his paper etc should work out of the box ). There must be a (legal)way to enable 3 party repos during the installation process and set these things up for the noob user. ( moving the legal liability from fedora to the user, disclaimer or something he has to read, approve and press ok for ). If not move the Fedora HQ to Europe and create a legal and handicapped Fedora spin to be released in the states since everybody is so keen on suing everybody in the states. ( we still have some sanity and dignity left here in Europe, I said some :-) For their defence the states are young as a nation maybe this will grow of them. ) Offer encryption on user sensitive data during install or even by default on hardrive. ( browser cache, email cache etc or maybe offer the user to have his /home on encrypted partion ). What we do ( Surf the web,what we spend our money on etc ) is being monitor/catalog/profiled enough as is. Atleas if somebody gets his hands on your box/drive/laptop lets give him hard time to actually get your data. Lets try to start do see things from noob user perspective and not advanced/dev user perspective. We advanced/developers can handle our selfs the noob cant! Best regards Johann B. Ps. Why was minimal install ( no gui ) removed from anaconda? /Fedora by the user for the user.../ -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From debarshi.ray at gmail.com Mon Sep 3 12:34:31 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 3 Sep 2007 18:04:31 +0530 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <46DBDFA6.8080008@gmail.com> <364d303b0709030336i6b9f65a6j613396f54eea811@mail.gmail.com> Message-ID: <3170f42f0709030534p562758fawaf6b886a53458c19@mail.gmail.com> > I'd rather just see it configured as the default - it is certainly more > pleasant to look at than the current method. +1 Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jkeating at redhat.com Mon Sep 3 12:47:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Sep 2007 08:47:47 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DBFD50.5020505@hi.is> References: <46DBFD50.5020505@hi.is> Message-ID: <20070903084747.28e1e15e@ender> On Mon, 03 Sep 2007 12:25:52 +0000 ""J?hann B. Gu?mundsson"" wrote: > Why was minimal install ( no gui ) removed from anaconda? Because "minimal" meant way too many different things to different people. Instead we just give you control over the package set and let you even de-select the Base group (no yum for you!). Now everybody can define/select their own meaning of Minimal. (and remember, many non-english languages need X to display the fonts correctly. Not very friendly if we dismiss them as users.) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin.sourada at seznam.cz Mon Sep 3 12:58:33 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 14:58:33 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DBFD50.5020505@hi.is> References: <46DBFD50.5020505@hi.is> Message-ID: <1188824313.9729.25.camel@pc-notebook> On Mon, 2007-09-03 at 14:25 +0200, "J?hann B. Gu?mundsson" wrote: > Faster system-start/shutdown! Service need to start on demand rather > then during the boot up process or > at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, > printer service sis etc. ) It's better to have > the user to go through setup/installation/initializations process ( they > are used to it ) > and have faster startup than enable lots of unwanted/unneeded service > during startup "for everything works solution"! > +1 for this from here, BUT. Most of the nowadays notebooks has bluetooth in them, but it's turned off by default. You turn it on usually hitting or switching some button. As it is usually connected via USB internaly, it will not get detected by Anaconda or Kudzu, unless turned on. The bluetooth service, when running, however detects that bluetooth was plugged/turned on and appear in systray (unless set otherwise). While this is true for bluetooth, it might be similar for other services. I think we should rather take a loooong thought and add to FirstBoot one screen for selecting services, which would be easy and simple to use. You would have there a combo with Desktop/Notebook/Server choices, and some checkboxes for optional services (but with sane names). I can imagine that as nobody needs bluetooth on server, on Desktop nearly nobody needs running power manager, etc. We should take a thought and decide what services should be enabled by default and what services should be easily available for user enabling during first boot (most likely the cups one, but MUST be called something like Printer Support). > Application need to be able to adjust firewall to allow access for them > selves. We don't like it but they noob user will and if > your arguments are, the application will mess up my highly complicated > netfilter/iptables firewall, routing rules than your > smart enough to be able to *hash* an check box who would disable this > feature in system-config-security, or at least offer > a wider selection of services to open in s-c-s especially those who > need more than just an port opening ( protocol 47 48 50 51 etc.. ). > The noob user is not able to create there own *Custom* firewall rules. > I hope I am no so geeky user, but to this I'd tell NO, NO, NO. If opening ports, than not automatically, but via system-config-firewall. If it is designed nice enough I think everyone can handle it. SELinux is another topic though... But I don't use it, so here I cannot make any suggestions. > Service should be bound to certain interface ( lo eth* ) instead being > configured default to listen to *. > It cannot be? (I really don't know) > Let the majority fedora user community decide what should be the > default application to use in gnome/kde to open/play/view etc files > and which application will come with default installation ( in gnome/kde > ), do research in what people are adding/changing/replacing > to get better hint of what should be used as default app behavior or > better yet let fedora user vote what should be used in new release in fedora > ( browser pluggin maybe that would ask user to vote on what ( > apps/fetures ) they want to see in next release of fedora vote counted and > implemented after dev freeze? ). > +1 for this. The default applications need rethink, as well as default starters (the apps icons on panel). I think we need not to do a survey, mugshot serves good for that purpose [1]. > Application user interface should be kept simple and simple to use with > advanced menu feature for the advanced user. > Simple? Go for Gnome. Advanced? Go for KDE. I know, it's a lot of simplification, but generally people who want to set up everything use KDE and people who want things just work use GNOME. But being advanced user does not necessarily mean that you go with KDE... I don't think we need improvements in this case (maybe the pirut/pup and system-config-*, but that is being worked on continually). > Things should work as much as possible out of the box . > 99% what normal user is doing ( surfing the web, reading his email, > writing his paper etc should work out of the box ). > There must be a (legal)way to enable 3 party repos during the > installation process and set these things up for the noob user. > ( moving the legal liability from fedora to the user, disclaimer or > something he has to read, approve and press ok for ). > If not move the Fedora HQ to Europe and create a legal and handicapped > Fedora > spin to be released in the states since everybody is so keen on suing > everybody in the states. > ( we still have some sanity and dignity left here in Europe, I said some > :-) For their defence the states are young as a nation > maybe this will grow of them. ) > +1, but with this you should rather go ask on fedora/redhat legal. I don't think we could move Fedora HQ to Europe, but maybe there could be a legal way, how to help user with enabling third party repos (most likely livna or fresh, but not both) during the installation process. > Offer encryption on user sensitive data during install or even by > default on hardrive. > ( browser cache, email cache etc or maybe offer the user to have his > /home on encrypted partion ). > What we do ( Surf the web,what we spend our money on etc ) is being > monitor/catalog/profiled enough as is. > Atleas if somebody gets his hands on your box/drive/laptop lets give him > hard time to actually get your data. > AFAIK this is being worked on. Martin References: [1] http://mugshot.org/applications > Lets try to start do see things from noob user perspective and not > advanced/dev user perspective. > We advanced/developers can handle our selfs the noob cant! > > Best regards > Johann B. > > Ps. > Why was minimal install ( no gui ) removed from anaconda? > > /Fedora by the user for the user.../ > > -- > Johann B. Gudmundsson. RHCE,CCSA > Unix System Engineer. > IT Management. > Reiknistofnun University of Iceland. > Taeknigardi, Dunhaga 5. Email: johannbg at hi.is > IS-107 Reykjavik. Phone: +354-525-4267 > Iceland. Fax: +354-552-8801 > -------------- 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 Mon Sep 3 13:00:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Sep 2007 09:00:19 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188824313.9729.25.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> Message-ID: <20070903090019.1f746ae4@ender> On Mon, 03 Sep 2007 14:58:33 +0200 Martin Sourada wrote: > I think we should rather take a loooong thought and add to FirstBoot > one screen for selecting services, which would be easy and simple to > use. You would have there a combo with Desktop/Notebook/Server > choices, and some checkboxes for optional services (but with sane > names). I can imagine that as nobody needs bluetooth on server, on > Desktop nearly nobody needs running power manager, etc. We should > take a thought and decide what services should be enabled by default > and what services should be easily available for user enabling during > first boot (most likely the cups one, but MUST be called something > like Printer Support). Actually my feeling is that we should get rid of as many firstboot screens as possible and just pick reasonable defaults. The tools are there if a curious user needs to adjust something. So much of what we ask is just silly. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin.sourada at seznam.cz Mon Sep 3 13:18:26 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 15:18:26 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <20070903090019.1f746ae4@ender> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> Message-ID: <1188825506.9729.41.camel@pc-notebook> On Mon, 2007-09-03 at 15:00 +0200, Jesse Keating wrote: > On Mon, 03 Sep 2007 14:58:33 +0200 > Martin Sourada wrote: > > > I think we should rather take a loooong thought and add to FirstBoot > > one screen for selecting services, which would be easy and simple to > > use. You would have there a combo with Desktop/Notebook/Server > > choices, and some checkboxes for optional services (but with sane > > names). I can imagine that as nobody needs bluetooth on server, on > > Desktop nearly nobody needs running power manager, etc. We should > > take a thought and decide what services should be enabled by default > > and what services should be easily available for user enabling during > > first boot (most likely the cups one, but MUST be called something > > like Printer Support). > > Actually my feeling is that we should get rid of as many firstboot > screens as possible and just pick reasonable defaults. The tools are > there if a curious user needs to adjust something. So much of what we > ask is just silly. > Yes, most ARE, but the one with services could be useful. There is a batch of services that are useful on most of notebooks, but are unneeded on most of Desktops/Servers and vice versa. And we'd like to get rid of as much unneeded services as possible, so if we target the default ones with a thought of the target platform, it would be IMHO more effective. Maybe it could go to anaconda, but personally I think that first boot is better place for that. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- 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 kanarip at kanarip.com Mon Sep 3 13:21:30 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 15:21:30 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DBFD50.5020505@hi.is> References: <46DBFD50.5020505@hi.is> Message-ID: <46DC0A5A.6020607@kanarip.com> J?hann B. Gu?mundsson wrote: > Faster system-start/shutdown! Service need to start on demand rather > then during the boot up process or > at least if anaconda/kudzu don't detect it don't enable it ( bluetooth, > printer service sis etc. ) It's better to have > the user to go through setup/installation/initializations process ( they > are used to it ) > and have faster startup than enable lots of unwanted/unneeded service > during startup "for everything works solution"! > I guess the next generation of init-scripts is going to figure out what the user wants. You have a point on the bluetooth/printer item, but the "unwanted" services is just silly. > Application need to be able to adjust firewall to allow access for them > selves. We don't like it but they noob user will and if > your arguments are, the application will mess up my highly complicated > netfilter/iptables firewall, routing rules than your > smart enough to be able to *hash* an check box who would disable this > feature in system-config-security, or at least offer > a wider selection of services to open in s-c-s especially those who > need more than just an port opening ( protocol 47 48 50 51 etc.. ). > The noob user is not able to create there own *Custom* firewall rules. > If an application is allowed to change the firewall configuration why do we even include the firewall at all? What's next, applications that can modify the SELinux policies to allow themselves to run? I'm almost certain it should have said that if someone enables the webserver service (regardless of what actual software is providing the service), he should be asked whether he wants to open up his firewall for this/these new socket(s). > Service should be bound to certain interface ( lo eth* ) instead being > configured default to listen to *. > Right, because on one side you want to make things easier, but the bind address is /so easy/ to configure from any GUI administration tool, that you want to limit the bind to a certain interface only? What happens if there's no eth0? What happens if you have eth0, wlan0 and ppp0 and change between those interfaces because you are a roaming user? > Let the majority fedora user community decide what should be the > default application to use in gnome/kde to open/play/view etc files > and which application will come with default installation ( in gnome/kde > ), do research in what people are adding/changing/replacing > to get better hint of what should be used as default app behavior or > better yet let fedora user vote what should be used in new release in > fedora > ( browser pluggin maybe that would ask user to vote on what ( > apps/fetures ) they want to see in next release of fedora vote counted and > implemented after dev freeze? ). > I believe we have that already. > Application user interface should be kept simple and simple to use with > advanced menu feature for the advanced user. > Things should work as much as possible out of the box . > 99% what normal user is doing ( surfing the web, reading his email, > writing his paper etc should work out of the box ). I guess your wish got heard retroactively and implemented some years ago. > There must be a (legal)way to enable 3 party repos during the > installation process and set these things up for the noob user. God no! If we do that, we lose. On a personal note; I'd rather make it as hard as possible to ever use anything I can't read any source code of, or that isn't licensed to permit me to do whatever I want to do with it. > ( moving the legal liability from fedora to the user, disclaimer or > something he has to read, approve and press ok for ). > If not move the Fedora HQ to Europe and create a legal and handicapped > Fedora > spin to be released in the states since everybody is so keen on suing > everybody in the states. > ( we still have some sanity and dignity left here in Europe, I said some > :-) For their defence the states are young as a nation > maybe this will grow of them. ) > Right. Europe has sanity and dignity but the US don't. Right. *sigh* > Offer encryption on user sensitive data during install or even by > default on hardrive. > ( browser cache, email cache etc or maybe offer the user to have his > /home on encrypted partion ). > What we do ( Surf the web,what we spend our money on etc ) is being > monitor/catalog/profiled enough as is. Atleas if somebody gets his hands > on your box/drive/laptop lets give him hard time to actually get your data. May I ask how you imagine the user recovers his data if he looses his private key or passphrase? > > Lets try to start do see things from noob user perspective and not > advanced/dev user perspective. > We advanced/developers can handle our selfs the noob cant! > > Best regards > Johann B. > > Ps. > Why was minimal install ( no gui ) removed from anaconda? It wasn't. > /Fedora by the user for the user.../ *Users*, plural. Thank you. -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From chitlesh at fedoraproject.org Mon Sep 3 13:43:33 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 3 Sep 2007 15:43:33 +0200 Subject: rawhide missing /bin/hostname Message-ID: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> Hello there, rawhide is missing /bin/hostname /etc/profile: line 38: /bin/hostname: No such file or directory http://koji.fedoraproject.org/koji/getfile?taskID=145760&name=root.log regards, Chitlesh -- http://clunixchit.blogspot.com From mcepl at redhat.com Mon Sep 3 13:37:36 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Sep 2007 15:37:36 +0200 Subject: ubuntu bulletproof x References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB663B.8060805@filteredperception.org> <604aa7910709021917j1e1635d1ld6c0467690d9ed17@mail.gmail.com> <46DB7424.3020003@filteredperception.org> <16de708d0709022042g3438703ald637fc0e64f46aea@mail.gmail.com> <46DB8B18.3010404@filteredperception.org> Message-ID: On 2007-09-03, 04:18 GMT, Douglas McClendon wrote: >> Feel free to ask some kernel maintainer how much Canonical >> contributes >> to the kernel. > > And what percentage of lines of code in fedora is the kernel? > > kernel != distro. The same question could be I am afraid asked about Canonical's contribution to X, I am afraid, which is much closer to the topic of this thread. Matej From mackay_d at bellsouth.net Mon Sep 3 13:47:16 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 03 Sep 2007 08:47:16 -0500 Subject: Python 3.0 In-Reply-To: <46DAE9EC.6000001@gmail.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <1188748279.26358.3.camel@vorpal.macdev.com> <46DAE9EC.6000001@gmail.com> Message-ID: <1188827236.30160.34.camel@vorpal.macdev.com> On Sun, 2007-09-02 at 09:50 -0700, Toshio Kuratomi wrote: > > You do love to split hairs. It's clear from the minutes that FESCO was > > concerned that the functionality supplied by Zope should be available to > > Fedora Infrastructure, and didn't have to rely on F7 to supply it. The > > rest of us mortals didn't fare so well. > > > Heh. If you really want your hairs split, it's really the Fedora > Documentation Project that wants to use Zope/Plone. Infrastructure just > manages the services. :-) Perhaps it's time to shave my head. > Since that's not really the information you want, let's look at it this > another way: Do you have a team of people who are maintaining > zope/plone/python2.4 right now? Is it going well? How do they decide > which python modules to build for python2.4? Do they limit the bug > reports they deal with to bug reports against zope/plone or do they > handle bugs from people who are running python2.4 for other reasons? I don't, obviously. The zope/plone communities do, for zope and plone. And, the problem for the zope folks in migrating to 2.5 is that the python developers chose to modify the c/python api for the benefit of a very few people running simulations using huge datasets on 64-bit machines. I don't believe that the actual python syntax changes presented a problem. That, of course, is not going to be the case going to python 3.0 and beyond. > Most importantly, are they willing to commit to maintaining this stack > of packages for the life of F-7? Well, let's see. Looking in Bugzilla for python on FC6 (2.4), there are a total of twelve bug reports, five of which are dups, and one was not a bug. Of the remaining bugs, two were from rawhide, and the remaing four are still open (dating from Nov/Dec 2006). Those were presumably referred upstream to the python developers. Given all that, how much additional activity would you expect for an F7 (and probably F8) compat-python? > I'm no longer on FESCo but these were some of the questions that were > asked that have a technical justification and I highly suspect that the > current FESCo will listen to the answers to these questions as well when > deciding whether compat-python can exist within Fedora without putting > too much extra work on the rest of the distro. I would think that a bigger concern would be the suitability of python as a development platform for large projects. Don't get me wrong, I use python, and it's great for rapid development. It's not so great when the python developers consistently make changes that break compatibility so that you have to rework the code. > Finally, I want to keep stressing that FESCo did not ban zope or plone. > They discussed what the standard of commitment should be for a person > or team to maintain a compat-python package in Fedora. We wanted to > allow this goal to be met: > "[including] a wide range of packages that fits into the various > different needs of the users." The fact is that the zope/plone developers are going to have to play catch up for quite some time given the announced intentions of the python developers. If you're going to wait for them to get current, then you have effectively banned them for probably years to come. > But not at the expense of: > "[being] on the leading edge of free and open source technology, by > adopting and helping develop new features and version upgrades." > and > "[providing] a robust development platform for building software and > robust general integrated set of software that balances the needs for > both desktop and server users." Ironically, zope/plone IS a robust development platform. > The questions we wanted answered were to ensure that there was a > commitment by the packager(s) involved in compat-python2.4 to meet the > robustness goal for the life of the packages so that people working on > the leading edge goal didn't have to stop what they were doing and fix > problems with the compat- packages. Correct me if I'm wrong, but it looks like there was one update to python for fc6 going from python-2.4.3-18 on the installation iso to python-2.4.4-1. There are still four open bugs on the update. I'm guessing that the python developers aren't really jumping to get those fixed. Anyway, where is the evidence that such a situation would arise? > * Goals copied from: http://fedoraproject.org/wiki/Objectives > * Note: when Jeremy has a chance to reply to these messages he may have > a different perspective on FESCo's discussions as he was arguing the > opposite point of view as I was. Toshio, thank you very much for taking the time to give us your perspective. I appreciate it. Dave From jwboyer at jdub.homelinux.org Mon Sep 3 13:52:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 3 Sep 2007 08:52:22 -0500 Subject: rawhide missing /bin/hostname In-Reply-To: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> Message-ID: <20070903085222.2faa99a6@vader.jdub.homelinux.org> On Mon, 3 Sep 2007 15:43:33 +0200 "Chitlesh GOORAH" wrote: > Hello there, > > rawhide is missing /bin/hostname > > /etc/profile: line 38: /bin/hostname: No such file or directory > > http://koji.fedoraproject.org/koji/getfile?taskID=145760&name=root.log Your subject line is a bit misleading. Rawhide has /bin/hostname. The buildroot does not. I don't know why though. josh From mclasen at redhat.com Mon Sep 3 14:00:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 03 Sep 2007 10:00:57 -0400 Subject: rawhide missing /bin/hostname In-Reply-To: <20070903085222.2faa99a6@vader.jdub.homelinux.org> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> Message-ID: <1188828058.4628.2.camel@localhost.localdomain> On Mon, 2007-09-03 at 08:52 -0500, Josh Boyer wrote: > On Mon, 3 Sep 2007 15:43:33 +0200 > "Chitlesh GOORAH" wrote: > > > Hello there, > > > > rawhide is missing /bin/hostname > > > > /etc/profile: line 38: /bin/hostname: No such file or directory > > > > http://koji.fedoraproject.org/koji/getfile?taskID=145760&name=root.log > > Your subject line is a bit misleading. Rawhide has /bin/hostname. The > buildroot does not. I don't know why though. Wild guess: because setup doesn't require net-tools From ngompa13 at gmail.com Mon Sep 3 14:02:25 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 3 Sep 2007 09:02:25 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <46DB8D9D.2060001@filteredperception.org> References: <8278b1b0709020821k6525aa5as82066ba2e6ac43c6@mail.gmail.com> <46DB0150.30701@fedoraunity.org> <46DB1842.2060702@filteredperception.org> <8278b1b0709021316j32681a6awfc39352112923f1e@mail.gmail.com> <46DB1E60.4070100@filteredperception.org> <8278b1b0709022119y35a387a4n762a127e0c7bd1a7@mail.gmail.com> <46DB8D9D.2060001@filteredperception.org> Message-ID: <8278b1b0709030702w148b051cj3d6c2e5f8ff8bd0f@mail.gmail.com> Well, stability of Windows notwithstanding, Windows does have a good model of a firstboot interface when you buy a new computer. It lets you configure all the user-applicable settings afterward, which is something that I think should be implemented throughout the whole thing. Stuff like timezone could be set up in firstboot. But things like root password need to be set up in the Windows installer. For a non-anaconda-based Win32 installer, I might be able to help with that using NSIS (http://nsis.sf.net), since I have been working on NSIS installers for Windows-based apps I package up. On 9/2/07, Douglas McClendon wrote: > > King InuYasha wrote: > > I'm talking about using a fully Win32-based installer to install Fedora > into > > a disk image file and then run firstboot onward from the Linux side. I > guess > > that would mean extending anaconda yet again to include more > > functionality... > > Whether you put the logic in a (non-anaconda) fully win-32 based > installer, or anaconda, or firstboot, it has to go somewhere. > > I think that the ideal answer would be the ability to modularize things > like timezone selection, so that they could be easily moved between > anaconda and firstboot (as has been mentioned in other recent threads). > > Basically the configuration has to happen somewhere. You can either ask > the user > > a) in windows, during install > b) in firstboot > c) in anaconda running on the installed system > d) assume and install a default configuration (i.e. like what people see > on the livecd currently), and make sure the user knows the > system-config-* tool to change the default. > > > I'm not really partial to any of them. I say hack together a proof of > concept asap, and then work on whatever seems to be the lowest hanging > fruit for improving the user experience. > > -dmc > > > > > > > On 9/2/07, Douglas McClendon wrote: > >> King InuYasha wrote: > >>> I dunno about booting a RW version of the livecd ext3 image and then > >> finish > >>> installation that way, it might be simpler just to go ahead and do > >> normal > >>> installation but instead to a file on the Windows partition within > >> Windows. > >>> Simply to not have the redundancy..... It could invoke firstboot > >> though.... > >> > >> > >> My theory, was that it would be less work to get ananconda to handle > >> that*, than it would be to port anaconda to windows. > >> > >> Again, this is only from the perspective of allowing the user to > >> download an installer in windows, and then reboot straight to their > >> installed linux, without the intermediary step of burning a bootable > >> install cd, and booting from it. > >> > >> From the perspective that I think you are talking about, of just doing > >> a 'normal installation' (e.g. download bootable installable iso, then > >> boot from it), it is indeed much simpler, and perhaps just a matter of > >> ressurrecting functionality that existed many years ago. > >> > >> -dmc > >> > >> * (especially if for personal rebootless reasons I was going to do most > >> of the foundation work anyway) > >> > >> > >>> On 9/2/07, Douglas McClendon > wrote: > >>>> Jonathan Steffan wrote: > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA1 > >>>>> > >>>>> King InuYasha wrote: > >>>>>> Hello, > >>>>>> > >>>>>> I recently discovered a very interesting project called Wubi ( > >>>>>> http://wubi-installer.org/) which permits installation of > >>>>>> Ubuntu/Kubuntu/Xubuntu to a disk image file on a Windows drive and > >>>> makes the > >>>>>> appropriate boot entry changes to allow booting to Linux from the > >> disk > >>>> image > >>>>>> file in the Windows partition. Ubuntu Gutsy plans to add it to the > >>>> official > >>>>>> methods of installation, and I was wondering what you guys think > >> about > >>>>>> having something similar in Fedora? > >>>>>> > >>>>>> > >>>>> This would be neat and I've looked into it before. From the Virtual > >>>>> FUDCon, I've taken that a user needing a windows installer is not in > >> our > >>>>> target audience (at least not right now.) With regards to making it > an > >>>>> "unofficial" installer to prove it's viability, I'm all for it. > Fedora > >>>>> sponsored/official live images were sparked by community initiative, > a > >>>>> 'from windows' installer might be an example in the future. I don't > >>>>> particularly like the way Wubi gets things done, but give the > concept > >>>>> merit. I'd look at helping to do something similar, but using > anaconda > >>>>> to do the install among other changes. > >>>> I think this is merely a matter of ressurrecting a long-dead feature. > >>>> Wasn't anaconda historically able to install to a file on a vfat > >>>> partition? > >>>> > >>>> Naturally during those dark ages when a RW ntfs driver was > unavailable, > >>>> and the vast majority of windows users used ntfs rather than vfat, > this > >>>> was not possible. > >>>> > >>>> The instant that an rw-ntfs driver was in fedora, I was drooling in > >>>> anticipation of this feature returning. > >>>> > >>>> Of course, having a native win32 installer would be pretty cool too, > >> for > >>>> all the reasons wubi is doing it. Interestingly, I can see a simple > >>>> win32 installer that just installs the livecd ext3 image as is, and > >> then > >>>> lets you run anaconda from an RW version of the livecd image once > >>>> rebooted into linux. In fact, the changes to get that incarnation of > >>>> anaconda to do the right thing, are nearly identical to the changes I > >>>> have been kicking around to support rebootless installation. (i.e. > the > >>>> stuff anaconda tweaks neads to be the stuff from /, and not > >>>> /mnt/sysimage). > >>>> > >>>> bwa ha ha.... > >>>> > >>>> -dmc > >>>> > >>>> -- > >>>> 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 > >> > > > > -- > 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 mackay_d at bellsouth.net Mon Sep 3 14:03:35 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 03 Sep 2007 09:03:35 -0500 Subject: Python 3.0 In-Reply-To: <20070902172406.2ac86ab9@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> Message-ID: <1188828215.30160.43.camel@vorpal.macdev.com> On Sun, 2007-09-02 at 17:24 -0500, Josh Boyer wrote: > On Sun, 02 Sep 2007 10:59:28 -0500 > "David G. Mackay" wrote: > > > > And for the record, I do use Fedora. Rawhide at home, latest release > > > at work. On every machine I own. That covers the gamut of primary > > > arches Fedora has (i686, x86_64, ppc, ppc64). > > > > > > josh > > > > And what do you do when you require functionality that's not in Fedora? > > Depends. If it's outside the scope of Fedora, such as codecs, etc I > certainly don't expect Fedora to fill that need. If it's within the > realm of Fedora, and it's not present yet I package it up myself. If > it's already in Fedora and it's lacking something I need, I work with > upstream to get it in place so it will follow naturally to Fedora. So you really rely on your ability to extend Fedora to make it do what you want. I understand the problems with the codecs, and expect that, were it legal to do so, they would be included. The problems stemming from the need for a compat-python are a bit different. Given the fact that python breaks compatibility with itself rather badly on a regualar basis, I suspect that your problems working with upstream developers are going to increase, and Fedora's own in-house projects may very well need a compat-python. Dave From mackay_d at bellsouth.net Mon Sep 3 14:08:00 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 03 Sep 2007 09:08:00 -0500 Subject: Python 3.0 In-Reply-To: <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> Message-ID: <1188828480.30160.49.camel@vorpal.macdev.com> On Sun, 2007-09-02 at 23:44 +0100, Jonathan Underwood wrote: > You do realize there is a currently supported Fedora release which > includes Zope, Plone and python 2.4? I have a machine running FC6 with Zope and Plone. It will probably be migrated to Centos 5 soon as FC6 support will probably go away before 2008. And. who knows, it might become a critical enough app that I'll spring for RHEL5 support. Dave From martin.sourada at seznam.cz Mon Sep 3 14:08:28 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 16:08:28 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC0A5A.6020607@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> Message-ID: <1188828508.9729.63.camel@pc-notebook> On Mon, 2007-09-03 at 15:21 +0200, Jeroen van Meeuwen wrote: > God no! If we do that, we lose. On a personal note; I'd rather make it > as hard as possible to ever use anything I can't read any source code > of, or that isn't licensed to permit me to do whatever I want to do with it. > I guess he meant rather GPL software that cannot be shipped in U.S. due to patent issues, as most of the software provided by the most widely used third party repos (livna and fresh) is GPL. There are many examples suggesting why this should be as easy as possible - ability to play legally bought DVDs, ability to play mp3, DivX, H.264, ... audio/video. Ability to install mplayer during installation, ability to install gstreamer-plugins-{ugly,bad}... If we do not support this we loose. And remember, all the things I am talking about are licenced under licences that are acceptable into Fedora, only the damn U.S. wrongly implemented patents for software (where they actually rather hinder progress than encourage it) prohibits us from shipping them with Fedora. Proprietary drivers are there as well, but that's not why we should make these repos easy accessible. We should encourage usage of FOSS software, but how can we do that when we are prohibited by U.S. laws to ship FOSS software that implements patented things? And no, I cannot play DVDs using vanilla Fedora and no, theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, I can use ogg vorbis instead of mp3, but then my HW player will not play them. > Right. Europe has sanity and dignity but the US don't. Right. There's a point in it, but nevertheless it's not true. US do sometimes suck, but in other things the EU does as well. Martin -------------- 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 Mon Sep 3 14:18:42 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 03 Sep 2007 10:18:42 -0400 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> Message-ID: <1188829122.4628.10.camel@localhost.localdomain> On Sat, 2007-09-01 at 07:57 +0530, Debarshi 'Rishi' Ray wrote: > > Just do > > > > gconftool-2 --type string --set /apps/gnome-screensaver/lock_dialog_theme system > > > > to get that dialog. > > I just did it, and it looks really nice on my Rawhide desktop. > > > We turned it off by default, since some people were confused by it. > > How can one be confused by such a thing? > The original implementation tied the greeter theme to the selected screensaver, so that the fedora-branded dialog would only appear for the "flying fedora" saver. That was what some people found confusing. Later, the lock dialog theming was changed to be keyed off a gconf key. FWIW, I don't think turning it on by default would be a problem. From sundaram at fedoraproject.org Mon Sep 3 14:17:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 03 Sep 2007 19:47:37 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188825506.9729.41.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> Message-ID: <46DC1781.80702@fedoraproject.org> Martin Sourada wrote: >> > Yes, most ARE, but the one with services could be useful. There is a > batch of services that are useful on most of notebooks, but are unneeded > on most of Desktops/Servers and vice versa. And we'd like to get rid of > as much unneeded services as possible, so if we target the default ones > with a thought of the target platform, it would be IMHO more effective. > Maybe it could go to anaconda, but personally I think that first boot is > better place for that. Asking the user in this case is the wrong answer. Don't expect the user to cherry pick services to enable/disable during installation. If users want to do that they can do it post installation or use kickstart. Rahul From kanarip at kanarip.com Mon Sep 3 14:31:39 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 16:31:39 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188828508.9729.63.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> Message-ID: <46DC1ACB.7020300@kanarip.com> Martin Sourada wrote: > On Mon, 2007-09-03 at 15:21 +0200, Jeroen van Meeuwen wrote: >> God no! If we do that, we lose. On a personal note; I'd rather make it >> as hard as possible to ever use anything I can't read any source code >> of, or that isn't licensed to permit me to do whatever I want to do with it. >> > I guess he meant rather GPL software that cannot be shipped in U.S. due > to patent issues, as most of the software provided by the most widely > used third party repos (livna and fresh) is GPL. There are many examples > suggesting why this should be as easy as possible - ability to play > legally bought DVDs, ability to play mp3, DivX, H.264, ... audio/video. > Ability to install mplayer during installation, ability to install > gstreamer-plugins-{ugly,bad}... > If a legally bought DVD doesn't play on Fedora, that doesn't mean the real problem lies within Fedora. If you disagree; how does that make it a Fedora problem exactly? > If we do not support this we loose. We are strong fighters in the army of the Free (as in Freedom, not Gratis). We lose some, but we win an awful lot. And remember, all the things I am > talking about are licenced under licences that are acceptable into > Fedora, only the damn U.S. wrongly implemented patents for software > (where they actually rather hinder progress than encourage it) prohibits > us from shipping them with Fedora. Proprietary drivers are there as > well, but that's not why we should make these repos easy accessible. > > We should encourage usage of FOSS software, but how can we do that when > we are prohibited by U.S. laws to ship FOSS software that implements > patented things? And no, I cannot play DVDs using vanilla Fedora and no, > theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, > I can use ogg vorbis instead of mp3, but then my HW player will not play > them. > Restrictively patented software may, in your and many others' opinion, still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free in the most pure sense of the word; If I can't share what I use, freely, with someone else just because there so happens to be an ocean in between and my buddy is living in the states; that to me isn't free. No matter how we may differ in opinion though, freedom is essential; I think we all agree on that. Fedora however seems to consider freedom to be /freedom for everyone/, so independent from where you live or what the local law says you can or cannot do. That is what I encourage. -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From martin.sourada at seznam.cz Mon Sep 3 14:44:23 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 16:44:23 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC1781.80702@fedoraproject.org> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <46DC1781.80702@fedoraproject.org> Message-ID: <1188830663.9729.71.camel@pc-notebook> On Mon, 2007-09-03 at 16:17 +0200, Rahul Sundaram wrote: > Martin Sourada wrote: > > >> > > Yes, most ARE, but the one with services could be useful. There is a > > batch of services that are useful on most of notebooks, but are unneeded > > on most of Desktops/Servers and vice versa. And we'd like to get rid of > > as much unneeded services as possible, so if we target the default ones > > with a thought of the target platform, it would be IMHO more effective. > > Maybe it could go to anaconda, but personally I think that first boot is > > better place for that. > > Asking the user in this case is the wrong answer. Don't expect the user > to cherry pick services to enable/disable during installation. If users > want to do that they can do it post installation or use kickstart. > > Rahul > If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of question then yes. If we ask him do you have notebook, desktop or server, than it is right to ask him. And having these three different platforms means different needed services. Which precisely are these need not to be known by the person who is questioned. But there are also services we cannot know if user will need it or not, but still has such names, that user cannot guess for what they are. Cups is one example. Many users do not want this by default (they don't have a printer connected to their PC), but others do, even if they are just ordinary users, knowing nothing about services. If we ask them, do you want to turn printer support on, he will know the answer. That is my point, I hope it is clear enough. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Mon Sep 3 14:49:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 3 Sep 2007 09:49:05 -0500 Subject: Python 3.0 In-Reply-To: <1188828215.30160.43.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> Message-ID: <20070903094905.3d3b53af@vader.jdub.homelinux.org> On Mon, 03 Sep 2007 09:03:35 -0500 "David G. Mackay" wrote: > On Sun, 2007-09-02 at 17:24 -0500, Josh Boyer wrote: > > On Sun, 02 Sep 2007 10:59:28 -0500 > > "David G. Mackay" wrote: > > > > > > And for the record, I do use Fedora. Rawhide at home, latest release > > > > at work. On every machine I own. That covers the gamut of primary > > > > arches Fedora has (i686, x86_64, ppc, ppc64). > > > > > > > > josh > > > > > > And what do you do when you require functionality that's not in Fedora? > > > > Depends. If it's outside the scope of Fedora, such as codecs, etc I > > certainly don't expect Fedora to fill that need. If it's within the > > realm of Fedora, and it's not present yet I package it up myself. If > > it's already in Fedora and it's lacking something I need, I work with > > upstream to get it in place so it will follow naturally to Fedora. > > So you really rely on your ability to extend Fedora to make it do what > you want. I understand the problems with the codecs, and expect that, > were it legal to do so, they would be included. The problems stemming > from the need for a compat-python are a bit different. Given the fact > that python breaks compatibility with itself rather badly on a regualar > basis, I suspect that your problems working with upstream developers are > going to increase, and Fedora's own in-house projects may very well need > a compat-python. Well, two things: 1) You asked what I do when Fedora lacks something _I_ need. That has never included zope/plone or really any other python app. So, at a personal level, I'm not really impacted here. But my approach would not differ it I was. 2) Fedora has quite a few in-house python projects and none of them have needed a compat package so far. Whether that is because of internal whip cracking to port to newer python, or because people are just that motivated I have no idea. I don't work on any of those projects. All that being said, it is _extremely_ important to remember that just because it's not in Fedora doesn't mean it's bad. If people need a compat python package, then they can by all means create one themselves and slap it into a third party repo for others to use. Take Ignacio for example. While I disagree that Fedora as a _distro_ needs a python3.0 alpha package at the moment, I applaud his efforts to get it packaged and shared. I think that is a very worthwhile effort, and I'm glad he's done so. I only wish something like that would have happened for zope/plone in the F7 timeframe. (And maybe it did, I just am not aware of it.) josh From johannbg at hi.is Mon Sep 3 14:56:54 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Mon, 03 Sep 2007 14:56:54 +0000 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC0A5A.6020607@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> Message-ID: <46DC20B6.1010901@hi.is> Jeroen van Meeuwen wrote: > J?hann B. Gu?mundsson wrote: >> Faster system-start/shutdown! Service need to start on demand rather >> then during the boot up process or >> at least if anaconda/kudzu don't detect it don't enable it ( >> bluetooth, printer service sis etc. ) It's better to have >> the user to go through setup/installation/initializations process ( >> they are used to it ) >> and have faster startup than enable lots of unwanted/unneeded >> service during startup "for everything works solution"! >> > > I guess the next generation of init-scripts is going to figure out > what the user wants. You have a point on the bluetooth/printer item, > but the "unwanted" services is just silly. > >> Application need to be able to adjust firewall to allow access for >> them selves. We don't like it but they noob user will and if >> your arguments are, the application will mess up my highly >> complicated netfilter/iptables firewall, routing rules than your >> smart enough to be able to *hash* an check box who would disable this >> feature in system-config-security, or at least offer >> a wider selection of services to open in s-c-s especially those who >> need more than just an port opening ( protocol 47 48 50 51 etc.. ). >> The noob user is not able to create there own *Custom* firewall rules. >> > > If an application is allowed to change the firewall configuration why > do we even include the firewall at all? What's next, applications that > can modify the SELinux policies to allow themselves to run? > You still need to be root to enable these (chkconfig ) services so why not let it open access for it self while you enable the service. If you have custom firewall rules check the hash box to disable this so doesn't mess up firewall rules. Regarding the SElinux I cannot predict the future tho I would mind having that ability > I'm almost certain it should have said that if someone enables the > webserver service (regardless of what actual software is providing the > service), he should be asked whether he wants to open up his firewall > for this/these new socket(s). > >> Service should be bound to certain interface ( lo eth* ) instead >> being configured default to listen to *. >> > > Right, because on one side you want to make things easier, but the > bind address is /so easy/ to configure from any GUI administration > tool, that you want to limit the bind to a certain interface only? > What happens if there's no eth0? What happens if you have eth0, wlan0 > and ppp0 and change between those interfaces because you are a roaming > user? > It should not still be set to listen to all interfaces >> Let the majority fedora user community decide what should be the >> default application to use in gnome/kde to open/play/view etc files >> and which application will come with default installation ( in >> gnome/kde ), do research in what people are adding/changing/replacing >> to get better hint of what should be used as default app behavior or >> better yet let fedora user vote what should be used in new release in >> fedora >> ( browser pluggin maybe that would ask user to vote on what ( >> apps/fetures ) they want to see in next release of fedora vote >> counted and >> implemented after dev freeze? ). >> > > I believe we have that already. > Ok where I wanna vote against use of Totem and Evolution System-config-network as default and vote for VLC and Thunderbird and NetworkManager instead... >> Application user interface should be kept simple and simple to use >> with advanced menu feature for the advanced user. Things should work >> as much as possible out of the box . >> 99% what normal user is doing ( surfing the web, reading his email, >> writing his paper etc should work out of the box ). > > I guess your wish got heard retroactively and implemented some years ago. We are behind in supporting media in browser ( java mplayer plugin etc ) > >> There must be a (legal)way to enable 3 party repos during the >> installation process and set these things up for the noob user. > > God no! If we do that, we lose. On a personal note; I'd rather make it > as hard as possible to ever use anything I can't read any source code > of, or that isn't licensed to permit me to do whatever I want to do > with it. > Hum wonder if noobs like reading source don't think so... >> ( moving the legal liability from fedora to the user, disclaimer or >> something he has to read, approve and press ok for ). >> If not move the Fedora HQ to Europe and create a legal and >> handicapped Fedora >> spin to be released in the states since everybody is so keen on suing >> everybody in the states. >> ( we still have some sanity and dignity left here in Europe, I said >> some :-) For their defence the states are young as a nation >> maybe this will grow of them. ) >> > > Right. Europe has sanity and dignity but the US don't. Right. > > *sigh* > >> Offer encryption on user sensitive data during install or even by >> default on hardrive. >> ( browser cache, email cache etc or maybe offer the user to have his >> /home on encrypted partion ). >> What we do ( Surf the web,what we spend our money on etc ) is being >> monitor/catalog/profiled enough as is. Atleas if somebody gets his >> hands on your box/drive/laptop lets give him hard time to actually >> get your data. > > May I ask how you imagine the user recovers his data if he looses his > private key or passphrase? > I don't you just get screwed.. >> >> Lets try to start do see things from noob user perspective and not >> advanced/dev user perspective. >> We advanced/developers can handle our selfs the noob cant! >> >> Best regards >> Johann B. >> >> Ps. >> Why was minimal install ( no gui ) removed from anaconda? > > It wasn't. > >> /Fedora by the user for the user.../ > > *Users*, plural. Thank you. > Best regards Johann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From sundaram at fedoraproject.org Mon Sep 3 14:55:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 03 Sep 2007 20:25:36 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188830663.9729.71.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <46DC1781.80702@fedoraproject.org> <1188830663.9729.71.camel@pc-notebook> Message-ID: <46DC2068.5030302@fedoraproject.org> Martin Sourada wrote: >> > If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of > question then yes. If we ask him do you have notebook, desktop or > server, than it is right to ask him. Whether a system is a laptop or not can be detected by the installer. Desktop/Server usages can be quite fuzzy and you can't really determine which services to run based on such simplistic questions. And having these three different > platforms means different needed services. Which precisely are these > need not to be known by the person who is questioned. But there are also > services we cannot know if user will need it or not, but still has such > names, that user cannot guess for what they are. Cups is one example. > Many users do not want this by default (they don't have a printer > connected to their PC), but others do, even if they are just ordinary > users, knowing nothing about services. If we ask them, do you want to > turn printer support on, he will know the answer. That is my point, I > hope it is clear enough. Cups and many other services can just be started on demand. Look up Dbus system activation. http://blog.fubar.dk/?p=93 Rahul From martin.sourada at seznam.cz Mon Sep 3 15:02:08 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 17:02:08 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC1ACB.7020300@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> Message-ID: <1188831728.9729.88.camel@pc-notebook> On Mon, 2007-09-03 at 16:31 +0200, Jeroen van Meeuwen wrote: > If a legally bought DVD doesn't play on Fedora, that doesn't mean the > real problem lies within Fedora. If you disagree; how does that make it > a Fedora problem exactly? > No, but the crowd of people he is talking about will think it is a Fedora problem. In this case it's problem of libdvdcss legality. Yes it is open source software, freely redistributable, but its usage is questionable. As far as I understand wiki page about this [1], it is legal to use it, even in the U.S. > > If we do not support this we loose. > > We are strong fighters in the army of the Free (as in Freedom, not > Gratis). We lose some, but we win an awful lot. > Yes, and software patents, as they are, are hindering our efforts. We cannot ship mp3 support. And why? Free (as in freedom) software for playing and encoding it is available. But software patents take the choice away from us. > And remember, all the things I am > > talking about are licenced under licences that are acceptable into > > Fedora, only the damn U.S. wrongly implemented patents for software > > (where they actually rather hinder progress than encourage it) prohibits > > us from shipping them with Fedora. Proprietary drivers are there as > > well, but that's not why we should make these repos easy accessible. > > > > We should encourage usage of FOSS software, but how can we do that when > > we are prohibited by U.S. laws to ship FOSS software that implements > > patented things? And no, I cannot play DVDs using vanilla Fedora and no, > > theora isn't better than H.264 (implemented in FOSS x264 codec) and yes, > > I can use ogg vorbis instead of mp3, but then my HW player will not play > > them. > > > > Restrictively patented software may, in your and many others' opinion, > still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free > in the most pure sense of the word; If I can't share what I use, freely, > with someone else just because there so happens to be an ocean in > between and my buddy is living in the states; that to me isn't free. > The mp3 software (for example) itself isn't patented, but as far as I understand the patent thing, it violates the patents. Software patents are just defective by design, but it is not a problem of the idea, it's a problem of the implementation, IMHO. > No matter how we may differ in opinion though, freedom is essential; I > think we all agree on that. Fedora however seems to consider freedom to > be /freedom for everyone/, so independent from where you live or what > the local law says you can or cannot do. That is what I encourage. > Agreed, but it's not our fault, that in some countries people have less freedom from the start (i.e. are not able to use free, as in freedom, software because of some, not very sane, banns). I think we should promote freedom not only by supplying only applications guaranteeing such freedom, but also help to fight for their rights to those, who have them lessened (e.g. in the case of software patents). Martin References: [1] http://en.wikipedia.org/wiki/Libdvdcss PS: the software patents could be a good thing, but if they could apply only to harder things to think out and only to the person who come with the idea. Also patent fees should be paid only in cases where the one who uses the patented thing gain money from it, which FOSS software certainly don't. The current state of things is similar like if you were forced to pay patent fees to wheel-patent-holder (which could be some really big company) if you make your own wheel and give it to your kid for playing. > -- > Kind regards, > > Jeroen van Meeuwen > -kanarip > > -- > http://www.kanarip.com/ > RHCE, LPIC-2, MCP, CCNA > C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 > -------------- 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 martin.sourada at seznam.cz Mon Sep 3 15:12:23 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 17:12:23 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC2068.5030302@fedoraproject.org> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <46DC1781.80702@fedoraproject.org> <1188830663.9729.71.camel@pc-notebook> <46DC2068.5030302@fedoraproject.org> Message-ID: <1188832343.9729.98.camel@pc-notebook> On Mon, 2007-09-03 at 16:55 +0200, Rahul Sundaram wrote: > Martin Sourada wrote: > > >> > > If we ask him do-you-want-to-turn-cups-hal-hcid-services-on kind of > > question then yes. If we ask him do you have notebook, desktop or > > server, than it is right to ask him. > > Whether a system is a laptop or not can be detected by the installer. > Desktop/Server usages can be quite fuzzy and you can't really determine > which services to run based on such simplistic questions. > Well, on desktop you usually don't need any server services (http server, ftp server, ssh server,...) on server you usually don't need any desktop services (bluetooth, ConsoleKit, to name some) and some of the notebook services. Also there are cases where you combine e.g. laptop with server (like in my case, having mostly laptop services, but vsftpd and postfix in addition), but these users know, how to enable services by themselves. > And having these three different > > platforms means different needed services. Which precisely are these > > need not to be known by the person who is questioned. But there are also > > services we cannot know if user will need it or not, but still has such > > names, that user cannot guess for what they are. Cups is one example. > > Many users do not want this by default (they don't have a printer > > connected to their PC), but others do, even if they are just ordinary > > users, knowing nothing about services. If we ask them, do you want to > > turn printer support on, he will know the answer. That is my point, I > > hope it is clear enough. > > Cups and many other services can just be started on demand. Look up Dbus > system activation. > > http://blog.fubar.dk/?p=93 > Then it is sufficient to enable cups automatically, when user adds first printer. But still the defaults remain and I have many running services in default install, I'll clearly have no use for. If the difference between notebook/desktop/server is one or two service, than it is not much, if the difference is bigger you will have significantly longer boot time, only because having services you clearly don't need. Martin > Rahul > -------------- 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 kanarip at kanarip.com Mon Sep 3 15:17:58 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 17:17:58 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC20B6.1010901@hi.is> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <46DC20B6.1010901@hi.is> Message-ID: <46DC25A6.5020606@kanarip.com> J?hann B. Gu?mundsson wrote: > Jeroen van Meeuwen wrote: >> If an application is allowed to change the firewall configuration why >> do we even include the firewall at all? What's next, applications that >> can modify the SELinux policies to allow themselves to run? >> > > You still need to be root to enable these (chkconfig ) services so why > not let it open access for it self while you enable the service. > If you have custom firewall rules check the hash box to disable this so > doesn't mess up firewall rules. Regarding the SElinux I cannot predict > the future > tho I would mind having that ability > You do not necessarily have to be root but gain root privileges. In addition, some applications like HAL daemon can enable (for example) CUPS (ergo without the user being root or gaining any privileges); would you want to let that automatically open up your firewall? SELinux in this case does get a little help. If you run authconfig to configure NIS and choose to update the configuration files (--update), it enables the ypbind as well as the allow_ypbind SELinux boolean. "service httpd start" however should not, under any circumstance, enable any of the SELinux booleans involved with where httpd may look for files. >>> Service should be bound to certain interface ( lo eth* ) instead >>> being configured default to listen to *. >>> >> >> Right, because on one side you want to make things easier, but the >> bind address is /so easy/ to configure from any GUI administration >> tool, that you want to limit the bind to a certain interface only? >> What happens if there's no eth0? What happens if you have eth0, wlan0 >> and ppp0 and change between those interfaces because you are a roaming >> user? >> > It should not still be set to listen to all interfaces Good argument, I guess we really need to reconsider. >>> Let the majority fedora user community decide what should be the >>> default application to use in gnome/kde to open/play/view etc files [...] >> >> I believe we have that already. >> > Ok where I wanna vote against use of Totem and Evolution > System-config-network as default and vote for VLC and Thunderbird and > NetworkManager instead... > Try the wiki Feature pages. These threads will most definitely not get the feature you want. VLC btw is out-of-the-question. >>> Application user interface should be kept simple and simple to use >>> with advanced menu feature for the advanced user. Things should work >>> as much as possible out of the box . >>> 99% what normal user is doing ( surfing the web, reading his email, >>> writing his paper etc should work out of the box ). >> >> I guess your wish got heard retroactively and implemented some years ago. > We are behind in supporting media in browser ( java mplayer plugin etc ) Do you think there might be a reason why these are not in Fedora? >> >>> There must be a (legal)way to enable 3 party repos during the >>> installation process and set these things up for the noob user. >> >> God no! If we do that, we lose. On a personal note; I'd rather make it >> as hard as possible to ever use anything I can't read any source code >> of, or that isn't licensed to permit me to do whatever I want to do >> with it. >> > > Hum wonder if noobs like reading source don't think so... > Consider what a noob does on any other Operating System Of (No-)Choice. It isn't much easier. >> May I ask how you imagine the user recovers his data if he looses his >> private key or passphrase? >> > > I don't you just get screwed.. > Nice, that'll bring us good user experience. -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From sundaram at fedoraproject.org Mon Sep 3 15:24:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 03 Sep 2007 20:54:13 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188832343.9729.98.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <46DC1781.80702@fedoraproject.org> <1188830663.9729.71.camel@pc-notebook> <46DC2068.5030302@fedoraproject.org> <1188832343.9729.98.camel@pc-notebook> Message-ID: <46DC271D.80603@fedoraproject.org> Martin Sourada wrote: >> > Well, on desktop you usually don't need any server services (http > server, ftp server, ssh server,...) Like I said it's fuzzy. GNOME file sharing program called gnome-user-share depends on httpd for example. >> http://blog.fubar.dk/?p=93 >> > Then it is sufficient to enable cups automatically, when user adds first > printer. But still the defaults remain and I have many running services > in default install, I'll clearly have no use for Those are bugs that need to be fixed. Asking the user here is just a workaround to paper over this problem. Rahul From s.adam at diffingo.com Mon Sep 3 15:33:20 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Mon, 03 Sep 2007 11:33:20 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188825506.9729.41.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> Message-ID: <1188833600.32365.13.camel@Diffingo.localdomain> > > Yes, most ARE, but the one with services could be useful. There is a > batch of services that are useful on most of notebooks, but are unneeded > on most of Desktops/Servers and vice versa. And we'd like to get rid of > as much unneeded services as possible, so if we target the default ones > with a thought of the target platform, it would be IMHO more effective. > Maybe it could go to anaconda, but personally I think that first boot is > better place for that. +1 - A simple list with a service's name and a short description would be very useful, and not to mention cut boot time. IMHO there are many services they Fedora has enabled by default which are relatively useless for most users. The whole rpc/nfs gang of services, sendmail - Why? I may be wrong, but I doubt that most of our users want to be running NFS and mail servers on a default install. Besides that, running Bluetooth on a machine without Bluetooth-capable hardware is a complete waste of resources. A simple example: [X] Laptop services [ ] Bluetooth - Bluetooth connectivity services [X] NetworkManager - Easy management of network connections [ ] Avahi - Zeroconf network discovery [ ] NFS - File sharing [ ] sendmail - Mail server [ ] SMB - Samba (Windows) file and printer sharing [ ] SSH - Remote shell Laptop Services would enable cpuspeed and apmd, as desktop machines don't really *need* those services. The rest can be enabled as the user sees fit. Stewart From lesmikesell at gmail.com Mon Sep 3 15:34:36 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 03 Sep 2007 10:34:36 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC1ACB.7020300@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> Message-ID: <46DC298C.70604@gmail.com> Jeroen van Meeuwen wrote: > > Restrictively patented software may, in your and many others' opinion, > still be Free; I my opinion, it's not. It may be FOSS, but it isn't Free > in the most pure sense of the word; If I can't share what I use, freely, > with someone else just because there so happens to be an ocean in > between and my buddy is living in the states; that to me isn't free. But surprisingly, nobody makes any effort to share the burden of system administration, which is why so few people use unix-like systems and why there are endless discussions like this of what packages should and shouldn't be installed or bundled in some small set of configuration choices that aren't going to fit everyone or be exactly right for any purpose. What we really need is a push-button way for anyone who thinks they have built a system that is well configured for some particular use to publish his installed package list - and perhaps add a repository in the odd case that he needed something not in the usual repositories. Then anyone else should be able to read through the descriptions of the purposes for these configurations and why the admin that created them believes his setup is the best, pick one, and automatically get the same set of packages installed on his own computer - and periodically repeat to track the updates. This would eliminate about 90% of the reasons for having multiple distributions with confusing differences and give the effect of having an expert system administrator tuning each installation for its intended use. If free software distribution was really about sharing instead of providing a complex base to sell support and services, I think something like this would have been done long ago. -- Les Mikesell lesmikesell at gmail.com From johannbg at hi.is Mon Sep 3 15:46:25 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Mon, 03 Sep 2007 15:46:25 +0000 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC25A6.5020606@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <46DC20B6.1010901@hi.is> <46DC25A6.5020606@kanarip.com> Message-ID: <46DC2C51.9010803@hi.is> Let's not forget to take the noob user perspective on things regarding my thread.. Jeroen van Meeuwen wrote: > J?hann B. Gu?mundsson wrote: >> Jeroen van Meeuwen wrote: >>> If an application is allowed to change the firewall configuration >>> why do we even include the firewall at all? What's next, >>> applications that can modify the SELinux policies to allow >>> themselves to run? >>> >> >> You still need to be root to enable these (chkconfig ) services so >> why not let it open access for it self while you enable the service. >> If you have custom firewall rules check the hash box to disable this >> so doesn't mess up firewall rules. Regarding the SElinux I cannot >> predict the future >> tho I would mind having that ability >> > > You do not necessarily have to be root but gain root privileges. In > addition, some applications like HAL daemon can enable (for example) > CUPS (ergo without the user being root or gaining any privileges); > would you want to let that automatically open up your firewall? > > SELinux in this case does get a little help. If you run authconfig to > configure NIS and choose to update the configuration files (--update), > it enables the ypbind as well as the allow_ypbind SELinux boolean. > "service httpd start" however should not, under any circumstance, > enable any of the SELinux booleans involved with where httpd may look > for files. > Finding the golden way between service firewall and SElinux on what should/could be open automatically takes time and discussion. Rome wasn't build in one day, but the fewer steps needed to get things working for the noob user the better. At least more checkbox for more service should be added to s-c-s specially the vpn/protocols related one... >>>> Service should be bound to certain interface ( lo eth* ) instead >>>> being configured default to listen to *. >>>> >>> >>> Right, because on one side you want to make things easier, but the >>> bind address is /so easy/ to configure from any GUI administration >>> tool, that you want to limit the bind to a certain interface only? >>> What happens if there's no eth0? What happens if you have eth0, >>> wlan0 and ppp0 and change between those interfaces because you are a >>> roaming user? >>> >> It should not still be set to listen to all interfaces > > Good argument, I guess we really need to reconsider. > >>>> Let the majority fedora user community decide what should be the >>>> default application to use in gnome/kde to open/play/view etc files > [...] >>> >>> I believe we have that already. >>> >> Ok where I wanna vote against use of Totem and Evolution >> System-config-network as default and vote for VLC and Thunderbird and >> NetworkManager instead... >> > > Try the wiki Feature pages. These threads will most definitely not get > the feature you want. VLC btw is out-of-the-question. The Fedora users should vote what is and what is out in default install, so up with poll my vote will be one of thousand, hundred of thousand and even millions. > >>>> Application user interface should be kept simple and simple to use >>>> with advanced menu feature for the advanced user. Things should >>>> work as much as possible out of the box . >>>> 99% what normal user is doing ( surfing the web, reading his email, >>>> writing his paper etc should work out of the box ). >>> >>> I guess your wish got heard retroactively and implemented some years >>> ago. >> We are behind in supporting media in browser ( java mplayer plugin etc ) > > Do you think there might be a reason why these are not in Fedora? > >>> >>>> There must be a (legal)way to enable 3 party repos during the >>>> installation process and set these things up for the noob user. >>> >>> God no! If we do that, we lose. On a personal note; I'd rather make >>> it as hard as possible to ever use anything I can't read any source >>> code of, or that isn't licensed to permit me to do whatever I want >>> to do with it. >>> >> >> Hum wonder if noobs like reading source don't think so... >> > > Consider what a noob does on any other Operating System Of > (No-)Choice. It isn't much easier. > >>> May I ask how you imagine the user recovers his data if he looses >>> his private key or passphrase? >>> >> >> I don't you just get screwed.. >> > > Nice, that'll bring us good user experience. > -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From kanarip at kanarip.com Mon Sep 3 16:00:43 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 18:00:43 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC298C.70604@gmail.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> <46DC298C.70604@gmail.com> Message-ID: <46DC2FAB.2030602@kanarip.com> Les Mikesell wrote: > Jeroen van Meeuwen wrote: >> >> Restrictively patented software may, in your and many others' opinion, >> still be Free; I my opinion, it's not. It may be FOSS, but it isn't >> Free in the most pure sense of the word; If I can't share what I use, >> freely, with someone else just because there so happens to be an ocean >> in between and my buddy is living in the states; that to me isn't free. > > But surprisingly, nobody makes any effort to share the burden of system > administration, which is why so few people use unix-like systems and why > there are endless discussions like this of what packages should and > shouldn't be installed or bundled in some small set of configuration > choices that aren't going to fit everyone or be exactly right for any > purpose. > I'm sorry, you should not have read "If I can't share what I use" as: "If I cannot publish a list of my installed software and their settings" rather then "I'm using something that is free here, but once I start using it elsewhere it may be illegal or I might get sued." > What we really need is a push-button way for anyone who thinks they have > built a system that is well configured for some particular use to > publish his installed package list - and perhaps add a repository in the > odd case that he needed something not in the usual repositories. Then > anyone else should be able to read through the descriptions of the > purposes for these configurations and why the admin that created them > believes his setup is the best, pick one, and automatically get the same > set of packages installed on his own computer - and periodically repeat > to track the updates. This would eliminate about 90% of the reasons for > having multiple distributions with confusing differences and give the > effect of having an expert system administrator tuning each installation > for its intended use. > If you're gonna build profiles of what software is suited for what purpose, along with the ideal settings, I'm curious what a user would think of a 3-million-profiles-website he can choose the most fit profile from. -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From dominik at greysector.net Mon Sep 3 16:05:47 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 3 Sep 2007 18:05:47 +0200 Subject: ubuntu bulletproof x In-Reply-To: <46DB3D8D.9060309@gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> Message-ID: <20070903160547.GA8541@ryvius.pekin.waw.pl> On Monday, 03 September 2007 at 00:47, Les Mikesell wrote: > Dominik 'Rathann' Mierzejewski wrote: > >On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: > >[...] > >>(and again, for the sake of argument, lets pretend that doing anything > >>from a command line, or editing a text file, or researching obscure > >>specs about your monitor, is not an option for the users in question) > > > >I think that for majority of monitors out there, you can find the specs > >in 5 minutes using Google. > > And then translate that into a modeline with another 3 days of googling. That could be easily automated, but for now: man gtf Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From kanarip at kanarip.com Mon Sep 3 16:12:15 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 03 Sep 2007 18:12:15 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC2C51.9010803@hi.is> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <46DC20B6.1010901@hi.is> <46DC25A6.5020606@kanarip.com> <46DC2C51.9010803@hi.is> Message-ID: <46DC325F.8080605@kanarip.com> J?hann B. Gu?mundsson wrote: > Let's not forget to take the noob user perspective on things regarding > my thread.. > Somehow I think we do have users in mind somewhere, when trying to develop, build and release this distribution, along with it's new software we create and all new techniques we adopt, but somehow every once in a while someone seems to forget that this "noob user perspective" is not what the key audience of Fedora has. -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From lesmikesell at gmail.com Mon Sep 3 17:02:05 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 03 Sep 2007 12:02:05 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC2FAB.2030602@kanarip.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> <46DC298C.70604@gmail.com> <46DC2FAB.2030602@kanarip.com> Message-ID: <46DC3E0D.4080400@gmail.com> Jeroen van Meeuwen wrote: >>> Restrictively patented software may, in your and many others' >>> opinion, still be Free; I my opinion, it's not. It may be FOSS, but >>> it isn't Free in the most pure sense of the word; If I can't share >>> what I use, freely, with someone else just because there so happens >>> to be an ocean in between and my buddy is living in the states; that >>> to me isn't free. >> >> But surprisingly, nobody makes any effort to share the burden of >> system administration, which is why so few people use unix-like >> systems and why there are endless discussions like this of what >> packages should and shouldn't be installed or bundled in some small >> set of configuration choices that aren't going to fit everyone or be >> exactly right for any purpose. >> > > I'm sorry, you should not have read "If I can't share what I use" as: > > "If I cannot publish a list of my installed software and their settings" > > rather then > > "I'm using something that is free here, but once I start using it > elsewhere it may be illegal or I might get sued." My take on it is that there is a lot of work that can be shared with no legal interference and no one bothers to do it. Why not solve the problem that can be solved easily first? >> What we really need is a push-button way for anyone who thinks they >> have built a system that is well configured for some particular use to >> publish his installed package list - and perhaps add a repository in >> the odd case that he needed something not in the usual repositories. >> Then anyone else should be able to read through the descriptions of >> the purposes for these configurations and why the admin that created >> them believes his setup is the best, pick one, and automatically get >> the same set of packages installed on his own computer - and >> periodically repeat to track the updates. This would eliminate about >> 90% of the reasons for having multiple distributions with confusing >> differences and give the effect of having an expert system >> administrator tuning each installation for its intended use. >> > > If you're gonna build profiles of what software is suited for what > purpose, along with the ideal settings, I'm curious what a user would > think of a 3-million-profiles-website he can choose the most fit profile > from. It's approximately the same problem as deciding what song to listen to, or what news story to read next, something people do all the time, and more useful than wading through the gazillion different distributions on distrowatch, each trying to be a general purpose solution not really matched to any specific use. I doubt if there are 3 million people arrogant enough to call themselves experts, though. There are probably a few hundred configurations that an expert sysadmin would build for 99% of uses and the good ones would sort themselves out by reputation and be improved by user feedback. The base distribution could then just concentrate on getting all the programs into a repository and keeping their interfaces compatible so you didn't have to throw everything out to update. -- Les Mikesell lesmikesell at gmail.com From j.w.r.degoede at hhs.nl Mon Sep 3 17:38:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 03 Sep 2007 19:38:53 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188833600.32365.13.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> Message-ID: <46DC46AD.2080702@hhs.nl> Stewart Adam wrote: >> >> Yes, most ARE, but the one with services could be useful. There is a >> batch of services that are useful on most of notebooks, but are unneeded >> on most of Desktops/Servers and vice versa. And we'd like to get rid of >> as much unneeded services as possible, so if we target the default ones >> with a thought of the target platform, it would be IMHO more effective. >> Maybe it could go to anaconda, but personally I think that first boot is >> better place for that. > +1 - A simple list with a service's name and a short description would > be very useful, and not to mention cut boot time. IMHO there are many > services they Fedora has enabled by default which are relatively useless > for most users. The whole rpc/nfs gang of services, sendmail - Why? I > may be wrong, but I doubt that most of our users want to be running NFS > and mail servers on a default install. Besides that, running Bluetooth > on a machine without Bluetooth-capable hardware is a complete waste of > resources. > > A simple example: > [X] Laptop services > [ ] Bluetooth - Bluetooth connectivity services > [X] NetworkManager - Easy management of network connections > [ ] Avahi - Zeroconf network discovery > [ ] NFS - File sharing > [ ] sendmail - Mail server > [ ] SMB - Samba (Windows) file and printer sharing > [ ] SSH - Remote shell > > Laptop Services would enable cpuspeed and apmd, as desktop machines > don't really *need* those services. The rest can be enabled as the user > sees fit. > Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU fan at full speed for no good reason, I also like my powerbil being as high as possible. I can see merits on the general idea here, but the concept of desktops not needing powermanagement is from the previous century. Regards, Hans From mackay_d at bellsouth.net Mon Sep 3 17:48:32 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 03 Sep 2007 12:48:32 -0500 Subject: Python 3.0 In-Reply-To: <20070903094905.3d3b53af@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> Message-ID: <1188841712.31055.15.camel@vorpal.macdev.com> On Mon, 2007-09-03 at 09:49 -0500, Josh Boyer wrote: > > > > And what do you do when you require functionality that's not in Fedora? > > > > > > Depends. If it's outside the scope of Fedora, such as codecs, etc I > > > certainly don't expect Fedora to fill that need. If it's within the > > > realm of Fedora, and it's not present yet I package it up myself. If > > > it's already in Fedora and it's lacking something I need, I work with > > > upstream to get it in place so it will follow naturally to Fedora. > > > > So you really rely on your ability to extend Fedora to make it do what > > you want. I understand the problems with the codecs, and expect that, > > were it legal to do so, they would be included. The problems stemming > > from the need for a compat-python are a bit different. Given the fact > > that python breaks compatibility with itself rather badly on a regualar > > basis, I suspect that your problems working with upstream developers are > > going to increase, and Fedora's own in-house projects may very well need > > a compat-python. > > Well, two things: > > 1) You asked what I do when Fedora lacks something _I_ need. That has > never included zope/plone or really any other python app. So, at a > personal level, I'm not really impacted here. But my approach would > not differ it I was. That's laudable. But, at some point, if enough of what you needed fell outside of items included in Fedora you might want to ratchet things up a notch. Especially if some of those could be included in Fedora without that much effort. > 2) Fedora has quite a few in-house python projects and none of them > have needed a compat package so far. Whether that is because of > internal whip cracking to port to newer python, or because people are > just that motivated I have no idea. I don't work on any of those > projects. Thus far, most of the python changes haven't broken compatibility at the python source level. It's been a different story with the low level c/python api, which is what's impacted zope so much. Now, however, they're going to break compatibility at the python source level. > All that being said, it is _extremely_ important to remember that just > because it's not in Fedora doesn't mean it's bad. If people need a > compat python package, then they can by all means create one themselves > and slap it into a third party repo for others to use. Which has been done. My concern is that the resistance to a compat package at Fedora seems to be pretty much unfounded. I've looked at Bugzilla entries for python 2.4.x in FC6, as well as entries for some of the compat-gcc pakages from the past. If there's been abuse and activity generated by past compat-gcc packages, I've found little evidence in Bugzilla. The activity for python 2.4.x has also been minimal, so I don't see why you would suddenly expect a barrage of action for the compat package. If I've overlooked something, then by all means, please let me know. > Take Ignacio for example. While I disagree that Fedora as a > _distro_ needs a python3.0 alpha package at the moment, I applaud his > efforts to get it packaged and shared. I think that is a very > worthwhile effort, and I'm glad he's done so. I only wish something > like that would have happened for zope/plone in the F7 timeframe. (And > maybe it did, I just am not aware of it.) It was tried. As it stands, Zope and Plone, which were availabe in Extras for FC6, aren't available directly, and probably won't be for F8. Dave From ssorce at redhat.com Mon Sep 3 17:50:12 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Sep 2007 13:50:12 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC3E0D.4080400@gmail.com> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> <46DC298C.70604@gmail.com> <46DC2FAB.2030602@kanarip.com> <46DC3E0D.4080400@gmail.com> Message-ID: <1188841812.6201.78.camel@localhost.localdomain> On Mon, 2007-09-03 at 12:02 -0500, Les Mikesell wrote: > I doubt if there are 3 million people > arrogant enough to call themselves experts, though. There are > probably > a few hundred configurations that an expert sysadmin would build for > 99% > of uses and the good ones would sort themselves out by reputation and > be > improved by user feedback. The base distribution could then just > concentrate on getting all the programs into a repository and keeping > their interfaces compatible so you didn't have to throw everything > out > to update. You have heard about how Fedora has built an infrastructure to allow very easily to create "spins", what do you think that has been built for ? >From another email: > If free software distribution was really about sharing instead of > providing a complex base to sell support and services, I think > something like this would have been done long ago." Can you spare us this ridiculous rhetoric ? Fedora is now built to make it easy to build spins. Just publishing a list of packages and let it die in oblivion is not going to help anybody. An expert willing to help others can instead build a spin and really benefit other people, by providing them with a targeted distribution without caring about packaging, but just about how to select and put together packages and making sure you can build an installable system, which is what your are asking for. Simo. From jwboyer at jdub.homelinux.org Mon Sep 3 18:18:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 3 Sep 2007 13:18:00 -0500 Subject: Python 3.0 In-Reply-To: <1188841712.31055.15.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> Message-ID: <20070903131800.4659b7e3@vader.jdub.homelinux.org> On Mon, 03 Sep 2007 12:48:32 -0500 "David G. Mackay" wrote: > Which has been done. My concern is that the resistance to a compat > package at Fedora seems to be pretty much unfounded. I've looked at > Bugzilla entries for python 2.4.x in FC6, as well as entries for some of > the compat-gcc pakages from the past. If there's been abuse and > activity generated by past compat-gcc packages, I've found little > evidence in Bugzilla. The activity for python 2.4.x has also been > minimal, so I don't see why you would suddenly expect a barrage of > action for the compat package. If I've overlooked something, then by > all means, please let me know. I'm not going to rehash all the arguments again. Look at the zope/plone thread from a while ago. > It was tried. As it stands, Zope and Plone, which were availabe in > Extras for FC6, aren't available directly, and probably won't be for F8. Certainly won't be for F8 release. Maybe if Zope and Plone can run on python 2.5/2.6 soon then they can be added as updates for F8 and in F9. josh From jon at fedoraunity.org Mon Sep 3 18:26:51 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 03 Sep 2007 12:26:51 -0600 Subject: Python 3.0 In-Reply-To: <1188841712.31055.15.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> Message-ID: <46DC51EB.70207@fedoraunity.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David G. Mackay wrote: > On Mon, 2007-09-03 at 09:49 -0500, Josh Boyer wrote: > >> Take Ignacio for example. While I disagree that Fedora as a >> _distro_ needs a python3.0 alpha package at the moment, I applaud his >> efforts to get it packaged and shared. I think that is a very >> worthwhile effort, and I'm glad he's done so. I only wish something >> like that would have happened for zope/plone in the F7 timeframe. (And >> maybe it did, I just am not aware of it.) > > It was tried. +1 > As it stands, Zope and Plone, which were availabe in > Extras for FC6, aren't available directly, and probably won't be for F8. I'm still maintaining the FC6 packages and the EPEL packages (granted updates for EPEL go to updates-testing) using the provided python. Plone will not be running on python 2.5 for some time. Plone is currently targeting Zope 2, albeit "Five" is like backporting Zope 3 code, and Zope 3 is *just now* starting to work with python 2.5... or is at least close. This currently has the effect of restricting Zope 2 to FC <= 6. I can't speak for the Zope developers, but I don't see a rush to also get Zope 2 working with python 2.5. == compat-python24 == Maybe today I will finish my upgrade testing and will push the compat- packages into livna. The compat-python packages have passed review and I just need to upload the new compat packages for zope (2.10.4) and plone (3.0). I'm guessing this means I am going to end up being the compat-python maintainer [in livna]. I was more or less avoiding this because I'm not sure I will know what to do when things break and would inheritly be passing the buck, so to speak. I would have to ask for help, either on IRC or this list (and have no problem doing so) which does create extra overhead and is something that was trying to be avoided. Anywho, the packages are done and work (I've been using them for most of the Fedora 7 release). I've only packaged what is needed for Zope/Plone and that was another point in the discussion. Who decides what compat support/module we provide? Seeing as how the packages I've done are for my personal uses for Zope/Plone, I'm most likely not going to personally do many other compat-python packages. compat-python-ldap will be there at some point, but I think that is all. == /compat-python24 == Zope/Plone is a somewhat special case with what broke and I'm not sure having python 2.5 packages (in Fedora) earlier would have helped anything. I'm all for getting python 3 packaged and available, but agree outside of Fedora would be best. Even if python 3 is available, we are still going to need to rely upon upstream projects using python to be aware of the changes and start testing/fixing. There seems to be more to this process then I want to spend time on (politics?) and thus have gone the route of compat packages. Jonathan Steffan daMaestro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3FHqrRJs5w2Gr1kRApguAKCWCk84MQcjmVhEWYXCrSwHSBCyHwCfR0D+ XYjuWinQKKbLPlAragBmFhU= =dG5t -----END PGP SIGNATURE----- From jspaleta at gmail.com Mon Sep 3 18:27:06 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 3 Sep 2007 10:27:06 -0800 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188825506.9729.41.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> Message-ID: <604aa7910709031127q39fcbachdfb8252776d6f076@mail.gmail.com> On 9/3/07, Martin Sourada wrote: > Yes, most ARE, but the one with services could be useful. There is a > batch of services that are useful on most of notebooks, but are unneeded > on most of Desktops/Servers and vice versa. This does not have to be in firstboot.. this can be post-firstboot. I personally do not want to be stuck in the installer or firstboot any longer than I absolutely must. Turning services off and other customization tasks I can do after I am in the running system...in parallel with other more important activities like installing updates or reading penny-arcade. Adding a services dialog in firstboot or anaconda has the additional complication that users who are confused by it, have no mechanism to talk to other users while sitting in the installer interface or firstboot. You are giving unsuspecting users the option to turn services off before experiencing what the default system configuration. If they decide to turn things off, things they actually really need but don't understand the system well enough to know it, then you have given them the option to cripple the system before they even see what a working system is suppose to be. And you've done it in a way that makes it more difficult to get help repairing. If you want, add a well worded blurb about the existence of the services configuration tool in a firstboot page or something..but don't expose services in the installer process. Let users work with the default services, and then customize. -jef From jkeating at redhat.com Mon Sep 3 18:27:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Sep 2007 14:27:16 -0400 Subject: Python 3.0 In-Reply-To: <1188828480.30160.49.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> Message-ID: <20070903142716.38a70949@ender> On Mon, 03 Sep 2007 09:08:00 -0500 "David G. Mackay" wrote: > I have a machine running FC6 with Zope and Plone. It will probably be > migrated to Centos 5 soon as FC6 support will probably go away before > 2008. And. who knows, it might become a critical enough app that I'll > spring for RHEL5 support. And there is absolutely nothing wrong with that migration path. The best tool for the job. The Fedora universe as it were has a multitude of tools in it's tool belt. There is Fedora, there is RHEL, there is EPEL, and to some extent there is CentOS. There are also tools that will allow you to create your own erm.. tool for whatever job you need to do. Provided all this, I can't fathom a case where your need isn't serviced by at least one of these offerings. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From s.adam at diffingo.com Mon Sep 3 18:55:19 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Mon, 03 Sep 2007 14:55:19 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC46AD.2080702@hhs.nl> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> Message-ID: <1188845719.4826.3.camel@Diffingo.localdomain> On Mon, 2007-09-03 at 19:38 +0200, Hans de Goede wrote: > Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU > fan at full speed for no good reason, I also like my powerbil being as high as > possible. > > I can see merits on the general idea here, but the concept of desktops not > needing powermanagement is from the previous century. > > Regards, > > Hans > That's what I'm saying - Letting the user select is nice. Some machine's fans will blare, others not. Some Desktop CPU have throttle states, others none or not enough to make a big change. Stewart From sundaram at fedoraproject.org Mon Sep 3 19:00:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 04 Sep 2007 00:30:50 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188845719.4826.3.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> Message-ID: <46DC59E2.4070308@fedoraproject.org> Stewart Adam wrote: > On Mon, 2007-09-03 at 19:38 +0200, Hans de Goede wrote: >> Yes I don't need cpuspeed, as I *really* like listening to the sound of my CPU >> fan at full speed for no good reason, I also like my powerbil being as high as >> possible. >> >> I can see merits on the general idea here, but the concept of desktops not >> needing powermanagement is from the previous century. >> >> Regards, >> >> Hans >> > > That's what I'm saying - Letting the user select is nice. Some machine's > fans will blare, others not. Some Desktop CPU have throttle states, > others none or not enough to make a big change. The user will always have the choice. The question is only whether a list of all possible services make sense to ask in the installer. IMO, this is the distribution's responsibility. For cpuspeed, enable it by default if the hardware is capable. If the hardware is not capable, cpuspeed disables itself on start. Rahul From jspaleta at gmail.com Mon Sep 3 19:03:29 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 3 Sep 2007 11:03:29 -0800 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188845719.4826.3.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> Message-ID: <604aa7910709031203m6f19c310if3b8a7ef635fb810@mail.gmail.com> On 9/3/07, Stewart Adam wrote: > That's what I'm saying - Letting the user select is nice. Some machine's > fans will blare, others not. Some Desktop CPU have throttle states, > others none or not enough to make a big change. we have a way to select services... its called system-config-services and its in the System->Administration menu. There's absolutely no compelling reason to move the selection dialog for services into the install process. -jef From ajackson at redhat.com Mon Sep 3 18:54:57 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 03 Sep 2007 14:54:57 -0400 Subject: ubuntu bulletproof x In-Reply-To: <46D9D3B5.6080305@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> Message-ID: <1188845697.22573.27.camel@localhost.localdomain> On Sat, 2007-09-01 at 16:03 -0500, Douglas McClendon wrote: > Adam Jackson wrote: > > > If I were being cynical, I'd say a large part of the reason they'll be > > moderately successful at this whole 'bulletproof' thing is due to work > > I've already put in to fixing autoconfiguration within X itself, and > > that the press releases are just so much propaganda. Don't get me > > wrong, Fedora sucks at self-publicity, we should do better, but all I > > see in that project is prettier UI and not technical correctness. If > > you do it _right_, you don't ever have to admit failure. Asking for the > > inf file is admitting failure. > > I suspect you'll tell me why I'm wrong- But aren't there (a significant > number of) situations where autodetect fails, and in fact due to > hardware limitations can't succeed, but the process of the user > specifying the monitor type, and info, from the driver CD, will cause > success? > > Even if those situations account for 1/10,000 users, those are precisely > the cases that need to be covered to market something as "bulletproof". > > Now of course, it won't solve the problem of the user getting confused > and using the wrong CD for the monitor... Yeah, okay, force me to clarify. Grumble. There are cases where we can't tell what monitor the user has. They're almost completely described by "either the card can't do DDC, or the cable is broken". The former is a vanishingly small class of hardware, voodoo1 basically. The latter happens depressingly often particularly with projector setups. In either case, asking for the windows CD won't tell you what you want to know. It will tell you sync ranges, when what you _want_ to know is desired resolution and display type (as in, CRT, LCD, beamer, whatever). Afterwards you can validate that against the sync ranges from the INF file if you want, but really, either it'll work or it won't, and asking for the CD won't make it work better. It's a red herring, is my point. It's a non-feature. It's like going to buy a Ferrari and the salesman keeps talking about how great the cupholders are. They might be great, truly exemplary, but they're not really what you're interested in. - ajax From pemboa at gmail.com Mon Sep 3 19:15:24 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Sep 2007 14:15:24 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DBFD50.5020505@hi.is> References: <46DBFD50.5020505@hi.is> Message-ID: <16de708d0709031215q7a5f4caeu43bcef74afbaa27b@mail.gmail.com> I have my own strong feelings on a lot of the issues you mentioned. And I would like for there to be discussion on them, but a few things need to be considered. These threads are hardly ever constructive. Could we first have a discussion on some ground rules, etc to make these kind of discussions fruitful? Could people suspend emotionally driven responses and keep things as technical as possible? I'd rather we spend a month figuring out _how_ to have these discussions in a constructive manner, than have several of these threads. From martin.sourada at seznam.cz Mon Sep 3 19:33:37 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 03 Sep 2007 21:33:37 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <46DC59E2.4070308@fedoraproject.org> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <46DC59E2.4070308@fedoraproject.org> Message-ID: <1188848017.9729.107.camel@pc-notebook> On Mon, 2007-09-03 at 21:00 +0200, Rahul Sundaram wrote: > The user will always have the choice. The question is only whether a > list of all possible services make sense to ask in the installer. IMO, > this is the distribution's responsibility. For cpuspeed, enable it by > default if the hardware is capable. If the hardware is not capable, > cpuspeed disables itself on start. > > Rahul > Yes, it is distribution's responsibility, but the goal here is to make the boot process more effective. That means point out services we don't need and remove them from default configuration. If we can do this process fully automatic and dependant on hardware, than I am all for it not being in anaconda or first boot. If not, give user basic, easy choice of default configuration, either of which will NOT break a system, the set of enabled/disabled services would be chosen by distribution. Another thing is system-config-services. Do we want users to use it? If yes then we need to make it as much as possible fool-proof. That basically means that we should give sane names there and not just name of the services - everyone knows what bluetooth means, not anyone knows what cups is. Sometimes description is enough, sometimes the description is misleading, hard to understand. Martin -------------- 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 myfedora at richip.dhs.org Mon Sep 3 19:34:08 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 03 Sep 2007 13:34:08 -0600 Subject: ubuntu bulletproof x In-Reply-To: <1188845697.22573.27.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> Message-ID: <1188848048.6335.23.camel@localhost6.localdomain6> On Mon, 2007-09-03 at 14:54 -0400, Adam Jackson wrote: > In either case, asking for the windows CD won't tell you what you want > to know. It will tell you sync ranges, when what you _want_ to know is > desired resolution and display type (as in, CRT, LCD, beamer, whatever). > Afterwards you can validate that against the sync ranges from the INF > file if you want, but really, either it'll work or it won't, and asking > for the CD won't make it work better. As someone who's done some work in the embedded space, I can see how it's possible that the device might return wrong information which is superseded by information found in driver updates. Firmware can't always be updated, so if the hardware does return with some error or new information is deemed important or necessary, that's usually done through some file update. What's the objective here? To come up with working ModeLines for the video card and video display combination? Don't Windows INF files contain additional information useful for coming up with those ModeLines that isn't available from the hardware (EDID)? How does Windows determine the valid resolutions for the same piece of hardware? When X can't come up with the same resolutions as Windows, is it because of a difference in computational algorithms? (someone mentioned how X gives width more importance) Is there no value to be gained from INF files? So there are four actors here: the monitor which supplies EDID information, information provided through some external file like the Windows INF, the user who might be able to make learned configs and the X server. I'm sure you all agree that the objective is a working display. Additionally, you might all agree that most, if not all, of the actions should be between the X server and the hardware, followed by additional external information (possibly provided as a file by the manufacturer or a database of information) and finally the user (whose sole purpose ideally is just to pick the setting which pleases him/her most). It seems people have to agree first on what the ideal objectives are and then discuss the technical aspects for achieving it. I agree with another poster who puts value to constructive criticism. May I also suggest that derogatory remarks or character attacks be lessened? Also, I hope the developers "in the know" will understand that in this community, some aren't as technically adept as they are but would still like to understand and learn, and no amount of post rereading is going to make it clearer IF there are information lacking or that needs clearing. -- Richi Plana From pemboa at gmail.com Mon Sep 3 19:38:07 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Sep 2007 14:38:07 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188848017.9729.107.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <46DC59E2.4070308@fedoraproject.org> <1188848017.9729.107.camel@pc-notebook> Message-ID: <16de708d0709031238l6c3a6160qfb645188116f04a@mail.gmail.com> On 9/3/07, Martin Sourada wrote: > Another thing is system-config-services. Do we want users to use it? If > yes then we need to make it as much as possible fool-proof. That > basically means that we should give sane names there and not just name > of the services - everyone knows what bluetooth means, not anyone knows > what cups is. Sometimes description is enough, sometimes the description > is misleading, hard to understand. Last time I used it, most of the services came with descriptions. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sundaram at fedoraproject.org Mon Sep 3 19:36:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 04 Sep 2007 01:06:56 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188848017.9729.107.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <46DC59E2.4070308@fedoraproject.org> <1188848017.9729.107.camel@pc-notebook> Message-ID: <46DC6258.70709@fedoraproject.org> Martin Sourada wrote: >> > Yes, it is distribution's responsibility, but the goal here is to make > the boot process more effective. That means point out services we don't > need and remove them from default configuration. If we can do this > process fully automatic and dependant on hardware, than I am all for it > not being in anaconda or first boot. That is what is being worked upon atleast incrementally. > Another thing is system-config-services. Do we want users to use it? If > yes then we need to make it as much as possible fool-proof. That > basically means that we should give sane names there and not just name > of the services - everyone knows what bluetooth means, not anyone knows > what cups is. Sometimes description is enough, sometimes the description > is misleading, hard to understand. File a bug report with suggestions for better short descriptive messages. Rahul From dmc.fedora at filteredperception.org Mon Sep 3 19:53:39 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 14:53:39 -0500 Subject: ubuntu bulletproof x In-Reply-To: <1188845697.22573.27.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> Message-ID: <46DC6643.40308@filteredperception.org> Adam Jackson wrote: > On Sat, 2007-09-01 at 16:03 -0500, Douglas McClendon wrote: >> Adam Jackson wrote: >> >>> If I were being cynical, I'd say a large part of the reason they'll be >>> moderately successful at this whole 'bulletproof' thing is due to work >>> I've already put in to fixing autoconfiguration within X itself, and >>> that the press releases are just so much propaganda. Don't get me >>> wrong, Fedora sucks at self-publicity, we should do better, but all I >>> see in that project is prettier UI and not technical correctness. If >>> you do it _right_, you don't ever have to admit failure. Asking for the >>> inf file is admitting failure. >> I suspect you'll tell me why I'm wrong- But aren't there (a significant >> number of) situations where autodetect fails, and in fact due to >> hardware limitations can't succeed, but the process of the user >> specifying the monitor type, and info, from the driver CD, will cause >> success? >> >> Even if those situations account for 1/10,000 users, those are precisely >> the cases that need to be covered to market something as "bulletproof". >> >> Now of course, it won't solve the problem of the user getting confused >> and using the wrong CD for the monitor... > > Yeah, okay, force me to clarify. Grumble. > > There are cases where we can't tell what monitor the user has. They're > almost completely described by "either the card can't do DDC, or the > cable is broken". The former is a vanishingly small class of hardware, > voodoo1 basically. The latter happens depressingly often particularly > with projector setups. So, to save you the trouble of rereading all of my posts. Can you explicitly confirm this (which it sounds like you did, but not in a way that clearly addressed the point I tried to make half a dozen times last night). Repeat after me- "There is *NEVER* a situation, when the monitor fails to provide correct information, due to a broken or absent edid implementation, and which at the same time, sufficient information could be parsed from the .inf that came on the CD with the monitor, to provide the user, a reasonable experience requiring no user interaction beyond putting the cd in the drive". (and at which time, the X driver could not have accomplished the same thing automatically without the .inf) If that truly is *NEVER* a possibility, then my main speculative argument, was wrong. You make it sound as though monitor .inf files *NEVER* contain available resolution information. This sounds odd to me. Please verify my understanding of that as well. -dmc > > In either case, asking for the windows CD won't tell you what you want > to know. It will tell you sync ranges, when what you _want_ to know is > desired resolution and display type (as in, CRT, LCD, beamer, whatever). > Afterwards you can validate that against the sync ranges from the INF > file if you want, but really, either it'll work or it won't, and asking > for the CD won't make it work better. > > It's a red herring, is my point. It's a non-feature. It's like going > to buy a Ferrari and the salesman keeps talking about how great the > cupholders are. They might be great, truly exemplary, but they're not > really what you're interested in. > > - ajax > From s.adam at diffingo.com Mon Sep 3 19:56:52 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Mon, 03 Sep 2007 15:56:52 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <604aa7910709031203m6f19c310if3b8a7ef635fb810@mail.gmail.com> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <604aa7910709031203m6f19c310if3b8a7ef635fb810@mail.gmail.com> Message-ID: <1188849412.7850.7.camel@Diffingo.localdomain> On Mon, 2007-09-03 at 11:03 -0800, Jeff Spaleta wrote: > On 9/3/07, Stewart Adam wrote: > > That's what I'm saying - Letting the user select is nice. Some machine's > > fans will blare, others not. Some Desktop CPU have throttle states, > > others none or not enough to make a big change. > > we have a way to select services... its called system-config-services > and its in the System->Administration menu. There's absolutely no > compelling reason to move the selection dialog for services into the > install process. > > -jef I in no way want to offend the coders system-config-services as it's a great tool but honestly when I took my first look at it I wasn't so sure what it all meant and I doubt new users will either. Besides being confused about all the runlevels and things each initscript has it's own status message and the descriptions of the services aren't always so clear. Duplicating s-c-s into firstboot would be pointless; I think what Martin was trying to say was that a the services we enable now as a "just incase" like apmd, cpuspeed, the rpc batch could go into a "Do you actually need these?" list. A simple checkmark with clear, one-lined descriptions. Stewart From sundaram at fedoraproject.org Mon Sep 3 20:04:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 04 Sep 2007 01:34:05 +0530 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188849412.7850.7.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <604aa7910709031203m6f19c310if3b8a7ef635fb810@mail.gmail.com> <1188849412.7850.7.camel@Diffingo.localdomain> Message-ID: <46DC68B5.1080001@fedoraproject.org> Stewart Adam wrote: > I in no way want to offend the coders system-config-services as it's a > great tool but honestly when I took my first look at it I wasn't so sure > what it all meant and I doubt new users will either. Besides being > confused about all the runlevels and things each initscript has it's own > status message and the descriptions of the services aren't always so > clear. > > Duplicating s-c-s into firstboot would be pointless; I think what Martin > was trying to say was that a the services we enable now as a "just > incase" like apmd, cpuspeed, the rpc batch could go into a "Do you > actually need these?" list. A simple checkmark with clear, one-lined > descriptions. Anaconda/Firstboot usually works by integrating system-config-* instead of reinventing the wheel with a different configuration tool inside the installer. If system-config-services needs improvement, that needs to be fixed regardless of whether it is going to be in firstboot or not. Rahul From naheemzaffar at gmail.com Mon Sep 3 20:07:36 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 3 Sep 2007 21:07:36 +0100 Subject: ubuntu bulletproof x In-Reply-To: <46DC6643.40308@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> Message-ID: <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> I think the onus should be on the other foot. Unless you are the one doing the work, it is for you to prove that there is a benefit. Should be rather easy. ("I can prove that dogs exist. I cannot prove that aliens do not" is probably a bad analogy...) From jspaleta at gmail.com Mon Sep 3 20:11:24 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 3 Sep 2007 12:11:24 -0800 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188849412.7850.7.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <604aa7910709031203m6f19c310if3b8a7ef635fb810@mail.gmail.com> <1188849412.7850.7.camel@Diffingo.localdomain> Message-ID: <604aa7910709031311m29d7e946j707fcafe111dfb9f@mail.gmail.com> On 9/3/07, Stewart Adam wrote: > Duplicating s-c-s into firstboot would be pointless; I think what Martin > was trying to say was that a the services we enable now as a "just > incase" like apmd, cpuspeed, the rpc batch could go into a "Do you > actually need these?" list. A simple checkmark with clear, one-lined > descriptions. If you are able to simplify it... then simplify it post-install by improving s-c-services. There is no compelling reason to let users disable default services as part of the install process. Let's say my wife installs fedora on her desktop and she doesn't want bluetooth. Using an install time process...like you want..she'd turn it off at install time right? Now lets say she gets a spiffy bluetooth appliance and an usb to bluetooth adaptor for her desktop so she can talk to that bluetooth appliance. Where does she go to re-enable bluetooth on the desktop? She has to go to s-c-services!!!!!!! The ultimate win here is to fix the primary user interface users need to use to turn off and turn on services they feel they need or don't need. The other ultimate win is to more towards on-demand servicing as much as possible to reduce the need for any service control. There is no compelling reason to drive this into the install process.. it only complicates usability because the user will have to interact with a different interface to turn services back on post-install. -jef From lsof at nodata.co.uk Mon Sep 3 20:11:38 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 03 Sep 2007 22:11:38 +0200 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <16de708d0709031215q7a5f4caeu43bcef74afbaa27b@mail.gmail.com> References: <46DBFD50.5020505@hi.is> <16de708d0709031215q7a5f4caeu43bcef74afbaa27b@mail.gmail.com> Message-ID: <1188850298.6126.0.camel@sb-home> Am Montag, den 03.09.2007, 14:15 -0500 schrieb Arthur Pemberton: > I have my own strong feelings on a lot of the issues you mentioned. > And I would like for there to be discussion on them, but a few things > need to be considered. > > These threads are hardly ever constructive. > > Could we first have a discussion on some ground rules, etc to make > these kind of discussions fruitful? > > Could people suspend emotionally driven responses and keep things as > technical as possible? > > I'd rather we spend a month figuring out _how_ to have these > discussions in a constructive manner, than have several of these > threads. > Well a wiki-based discussion was once suggested as a possible method, but the reason why the discussion fails is because there are too many points to address. From dmc.fedora at filteredperception.org Mon Sep 3 20:19:46 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 03 Sep 2007 15:19:46 -0500 Subject: ubuntu bulletproof x In-Reply-To: <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> Message-ID: <46DC6C62.5080201@filteredperception.org> Naheem Zaffar wrote: > I think the onus should be on the other foot. > > Unless you are the one doing the work, it is for you to prove that > there is a benefit. Should be rather easy. > > ("I can prove that dogs exist. I cannot prove that aliens do not" is > probably a bad analogy...) Since he is the 'indisputable' X hacker, I am willing to take his word, that if he has *NEVER* seen such a scenario, that they don't exist. Perhaps I should have phrased the question - 'You have never seen a situation', or 'you have never run across a situation'. Honestly, I think I might have a situation, if I could actually track down the driver cd for the monitor I have (which I bought from a surplus, with no driver cd). I.e. my micron ap150t, with current fc7, comes up as 800x600, when it is a 1024x768 lcd. My suspicion is that in the .inf file for the monitor, is the information about the hsync, the vsync, and that it is capable of 1024x768 resolution, which would be all the info needed. But I admit, suspicions aren't worth anything in this argument. -dmc From sundaram at fedoraproject.org Mon Sep 3 20:20:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 04 Sep 2007 01:50:08 +0530 Subject: Developing Fedora Derivative distro yum "priority" question In-Reply-To: <604aa7910708311146o704f2300w91c331b404db8fb2@mail.gmail.com> References: <6e24a8e80708301354s4e830a3t225bd4ea7a403721@mail.gmail.com> <1188507923.27085.280.camel@cutter> <6e24a8e80708301417g6fc2e9d0kf009913fff4fe961@mail.gmail.com> <1188509897.3654.15.camel@dhcp83-165.boston.redhat.com> <1188510322.22413.27.camel@oneill.fubar.dk> <6e24a8e80708310520y1919d75ej52fde4eb779e269f@mail.gmail.com> <46D82A01.4000301@filteredperception.org> <46D83B7E.9040703@fedoraproject.org> <604aa7910708311146o704f2300w91c331b404db8fb2@mail.gmail.com> Message-ID: <46DC6C78.1010405@fedoraproject.org> Jeff Spaleta wrote: > On 8/31/07, Rahul Sundaram wrote: >> "You may also not then say that your product "contains Fedora" or is an >> alternate "edition" of Fedora. You may say that your product is "a >> derivative of Fedora" or is "built upon Fedora", but you must make it >> clear that your product is NOT Fedora" >> >> This is based on "fair use" and you don't need explicit permission. > > You know, we should probably consider stating a single preference for > how to communicate this. And make the stated preference easy to find > in the text instead of buried in the middle of a longer paragraph. Ideally we will have tools that allow you to pass a argument that marks a custom spin as a derivative with appropriate text and branding in the right places and use the documentation only to compliment the capability with these tools. Rahul From pemboa at gmail.com Mon Sep 3 20:24:32 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 3 Sep 2007 15:24:32 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188850298.6126.0.camel@sb-home> References: <46DBFD50.5020505@hi.is> <16de708d0709031215q7a5f4caeu43bcef74afbaa27b@mail.gmail.com> <1188850298.6126.0.camel@sb-home> Message-ID: <16de708d0709031324s4ba47f48n875a63cb76e573c5@mail.gmail.com> On 9/3/07, nodata wrote: > Am Montag, den 03.09.2007, 14:15 -0500 schrieb Arthur Pemberton: > > I have my own strong feelings on a lot of the issues you mentioned. > > And I would like for there to be discussion on them, but a few things > > need to be considered. > > > > These threads are hardly ever constructive. > > > > Could we first have a discussion on some ground rules, etc to make > > these kind of discussions fruitful? > > > > Could people suspend emotionally driven responses and keep things as > > technical as possible? > > > > I'd rather we spend a month figuring out _how_ to have these > > discussions in a constructive manner, than have several of these > > threads. > > > > Well a wiki-based discussion was once suggested as a possible method, > but the reason why the discussion fails is because there are too many > points to address. Well could some respected individual divide and conqueror these discussions? I think we can and will benefit. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From myfedora at richip.dhs.org Mon Sep 3 20:27:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 03 Sep 2007 14:27:58 -0600 Subject: ubuntu bulletproof x In-Reply-To: <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> Message-ID: <1188851278.6335.40.camel@localhost6.localdomain6> On Mon, 2007-09-03 at 21:07 +0100, Naheem Zaffar wrote: > I think the onus should be on the other foot. Come on. We're a community here. This isn't supposed to be a debate where one's only concern is to win the argument. I believe the onus to reply is on anyone who knows the answer to the question. In case no one knows the answer for certain, then ideally it would be on all of us who wants what is best for the project. Anyway, I thought I'd find out for myself. I went to the ViewSonic website and downloaded the drivers for WinXP (http://www.viewsonic.com/support/drivers/download.cfm?key=37). It turns out that they supply 2 to 3 file per monitor. An optional .cat file (Catalog file. not sure what that is but it looks like a signature file), an .icm file (Microsoft ICM Color Profile) and the .inf file. I took a random INF file and am pasting it in this email. I'm also just pasting the parts which seem relative to the objective of coming up with valid Modes and ModeLines: [VLCDS23412-1.Install] ;VX800 DelReg=DEL_CURRENT_REG AddReg=VLCDS23412-1.AddReg,1280,DPMS Copyfiles=VLCDS23412-1.CopyFiles [DEL_CURRENT_REG] HKR,MODES HKR,,MaxResolution HKR,,DPMS HKR,,ICMProfile [1280] HKR,,MaxResolution,,"1280,1024" [DPMS] HKR,,DPMS,,1 [VLCDS23412-1.AddReg] ;VX800 HKR,"MODES\1280,1024",Mode1,,"24-82,56-85,+,+" HKR,,ICMProfile,0,"VX800.ICM" [VLCDS23412-1.CopyFiles] VX800.ICM I've no idea what these are for, but I'm hoping someone who knows a lot more can tell me if there's any value here. Unfortunately, I don't know which monitors / displays don't give correct EDID information so this is as far as my research could go. -- Richi Plana From markg85 at gmail.com Mon Sep 3 20:40:39 2007 From: markg85 at gmail.com (Mark) Date: Mon, 3 Sep 2007 22:40:39 +0200 Subject: Why don't we have a themed "Screen Locked" anymore? In-Reply-To: <1188829122.4628.10.camel@localhost.localdomain> References: <6e24a8e80708301644pdad3362rc193a30e8d4dfeba@mail.gmail.com> <46D81D9C.4090105@redhat.com> <1188577744.4620.2.camel@localhost.localdomain> <3170f42f0708311927v7939b27q28177b9420a38e89@mail.gmail.com> <1188829122.4628.10.camel@localhost.localdomain> Message-ID: <6e24a8e80709031340j1812d7c6wd50c9bd206def131@mail.gmail.com> So this means that it's gonna be on for Fedora 8? btw the theme Nicu Buculei made for it looks very good with it. Good job, Nicu. From lesmikesell at gmail.com Mon Sep 3 20:51:11 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 03 Sep 2007 15:51:11 -0500 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188841812.6201.78.camel@localhost.localdomain> References: <46DBFD50.5020505@hi.is> <46DC0A5A.6020607@kanarip.com> <1188828508.9729.63.camel@pc-notebook> <46DC1ACB.7020300@kanarip.com> <46DC298C.70604@gmail.com> <46DC2FAB.2030602@kanarip.com> <46DC3E0D.4080400@gmail.com> <1188841812.6201.78.camel@localhost.localdomain> Message-ID: <46DC73BF.5030408@gmail.com> Simo Sorce wrote: > On Mon, 2007-09-03 at 12:02 -0500, Les Mikesell wrote: >> I doubt if there are 3 million people >> arrogant enough to call themselves experts, though. There are >> probably >> a few hundred configurations that an expert sysadmin would build for >> 99% >> of uses and the good ones would sort themselves out by reputation and >> be >> improved by user feedback. The base distribution could then just >> concentrate on getting all the programs into a repository and keeping >> their interfaces compatible so you didn't have to throw everything >> out >> to update. > > You have heard about how Fedora has built an infrastructure to allow > very easily to create "spins", what do you think that has been built > for ? You don't get it - I'm not interested in yet another limited set of choices on a custom CD that is already outdated by the time you download it. I'd like to see a framework to track an expertly-maintained system with little extra effort for the person doing the maintenance and none on the ones following it. If the admin adds or updates packages, the next update of the tracking machines should do the same. >>From another email: >> If free software distribution was really about sharing instead of >> providing a complex base to sell support and services, I think >> something like this would have been done long ago." > > Can you spare us this ridiculous rhetoric ? It is an overgeneralization, but not ridiculous. You can choose between distributions funded by support/service subscriptions or ones that don't care much about the user experience and just warehouse the code. I think we'd be better off with a way to share the support/service work and make user experiences reproducible in any quantity. > Fedora is now built to make it easy to build spins. Just publishing a > list of packages and let it die in oblivion is not going to help > anybody. Yes, that's exactly my point - the mechanism must permit tracking the continuous changes and updates made by the expert. > An expert willing to help others can instead build a spin and > really benefit other people, by providing them with a targeted > distribution without caring about packaging, but just about how to > select and put together packages and making sure you can build an > installable system, which is what your are asking for. No, that will be wrong by the time it reaches a user's hands. The mechanism I want is a minimal install that gets yum or an equivalent on the internet. From there you pick an expert and a purpose for your machine and automatically get the set of packages installed in a tested, known-to-work, configuration just like an enterprise IT department might build for their desktops. Don't like it? Just pick a different one and the package manager would adjust the installed packages to match. Even if you have to try several know-working setups to get something you like it will be vastly easier than individually testing thousands of programs in all possible combinations yourself, and once you find a working master system you could always have an equally nicely working copy of it. -- Les Mikesell lesmikesell at gmail.com From myfedora at richip.dhs.org Mon Sep 3 21:00:48 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 03 Sep 2007 15:00:48 -0600 Subject: ubuntu bulletproof x In-Reply-To: <46DC6C62.5080201@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> <3adc77210709031307yd435bd9g1473245ac8c25753@mail.gmail.com> <46DC6C62.5080201@filteredperception.org> Message-ID: <1188853248.6335.44.camel@localhost6.localdomain6> On Mon, 2007-09-03 at 15:19 -0500, Douglas McClendon wrote: > Honestly, I think I might have a situation, if I could actually track > down the driver cd for the monitor I have (which I bought from a > surplus, with no driver cd). I.e. my micron ap150t, with current fc7, > comes up as 800x600, when it is a 1024x768 lcd. That would have been a nice example (where the current system doesn't detect the maximum capabilities properly). Unfortunately, when I tried searching for the INF files, as well, I couldn't find any from the official support site (http://support.mpccorp.com/downloads/driver.html) and the best I could find was this thread: http://forums.driverguide.com/showthread.php?t=19355 According to it, no "driver" files exist (no INF files) for WinXP and for 95/98/Me, the user should just configure it as a "Plug & Play" monitor. If Windows is getting it right, then it's likely not from an external input file. -- Richi Plana From buildsys at fedoraproject.org Mon Sep 3 21:55:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 3 Sep 2007 17:55:45 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-03 Message-ID: <20070903215545.376FA152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 15 NEW audio-convert-mod-3.45.1-1.fc6 : A simple audio file converter supporting many formats geda-docs-20070902-1.fc6 geda-examples-20070902-1.fc6 geda-gattrib-20070902-1.fc6 geda-gnetlist-20070902-1.fc6 geda-gschem-20070902-1.fc6 geda-gsymcheck-20070902-1.fc6 geda-symbols-20070902-1.fc6 geda-utils-20070902-1.fc6 hardinfo-0.4.2.2-5.fc6 libgeda-20070902-1.fc6 libtasn1-1.1-1.fc6 util-vserver-0.30.214-1.fc6 NEW wxdfast-0.6.0-3.fc6 : Multi-threaded download manager yum-cron-0.4-1.fc6 Changes in Fedora Extras 6: audio-convert-mod-3.45.1-1.fc6 ------------------------------ * Fri Aug 24 2007 Stewart Adam 3.45.1-1 - Update to 3.45.1 (see CHANGELOG file for details on version changes) - Remove uninstall script from package - Update License tag per guideline changes - Use sitelib, not sitearch geda-docs-20070902-1.fc6 ------------------------ * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-examples-20070902-1.fc6 ---------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-gattrib-20070902-1.fc6 --------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-gnetlist-20070902-1.fc6 ---------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-gschem-20070902-1.fc6 -------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-gsymcheck-20070902-1.fc6 ----------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-symbols-20070902-1.fc6 --------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-utils-20070902-1.fc6 ------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 hardinfo-0.4.2.2-5.fc6 ---------------------- * Sun Sep 02 2007 Adel Gadllah 0.4.2.2-5 - Fix libz detection RH #274381 * Fri Aug 03 2007 Adel Gadllah 0.4.2.2-4 - Update License tag libgeda-20070902-1.fc6 ---------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 libtasn1-1.1-1.fc6 ------------------ * Mon Sep 03 2007 Enrico Scholz - 1.1-1 - updated to 1.1 util-vserver-0.30.214-1.fc6 --------------------------- * Mon Sep 03 2007 Enrico Scholz - 0.30.214-1 - updated to 0.30.214 wxdfast-0.6.0-3.fc6 ------------------- * Thu Aug 23 2007 Adel Gadllah 0.6.0-3 - Fix source file permissions * Wed Aug 22 2007 Adel Gadllah 0.6.0-2 - Add patches and specfile changes from Dan Horak (RH #249524) yum-cron-0.4-1.fc6 ------------------ * Mon Sep 03 2007 Alec Habig - 0.4-1 - Fix bug in cron.daily which was preventing updates from running - Integrate Frank's checkonly patches into the source From johannbg at hi.is Tue Sep 4 00:24:29 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Tue, 4 Sep 2007 00:24:29 -0000 (GMT) Subject: NR1. Reduce boot time by disabling services! Message-ID: <15502.88.149.97.225.1188865469.squirrel@webmail.hi.is> Creating an more constructive threat as Arthur suggested dealing with one topic at a time. 1. Can we reduce service at startup to decrease boot time? 2. Can we enable service based on underlying hardware during installation? 3. Should we or should we not make the hardware detected enabled services make due as default enabled services during installation ( Given that that is possible! ) 3. If services can be enabled based on hardware during installation when should the user configure which services he will start? A.During installation faze ( Anaconda )? B.During first boot configuration? C.After he logs in for the first time or when ever he choose to do so. 4. If we reduce service at boot time which service should/can be disabled and which services should/must be enabled? 5. Can we enable service after installation by hardware detection, Let's say I plug in my usb bluetooth dongle bluetooth dongle detected bluetooth service enabled, plug my printer to the printer port printer service enabled etc. Best regards Johann B. From bruno at wolff.to Tue Sep 4 03:29:02 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 3 Sep 2007 22:29:02 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <200709030808.49370.sgrubb@redhat.com> References: <46C9BF64.9040103@hi.is> <20070901153242.GB16761@wolff.to> <20070903135335.4172fcd8@lain.camperquake.de> <200709030808.49370.sgrubb@redhat.com> Message-ID: <20070904032902.GA31978@wolff.to> On Mon, Sep 03, 2007 at 08:08:48 -0400, Steve Grubb wrote: > > Agreed. Besides, I've seen drives go from good to crap within an hour. A daily > report would be too late to be of use. I'd rather see us develop the > infrastructure for messaging around rsyslog so that each daemon does not need > to be modified if there was something that an admin wanted to be alerted for. You can schedule smartd to run more than once a day. This might particularly make sense for the short selft tests that run in a couple of minutes. And smartd itself can send mail alerts when specific things are detected. Since you can specify a command to run to send the mail, this notification could also do other things. From debarshi.ray at gmail.com Tue Sep 4 03:54:58 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Sep 2007 09:24:58 +0530 Subject: Libedit build failure (was: rawhide report: 20070902 changes) Message-ID: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> After my review request for libedit (https://bugzilla.redhat.com/show_bug.cgi?id=274891) was approved, I can not build it for Rawhide (http://koji.fedoraproject.org/koji/taskinfo?taskID=146341). It built successfully for Fedora 7 (http://koji.fedoraproject.org/koji/taskinfo?taskID=146359). Is this due to the feature freeze for Fedora 8 Test 2? Please note that libedit does resolve broken dependency for libreadline-java. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at redhat.com Tue Sep 4 09:09:07 2007 From: buildsys at redhat.com (Build System) Date: Tue, 4 Sep 2007 05:09:07 -0400 Subject: rawhide report: 20070904 changes Message-ID: <200709040909.l84997hk001453@porkchop.devel.redhat.com> Updated Packages: gutenprint-5.0.1-4.fc8 ---------------------- * Fri Aug 31 2007 Tim Waugh 5.0.1-4 - Plug-in name is gutenprint, not print. kernel-2.6.23-0.161.rc5.fc8 --------------------------- * Sun Sep 02 2007 Dave Jones - Fix oops in IPv4. * Sat Sep 01 2007 Dave Jones - Terminate list in ata-piix * Sat Sep 01 2007 Dave Jones - 2.6.23-rc5 pykickstart-1.11-1.fc8 ---------------------- * Mon Sep 03 2007 Jeremy Katz - 1.11-1 - fix a few tracebacks Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 grig - 0.7.2-2.fc8.i386 requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE libreadline-java - 0.8.0-19.fc8.i386 requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.i386 requires libedit.so.0 moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) grig - 0.7.2-2.fc8.x86_64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.x86_64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) pygsl-devel - 0.9.1-4.fc8.x86_64 requires gsl.devel pygsl-devel - 0.9.1-4.fc8.i386 requires gsl.devel rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 grig - 0.7.2-2.fc8.ppc requires libhamlib-1.2.5.so.2 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp libreadline-java - 0.8.0-19.fc8.ppc requires libedit >= 0:2.9 libreadline-java - 0.8.0-19.fc8.ppc requires libedit.so.0 moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 pygsl-devel - 0.9.1-4.fc8.ppc requires gsl.devel pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 grig - 0.7.2-2.fc8.ppc64 requires libhamlib-1.2.5.so.2()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit.so.0()(64bit) libreadline-java - 0.8.0-19.fc8.ppc64 requires libedit >= 0:2.9 moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) pygsl-devel - 0.9.1-4.fc8.ppc64 requires gsl.devel resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From paul at all-the-johnsons.co.uk Tue Sep 4 10:55:22 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 4 Sep 2007 10:55:22 +0000 Subject: rawhide report: 20070904 changes In-Reply-To: <200709040909.l84997hk001453@porkchop.devel.redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> Message-ID: <20070904105522.M20665@all-the-johnsons.co.uk> Hi, > Updated Packages: > For some reason, I can't do an update as yum complains that dbus and dbus-glib both need a version of libexpat which is out of sync. Is anyone else seeing this after doing an install from the 8T1 x86_64 DVD? TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From rjones at redhat.com Tue Sep 4 11:22:37 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 12:22:37 +0100 Subject: rawhide report: 20070904 changes In-Reply-To: <200709040909.l84997hk001453@porkchop.devel.redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> Message-ID: <46DD3FFD.4070308@redhat.com> Build System wrote: > ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 I haven't been able to rebuild the OCaml packages because of something I don't understand which is happening in Koji. I described the problem here but didn't get an answer: https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00029.html Same thing is still happening. Here's an example from today: http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mschwendt.tmp0701.nospam at arcor.de Tue Sep 4 11:48:37 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Sep 2007 13:48:37 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <46DD3FFD.4070308@redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> Message-ID: <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Sep 2007 12:22:37 +0100, Richard W.M. Jones wrote: > Build System wrote: > > ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > > I haven't been able to rebuild the OCaml packages because of something I > don't understand which is happening in Koji. I described the problem > here but didn't get an answer: > > https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00029.html > > Same thing is still happening. Here's an example from today: > > http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log Have you rebuilt ocaml-lablgl for the new version-release of ocaml yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see here, too http://koji.fedoraproject.org/koji/rpminfo?rpmID=191299 which is not available since ocaml is at 3.10.0-6.fc8 already. Above broken deps report, on the contrary, is against frozen rawhide (=f8test2), while packages in koji can be newer already. HTH. From rjones at redhat.com Tue Sep 4 12:00:15 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 13:00:15 +0100 Subject: rawhide report: 20070904 changes In-Reply-To: <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DD48CF.1070703@redhat.com> Michael Schwendt wrote: > On Tue, 04 Sep 2007 12:22:37 +0100, Richard W.M. Jones wrote: > >> Build System wrote: >>> ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >>> ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> I haven't been able to rebuild the OCaml packages because of something I >> don't understand which is happening in Koji. I described the problem >> here but didn't get an answer: >> >> https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00029.html >> >> Same thing is still happening. Here's an example from today: >> >> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log > > Have you rebuilt ocaml-lablgl for the new version-release of ocaml > yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see > here, too I can't build ocaml-lablgl because I'm not the package owner (AIUI). I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not needed for that build. > http://koji.fedoraproject.org/koji/rpminfo?rpmID=191299 > > which is not available since ocaml is at 3.10.0-6.fc8 already. > > Above broken deps report, on the contrary, is against frozen rawhide (=f8test2), > while packages in koji can be newer already. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mackay_d at bellsouth.net Tue Sep 4 12:14:09 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 07:14:09 -0500 Subject: Python 3.0 In-Reply-To: <20070903131800.4659b7e3@vader.jdub.homelinux.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <20070903131800.4659b7e3@vader.jdub.homelinux.org> Message-ID: <1188908049.1394.9.camel@vorpal.macdev.com> On Mon, 2007-09-03 at 13:18 -0500, Josh Boyer wrote: > On Mon, 03 Sep 2007 12:48:32 -0500 > "David G. Mackay" wrote: > > > Which has been done. My concern is that the resistance to a compat > > package at Fedora seems to be pretty much unfounded. I've looked at > > Bugzilla entries for python 2.4.x in FC6, as well as entries for some of > > the compat-gcc pakages from the past. If there's been abuse and > > activity generated by past compat-gcc packages, I've found little > > evidence in Bugzilla. The activity for python 2.4.x has also been > > minimal, so I don't see why you would suddenly expect a barrage of > > action for the compat package. If I've overlooked something, then by > > all means, please let me know. > > I'm not going to rehash all the arguments again. Look at the > zope/plone thread from a while ago. You mean the one that stopped when FESCO agreed to reconsider the compat-python issue? I'm sorry, but I've looked, and found nothing to suggest that the compat boogeyman is really going to jump out of the closet and devour small children in their sleep. It really sounds like FESCO is insisting that the compat-python packager will require a bulldozer to move a BB. Like I said, if there's evidence to the contrary, why doesn't someone just post it. > > It was tried. As it stands, Zope and Plone, which were availabe in > > Extras for FC6, aren't available directly, and probably won't be for F8. > > Certainly won't be for F8 release. Maybe if Zope and Plone can run on > python 2.5/2.6 soon then they can be added as updates for F8 and in F9. If they can get it running on 2.5, the track record suggests that 2.6 would, at best, be iffy. Dave From debarshi.ray at gmail.com Tue Sep 4 12:19:47 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Sep 2007 17:49:47 +0530 Subject: Libedit build failure (was: rawhide report: 20070902 changes) In-Reply-To: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> References: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> Message-ID: <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> Can someone kindly look into this? I have already got a bug (http://koji.fedoraproject.org/koji/buildinfo?buildID=17689 )which seems to be related to this issue. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mschwendt.tmp0701.nospam at arcor.de Tue Sep 4 12:30:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Sep 2007 14:30:38 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <46DD48CF.1070703@redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> Message-ID: <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Sep 2007 13:00:15 +0100, Richard W.M. Jones wrote: > >> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log > > > > Have you rebuilt ocaml-lablgl for the new version-release of ocaml > > yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see > > here, too > > I can't build ocaml-lablgl because I'm not the package owner (AIUI). > > I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not > needed for that build. Okay, then let's see whether the failure is reproducible with a scratch-build of ocaml-findlib: http://koji.fedoraproject.org/koji/taskinfo?taskID=146938 ocaml-lablgl is not listed anywhere in the koji buildroot log and not during the resolve-step either. With a local install of rawhide, it is not reproducible, although it's the old 4.fc8 release of ocaml, and yum resolves the BuildRequires for ocaml-findlib like this (NO ocaml-lablgl): ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: m4 i386 1.4.10-1.fc8 development 209 k ocaml-camlp4-devel i386 3.10.0-4.fc8 development 6.6 M ocaml-labltk-devel i386 3.10.0-4.fc8 development 1.7 M Installing for dependencies: gdbm-devel i386 1.8.0-27.fc7 development 36 k libX11-devel i386 1.1.2-2.fc8 development 1.1 M libXau-devel i386 1.0.3-3.fc8 development 11 k libXdmcp-devel i386 1.0.2-4.fc8 development 7.7 k mesa-libGL-devel i386 7.0.1-4.fc8 development 448 k ncurses-devel i386 5.6-9.20070812.fc8 development 653 k ocaml i386 3.10.0-4.fc8 development 5.4 M ocaml-camlp4 i386 3.10.0-4.fc8 development 22 M ocaml-labltk i386 3.10.0-4.fc8 development 383 k ocaml-ocamldoc i386 3.10.0-4.fc8 development 2.2 M ocaml-runtime i386 3.10.0-4.fc8 development 1.5 M pkgconfig i386 1:0.22-3.fc8 development 66 k xorg-x11-proto-devel i386 7.2-13.fc8 development 277 k From jkeating at redhat.com Tue Sep 4 12:18:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 08:18:25 -0400 Subject: Developing Fedora Derivative distro yum "priority" question In-Reply-To: <46DC6C78.1010405@fedoraproject.org> References: <6e24a8e80708301354s4e830a3t225bd4ea7a403721@mail.gmail.com> <1188507923.27085.280.camel@cutter> <6e24a8e80708301417g6fc2e9d0kf009913fff4fe961@mail.gmail.com> <1188509897.3654.15.camel@dhcp83-165.boston.redhat.com> <1188510322.22413.27.camel@oneill.fubar.dk> <6e24a8e80708310520y1919d75ej52fde4eb779e269f@mail.gmail.com> <46D82A01.4000301@filteredperception.org> <46D83B7E.9040703@fedoraproject.org> <604aa7910708311146o704f2300w91c331b404db8fb2@mail.gmail.com> <46DC6C78.1010405@fedoraproject.org> Message-ID: <20070904081825.7fb08d13@ender> On Tue, 04 Sep 2007 01:50:08 +0530 Rahul Sundaram wrote: > Ideally we will have tools that allow you to pass a argument that > marks a custom spin as a derivative with appropriate text and > branding in the right places and use the documentation only to > compliment the capability with these tools. Yes, there is some idea of including a generic logos package within Fedora so that one can be used instead of the branded logos very easily, and have all the appropriate "based on" whatever language. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Sep 4 12:21:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 08:21:39 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188845719.4826.3.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> Message-ID: <20070904082139.2a2d40d6@ender> On Mon, 03 Sep 2007 14:55:19 -0400 Stewart Adam wrote: > That's what I'm saying - Letting the user select is nice. Some > machine's fans will blare, others not. Some Desktop CPU have throttle > states, others none or not enough to make a big change. Letting the user choose is fine. Asking every single user the question is not fine. I'm all for customization and choice, I just think we toss enough technobabble at people and get in their way enough before we let them use the system. Keep in mind that Live images don't really go through this and there haven't been many(any?) complaints in that area despite the rather large uptake on usage. I think that model somewhat proves that we don't have to bombard our users with a ton of questions and instead pick reasonable defaults and provide tools to adjust after the fact. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rjones at redhat.com Tue Sep 4 12:27:05 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 13:27:05 +0100 Subject: rawhide report: 20070904 changes In-Reply-To: <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DD4F19.6010000@redhat.com> Michael Schwendt wrote: > On Tue, 04 Sep 2007 13:00:15 +0100, Richard W.M. Jones wrote: > >>>> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log >>> Have you rebuilt ocaml-lablgl for the new version-release of ocaml >>> yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see >>> here, too >> I can't build ocaml-lablgl because I'm not the package owner (AIUI). >> >> I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not >> needed for that build. > > Okay, then let's see whether the failure is reproducible with > a scratch-build of ocaml-findlib: > http://koji.fedoraproject.org/koji/taskinfo?taskID=146938 > > ocaml-lablgl is not listed anywhere in the koji buildroot log and not during > the resolve-step either. So ... it's a bug in Koji then? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Tue Sep 4 12:27:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 08:27:20 -0400 Subject: Libedit build failure (was: rawhide report: 20070902 changes) In-Reply-To: <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> References: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> Message-ID: <20070904082720.6790e959@ender> On Tue, 4 Sep 2007 17:49:47 +0530 "Debarshi 'Rishi' Ray" wrote: > Can someone kindly look into this? I have already got a bug > (http://koji.fedoraproject.org/koji/buildinfo?buildID=17689 )which > seems to be related to this issue. libedit was asked to be orphaned from f8, thus it was blocked. If you are reviving the package I will unblock it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Tue Sep 4 12:46:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Sep 2007 14:46:15 +0200 Subject: ocaml-lablgl problems =?utf-8?b?wrc=?= Re: rawhide report: 20070904 changes In-Reply-To: <46DD4F19.6010000@redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> Message-ID: <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Sep 2007 13:27:05 +0100, Richard W.M. Jones wrote: > Michael Schwendt wrote: > > On Tue, 04 Sep 2007 13:00:15 +0100, Richard W.M. Jones wrote: > > > >>>> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log > >>> Have you rebuilt ocaml-lablgl for the new version-release of ocaml > >>> yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see > >>> here, too > >> I can't build ocaml-lablgl because I'm not the package owner (AIUI). > >> > >> I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not > >> needed for that build. > > > > Okay, then let's see whether the failure is reproducible with > > a scratch-build of ocaml-findlib: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=146938 > > > > ocaml-lablgl is not listed anywhere in the koji buildroot log and not during > > the resolve-step either. > > So ... it's a bug in Koji then? To me it smells like conflicting Provides. Take a look at what symbols ocaml-lablgl provides: http://koji.fedoraproject.org/koji/rpminfo?rpmID=191299 I understand you don't want the package as BR, but other ocaml-* packages contain corresponding Requires: $ repoquery --whatrequires 'ocaml(Arg) ocaml(Array) ocaml(Buffer) ocaml(Callback) ocaml(Char) ocaml(Gl) ocaml(GlArray) ocaml(GlClear) ocaml(GlDraw) ocaml(GlFunc) ocaml(GlLight) ocaml(GlList) ocaml(GlMap) ocaml(GlMat) ocaml(GlMisc) ocaml(GlPix) ocaml(GlTex) ocaml(GluMat) ocaml(GluMisc) ocaml(GluNurbs) ocaml(GluQuadric) ocaml(GluTess) ocaml(Glut) ocaml(Hashtbl) ocaml(List) ocaml(Obj) ocaml(Pervasives) ocaml(Printf) ocaml(Protocol) ocaml(Raw) ocaml(Rawwidget) ocaml(StdLabels) ocaml(String) ocaml(Support) ocaml(Textvariable) ocaml(Timer) ocaml(Tk) ocaml(Togl) ocaml(Widget)' ocaml-ocamldoc-0:3.10.0-4.fc8.i386 ocaml-0:3.10.0-4.fc8.i386 ocaml-lablgl-0:1.02-12.fc8.i386 ocaml-camlp4-0:3.10.0-4.fc8.i386 ocaml-ulex-0:1.0-3.fc8.i386 ocaml-labltk-0:3.10.0-4.fc8.i386 This can cause ocaml-lablgl to be pulled in by yum depsolving, because it is one packages that "Provides" the required thing. From skvidal at fedoraproject.org Tue Sep 4 12:38:26 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 04 Sep 2007 08:38:26 -0400 Subject: Making "upstream" tarballs available In-Reply-To: <46D8866F.5010208@gmail.com> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> <46D86D98.6090207@fedoraproject.org> <46D87E9D.5070701@gmail.com> <46D88284.90305@fedoraproject.org> <46D8866F.5010208@gmail.com> Message-ID: <1188909506.14826.4.camel@cutter> On Fri, 2007-08-31 at 14:21 -0700, Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rahul Sundaram wrote: > > Toshio Kuratomi wrote: > > > >> We can add the recommendation but we can't eliminate the "SRPM is > >> canonical" language as long as people still want the SRPM to be the > >> canonical location. To remove the exception, you'll have to talk to the > >> devs involved to see whether they're against moving into hosted.fp.o. > >> > >> If everyone wants to we'd be happy to get rid of the exception :-) > > > > The next thing would be is to list out the packages which has the > > packages as the canonical source, contact the developers and ask them if > > they are willing to move to hosted. > > Seth is working on this. I haven't looked at it because not all > packages are reviewed yet.... and therefore not all packages are going > to have proper Source: lines or comments conforming to the Guidelines. Here's the results - I just did searches against devel and F-7 pkgs. http://skvidal.fedorapeople.org/misc/source-without-url.txt the script I used is here: http://skvidal.fedorapeople.org/misc/look-for-no-url-source.sh It should help us track down the ones we can control and help it. some that are listed that spring to mind: system-config-bind system-config-boot system-config-cluster system-config-date system-config-display system-config-firewall system-config-keyboard system-config-kickstart system-config-language system-config-lvm system-config-netboot system-config-network system-config-nfs system-config-printer system-config-rootpassword system-config-samba system-config-securitylevel system-config-services system-config-soundcard system-config-users system-switch-java system-switch-mail -sv From mike at miketc.com Tue Sep 4 12:45:26 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 04 Sep 2007 07:45:26 -0500 Subject: rawhide report: 20070904 changes In-Reply-To: <200709040909.l84997hk001453@porkchop.devel.redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> Message-ID: <1188909926.12253.6.camel@scrappy.miketc.com> On Tue, 2007-09-04 at 05:09 -0400, Build System wrote: > Broken deps for i386 > ---------------------------------------------------------- > ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > Heh, the two programs above are really getting annoying seeing them on the rawhide build email everyday. Any chance these are getting rebuilt or fixed soon? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From debarshi.ray at gmail.com Tue Sep 4 12:47:43 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Sep 2007 18:17:43 +0530 Subject: Libedit build failure (was: rawhide report: 20070902 changes) In-Reply-To: <20070904082720.6790e959@ender> References: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> <20070904082720.6790e959@ender> Message-ID: <3170f42f0709040547i2e327483qb65b36ad788675b7@mail.gmail.com> > libedit was asked to be orphaned from f8, thus it was blocked. If you > are reviving the package I will unblock it. I am reviving it, and have asked for F-7 and FC-6 branches also. Currently I could build it for F-&, but not for Rawhide. I have not tried FC-6 yet. Can you please unblock it? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mackay_d at bellsouth.net Tue Sep 4 12:48:18 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 07:48:18 -0500 Subject: Python 3.0 In-Reply-To: <46DC51EB.70207@fedoraunity.org> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <46DC51EB.70207@fedoraunity.org> Message-ID: <1188910098.1394.28.camel@vorpal.macdev.com> On Mon, 2007-09-03 at 12:26 -0600, Jonathan Steffan wrote: > > As it stands, Zope and Plone, which were availabe in > > Extras for FC6, aren't available directly, and probably won't be for F8. > > I'm still maintaining the FC6 packages and the EPEL packages (granted > updates for EPEL go to updates-testing) using the provided python. Hi, Jonathan. FC6 will hit EOL soon, but I suppose maintaing things for EPEL will keep you off the streets, and out of bars for a while. > Plone will not be running on python 2.5 for some time. Plone is > currently targeting Zope 2, albeit "Five" is like backporting Zope 3 > code, and Zope 3 is *just now* starting to work with python 2.5... or is > at least close. This currently has the effect of restricting Zope 2 to > FC <= 6. I can't speak for the Zope developers, but I don't see a rush > to also get Zope 2 working with python 2.5. And, I wouldn't be too sanguine about the prospects of either working with 2.6 for quite some time. > == compat-python24 == > > Maybe today I will finish my upgrade testing and will push the compat- > packages into livna. The compat-python packages have passed review and I > just need to upload the new compat packages for zope (2.10.4) and plone > (3.0). I'm guessing this means I am going to end up being the > compat-python maintainer [in livna]. I was more or less avoiding this > because I'm not sure I will know what to do when things break and would > inheritly be passing the buck, so to speak. I would have to ask for Unless it somehow interferes with the standard python package, be it 2.5, 2.6, or whatever, I don't expect much. I'd love to get a recap of that in about six months or so. Out of the twelve bugs for python in FC6, eight were dups, not a bug, or rawhide. The four actual bugs that are still open were probably kicked upstream, and remain open eight or nine months later. > help, either on IRC or this list (and have no problem doing so) which > does create extra overhead and is something that was trying to be > avoided. Anywho, the packages are done and work (I've been using them > for most of the Fedora 7 release). I've only packaged what is needed for > Zope/Plone and that was another point in the discussion. Who decides > what compat support/module we provide? Seeing as how the packages I've > done are for my personal uses for Zope/Plone, I'm most likely not going > to personally do many other compat-python packages. compat-python-ldap > will be there at some point, but I think that is all. Thank you very much for your efforts. > == /compat-python24 == > > > Zope/Plone is a somewhat special case with what broke and I'm not sure > having python 2.5 packages (in Fedora) earlier would have helped > anything. I'm all for getting python 3 packaged and available, but agree > outside of Fedora would be best. Even if python 3 is available, we are > still going to need to rely upon upstream projects using python to be > aware of the changes and start testing/fixing. There seems to be more to > this process then I want to spend time on (politics?) and thus have gone > the route of compat packages. I haven't really looked for discussion on the Zope lists concerning python 3.x, but if I owned as many lines of python code as they do, I'd be a very unhappy camper. Maybe someone will come along and design a language that's a worthy successor to python. Someone with a bit more regard for the end users. Dave From jkeating at redhat.com Tue Sep 4 12:43:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 08:43:00 -0400 Subject: Libedit build failure (was: rawhide report: 20070902 changes) In-Reply-To: <3170f42f0709040547i2e327483qb65b36ad788675b7@mail.gmail.com> References: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> <20070904082720.6790e959@ender> <3170f42f0709040547i2e327483qb65b36ad788675b7@mail.gmail.com> Message-ID: <20070904084300.21a831c2@ender> On Tue, 4 Sep 2007 18:17:43 +0530 "Debarshi 'Rishi' Ray" wrote: > I am reviving it, and have asked for F-7 and FC-6 branches also. > Currently I could build it for F-&, but not for Rawhide. I have not > tried FC-6 yet. > > Can you please unblock it? already done. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From debarshi.ray at gmail.com Tue Sep 4 12:52:51 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 4 Sep 2007 18:22:51 +0530 Subject: Libedit build failure (was: rawhide report: 20070902 changes) In-Reply-To: <20070904084300.21a831c2@ender> References: <3170f42f0709032054x16f394ackb1a8b1171816c179@mail.gmail.com> <3170f42f0709040519j4a9abc4ds939f96fcc0cc8b76@mail.gmail.com> <20070904082720.6790e959@ender> <3170f42f0709040547i2e327483qb65b36ad788675b7@mail.gmail.com> <20070904084300.21a831c2@ender> Message-ID: <3170f42f0709040552n459f22b1m8df70a799a9305c7@mail.gmail.com> >> Can you please unblock it? > already done. Thanks. :-) Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From rjones at redhat.com Tue Sep 4 12:50:09 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 13:50:09 +0100 Subject: ocaml-lablgl problems =?utf-8?q?=C2=B7_Re=3A_rawhide_report?= =?utf-8?q?=3A_20070904_changes?= In-Reply-To: <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DD5481.4040509@redhat.com> Michael Schwendt wrote: > On Tue, 04 Sep 2007 13:27:05 +0100, Richard W.M. Jones wrote: > >> Michael Schwendt wrote: >>> On Tue, 04 Sep 2007 13:00:15 +0100, Richard W.M. Jones wrote: >>> >>>>>> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log >>>>> Have you rebuilt ocaml-lablgl for the new version-release of ocaml >>>>> yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see >>>>> here, too >>>> I can't build ocaml-lablgl because I'm not the package owner (AIUI). >>>> >>>> I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not >>>> needed for that build. >>> Okay, then let's see whether the failure is reproducible with >>> a scratch-build of ocaml-findlib: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=146938 >>> >>> ocaml-lablgl is not listed anywhere in the koji buildroot log and not during >>> the resolve-step either. >> So ... it's a bug in Koji then? > > To me it smells like conflicting Provides. > Take a look at what symbols ocaml-lablgl provides: > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=191299 OK, the provides in that package are totally wrong. Someone else built that package? (I admit I don't really understand the complex system of branches used by Fedora). In fedora-development repo I see the correct list of provides for that package: rjones at oirase:~$ repoquery --provides ocaml-lablgl ocaml(Gl) = cd8e921dfaef68b9f7fdf19f19093d5e ocaml(GlArray) = 12a887a1d8b0554c82b2b7ec6ab8b9c6 ocaml(GlClear) = 8bb155ee2a37256be58e2a0157b8bafe ocaml(GlDraw) = 06a8bccb576f39b6fc4dd55c04423355 [etc.] (ie. no ocaml(Arg), etc. which are provided by the base ocaml-runtime package). So what can I do to fix this? Temporarily add Conflicts? Can I tell yum to definitely choose one package over another? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rc040203 at freenet.de Tue Sep 4 12:55:47 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 04 Sep 2007 14:55:47 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <1188909926.12253.6.camel@scrappy.miketc.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <1188909926.12253.6.camel@scrappy.miketc.com> Message-ID: <1188910547.24848.542.camel@mccallum.corsepiu.local> On Tue, 2007-09-04 at 07:45 -0500, Mike Chambers wrote: > On Tue, 2007-09-04 at 05:09 -0400, Build System wrote: > > > Broken deps for i386 > > ---------------------------------------------------------- > > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > > > > Heh, the two programs above are really getting annoying seeing them on > the rawhide build email everyday. Any chance these are getting rebuilt > or fixed soon? osgcal, osgal and openalpp are victims of the OpenSceneGraph-2 API changes. I already had proposed an approach to keep these programs (Downgrade OpenSceneGraph to OSG-1 and to add an OpenSceneGraph2 package), but feedback so far had been more or less non-exitant Remain the alternatives to make these packages buildable against OpenSceneGraph-2 (Doable for 1 or them - IIRC, it's osgal) or to abandoned them (osgalpp or osgal is dead upstream). Ralf From rjones at redhat.com Tue Sep 4 12:55:30 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 13:55:30 +0100 Subject: rawhide report: 20070904 changes In-Reply-To: <1188909926.12253.6.camel@scrappy.miketc.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <1188909926.12253.6.camel@scrappy.miketc.com> Message-ID: <46DD55C2.7030804@redhat.com> Mike Chambers wrote: >> ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 >> ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 > Heh, the two programs above are really getting annoying seeing them on > the rawhide build email everyday. Any chance these are getting rebuilt > or fixed soon? See the other part of this thread. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mackay_d at bellsouth.net Tue Sep 4 12:59:08 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 07:59:08 -0500 Subject: Python 3.0 In-Reply-To: <20070903142716.38a70949@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> Message-ID: <1188910748.1394.39.camel@vorpal.macdev.com> On Mon, 2007-09-03 at 14:27 -0400, Jesse Keating wrote: > On Mon, 03 Sep 2007 09:08:00 -0500 > "David G. Mackay" wrote: > > > I have a machine running FC6 with Zope and Plone. It will probably be > > migrated to Centos 5 soon as FC6 support will probably go away before > > 2008. And. who knows, it might become a critical enough app that I'll > > spring for RHEL5 support. > > > And there is absolutely nothing wrong with that migration path. The > best tool for the job. The Fedora universe as it were has a multitude > of tools in it's tool belt. There is Fedora, there is RHEL, there is > EPEL, and to some extent there is CentOS. There are also tools that > will allow you to create your own erm.. tool for whatever job you need > to do. Provided all this, I can't fathom a case where your need isn't > serviced by at least one of these offerings. The move to Centos or RHEL is due more to the switch from a development phase to production. I simply want the longer life cycle. You seem to be saying that it's alright for Fedora to lack useful features if the features are available in RHEL. That seems to make Fedora's utility as an upstream provider to RHEL somewhat less. And, FWIW, it is almost trivially easy to set up python and Zope under just about any flavor of Microsoft Windows from Win2K onwards. Security and maintenance are a different case, but I digress. Dave From mschwendt.tmp0701.nospam at arcor.de Tue Sep 4 13:08:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Sep 2007 15:08:03 +0200 Subject: ocaml-lablgl problems =?utf-8?b?wrc=?= Re: rawhide report: 20070904 changes In-Reply-To: <46DD5481.4040509@redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> <46DD5481.4040509@redhat.com> Message-ID: <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Sep 2007 13:50:09 +0100, Richard W.M. Jones wrote: > Michael Schwendt wrote: > > On Tue, 04 Sep 2007 13:27:05 +0100, Richard W.M. Jones wrote: > > > >> Michael Schwendt wrote: > >>> On Tue, 04 Sep 2007 13:00:15 +0100, Richard W.M. Jones wrote: > >>> > >>>>>> http://koji.fedoraproject.org/koji/getfile?taskID=146743&name=root.log > >>>>> Have you rebuilt ocaml-lablgl for the new version-release of ocaml > >>>>> yet? It still requires the older ocaml = 3.10.0-4.fc8 as you can see > >>>>> here, too > >>>> I can't build ocaml-lablgl because I'm not the package owner (AIUI). > >>>> > >>>> I don't _want_ ocaml-labgl in order to build ocaml-findlib - it's not > >>>> needed for that build. > >>> Okay, then let's see whether the failure is reproducible with > >>> a scratch-build of ocaml-findlib: > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=146938 > >>> > >>> ocaml-lablgl is not listed anywhere in the koji buildroot log and not during > >>> the resolve-step either. > >> So ... it's a bug in Koji then? > > > > To me it smells like conflicting Provides. > > Take a look at what symbols ocaml-lablgl provides: > > > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=191299 > > OK, the provides in that package are totally wrong. > > Someone else built that package? (I admit I don't really understand the > complex system of branches used by Fedora). In fedora-development repo > I see the correct list of provides for that package: > > rjones at oirase:~$ repoquery --provides ocaml-lablgl > ocaml(Gl) = cd8e921dfaef68b9f7fdf19f19093d5e > ocaml(GlArray) = 12a887a1d8b0554c82b2b7ec6ab8b9c6 > ocaml(GlClear) = 8bb155ee2a37256be58e2a0157b8bafe > ocaml(GlDraw) = 06a8bccb576f39b6fc4dd55c04423355 > [etc.] > > (ie. no ocaml(Arg), etc. which are provided by the base ocaml-runtime > package). What you call "fedora-development repo" is the frozen repo, whereas in koji there is a newer build of ocaml-lablgl: ocaml-lablgl = 1.02-12.fc8 (fedora-development) vs. ocaml-lablgl = 1.02-13.fc8 (koji) Apparently, the latter build (after the freeze!) is broken and provides more stuff. > So what can I do to fix this? Temporarily add Conflicts? Can I tell > yum to definitely choose one package over another? Open a ticket? From jkeating at redhat.com Tue Sep 4 13:00:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 09:00:32 -0400 Subject: Python 3.0 In-Reply-To: <1188910748.1394.39.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> Message-ID: <20070904090032.228151a8@ender> On Tue, 04 Sep 2007 07:59:08 -0500 "David G. Mackay" wrote: > The move to Centos or RHEL is due more to the switch from a > development phase to production. I simply want the longer life cycle. > > You seem to be saying that it's alright for Fedora to lack useful > features if the features are available in RHEL. That seems to make > Fedora's utility as an upstream provider to RHEL somewhat less. I'm saying that it's Ok for Fedora to abandon compatibility layers if there are other viable platforms in the Fedora universe that will support the required software. Fedora is about moving forward, not dragging behind. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Sep 4 13:02:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 09:02:06 -0400 Subject: ocaml-lablgl problems =?utf-8?b?wrc=?= Re: rawhide report: 20070904 changes In-Reply-To: <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> <46DD5481.4040509@redhat.com> <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070904090206.42bdd3dd@ender> On Tue, 4 Sep 2007 15:08:03 +0200 Michael Schwendt wrote: > What you call "fedora-development repo" is the frozen repo, whereas > in koji there is a newer build of ocaml-lablgl: > > ocaml-lablgl = 1.02-12.fc8 (fedora-development) > vs. > ocaml-lablgl = 1.02-13.fc8 (koji) > > Apparently, the latter build (after the freeze!) is broken and > provides more stuff. > > > So what can I do to fix this? Temporarily add Conflicts? Can I > > tell yum to definitely choose one package over another? > > Open a ticket? I would also suggest forming a ocaml SIG since it seems to be a large set of packages handled by a variety of different maintainers. You all should work together on this framework and prevent these things from happening. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Tue Sep 4 13:19:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 04 Sep 2007 15:19:48 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <1188910547.24848.542.camel@mccallum.corsepiu.local> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <1188909926.12253.6.camel@scrappy.miketc.com> <1188910547.24848.542.camel@mccallum.corsepiu.local> Message-ID: <46DD5B74.2080204@hhs.nl> Ralf Corsepius wrote: > On Tue, 2007-09-04 at 07:45 -0500, Mike Chambers wrote: >> On Tue, 2007-09-04 at 05:09 -0400, Build System wrote: >> >>> Broken deps for i386 >>> ---------------------------------------------------------- > >>> openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 >>> osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgText.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosg.so.1 >>> osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 >>> osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 >>> >> Heh, the two programs above are really getting annoying seeing them on >> the rawhide build email everyday. Any chance these are getting rebuilt >> or fixed soon? > > osgcal, osgal and openalpp are victims of the OpenSceneGraph-2 API > changes. > > I already had proposed an approach to keep these programs (Downgrade > OpenSceneGraph to OSG-1 and to add an OpenSceneGraph2 package), but > feedback so far had been more or less non-exitant > Thats not completely true, you did get feedback from several people including me, and I agree with Mike that these breakages are getting very annoying and should be fixed soon. Let me repeat my solution of when you asked howto downgrade: 1) Make the main OpenSceneGraph package OpenSceneGraph 1.x again, using epoch to fix version issues. 2) Add a new OpenSceneGraph2 package 3) Make the devel's conflict each other if doing an other solution turns out to be a lot of work. Solved. Regards, Hans From rjones at redhat.com Tue Sep 4 13:31:10 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 14:31:10 +0100 Subject: ocaml-lablgl problems =?utf-8?q?=C2=B7_Re=3A_rawhide_report?= =?utf-8?q?=3A_20070904_changes?= In-Reply-To: <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> <46DD5481.4040509@redhat.com> <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DD5E1E.6040001@redhat.com> Michael Schwendt wrote: > What you call "fedora-development repo" is the frozen repo, whereas > in koji there is a newer build of ocaml-lablgl: Is there documentation anywhere about these different repos? Naively I thought that the devel/ subdirectory must correspond in some way to the development repo, but obviously that's not the case. Jesse Keating wrote: > I would also suggest forming a ocaml SIG since it seems to be a large > set of packages handled by a variety of different maintainers. You all > should work together on this framework and prevent these things from > happening. We have one ... we are even talking to each other about this problem. The problem is that neither of us understands how to fix this. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rc040203 at freenet.de Tue Sep 4 13:38:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 04 Sep 2007 15:38:57 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <46DD5B74.2080204@hhs.nl> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <1188909926.12253.6.camel@scrappy.miketc.com> <1188910547.24848.542.camel@mccallum.corsepiu.local> <46DD5B74.2080204@hhs.nl> Message-ID: <1188913137.24848.554.camel@mccallum.corsepiu.local> On Tue, 2007-09-04 at 15:19 +0200, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Tue, 2007-09-04 at 07:45 -0500, Mike Chambers wrote: > >> On Tue, 2007-09-04 at 05:09 -0400, Build System wrote: > >> > >>> Broken deps for i386 > >>> ---------------------------------------------------------- > > > >>> openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosg.so.1 > >>> osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > >>> > >> Heh, the two programs above are really getting annoying seeing them on > >> the rawhide build email everyday. Any chance these are getting rebuilt > >> or fixed soon? > > > > osgcal, osgal and openalpp are victims of the OpenSceneGraph-2 API > > changes. > > > > I already had proposed an approach to keep these programs (Downgrade > > OpenSceneGraph to OSG-1 and to add an OpenSceneGraph2 package), but > > feedback so far had been more or less non-exitant > > > > Thats not completely true, you did get feedback from several people including > me, and I agree with Mike that these breakages are getting very annoying and > should be fixed soon. I am not in a position to fix them. ACLs, conventions > Let me repeat my solution of when you asked howto downgrade: > 1) Make the main OpenSceneGraph package OpenSceneGraph 1.x again, using epoch > to fix version issues. Won't help any of the packages, because they would still BR the wrong versions. i.e. these packages would not survive a rebuild without manual intervention. > 2) Add a new OpenSceneGraph2 package Non-applicable without epoch bump or rel-eng intervening. > 3) Make the devel's conflict each other if doing an other solution turns out to > be a lot of work. The devel packages would Conflict in any case, because the OSG-devel packages can't be made installable in parallel without major effort. > Solved. I didn't say it wasn't solvable. I was hoping for ways to avoid the epoch bump, or the maintainers of the packages above would have the insight to acknowledge their packages to be dead rsp. them to upgrade them to OSG2. To me, it doesn't make real sense to keep them. Ralf From mschwendt.tmp0701.nospam at arcor.de Tue Sep 4 13:59:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 4 Sep 2007 15:59:01 +0200 Subject: ocaml-lablgl problems =?utf-8?b?wrc=?= Re: rawhide report: 20070904 changes In-Reply-To: <46DD5E1E.6040001@redhat.com> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> <46DD5481.4040509@redhat.com> <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> <46DD5E1E.6040001@redhat.com> Message-ID: <20070904155901.21a1fee9.mschwendt.tmp0701.nospam@arcor.de> On Tue, 04 Sep 2007 14:31:10 +0100, Richard W.M. Jones wrote: > Michael Schwendt wrote: > > What you call "fedora-development repo" is the frozen repo, whereas > > in koji there is a newer build of ocaml-lablgl: > > Is there documentation anywhere about these different repos? Naively I > thought that the devel/ subdirectory must correspond in some way to the > development repo, but obviously that's not the case. It _is_ the case. Except when there is a freeze. F8 Test2 was frozen on Aug 29th. That means the repo was frozen. Builds from devel/ after that date stay in koji and are not released into the development repo unless you request rel-eng to do that: http://fedoraproject.org/wiki/ReleaseEngineering/TestFreezePolicy When the freeze is done, builds that have piled up in koji automatically enter the development repo again. The problem is that despite the freeze of the repo, koji continues to build against the very latest builds from devel/ because it creates new _internal_ repositories from the latest packages, including newer broken ones which are not in the public development repo because of the freeze policy. During the freeze, packagers can break devel in koji, and the broken deps report doesn't know about it because it only examines the public [frozen] repo. This is what has happened with ocaml-lablgl. It was built in koji after the freeze and is available in the koji buildroots for F8 development, but not yet in the public development repo (aka rawhide). > Jesse Keating wrote: > > I would also suggest forming a ocaml SIG since it seems to be a large > > set of packages handled by a variety of different maintainers. You all > > should work together on this framework and prevent these things from > > happening. > > We have one ... we are even talking to each other about this problem. > The problem is that neither of us understands how to fix this. You need to find out which contents of the ocaml-lablgl package cause these "Provides", and if it is not a build/configuration problem, possibly you need to filter them out with customised find-provides/find-requires scripts. I assume the scripts in the ocaml main package are used to create the ocaml(Foo) Provides. From walters at redhat.com Tue Sep 4 13:52:35 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 4 Sep 2007 09:52:35 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <20070904082139.2a2d40d6@ender> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <20070904082139.2a2d40d6@ender> Message-ID: On 9/4/07, Jesse Keating wrote: > > On Mon, 03 Sep 2007 14:55:19 -0400 > Stewart Adam wrote: > > > That's what I'm saying - Letting the user select is nice. Some > > machine's fans will blare, others not. Some Desktop CPU have throttle > > states, others none or not enough to make a big change. > > > Letting the user choose is fine. Asking every single user the question > is not fine. I'm all for customization and choice, I just think we > toss enough technobabble at people and get in their way enough before > we let them use the system. Keep in mind that Live images don't really > go through this and there haven't been many(any?) complaints in that > area despite the rather large uptake on usage. I think that model > somewhat proves that we don't have to bombard our users with a ton of > questions and instead pick reasonable defaults and provide tools to > adjust after the fact. *shakes pom-poms* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at Dell.com Tue Sep 4 14:03:13 2007 From: Matt_Domsch at Dell.com (Matt Domsch) Date: Tue, 4 Sep 2007 09:03:13 -0500 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <20070904140313.GC16231@auslistsprd01.us.dell.com> On Thu, Aug 30, 2007 at 08:32:30PM -0500, Anthony Bryan wrote: > > On Tue, Jun 19, 2007 at 03:40:59PM -0400, Anthony Bryan wrote: > > > >On Sat, Jun 09, 2007 at 07:51:20PM +0200, Ruben Kerkhof wrote: > > > > > > Have you had a chance to look over Ruben's additions? Any feedback? He > > > said he re-licensed it to line up w/ mirrormanager. Any ideas/comments > > > for features in Metalink that could be of use to Fedora? > > > > Yes, I took a quick look; I'll be able to do something with this, but > > not for the next 4 weeks, as I'm out of the office moving houses and > > on vacation, then catching up on real work. :-) > > checking in after 10 wks :) Will what Ruben submitted be usable? First, I apologize for over-estimating how much time I would have to work on MirrorManager in the last few weeks. $DAYJOB and personal responsibilities have overwhelmed my time. I spent a few hours on the plane Sunday thinking about MM and where it's at, even worked on a little code. See my writeup over on fedora-infrastructure-list. http://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00005.html Short story is, I probably won't get any metalink enablement done before the F8 launch, but I can participate in discussions of ideas for where to integrate it in, and can review patches. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rjones at redhat.com Tue Sep 4 14:05:03 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 04 Sep 2007 15:05:03 +0100 Subject: ocaml-lablgl problems =?utf-8?q?=C2=B7_Re=3A_rawhide_report?= =?utf-8?q?=3A_20070904_changes?= In-Reply-To: <20070904155901.21a1fee9.mschwendt.tmp0701.nospam@arcor.de> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <46DD3FFD.4070308@redhat.com> <20070904134837.1780ad0c.mschwendt.tmp0701.nospam@arcor.de> <46DD48CF.1070703@redhat.com> <20070904143038.b73b1ac2.mschwendt.tmp0701.nospam@arcor.de> <46DD4F19.6010000@redhat.com> <20070904144615.96436da0.mschwendt.tmp0701.nospam@arcor.de> <46DD5481.4040509@redhat.com> <20070904150803.10b8f2e8.mschwendt.tmp0701.nospam@arcor.de> <46DD5E1E.6040001@redhat.com> <20070904155901.21a1fee9.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46DD660F.90606@redhat.com> Michael Schwendt wrote: [...] Thanks Michael - nice explanation. We're working on fixing this now. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From katzj at redhat.com Tue Sep 4 14:14:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 10:14:55 -0400 Subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use) In-Reply-To: <1188682736.29069.15.camel@Diffingo.localdomain> References: <1188528437.27085.304.camel@cutter> <1188659848.3615.0.camel@sb-home> <1188673750.29226.47.camel@cutter> <200709012141.49915.opensource@till.name> <20070901225510.b831776d.mschwendt.tmp0701.nospam@arcor.de> <1188682736.29069.15.camel@Diffingo.localdomain> Message-ID: <1188915295.4464.34.camel@localhost.localdomain> On Sat, 2007-09-01 at 17:38 -0400, Stewart Adam wrote: > A configurable option in Pirut that would display the changelog entries > of a package from the currently installed version to the updated version > in the 'Update Details' window would be very useful. I'm just not sure > how hard it would be to integrate into Pirut / if the metadata contains > that information so I'll say sorry in advance if this is completely > unfeasible/unreasonable. Well, the idea is that the update notices[1] can provide this information and that should be back RSN. Downloading the changelog data gets kind of painful (the metadata file with changelogs is currently at twice the size of the filelists which I consider pretty painfully large to have to download) Jeremy [1] The problem is that rawhide doesn't have these. Although I have seriously considered writing the simple stupid "snag the last n changelogs and stuff them into the update metadata format" script that could then be run on rawhide pushes. Even better would be if it did the changelog diff from the previously pushed package like the rawhide mails do. If someone wants to work on this, let me know and I can help point you in the right direction From notting at redhat.com Tue Sep 4 14:30:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Sep 2007 10:30:35 -0400 Subject: rawhide missing /bin/hostname In-Reply-To: <1188828058.4628.2.camel@localhost.localdomain> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> Message-ID: <20070904143035.GB15029@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > Wild guess: because setup doesn't require net-tools It can't (setup cannot have deps.) Bill From laroche at redhat.com Tue Sep 4 14:36:13 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 4 Sep 2007 16:36:13 +0200 Subject: rawhide missing /bin/hostname In-Reply-To: <20070904143035.GB15029@nostromo.devel.redhat.com> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> <20070904143035.GB15029@nostromo.devel.redhat.com> Message-ID: <20070904143612.GA12968@dudweiler.stuttgart.redhat.com> On Tue, Sep 04, 2007 at 10:30:35AM -0400, Bill Nottingham wrote: > Matthias Clasen (mclasen at redhat.com) said: > > Wild guess: because setup doesn't require net-tools > > It can't (setup cannot have deps.) Hello all, Is there a reason util-linux-ng cannot be added to the core set of rpms for Fedora-devel? regards, Florian La Roche From mclasen at redhat.com Tue Sep 4 14:36:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 04 Sep 2007 10:36:03 -0400 Subject: rawhide missing /bin/hostname In-Reply-To: <20070904143035.GB15029@nostromo.devel.redhat.com> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> <20070904143035.GB15029@nostromo.devel.redhat.com> Message-ID: <1188916563.4564.2.camel@localhost.localdomain> On Tue, 2007-09-04 at 10:30 -0400, Bill Nottingham wrote: > Matthias Clasen (mclasen at redhat.com) said: > > Wild guess: because setup doesn't require net-tools > > It can't (setup cannot have deps.) Then /etc/profile should probably handle the absence of /bin/hostname more gracefully. From mackay_d at bellsouth.net Tue Sep 4 14:39:42 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 09:39:42 -0500 Subject: Python 3.0 In-Reply-To: <20070904090032.228151a8@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> Message-ID: <1188916783.1916.7.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 09:00 -0400, Jesse Keating wrote: > On Tue, 04 Sep 2007 07:59:08 -0500 > "David G. Mackay" wrote: > > > The move to Centos or RHEL is due more to the switch from a > > development phase to production. I simply want the longer life cycle. > > > > You seem to be saying that it's alright for Fedora to lack useful > > features if the features are available in RHEL. That seems to make > > Fedora's utility as an upstream provider to RHEL somewhat less. > > I'm saying that it's Ok for Fedora to abandon compatibility layers if > there are other viable platforms in the Fedora universe that will > support the required software. Fedora is about moving forward, not > dragging behind. Why does this remind me of Pangloss in Candide? And, I have been rather forcefully told on this list that Fedora stands alone. Dave From skvidal at fedoraproject.org Tue Sep 4 14:40:00 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 04 Sep 2007 10:40:00 -0400 Subject: rawhide missing /bin/hostname In-Reply-To: <20070904143612.GA12968@dudweiler.stuttgart.redhat.com> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> <20070904143035.GB15029@nostromo.devel.redhat.com> <20070904143612.GA12968@dudweiler.stuttgart.redhat.com> Message-ID: <1188916800.14826.14.camel@cutter> On Tue, 2007-09-04 at 16:36 +0200, Florian La Roche wrote: > On Tue, Sep 04, 2007 at 10:30:35AM -0400, Bill Nottingham wrote: > > Matthias Clasen (mclasen at redhat.com) said: > > > Wild guess: because setup doesn't require net-tools > > > > It can't (setup cannot have deps.) > > Hello all, > > Is there a reason util-linux-ng cannot be added to > the core set of rpms for Fedora-devel? > util-linux-ng appears to be in Core in comps.xml in rawhide. -sv From laroche at redhat.com Tue Sep 4 14:44:29 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 4 Sep 2007 16:44:29 +0200 Subject: rawhide missing /bin/hostname In-Reply-To: <1188916800.14826.14.camel@cutter> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> <20070904143035.GB15029@nostromo.devel.redhat.com> <20070904143612.GA12968@dudweiler.stuttgart.redhat.com> <1188916800.14826.14.camel@cutter> Message-ID: <20070904144429.GA13238@dudweiler.stuttgart.redhat.com> On Tue, Sep 04, 2007 at 10:40:00AM -0400, seth vidal wrote: > > On Tue, 2007-09-04 at 16:36 +0200, Florian La Roche wrote: > > On Tue, Sep 04, 2007 at 10:30:35AM -0400, Bill Nottingham wrote: > > > Matthias Clasen (mclasen at redhat.com) said: > > > > Wild guess: because setup doesn't require net-tools > > > > > > It can't (setup cannot have deps.) > > > > Hello all, > > > > Is there a reason util-linux-ng cannot be added to > > the core set of rpms for Fedora-devel? > > > > > util-linux-ng appears to be in Core in comps.xml in rawhide. Hello Seth, for koji/mock into the minimal set of installed packages. Could be either a hardcoded list in mock per release or into the comps file, should both work fine. regards, Florian La Roche From katzj at redhat.com Tue Sep 4 14:45:46 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 10:45:46 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188825506.9729.41.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> Message-ID: <1188917146.4464.41.camel@localhost.localdomain> On Mon, 2007-09-03 at 15:18 +0200, Martin Sourada wrote: > Yes, most ARE, but the one with services could be useful. There is a > batch of services that are useful on most of notebooks, but are unneeded > on most of Desktops/Servers and vice versa. And we'd like to get rid of > as much unneeded services as possible, so if we target the default ones > with a thought of the target platform, it would be IMHO more effective. > Maybe it could go to anaconda, but personally I think that first boot is > better place for that. Actually, the bigger problem is the concept that everything has to be a "system service run from an initscript". To pick a specific case -- the fact that bluetooth daemons get started by an initscript as a service is really not what you want at this point. You instead want them being started based on the existence of the hardware probably as a hal callout[1]. The same can really be said for most of the things which start by default currently which are maybe not needed in some cases. Services are for _servers_. And having to enable them (via system-config-services or chkconfig or ...) to use them makes sense because that's hardly going to be the only configuration you need to do for them. Jeremy [1] Bluetooth specifically is tracked with https://bugzilla.redhat.com/show_bug.cgi?id=222315 and the more general tracker bug is https://bugzilla.redhat.com/show_bug.cgi?id=222312 From ajackson at redhat.com Tue Sep 4 14:38:37 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 10:38:37 -0400 Subject: rawhide report: 20070830 changes In-Reply-To: <46D9CB06.30303@fedoraproject.org> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> <1188676645.1175.722.camel@localhost.localdomain> <46D9CB06.30303@fedoraproject.org> Message-ID: <1188916717.24181.1.camel@localhost.localdomain> On Sun, 2007-09-02 at 01:56 +0530, Rahul Sundaram wrote: > Adam Jackson wrote: > > On Sat, 2007-09-01 at 01:31 +0530, Rahul Sundaram wrote: > >> Build System wrote: > >>> New package java-1.7.0-icedtea > >>> IcedTea Runtime Environment > >> Good to see this. Is there any chance we can provide this for Fedora 7? > > > > That seems like a lot of work for little gain. I would much prefer the > > IcedTea developers spend their time on making it really great for F8, > > instead of making it mediocre for both F8 and F7 > > There are already Fedora 7 SRPMS available. Why would putting it in the > repository make it mediocre for Fedora 8? Duplication of effort, polynomial case explosion, blah blah. Fixing F7 takes time away from improving F8. I really shouldn't have to explain this. - ajax From katzj at redhat.com Tue Sep 4 14:47:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Sep 2007 10:47:06 -0400 Subject: rawhide report: 20070904 changes In-Reply-To: <20070904105522.M20665@all-the-johnsons.co.uk> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <20070904105522.M20665@all-the-johnsons.co.uk> Message-ID: <1188917226.4464.44.camel@localhost.localdomain> On Tue, 2007-09-04 at 10:55 +0000, Paul F. Johnson wrote: > > Updated Packages: > > > > For some reason, I can't do an update as yum complains that dbus and dbus-glib > both need a version of libexpat which is out of sync. Is anyone else seeing > this after doing an install from the 8T1 x86_64 DVD? Update yum first and it should work. Jeremy From ajackson at redhat.com Tue Sep 4 14:39:54 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 10:39:54 -0400 Subject: ubuntu bulletproof x In-Reply-To: <46DB3D8D.9060309@gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> Message-ID: <1188916794.24181.3.camel@localhost.localdomain> On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote: > Dominik 'Rathann' Mierzejewski wrote: > > On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: > > [...] > >> (and again, for the sake of argument, lets pretend that doing anything > >> from a command line, or editing a text file, or researching obscure > >> specs about your monitor, is not an option for the users in question) > > > > I think that for majority of monitors out there, you can find the specs > > in 5 minutes using Google. > > And then translate that into a modeline with another 3 days of googling. Why does anyone write a modeline by hand anymore? % man cvt - ajax From ajackson at redhat.com Tue Sep 4 14:48:11 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 10:48:11 -0400 Subject: ubuntu bulletproof x In-Reply-To: <46DB64AE.6000001@gmail.com> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB4C77.6060108@gmail.com> <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> <46DB64AE.6000001@gmail.com> Message-ID: <1188917291.24181.12.camel@localhost.localdomain> On Sun, 2007-09-02 at 20:34 -0500, Les Mikesell wrote: > Jeff Spaleta wrote: > > On 9/2/07, Les Mikesell wrote: > >> Isn't the fact that windows works with them a pretty good demonstration? > > > > Sadly we don't have access to that source code now do we. Please keep > > the rhetorical comments to a minimum. > > Seems pretty objective to me... Windows does almost exactly what we do. It uses the EDID information if it can be found, otherwise it constructs a list of candidate modes based on sync ranges. Some of them will be out of range for the monitor; it happens to have better UI for reverting to the older settings. > >> Is he suggesting that windows uses magic? I thought he meant instead > >> that X doesn't use the information sensibly. > > > > Are you asking me to-reinterpret Mr. Jackson's statements for > > additional implied meaning? Please, call me ajax. The only people who call me Adam or Mr. Jackson are telemarketers and judges. > Yes, in particular: > > "So you end up in some pretty hilarious situations, because > X prefers width over height, so even though your monitor's > 1600x1200, the sync range is big enough to fit 1680x1050, > so you'll try to fit that, and lose." > > I interpret that as an X issue, not a lack of information in the inf file. It's debatable whether that logic in X is a bug or not. It's certainly correct when sorting modes smaller than the native screen size: your field of vision is much wider than it is tall, so X should prefer wider modes. You only ever hit it as a bug in configuration when X can't query the monitor for its native aspect ratio, and you only manually specify sync ranges. The inf file does not give you aspect ratio. It only gives you sync ranges. - ajax From ajackson at redhat.com Tue Sep 4 14:51:54 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 10:51:54 -0400 Subject: ubuntu bulletproof x In-Reply-To: <20070902195925.GA20581@dspnet.fr.eu.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <20070902195925.GA20581@dspnet.fr.eu.org> Message-ID: <1188917514.24181.15.camel@localhost.localdomain> On Sun, 2007-09-02 at 21:59 +0200, Olivier Galibert wrote: > On Sun, Sep 02, 2007 at 02:24:06PM +0200, Matej Cepl wrote: > > Concerning the former, I don't understand how would information > > provided to Windows by the vendor was that much better than > > information they provide via hardware. > > "Hey, the tester says that the new monitor doesn't work with his video > card, it says 'out of range'" > "Oh, indeed, we broke EDID. Don't worry, we'll fix it on the driver > CD" If you can find _any_ driver CD where this happens, I will gladly write the code to use it. - ajax From ajackson at redhat.com Tue Sep 4 15:01:10 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 11:01:10 -0400 Subject: ubuntu bulletproof x In-Reply-To: <46DC6643.40308@filteredperception.org> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> Message-ID: <1188918070.24181.25.camel@localhost.localdomain> On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote: > Adam Jackson wrote: > > Yeah, okay, force me to clarify. Grumble. > > > > There are cases where we can't tell what monitor the user has. They're > > almost completely described by "either the card can't do DDC, or the > > cable is broken". The former is a vanishingly small class of hardware, > > voodoo1 basically. The latter happens depressingly often particularly > > with projector setups. > So, to save you the trouble of rereading all of my posts. Can you > explicitly confirm this (which it sounds like you did, but not in a way > that clearly addressed the point I tried to make half a dozen times last > night). > > Repeat after me- > > "There is *NEVER* a situation, when the monitor fails to provide correct > information, due to a broken or absent edid implementation, and which at > the same time, sufficient information could be parsed from the .inf that > came on the CD with the monitor, to provide the user, a reasonable > experience requiring no user interaction beyond putting the cd in the > drive". (and at which time, the X driver could not have accomplished > the same thing automatically without the .inf) Absent EDID in the sink device never happens anymore. It's a requirement for Vista certification. I'm fairly sure it was required for XP cert. It's a requirement for shipping any DVI sink device. It is _mandatory_. We can fail to get EDID, either because the cable broke the DDC pins, or timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or it's a really old monitor, or there's a crap KVM switch in the middle, or phase of the moon, or whatever. I have not found ISOs for every OEM CD for every monitor that ever shipped. I doubt I ever could. Therefore the following claim is merely statistical. However, on no OEM CD that I've ever found does the included INF file - or any other resource intended to be parsed by the machine - provide the same set of information as the EDID block for the monitor. It may provide a subset. The only subset I've ever seen is sync ranges. I'm not saying I'm happy about that. I would love to see a counterexample. But it's all the empirical evidence I have. - ajax From che666 at gmail.com Tue Sep 4 15:21:21 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 4 Sep 2007 17:21:21 +0200 Subject: rawhide report: 20070904 changes In-Reply-To: <1188913137.24848.554.camel@mccallum.corsepiu.local> References: <200709040909.l84997hk001453@porkchop.devel.redhat.com> <1188909926.12253.6.camel@scrappy.miketc.com> <1188910547.24848.542.camel@mccallum.corsepiu.local> <46DD5B74.2080204@hhs.nl> <1188913137.24848.554.camel@mccallum.corsepiu.local> Message-ID: 2007/9/4, Ralf Corsepius : > On Tue, 2007-09-04 at 15:19 +0200, Hans de Goede wrote: > > Ralf Corsepius wrote: > > > On Tue, 2007-09-04 at 07:45 -0500, Mike Chambers wrote: > > >> On Tue, 2007-09-04 at 05:09 -0400, Build System wrote: > > >> > > >>> Broken deps for i386 > > >>> ---------------------------------------------------------- > > > > > >>> openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosg.so.1 > > >>> osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > > >>> osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > > >>> > > >> Heh, the two programs above are really getting annoying seeing them on > > >> the rawhide build email everyday. Any chance these are getting rebuilt > > >> or fixed soon? > > > > > > osgcal, osgal and openalpp are victims of the OpenSceneGraph-2 API > > > changes. > > > > > > I already had proposed an approach to keep these programs (Downgrade > > > OpenSceneGraph to OSG-1 and to add an OpenSceneGraph2 package), but > > > feedback so far had been more or less non-exitant > > > > > > > Thats not completely true, you did get feedback from several people including > > me, and I agree with Mike that these breakages are getting very annoying and > > should be fixed soon. > I am not in a position to fix them. ACLs, conventions > > > Let me repeat my solution of when you asked howto downgrade: > > 1) Make the main OpenSceneGraph package OpenSceneGraph 1.x again, using epoch > > to fix version issues. > Won't help any of the packages, because they would still BR the wrong > versions. i.e. these packages would not survive a rebuild without manual > intervention. > > > 2) Add a new OpenSceneGraph2 package > Non-applicable without epoch bump or rel-eng intervening. > > > 3) Make the devel's conflict each other if doing an other solution turns out to > > be a lot of work. > The devel packages would Conflict in any case, because the OSG-devel > packages can't be made installable in parallel without major effort. > > > Solved. > I didn't say it wasn't solvable. > > I was hoping for ways to avoid the epoch bump, or the maintainers of the > packages above would have the insight to acknowledge their packages to > be dead rsp. them to upgrade them to OSG2. > > To me, it doesn't make real sense to keep them. i have to agree with ralf here. if the librarys are dead upstream and if they are not brought up to par with the current release of openscenegraph they might just vanish. Carrying old obsolete versions around or downgrading to them is just turning the clock back to an old state and wont fix or achieve anything besides encouraging counterproductive behaviour like not updating the projects that require open scene graph. It was important osg got updated. regards, Rudolf Kastl > > Ralf > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lesmikesell at gmail.com Tue Sep 4 15:29:14 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 04 Sep 2007 10:29:14 -0500 Subject: ubuntu bulletproof x In-Reply-To: <1188916794.24181.3.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> Message-ID: <46DD79CA.1010807@gmail.com> Adam Jackson wrote: > On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote: >> Dominik 'Rathann' Mierzejewski wrote: >>> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: >>> [...] >>>> (and again, for the sake of argument, lets pretend that doing anything >>>> from a command line, or editing a text file, or researching obscure >>>> specs about your monitor, is not an option for the users in question) >>> I think that for majority of monitors out there, you can find the specs >>> in 5 minutes using Google. >> And then translate that into a modeline with another 3 days of googling. > > Why does anyone write a modeline by hand anymore? > > % man cvt Because on the machines I'm used to using: # man cvt No manual entry for cvt -- Les Mikesell lesmikesell at gmail.com From denis at poolshark.org Tue Sep 4 15:25:31 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 04 Sep 2007 17:25:31 +0200 Subject: ubuntu bulletproof x In-Reply-To: <1188918070.24181.25.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> <1188918070.24181.25.camel@localhost.localdomain> Message-ID: <46DD78EB.1020304@poolshark.org> Adam Jackson wrote: > On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote: >> Adam Jackson wrote: >>> Yeah, okay, force me to clarify. Grumble. >>> >>> There are cases where we can't tell what monitor the user has. They're >>> almost completely described by "either the card can't do DDC, or the >>> cable is broken". The former is a vanishingly small class of hardware, >>> voodoo1 basically. The latter happens depressingly often particularly >>> with projector setups. > >> So, to save you the trouble of rereading all of my posts. Can you >> explicitly confirm this (which it sounds like you did, but not in a way >> that clearly addressed the point I tried to make half a dozen times last >> night). >> >> Repeat after me- >> >> "There is *NEVER* a situation, when the monitor fails to provide correct >> information, due to a broken or absent edid implementation, and which at >> the same time, sufficient information could be parsed from the .inf that >> came on the CD with the monitor, to provide the user, a reasonable >> experience requiring no user interaction beyond putting the cd in the >> drive". (and at which time, the X driver could not have accomplished >> the same thing automatically without the .inf) > > Absent EDID in the sink device never happens anymore. It's a > requirement for Vista certification. I'm fairly sure it was required > for XP cert. It's a requirement for shipping any DVI sink device. It > is _mandatory_. > > We can fail to get EDID, either because the cable broke the DDC pins, or > timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or > it's a really old monitor, or there's a crap KVM switch in the middle, > or phase of the moon, or whatever. > > I have not found ISOs for every OEM CD for every monitor that ever > shipped. I doubt I ever could. Therefore the following claim is merely > statistical. However, on no OEM CD that I've ever found does the > included INF file - or any other resource intended to be parsed by the > machine - provide the same set of information as the EDID block for the > monitor. It may provide a subset. The only subset I've ever seen is > sync ranges. > > I'm not saying I'm happy about that. I would love to see a > counterexample. But it's all the empirical evidence I have. Just wanted to thank you for writing such informative emails. Everytime I read one of your emails I learn something about X, and that's awesome. -denis From kanarip at kanarip.com Tue Sep 4 15:41:44 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 04 Sep 2007 17:41:44 +0200 Subject: ubuntu bulletproof x In-Reply-To: <46DD79CA.1010807@gmail.com> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <46DD79CA.1010807@gmail.com> Message-ID: <46DD7CB8.4030603@kanarip.com> Les Mikesell wrote: > Adam Jackson wrote: >> On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote: >>> Dominik 'Rathann' Mierzejewski wrote: >>>> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote: >>>> [...] >>>>> (and again, for the sake of argument, lets pretend that doing >>>>> anything from a command line, or editing a text file, or >>>>> researching obscure specs about your monitor, is not an option for >>>>> the users in question) >>>> I think that for majority of monitors out there, you can find the specs >>>> in 5 minutes using Google. >>> And then translate that into a modeline with another 3 days of googling. >> >> Why does anyone write a modeline by hand anymore? >> >> % man cvt > > Because on the machines I'm used to using: > > # man cvt > No manual entry for cvt > [root at elwood ~]# rpm -qf /usr/share/man/man1/cvt.1.gz xorg-x11-server-Xorg-1.3.0.0-22.fc8 -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From myfedora at richip.dhs.org Tue Sep 4 16:08:59 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 10:08:59 -0600 Subject: ubuntu bulletproof x In-Reply-To: <1188916794.24181.3.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> Message-ID: <1188922139.12969.10.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 10:39 -0400, Adam Jackson wrote: > Why does anyone write a modeline by hand anymore? > > % man cvt Thanks for the tip. Is there any way to fine-tune the results? On my Sony projector TV (with HDMI input), the automatically generated modeline (from EDID information, I might add) results in the graphics screen going out-of-bounds of the physical display. One of the nice things I've learned about X Windows is that the standard resolutions (1280x1024, 800x600, 1680x1050, etc.) aren't fixed (depending on the display device). That one can come up with arbitrary resolutions so long as the display supports it. There was a time when I would find the maximum resolution that my video card and display screen could use while maintaining a refresh rate of 75Hz. It was all done by hand and my bumbling about with numbers. Are those days gone? Or will that capability be somehow revived through a GUI program that will take care of the mathematical part of computing modelines (which used to be done by hand)? It really is too bad that the Modes can't be changed on the fly (without needing an X restart). -- Richi Plana From ajackson at redhat.com Tue Sep 4 16:16:46 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 12:16:46 -0400 Subject: ubuntu bulletproof x In-Reply-To: <1188922139.12969.10.camel@localhost6.localdomain6> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> Message-ID: <1188922606.24181.38.camel@localhost.localdomain> On Tue, 2007-09-04 at 10:08 -0600, Richi Plana wrote: > On Tue, 2007-09-04 at 10:39 -0400, Adam Jackson wrote: > > Why does anyone write a modeline by hand anymore? > > > > % man cvt > > Thanks for the tip. Is there any way to fine-tune the results? On my > Sony projector TV (with HDMI input), the automatically generated > modeline (from EDID information, I might add) results in the graphics > screen going out-of-bounds of the physical display. xvidtune should still work. Sadly it's probably the nicest UI for that atm. I'm also working on implementing DDC/CI, so you should be able to control many monitor adjustment parameters from the host side. > One of the nice things I've learned about X Windows is that the standard > resolutions (1280x1024, 800x600, 1680x1050, etc.) aren't fixed > (depending on the display device). That one can come up with arbitrary > resolutions so long as the display supports it. There was a time when I > would find the maximum resolution that my video card and display screen > could use while maintaining a refresh rate of 75Hz. It was all done by > hand and my bumbling about with numbers. Are those days gone? Or will > that capability be somehow revived through a GUI program that will take > care of the mathematical part of computing modelines (which used to be > done by hand)? That's sometimes true and sometimes not. For CRTs it's certainly still true. LCDs almost always have a native refresh rate, and they either have a built-in scaler or they don't. If they do, then you can feed them different refresh rates, and they'll resample the input to their native output frequency, but it doesn't win you anything to do so since the screen is going to pump out 60Hz whether you want it to or not. If the panel doesn't have a built-in scaler (which no dual-link monitor I've seen has, and many laptop panels don't), then you pretty much have to give it exactly the right refresh rate and an integer factor of the native pixel size. To compensate for that, many graphics chips have a scaler right at the output. NVIDIA cards, for example, are pretty much always driving the panel at the native size, and using the built-in scaler to change modes. This was actually a deficiency in EDID version 1.3; the "ranges" section was more or less required even though the monitor might not meaningfully _have_ sync ranges. EDID 1.4 (which I almost have implemented parser support for now) makes the ranges section optional, and defines how the host software is supposed to interpret EDID blocks without ranges. > It really is too bad that the Modes can't be changed on the fly (without > needing an X restart). In RANDR 1.2 they can. Ideally someone will write a usable frontend to it - so you can do mode injection and fallback recovery with a nice pretty UI - and we'll get all the drivers ported over to the RANDR 1.2 API. That will be winning. - ajax From a.badger at gmail.com Tue Sep 4 16:22:18 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 04 Sep 2007 09:22:18 -0700 Subject: Python 3.0 In-Reply-To: <1188910098.1394.28.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <46DC51EB.70207@fedoraunity.org> <1188910098.1394.28.camel@vorpal.macdev.com> Message-ID: <46DD863A.8040606@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David G. Mackay wrote: > On Mon, 2007-09-03 at 12:26 -0600, Jonathan Steffan wrote: > >> == compat-python24 == >> >> Maybe today I will finish my upgrade testing and will push the compat- >> packages into livna. The compat-python packages have passed review and I >> just need to upload the new compat packages for zope (2.10.4) and plone >> (3.0). I'm guessing this means I am going to end up being the >> compat-python maintainer [in livna]. I was more or less avoiding this >> because I'm not sure I will know what to do when things break and would >> inheritly be passing the buck, so to speak. I would have to ask for > > Unless it somehow interferes with the standard python package, be it > 2.5, 2.6, or whatever, I don't expect much. I'd love to get a recap of > that in about six months or so. Out of the twelve bugs for python in > FC6, eight were dups, not a bug, or rawhide. The four actual bugs that > are still open were probably kicked upstream, and remain open eight or > nine months later. > "This is the last planned release in the Python 2.4 series - future maintenance releases of Python will be in the 2.5 series, starting of course with 2.5.1." http://www.python.org/download/releases/2.4.4/ "If you really want to maintain a retired package, then the process is much the same as claiming an orphaned package. However, you need to be aware that fixing release critical bugs etc becomes your responsibility. This is to ensure the high quality and standards of packaging remain for Fedora package collection." http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages So things like those four bugs kicked upstream become the responsibility of our compat-python2.4 maintainer. Similarly, if any of the fixed rawhide bugs needed to be fixed for python2.4 as well, they would be the responsibility of our compat-python2.4 maintainer. So being the compat-python2.4 maintainer is a non-trivial job. It might even be easier to be the zope/plone maintainer and drive the port to python2.5 :-) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3YY6X6yAic2E7kgRAmnwAJ92fMqmfwU4zlIvYi2ofMILshdnuACgqTVj s2G0OO/0W0GOMX8m27HtIbo= =wdTB -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Sep 4 16:23:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 12:23:49 -0400 Subject: Python 3.0 In-Reply-To: <1188916783.1916.7.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> Message-ID: <20070904122349.41e55090@ender> On Tue, 04 Sep 2007 09:39:42 -0500 "David G. Mackay" wrote: > Why does this remind me of Pangloss in Candide? I have no idea what that means. > And, I have been > rather forcefully told on this list that Fedora stands alone. Perhaps it's a matter of context. It's no mystery that RHEL is a derivative of Fedora, and that CentOS is a free rebuild of RHEL. To think that they have nothing to do with the Fedora universe is just plain silly. To think that they aren't valid alternatives when looking for say a long term supported Fedora, or a build of Fedora with more thought to backward compatibility is just ignorant (not in a mean way, just in a "the person doesn't possess the information" kind of way). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From halfline at gmail.com Tue Sep 4 16:31:13 2007 From: halfline at gmail.com (Ray Strode) Date: Tue, 4 Sep 2007 12:31:13 -0400 Subject: ubuntu bulletproof x In-Reply-To: <1188922139.12969.10.camel@localhost6.localdomain6> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> Message-ID: <45abe7d80709040931x38bcbaaeree79ffba8336c4b3@mail.gmail.com> Hi, > > % man cvt > > Thanks for the tip. Is there any way to fine-tune the results? On my > Sony projector TV (with HDMI input), the automatically generated > modeline (from EDID information, I might add) results in the graphics > screen going out-of-bounds of the physical display. xorg-x11-server-utils has an old program called xvidtune, that provides a UI for doing little adjustments. When you're all done, ther'e's "Show" button that prints out the modeline to terminal. --Ray From jkeating at redhat.com Tue Sep 4 16:26:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 12:26:12 -0400 Subject: rawhide missing /bin/hostname In-Reply-To: <20070904144429.GA13238@dudweiler.stuttgart.redhat.com> References: <13dbfe4f0709030643w7ca4ea85r6a2c67ea98244a42@mail.gmail.com> <20070903085222.2faa99a6@vader.jdub.homelinux.org> <1188828058.4628.2.camel@localhost.localdomain> <20070904143035.GB15029@nostromo.devel.redhat.com> <20070904143612.GA12968@dudweiler.stuttgart.redhat.com> <1188916800.14826.14.camel@cutter> <20070904144429.GA13238@dudweiler.stuttgart.redhat.com> Message-ID: <20070904122612.1886c0cb@ender> On Tue, 4 Sep 2007 16:44:29 +0200 Florian La Roche wrote: > Hello Seth, > > for koji/mock into the minimal set of installed packages. > Could be either a hardcoded list in mock per release or > into the comps file, should both work fine. You're talking about two different things. The @base and @core groups are not used at all by koji / mock when populating a buildroot. Koji uses internal configuration to do this, mock uses an rpm that has a series of Requires. I'm moving more things to make use of a 'buildsys-build' group in comps, but it may take a while. As to why util-linux-ng isn't in the minimal buildroot, I have posted a proposal to adjust the buildroot a bit and I've been gathering feedback. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Tue Sep 4 16:36:43 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 04 Sep 2007 11:36:43 -0500 Subject: ubuntu bulletproof x In-Reply-To: <1188917291.24181.12.camel@localhost.localdomain> References: <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <604aa7910709021630r239c4139pf32133a75b86ce9d@mail.gmail.com> <46DB4C77.6060108@gmail.com> <604aa7910709021746t27bf7446g878be522d7e7960a@mail.gmail.com> <46DB64AE.6000001@gmail.com> <1188917291.24181.12.camel@localhost.localdomain> Message-ID: <46DD899B.9070307@gmail.com> Adam Jackson wrote: > Windows does almost exactly what we do. It uses the EDID information if > it can be found, otherwise it constructs a list of candidate modes based > on sync ranges. Some of them will be out of range for the monitor; it > happens to have better UI for reverting to the older settings. Were there ever versions of the X configurator that made changes on the fly and reverted if you didn't confirm that it worked or am I confusing this with some other old box? -- Les Mikesell lesmikesell at gmail.com From galibert at pobox.com Tue Sep 4 16:33:53 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 4 Sep 2007 18:33:53 +0200 Subject: ubuntu bulletproof x In-Reply-To: <1188922139.12969.10.camel@localhost6.localdomain6> References: <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> Message-ID: <20070904163353.GA68411@dspnet.fr.eu.org> On Tue, Sep 04, 2007 at 10:08:59AM -0600, Richi Plana wrote: > It really is too bad that the Modes can't be changed on the fly (without > needing an X restart). They can, kindasorta, with XFree86-VidModeExtension. xvidtune uses it. IIRC one value is not tunable easily, the pixel clock maybe. And the driver can refuse. OG. From skvidal at fedoraproject.org Tue Sep 4 16:32:58 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 04 Sep 2007 12:32:58 -0400 Subject: Python 3.0 In-Reply-To: <20070904122349.41e55090@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> Message-ID: <1188923578.14826.33.camel@cutter> On Tue, 2007-09-04 at 12:23 -0400, Jesse Keating wrote: > On Tue, 04 Sep 2007 09:39:42 -0500 > "David G. Mackay" wrote: > > > Why does this remind me of Pangloss in Candide? > > I have no idea what that means. Dr. Pangloss from Voltaire's Candide. His best known phrase is: "All is for the best in the best of all possible worlds" He was the quintessential optimist to a fault. Even while being arrested, tortured, natural-disaster-struck, etc. He would constantly say that all is for the best. Candide could comfortably be considered an early example of satire and a classic of western literature. http://en.wikipedia.org/wiki/Candide -sv From jspaleta at gmail.com Tue Sep 4 16:31:58 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 08:31:58 -0800 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188833600.32365.13.camel@Diffingo.localdomain> <46DC46AD.2080702@hhs.nl> <1188845719.4826.3.camel@Diffingo.localdomain> <20070904082139.2a2d40d6@ender> Message-ID: <604aa7910709040931q3b63407dl7e525856a793cc57@mail.gmail.com> On 9/4/07, Colin Walters wrote: > *shakes pom-poms* I would have thought that this was about boot times that you'd be shak'n your... boot-y. -jef"what does it say about me when the part of the 3 day weekend that I liked most was getting a solid block of time in on my in-house python data viewer."spaleta From galibert at pobox.com Tue Sep 4 16:35:57 2007 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 4 Sep 2007 18:35:57 +0200 Subject: ubuntu bulletproof x In-Reply-To: <1188922606.24181.38.camel@localhost.localdomain> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> <1188922606.24181.38.camel@localhost.localdomain> Message-ID: <20070904163556.GB68411@dspnet.fr.eu.org> On Tue, Sep 04, 2007 at 12:16:46PM -0400, Adam Jackson wrote: > Ideally someone will write a usable frontend to it - so you can do mode > injection and fallback recovery with a nice pretty UI - and we'll get > all the drivers ported over to the RANDR 1.2 API. That will be winning. Is there something remotely looking like documentation somewhere? OG. From ajackson at redhat.com Tue Sep 4 16:38:54 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 12:38:54 -0400 Subject: ubuntu bulletproof x In-Reply-To: <20070904163556.GB68411@dspnet.fr.eu.org> References: <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> <1188922606.24181.38.camel@localhost.localdomain> <20070904163556.GB68411@dspnet.fr.eu.org> Message-ID: <1188923934.24181.52.camel@localhost.localdomain> On Tue, 2007-09-04 at 18:35 +0200, Olivier Galibert wrote: > On Tue, Sep 04, 2007 at 12:16:46PM -0400, Adam Jackson wrote: > > Ideally someone will write a usable frontend to it - so you can do mode > > injection and fallback recovery with a nice pretty UI - and we'll get > > all the drivers ported over to the RANDR 1.2 API. That will be winning. > > Is there something remotely looking like documentation somewhere? Not really, sadly. The new xrandr utility is pretty readable if you're trying to do client-side bits. The driver side of the API is "look at the intel or nv drivers and steal code". - ajax From myfedora at richip.dhs.org Tue Sep 4 16:44:21 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 10:44:21 -0600 Subject: ubuntu bulletproof x In-Reply-To: <1188922606.24181.38.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> <1188922606.24181.38.camel@localhost.localdomain> Message-ID: <1188924261.12969.42.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 12:16 -0400, Adam Jackson wrote: > > It really is too bad that the Modes can't be changed on the fly > (without > > needing an X restart). > > In RANDR 1.2 they can. > > Ideally someone will write a usable frontend to it - so you can do mode > injection and fallback recovery with a nice pretty UI - and we'll get > all the drivers ported over to the RANDR 1.2 API. That will be winning. OMG. Does that mean being able to change any parameter in a given modeline? Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync ^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^ ^^^^^^ -> Any of these will be changeable on the fly? That would be winning. -- Richi Plana From fedora at leemhuis.info Tue Sep 4 16:51:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 04 Sep 2007 18:51:00 +0200 Subject: FESCo Meeting Summary for 2007-08-30 In-Reply-To: <1188510386.2808.6.camel@kennedy> References: <1188510386.2808.6.camel@kennedy> Message-ID: <46DD8CF4.10606@leemhuis.info> On 30.08.2007 23:46, Brian Pepple wrote: > === EPEL === > * FESCo approved a mandate for the continuation of EPEL, and will > let the EPEL folks decide on governance. "Mandate for the continuation of EPEL" -> I didn't know EPEL itself was questioned or time limited. The EPEL Steering committee mandate was time limited and we asked to extend it, so I assume that's what you meant? Further: so it was extended. Thanks. But was it extended for a unlimited time? Or just by one day, week, month, half a year, a whole year? Sorry to be pedantic, but I just want to update http://fedoraproject.org/wiki/EPEL/SteeringCommittee properly. CU knurd From myfedora at richip.dhs.org Tue Sep 4 16:38:02 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 10:38:02 -0600 Subject: Goal: Increased Modularity? Message-ID: <1188923882.12969.36.camel@localhost6.localdomain6> Hi, I've been reading past posts and am starting to understand the goals of the Fedora project much better. If I'm not mistaken, the primary goal isn't to target a specific set of users (ie. desktop vs. server) or platform (x86_64 vs. ppc, notebook vs. desktop), but to come up with a distro that's easy to re-spin for people who DO want to customize Fedora for a particular purpose. If that's the case, would I be correct in assuming that Fedora would prioritize increasing the modularity of its packages? That Fedora is making it easier to add or remove while minimizing the affect it would have on other packages? For instance, if I desired to come up with a spin that doesn't have Sendmail, why must I give up fetchmail, mutt or tor? Why is it that so many packages can't stand alone without libvorbis? I know that some of the packages NEED libvorbis, but for many, shouldn't it be optional and something that isn't required to be compiled against (think dlopen(3) instead of ld(1)) like gstreamer-plugins-* (which all seem to require libvorbis)? I guess I'm just stating a principle which should be a guiding one if Fedora wants to come up with a system that's really flexible for people who want to come up with their own spins. So currently, is it (a guiding principle to make packages modular and depend less on others)? Note that I'm not asking if this is to be a target, just if it's written somewhere as something to keep in mind when packaging things. I understand that Fedora is dealing with a huge system that's been around for ages. Some people's complaints about Fedora being too bulky isn't even Fedora's fault. They've just been dealing with a relic that it has to modernize. Towards that goal, Fedora has done a lot and continues to improve on it (next-gen init, boot-up process, etc.). -- Richi Plana From jkeating at redhat.com Tue Sep 4 16:43:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 12:43:55 -0400 Subject: Fedora 8 Test 2 slipping Message-ID: <20070904124355.59b604cd@ender> Due to issues with fast moving parts around installation and composition of the distribution (yum, anaconda, pykickstart, pungi, mash) we haven't had an installable tree for a little while, and not nearly enough time to shake out any other bugs that may be present due to Feature Freeze and lots of fresh content landing. As such we will be extending the freeze for a week to complete our unit testing and to prepare the release. New release date is 25 September 2007. No decisions have been made at this time about slipping any further part of the schedule. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From notting at redhat.com Tue Sep 4 16:57:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Sep 2007 12:57:03 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <1188923882.12969.36.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> Message-ID: <20070904165703.GB30334@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > For instance, if I desired to come up with a spin that doesn't have > Sendmail, why must I give up fetchmail, mutt or tor? Because they *require* a MTA to deliver/send the mail, at least in their default configurations > Why is it that so > many packages can't stand alone without libvorbis? I know that some of > the packages NEED libvorbis, but for many, shouldn't it be optional and > something that isn't required to be compiled against (think dlopen(3) > instead of ld(1)) like gstreamer-plugins-* (which all seem to require > libvorbis)? dlopen will cause you to break at runtime instead of buildtime if ABI changes - that's not good. Bill From bpepple at fedoraproject.org Tue Sep 4 17:07:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 04 Sep 2007 13:07:21 -0400 Subject: FESCo Meeting Summary for 2007-08-30 In-Reply-To: <46DD8CF4.10606@leemhuis.info> References: <1188510386.2808.6.camel@kennedy> <46DD8CF4.10606@leemhuis.info> Message-ID: <1188925641.7061.2.camel@kennedy> On Tue, 2007-09-04 at 18:51 +0200, Thorsten Leemhuis wrote: > On 30.08.2007 23:46, Brian Pepple wrote: > > > === EPEL === > > * FESCo approved a mandate for the continuation of EPEL, and will > > let the EPEL folks decide on governance. > > "Mandate for the continuation of EPEL" -> I didn't know EPEL itself was > questioned or time limited. The EPEL Steering committee mandate was time > limited and we asked to extend it, so I assume that's what you meant? Correct. > Further: so it was extended. Thanks. But was it extended for a unlimited > time? Or just by one day, week, month, half a year, a whole year? My intention was for an unlimited time. Does anyone else from FESCo disagree with that? Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Tue Sep 4 17:00:26 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 04 Sep 2007 13:00:26 -0400 Subject: ubuntu bulletproof x In-Reply-To: <1188924261.12969.42.camel@localhost6.localdomain6> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> <1188922606.24181.38.camel@localhost.localdomain> <1188924261.12969.42.camel@localhost6.localdomain6> Message-ID: <1188925226.24181.54.camel@localhost.localdomain> On Tue, 2007-09-04 at 10:44 -0600, Richi Plana wrote: > On Tue, 2007-09-04 at 12:16 -0400, Adam Jackson wrote: > > > It really is too bad that the Modes can't be changed on the fly > > (without > > > needing an X restart). > > > > In RANDR 1.2 they can. > > > > Ideally someone will write a usable frontend to it - so you can do mode > > injection and fallback recovery with a nice pretty UI - and we'll get > > all the drivers ported over to the RANDR 1.2 API. That will be winning. > > OMG. Does that mean being able to change any parameter in a given > modeline? > > Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync > ^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^ ^^^^^^ -> Any of these will be changeable on the fly? >From 'xrandr -h': --newmode [+HSync] [-HSync] [+VSync] [-VSync] - ajax From jwboyer at jdub.homelinux.org Tue Sep 4 17:14:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 4 Sep 2007 12:14:12 -0500 Subject: FESCo Meeting Summary for 2007-08-30 In-Reply-To: <1188925641.7061.2.camel@kennedy> References: <1188510386.2808.6.camel@kennedy> <46DD8CF4.10606@leemhuis.info> <1188925641.7061.2.camel@kennedy> Message-ID: <20070904121412.3a05729c@weaponx.rchland.ibm.com> On Tue, 04 Sep 2007 13:07:21 -0400 Brian Pepple wrote: > On Tue, 2007-09-04 at 18:51 +0200, Thorsten Leemhuis wrote: > > On 30.08.2007 23:46, Brian Pepple wrote: > > > > > === EPEL === > > > * FESCo approved a mandate for the continuation of EPEL, and will > > > let the EPEL folks decide on governance. > > > > "Mandate for the continuation of EPEL" -> I didn't know EPEL itself was > > questioned or time limited. The EPEL Steering committee mandate was time > > limited and we asked to extend it, so I assume that's what you meant? > > Correct. > > > Further: so it was extended. Thanks. But was it extended for a unlimited > > time? Or just by one day, week, month, half a year, a whole year? > > My intention was for an unlimited time. Does anyone else from FESCo > disagree with that? I recall the consensus of the meeting being that EPEL is doing great as-is, so unlimited seems fine with me. josh From Christian.Iseli at licr.org Tue Sep 4 17:24:11 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 4 Sep 2007 19:24:11 +0200 Subject: FESCo Meeting Summary for 2007-08-30 In-Reply-To: <1188925641.7061.2.camel@kennedy> References: <1188510386.2808.6.camel@kennedy> <46DD8CF4.10606@leemhuis.info> <1188925641.7061.2.camel@kennedy> Message-ID: <20070904192411.1aa3549d@ludwig-alpha.unil.ch> On Tue, 04 Sep 2007 13:07:21 -0400, Brian Pepple wrote: > My intention was for an unlimited time. Agreed. Christian From myfedora at richip.dhs.org Tue Sep 4 17:02:21 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 11:02:21 -0600 Subject: rawhide report: 20070830 changes In-Reply-To: <1188916717.24181.1.camel@localhost.localdomain> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> <1188676645.1175.722.camel@localhost.localdomain> <46D9CB06.30303@fedoraproject.org> <1188916717.24181.1.camel@localhost.localdomain> Message-ID: <1188925341.12969.47.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 10:38 -0400, Adam Jackson wrote: > On Sun, 2007-09-02 at 01:56 +0530, Rahul Sundaram wrote: > > Adam Jackson wrote: > > > On Sat, 2007-09-01 at 01:31 +0530, Rahul Sundaram wrote: > > >> Build System wrote: > > >>> New package java-1.7.0-icedtea > > >>> IcedTea Runtime Environment > > >> Good to see this. Is there any chance we can provide this for Fedora 7? > > > > > > That seems like a lot of work for little gain. I would much prefer the > > > IcedTea developers spend their time on making it really great for F8, > > > instead of making it mediocre for both F8 and F7 > > > > There are already Fedora 7 SRPMS available. Why would putting it in the > > repository make it mediocre for Fedora 8? > > Duplication of effort, polynomial case explosion, blah blah. Fixing F7 > takes time away from improving F8. > > I really shouldn't have to explain this. In other words there's the oft-forgotten responsibility that when packages are added, they're to be maintained, as well. What about jpackage.org? I've often relied on them for Java packages anyway since they're purists over there (which means, for now, more reliable). Have they given word on how they're going to handle icedtea and if there's to be packages for F7? -- Richi Plana From jkeating at redhat.com Tue Sep 4 17:17:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 13:17:47 -0400 Subject: Fedora 8 Test 2 slipping In-Reply-To: <20070904124355.59b604cd@ender> References: <20070904124355.59b604cd@ender> Message-ID: <20070904131747.74ca576f@ender> On Tue, 4 Sep 2007 12:43:55 -0400 Jesse Keating wrote: > New release date is 25 September 2007. *cough* Make that 13 September 2007. I accidentally read the Translation Freeze date. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From myfedora at richip.dhs.org Tue Sep 4 17:22:28 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 11:22:28 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <20070904165703.GB30334@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> Message-ID: <1188926548.12969.64.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 12:57 -0400, Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: > > For instance, if I desired to come up with a spin that doesn't have > > Sendmail, why must I give up fetchmail, mutt or tor? > > Because they *require* a MTA to deliver/send the mail, at least in their > default configurations Well, I figured that they are required because of their default configurations. But would Fedora be interested in changing it if modularity were indeed the higher goal? Besides, you said it requires an MTA. Would an effort to add the ability to detect the availability of /sbin/sendmail in the above-mentioned packages and use it if available or speak SMTP over port 25 if not be desirable? Packages like evolution and thunderbird do that and therefore don't "Require: sendmail". > > Why is it that so > > many packages can't stand alone without libvorbis? I know that some of > > the packages NEED libvorbis, but for many, shouldn't it be optional and > > something that isn't required to be compiled against (think dlopen(3) > > instead of ld(1)) like gstreamer-plugins-* (which all seem to require > > libvorbis)? > > dlopen will cause you to break at runtime instead of buildtime if > ABI changes - that's not good. Isn't that what escalating the version number to a higher layer (ie. RPM and yum) is all about? Currently, a break in ABI would result in an executable loader error. It would just be a conscious effort to move catching it from there to package management. If dlsym(3) were more verbose, it might even expose changes API/ABI changes. At any rate, other packages do it. Some multimedia apps do. Apache httpd does it. For apache, module (or plugin or whatever they call it) packages can be added or removed without affecting the system much. It's a huge effort, I know, but all I'm asking is if it's not in the guiding principles list that Fedora has. It would certainly make packagers and spinners very happy. -- Richi Plana From myfedora at richip.dhs.org Tue Sep 4 17:33:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 11:33:19 -0600 Subject: ubuntu bulletproof x In-Reply-To: <1188925226.24181.54.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <46DB1467.1060905@filteredperception.org> <20070902214136.GA4438@ryvius.pekin.waw.pl> <46DB3D8D.9060309@gmail.com> <1188916794.24181.3.camel@localhost.localdomain> <1188922139.12969.10.camel@localhost6.localdomain6> <1188922606.24181.38.camel@localhost.localdomain> <1188924261.12969.42.camel@localhost6.localdomain6> <1188925226.24181.54.camel@localhost.localdomain> Message-ID: <1188927199.12969.69.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 13:00 -0400, Adam Jackson wrote: > >From 'xrandr -h': > > --newmode > > > [+HSync] [-HSync] [+VSync] [-VSync] Sorry ... am on F7 and it wasn't appearing in xrandr in xorg-x11-server-utils-7.2-1.fc7.x86_64 .. That is tres cool. Now to figure out what those values mean again. If someone could write a GUI with the parameters in English (with translations, of course) with sliders while updating in real/run-time, we'd be golden. It'd be a step further than even Ubuntu's Bulletproof-X ;) (assuming they don't end up destroying their hardware) -- Richi Plana From nicolas.mailhot at laposte.net Tue Sep 4 17:54:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Sep 2007 19:54:18 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <20070904165703.GB30334@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> Message-ID: <1188928458.4344.1.camel@rousalka.dyndns.org> Le mardi 04 septembre 2007 ? 12:57 -0400, Bill Nottingham a ?crit : > Richi Plana (myfedora at richip.dhs.org) said: > > For instance, if I desired to come up with a spin that doesn't have > > Sendmail, why must I give up fetchmail, mutt or tor? > > Because they *require* a MTA to deliver/send the mail, at least in their > default configurations And BTW there's no need for this MTA to be sendmail [nim at rousalka ~]$ rpm -q fetchmail fetchmail-6.3.8-2.fc8.x86_64 [nim at rousalka ~]$ rpm -q sendmail package sendmail is not installed -- 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 notting at redhat.com Tue Sep 4 17:55:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Sep 2007 13:55:18 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <1188926548.12969.64.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> Message-ID: <20070904175518.GA1378@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > On Tue, 2007-09-04 at 12:57 -0400, Bill Nottingham wrote: > > Richi Plana (myfedora at richip.dhs.org) said: > > > For instance, if I desired to come up with a spin that doesn't have > > > Sendmail, why must I give up fetchmail, mutt or tor? > > > > Because they *require* a MTA to deliver/send the mail, at least in their > > default configurations > > Well, I figured that they are required because of their default > configurations. But would Fedora be interested in changing it if > modularity were indeed the higher goal? > > Besides, you said it requires an MTA. Would an effort to add the ability > to detect the availability of /sbin/sendmail in the above-mentioned > packages and use it if available or speak SMTP over port 25 if not be > desirable? Packages like evolution and thunderbird do that and therefore > don't "Require: sendmail". It's somehow better to have each package require its own separate configuration than to use a central package that only takes 2MB? I'm not saying you can't do it, but: - every mutt user would have to set up their own muttrc with smtp server information - every fetchmail user would have to change their invocation - and so on, for each package as needed > > dlopen will cause you to break at runtime instead of buildtime if > > ABI changes - that's not good. > > Isn't that what escalating the version number to a higher layer (ie. RPM > and yum) is all about? Sure, but then you're still breaking at runtime instead of build/install time. Bill From jspaleta at gmail.com Tue Sep 4 17:57:46 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 09:57:46 -0800 Subject: Goal: Increased Modularity? In-Reply-To: <1188923882.12969.36.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> Message-ID: <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> On 9/4/07, Richi Plana wrote: > gstreamer-plugins-* Can you give me a plausibly rational usage case where it is in the best interest of the targeted usage group of any gstreamer based application to not have ogg vorbis playback capability rolled into the set of plugins? I can't. Taking things to the extreme of ultimate modularity is a fallacy. Making components modular has tradeoffs in terms of usability and the discussion to increase modularity needs to have a usage case point of view in mind. -jef From nicolas.mailhot at laposte.net Tue Sep 4 18:00:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Sep 2007 20:00:47 +0200 Subject: rawhide report: 20070830 changes In-Reply-To: <1188925341.12969.47.camel@localhost6.localdomain6> References: <200708301247.l7UClIkB020612@porkchop.devel.redhat.com> <46D87388.9030100@fedoraproject.org> <1188676645.1175.722.camel@localhost.localdomain> <46D9CB06.30303@fedoraproject.org> <1188916717.24181.1.camel@localhost.localdomain> <1188925341.12969.47.camel@localhost6.localdomain6> Message-ID: <1188928847.4344.8.camel@rousalka.dyndns.org> Le mardi 04 septembre 2007 ? 11:02 -0600, Richi Plana a ?crit : > What about jpackage.org? I've often relied on them for Java packages > anyway since they're purists over there (which means, for now, more > reliable). Have they given word on how they're going to handle icedtea > and if there's to be packages for F7? jpackage should certainly ship icedtea in theory. That it will is another thing altogether - due to the immense majority of the jpp packages being noarch, I don't think the project ever evolved an efficient arch-specific rpm workflow. That being said, JPP is a community project too, so what it does is primarily determined by the contributions of its members. Anyone with sufficient time and energy can change the jpp roadmap through contributions. -- 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 jspaleta at gmail.com Tue Sep 4 18:04:47 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 10:04:47 -0800 Subject: Goal: Increased Modularity? In-Reply-To: <1188928458.4344.1.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188928458.4344.1.camel@rousalka.dyndns.org> Message-ID: <604aa7910709041104p25c1a7eese7965718e58b141f@mail.gmail.com> On 9/4/07, Nicolas Mailhot wrote: > And BTW there's no need for this MTA to be sendmail to be a little more explicit repoquery --whatprovides smtpdaemon sendmail postfix exim ssmtp all of those packages provide the necessary virtual provides that fetchmail is asking to be filled. So in reality.. this particular example is a non-problem. Any re-spinner has the option of using any package that provides smtpdaemon... modularity via the virtual provides. repoquery tells me that the only things that explicitly need sendmail are milter related. -jef From ndbecker2 at gmail.com Tue Sep 4 18:10:55 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 04 Sep 2007 14:10:55 -0400 Subject: iced-tea backport to f7? Message-ID: Would be nice to try this on f7. From ianburrell at gmail.com Tue Sep 4 18:45:44 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 4 Sep 2007 11:45:44 -0700 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070901152942.GA16761@wolff.to> References: <1187628864.3382.27.camel@localhost.localdomain> <56594.65.192.24.164.1187629663.squirrel@mail.jcomserv.net> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> Message-ID: On 9/1/07, Bruno Wolff III wrote: > On Sat, Sep 01, 2007 at 14:07:17 +0200, > Benny Amorsen wrote: > > > > Administrators sometimes want to limit which traffic can reach > > applications, and perhaps limit the risk when accidentally starting > > applications. Automating firewall setup makes that useless. > > That is probably the main reason. And having apps undo restrictions seems > like a really really bad idea. > > Plus I have no confidence that apps can properly rewrite iptables rules > correctly. iptables setups can have complications which will make it > hard to change them. I have used subroutines for checking reserved ip > ranges and have had services configured to only be available to local > ip addresses or specific interfaces. > > I think the idea of having some way to help people who want a service > available to the internet at large or some local ip addresses is a good > idea, but it needs to be an add on step that can be skipped, not some > invisible change behind the scenes. > I wonder if the solution is to display the linkage between services and firewall rules in the configuration tools. People would make the changes in the tools but they would know what is needed. For system-config-securitylevel, one possibility is to highlight the services that are enabled but haven't been opened. Another help would have system-config-services print out a warning if the user enables a service but the firewall rule is not opened. system-config-services could probably show a dialog box that opens the firewall rule. This would probably only work if system-config-securitylevel is managing the firewall. - Ian From fedora at leemhuis.info Tue Sep 4 16:38:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 04 Sep 2007 18:38:32 +0200 Subject: EPEL SIG Meetings now alternating between 17:00 and 23:00 UTC on Wednesdays Message-ID: <46DD8A08.3030905@leemhuis.info> Hi all! Just FYI, in the EPEL SIG meeting last week it was decided to have alternating meeting times for our weekly meetings on Wednesdays. In weeks with an even number (like this one, as it's the 36th week currently; the gnome panel date applet will tell you the current week number) we'll have the meetings at 23:00 UTC. In the weeks with and odd number we'll continue to have them at 17:00 UTC. Time are daylight saving times. During the winters we'll adjust them by one hour, to make sure the effective meeting time stays the same. So join us in the next meeting, which is scheduled for tomorrow at 23:00**UTC in #fedora-meeting. CU knurd P.S.: Note that this new meeting scheme doesn't revert the plan to try to get more stuff done on the list and less in the meetings. That still the plan, but we need to experiment a bit how to actually have a good workflow on the list (and quick meetings that still will be needed). From myfedora at richip.dhs.org Tue Sep 4 19:08:12 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 13:08:12 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> Message-ID: <1188932892.12969.107.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 09:57 -0800, Jeff Spaleta wrote: > On 9/4/07, Richi Plana wrote: > > gstreamer-plugins-* > Can you give me a plausibly rational usage case where it is in the > best interest of the targeted usage group of any gstreamer based > application to not have ogg vorbis playback capability rolled into the > set of plugins? I can't. The choice of libvorbis really was just to illustrate how something that's optional in the usage sense isn't optional in the packaging sense. I certainly can't come up with a use case where it won't be in the best interest of the targeted userbase to have. Truth be told, the gstreamer plugins system is exactly about modularity. It's the packaging of the plugins into -good, -bad, -ugly that breaks the modularity in the packaging sense. If I was a "modularity" zealot, I'd argue for having gstreamer-plugins-ogg-vorbis packages, etc., but I'm not. Read below. > Taking things to the extreme of ultimate modularity is a fallacy. > Making components modular has tradeoffs in terms of usability and the > discussion to increase modularity needs to have a usage case point of > view in mind. _I_ don't believe in ultimate or absolute anything. That's not what I was looking for. In fact, I would even go so far as to say that there should only be modularization when there's an existing need or even a predicted, likely need. The whole point to my bringing up the topic of keeping an eye on modularization was to solve a couple of problems that some people have. First, a couple of users are clamoring for lighter distributions. Services which aren't needed shouldn't be installed. Some people asked why certain services like sendmail needed to be installed. Somebody replied by saying a respin could be done, so I just checked if it was indeed possible by doing a "yum remove sendmail" and that's when I discovered that mutt and tor needed them when they should be optional. Of course, as it turns out, it's not sendmail that they require specifically but smtpdaemon. So I was in error with that example as the system DOES show a good deal of modularity via the virtual provides. So my two examples stink, :). I guess my point is that if the answer to a lot of people's requests is that "they can spin things themselves", I just thought it would be an important consideration for Fedora to give the respinners that flexibility THROUGH modularization. -- Richi Plana From pemboa at gmail.com Tue Sep 4 19:24:15 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 4 Sep 2007 14:24:15 -0500 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: References: <1187628864.3382.27.camel@localhost.localdomain> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> Message-ID: <16de708d0709041224t29d32129ufd52d5106bb393eb@mail.gmail.com> On 9/4/07, Ian Burrell wrote: > On 9/1/07, Bruno Wolff III wrote: > > On Sat, Sep 01, 2007 at 14:07:17 +0200, > > Benny Amorsen wrote: > > > > > > Administrators sometimes want to limit which traffic can reach > > > applications, and perhaps limit the risk when accidentally starting > > > applications. Automating firewall setup makes that useless. > > > > That is probably the main reason. And having apps undo restrictions seems > > like a really really bad idea. > > > > Plus I have no confidence that apps can properly rewrite iptables rules > > correctly. iptables setups can have complications which will make it > > hard to change them. I have used subroutines for checking reserved ip > > ranges and have had services configured to only be available to local > > ip addresses or specific interfaces. > > > > I think the idea of having some way to help people who want a service > > available to the internet at large or some local ip addresses is a good > > idea, but it needs to be an add on step that can be skipped, not some > > invisible change behind the scenes. > > > > I wonder if the solution is to display the linkage between services > and firewall rules in the configuration tools. People would make the > changes in the tools but they would know what is needed. For > system-config-securitylevel, one possibility is to highlight the > services that are enabled but haven't been opened. > > Another help would have system-config-services print out a warning if > the user enables a service but the firewall rule is not opened. > system-config-services could probably show a dialog box that opens the > firewall rule. This would probably only work if > system-config-securitylevel is managing the firewall. Seems like a fair compromise. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Tue Sep 4 19:28:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 11:28:19 -0800 Subject: Goal: Increased Modularity? In-Reply-To: <1188932892.12969.107.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> Message-ID: <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> On 9/4/07, Richi Plana wrote: > I guess my point is that if the answer to a lot of people's requests is > that "they can spin things themselves", I just thought it would be an > important consideration for Fedora to give the respinners that > flexibility THROUGH modularization. Sure, and my point is, we are attempting to do just that..where there is real benefit. Things like virtual provides and the alternatives system are used when it makes sense. And "where it makes sense" is always in flux. There's an effort afoot right now to virtualize how we deal with logos for example. There's no doubt in my mind that we are putting thought and effort into modularizing things to make re-spins more possible as the need arises. It helps immensely, if discussions are grounded around real situations that would benefit from additional modularization, and not hypotheticals. I would humbly suggest that you take a little time and play around with repoquery as found in the yum-utils package and explore the dependancy chains a little bit using the tools --whatprovides, --whatrequires, --alldeps features to get a feel for how much virtualization is being used at the packaging level. -jef From mackay_d at bellsouth.net Tue Sep 4 19:32:50 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 14:32:50 -0500 Subject: Python 3.0 In-Reply-To: <46DD863A.8040606@gmail.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <46DC51EB.70207@fedoraunity.org> <1188910098.1394.28.camel@vorpal.macdev.com> <46DD863A.8040606@gmail.com> Message-ID: <1188934370.2670.12.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 09:22 -0700, Toshio Kuratomi wrote: > > Unless it somehow interferes with the standard python package, be it > > 2.5, 2.6, or whatever, I don't expect much. I'd love to get a recap of > > that in about six months or so. Out of the twelve bugs for python in > > FC6, eight were dups, not a bug, or rawhide. The four actual bugs that > > are still open were probably kicked upstream, and remain open eight or > > nine months later. > > > "This is the last planned release in the Python 2.4 series - future > maintenance releases of Python will be in the 2.5 series, starting of > course with 2.5.1." > http://www.python.org/download/releases/2.4.4/ > > "If you really want to maintain a retired package, then the process is > much the same as claiming an orphaned package. However, you need to be > aware that fixing release critical bugs etc becomes your responsibility. > This is to ensure the high quality and standards of packaging remain for > Fedora package collection." > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > So things like those four bugs kicked upstream become the responsibility > of our compat-python2.4 maintainer. Similarly, if any of the fixed > rawhide bugs needed to be fixed for python2.4 as well, they would be the > responsibility of our compat-python2.4 maintainer. So being the > compat-python2.4 maintainer is a non-trivial job. It might even be > easier to be the zope/plone maintainer and drive the port to python2.5 :-) No offense, but it seems that you have set the standards for the compat maintainer far higher than Fedora or the python authors are willing to meet. It seems to be a disingenuous method of denying compat packages while claiming that Fedora hasn't done so. Dave From dyoung at mesd.k12.or.us Tue Sep 4 19:33:01 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Tue, 4 Sep 2007 12:33:01 -0700 Subject: iced-tea backport to f7? In-Reply-To: References: Message-ID: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> On 9/4/07, Neal Becker wrote: > Would be nice to try this on f7. yum --enablerepo=development install java-1.7.0-icedtea -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From myfedora at richip.dhs.org Tue Sep 4 19:34:21 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 13:34:21 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <20070904175518.GA1378@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> <20070904175518.GA1378@nostromo.devel.redhat.com> Message-ID: <1188934461.12969.115.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 13:55 -0400, Bill Nottingham wrote: > It's somehow better to have each package require its own separate > configuration than to use a central package that only takes 2MB? I'm > not saying you can't do it, but: > > - every mutt user would have to set up their own muttrc with smtp server information > - every fetchmail user would have to change their invocation > - and so on, for each package as needed I would say services directory or service discovery. But I digress. BTW, evolution and thunderbird users set up their own outgoing mail configuration. Personally it would be nicer if these services could be discovered or configured by an administrator globally or per user, but if the usage of a program like /sbin/sendmail must be hardcoded, then at the very least have some kind of smart fallback. > > > dlopen will cause you to break at runtime instead of buildtime if > > > ABI changes - that's not good. > > > > Isn't that what escalating the version number to a higher layer (ie. RPM > > and yum) is all about? > > Sure, but then you're still breaking at runtime instead of build/install > time. You probably would, but that would be limited with correct versioning and package management. It wouldn't be any worse than Apache httpd modules or gstreamer-plugins (the plugins themselves and not the libraries they link against. Fortunately, it's pretty stable). -- Richi Plana From myfedora at richip.dhs.org Tue Sep 4 19:44:37 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 13:44:37 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> Message-ID: <1188935077.12969.124.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 11:28 -0800, Jeff Spaleta wrote: > Sure, and my point is, we are attempting to do just that..where there > is real benefit. Things like virtual provides and the alternatives > system are used when it makes sense. And "where it makes sense" is > always in flux. There's an effort afoot right now to virtualize how we > deal with logos for example. There's no doubt in my mind that we are > putting thought and effort into modularizing things to make re-spins > more possible as the need arises. It helps immensely, if discussions > are grounded around real situations that would benefit from additional > modularization, and not hypotheticals. I would humbly suggest that > you take a little time and play around with repoquery as found in the > yum-utils package and explore the dependancy chains a little bit using > the tools --whatprovides, --whatrequires, --alldeps features to get a > feel for how much virtualization is being used at the packaging level. I'm not saying you guys aren't. I'm just wondering if it's written in a guideline somewhere or if each person has to come up with the same realization each and every time. If there's something to show people who might be interested in Fedora why they would want to use Fedora (because the people working on it are smart cookies based on what they've said they're doing). Best practices aren't based on current nor existing problems. I do apologize if I've wasted people's time, but I just wondered if there would be value in having certain things written down. And yes, I am starting to get a feel for the intricacies of the rpm and yum utils. -- Richi Plana From jspaleta at gmail.com Tue Sep 4 19:51:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 11:51:35 -0800 Subject: Python 3.0 In-Reply-To: <1188934370.2670.12.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <46DC51EB.70207@fedoraunity.org> <1188910098.1394.28.camel@vorpal.macdev.com> <46DD863A.8040606@gmail.com> <1188934370.2670.12.camel@vorpal.macdev.com> Message-ID: <604aa7910709041251x1eeb5846i18bc71b1c973be85@mail.gmail.com> On 9/4/07, David G. Mackay wrote: > No offense, but it seems that you have set the standards for the compat > maintainer far higher than Fedora or the python authors are willing to > meet. It seems to be a disingenuous method of denying compat packages > while claiming that Fedora hasn't done so. I don't necessarily think its unreasonable to set the bar higher for compat. Most of the work to fix the bugs in any package is done as part of the on-going development process that the upstream developers dictate. We strive to be in tune with that upstream process.. as a project. When we introduce compat packages we are taking a step away from the normal upstreaming process. Compat packages cannot rely on the forward momentum of upstream developers, nor can we be as confident that the work being done in the compat space is going to be applicable beyond our project. As a result there is an explicit need for the maintainer to take on a heavier burden of accountability, in recognition that we are choosing to extend the servicable lifetime of a codebase that the upstream developers themselves are no longer interested in. -jef From mackay_d at bellsouth.net Tue Sep 4 20:00:15 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 15:00:15 -0500 Subject: Python 3.0 In-Reply-To: <20070904122349.41e55090@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> Message-ID: <1188936015.2670.25.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 12:23 -0400, Jesse Keating wrote: > On Tue, 04 Sep 2007 09:39:42 -0500 > "David G. Mackay" wrote: > > > Why does this remind me of Pangloss in Candide? > > I have no idea what that means. I see that you've been updated on that already. > > And, I have been > > rather forcefully told on this list that Fedora stands alone. > > Perhaps it's a matter of context. It's no mystery that RHEL is a > derivative of Fedora, and that CentOS is a free rebuild of RHEL. To Last I heard, Fedora was a derivative of RHEL, and perhaps early on RH9. As I understand it, Red Hat expects Fedora to be an upstream provider. One of several. > think that they have nothing to do with the Fedora universe is just > plain silly. To think that they aren't valid alternatives when looking > for say a long term supported Fedora, or a build of Fedora with more > thought to backward compatibility is just ignorant (not in a mean way, > just in a "the person doesn't possess the information" kind of way). And, to think that you can discard functionality for the sake of staying on the cutting edge while improving the distro seems a bit short sighted. I would have thought that Fedora was trying to stake out their own "mind share". On the other hand, thanks for the mental image. It makes me wonder how many DVD isos are in the "Fedora Universe" install set, and where the torrent is. Dave From jwboyer at jdub.homelinux.org Tue Sep 4 20:04:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 4 Sep 2007 15:04:57 -0500 Subject: Python 3.0 In-Reply-To: <1188936015.2670.25.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> Message-ID: <20070904150457.48894ae6@weaponx.rchland.ibm.com> On Tue, 04 Sep 2007 15:00:15 -0500 "David G. Mackay" wrote: > On Tue, 2007-09-04 at 12:23 -0400, Jesse Keating wrote: > > On Tue, 04 Sep 2007 09:39:42 -0500 > > "David G. Mackay" wrote: > > > > > Why does this remind me of Pangloss in Candide? > > > > I have no idea what that means. > > I see that you've been updated on that already. > > > > And, I have been > > > rather forcefully told on this list that Fedora stands alone. > > > > Perhaps it's a matter of context. It's no mystery that RHEL is a > > derivative of Fedora, and that CentOS is a free rebuild of RHEL. To > > Last I heard, Fedora was a derivative of RHEL, and perhaps early on RH9. > As I understand it, Red Hat expects Fedora to be an upstream provider. > One of several. Um, no. In fact, these days it's often the opposite. RHEL is a derivative of Fedora. josh From jkeating at redhat.com Tue Sep 4 20:08:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 16:08:30 -0400 Subject: Python 3.0 In-Reply-To: <1188936015.2670.25.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> Message-ID: <20070904160830.55ee18e9@ender> On Tue, 04 Sep 2007 15:00:15 -0500 "David G. Mackay" wrote: > Last I heard, Fedora was a derivative of RHEL, and perhaps early on > RH9. Then you've been sadly misinformed. Red Hat Enterprise Linux has always been built from either Red Hat Linux of the day, or Fedora. Never (that I am aware of) have we taken an existing RHEL and turned it into RHL or Fedora. > As I understand it, Red Hat expects Fedora to be an upstream > provider. One of several. Yes, that's how derivitives work. We provide an upstream for RHEL. They take some of our packages, some they don't modify, some they do. They add some more packages from other sources, and produce something that while shares a lot alike with Fedora, and includes large parts of Fedora, it isn't Fedora. > > > think that they have nothing to do with the Fedora universe is just > > plain silly. To think that they aren't valid alternatives when > > looking for say a long term supported Fedora, or a build of Fedora > > with more thought to backward compatibility is just ignorant (not > > in a mean way, just in a "the person doesn't possess the > > information" kind of way). > > And, to think that you can discard functionality for the sake of > staying on the cutting edge while improving the distro seems a bit > short sighted. I would have thought that Fedora was trying to stake > out their own "mind share". We have our mind share, it's forward looking. We are targeting new software rather than trying to continually run old software. > > On the other hand, thanks for the mental image. It makes me wonder > how many DVD isos are in the "Fedora Universe" install set, and where > the torrent is. It all depends on how many folks create something from the Fedora packages that isn't Fedora. Somewhat impossible to track. That's like asking for a torrent for "Opensource Software", or "The Internet". Fedora doesn't have to be everything to every person. It doesn't have to solve all the problems. There are perfectly viable alternatives to Fedora, that are even based on Fedora, that solve some problem spaces that Fedora itself just isn't interested in. Duplication of effort is not fun for anybody. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Sep 4 20:15:56 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 12:15:56 -0800 Subject: Goal: Increased Modularity? In-Reply-To: <1188935077.12969.124.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <1188935077.12969.124.camel@localhost6.localdomain6> Message-ID: <604aa7910709041315x7b3861c9ld865fde0b477b12c@mail.gmail.com> On 9/4/07, Richi Plana wrote: > I'm not saying you guys aren't. I'm just wondering if it's written in a > guideline somewhere or if each person has to come up with the same > realization each and every time. If there's something to show people who > might be interested in Fedora why they would want to use Fedora (because > the people working on it are smart cookies based on what they've said > they're doing). Introduction of a virtual provides or other mechanims..requires discussion.. because it impacts multiple package maintainers. It's case by case. But it might not be so bad an idea to write a little glowy piece of prose describing how virtual provides are being used right now, to help people interested in re-spinning appreciate there is more modularization at the packaging level than the packaging list of default install of Fedora would suggest. Until you go poking at it, you may not know its there. -jef From lesmikesell at gmail.com Tue Sep 4 20:21:25 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 04 Sep 2007 15:21:25 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> Message-ID: <46DDBE45.7080703@gmail.com> Jeff Spaleta wrote: > On 9/4/07, Richi Plana wrote: >> I guess my point is that if the answer to a lot of people's requests is >> that "they can spin things themselves", I just thought it would be an >> important consideration for Fedora to give the respinners that >> flexibility THROUGH modularization. > > Sure, and my point is, we are attempting to do just that..where there > is real benefit. Things like virtual provides and the alternatives > system are used when it makes sense. And "where it makes sense" is > always in flux. Has anyone considered a system that 'makes sense' for multiuser operation where different users want different alternative targets at once - or the same user wants alternative JVMs for different applications at the same time? -- Les Mikesell lesmikesell at gmail.com From walters at redhat.com Tue Sep 4 20:26:01 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 4 Sep 2007 16:26:01 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <46DDBE45.7080703@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> Message-ID: On 9/4/07, Les Mikesell wrote: > > > Has anyone considered a system that 'makes sense' for multiuser > operation where different users want different alternative targets at > once - or the same user wants alternative JVMs for different > applications at the same time? Java has long supported this via JAVA_HOME and the like, what else do you want? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Tue Sep 4 20:27:28 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Sep 2007 12:27:28 -0800 Subject: Goal: Increased Modularity? In-Reply-To: <46DDBE45.7080703@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> Message-ID: <604aa7910709041327l312b8a86yf98a0dc904ce386a@mail.gmail.com> On 9/4/07, Les Mikesell wrote: > Has anyone considered a system that 'makes sense' for multiuser > operation where different users want different alternative targets at > once - or the same user wants alternative JVMs for different > applications at the same time? Are you suggesting that the alternatives system, in association with shell PATH variables isn't adequate enough for a user who knows enough about things such as sendmail alternatives to reconfigure to their hearts content? I'm pretty sure alternatives allows for per-user configurations, into per-user defined paths for executables and manpages and what not. -jef From bernie at codewiz.org Tue Sep 4 20:31:18 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 04 Sep 2007 16:31:18 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <20070904165703.GB30334@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> Message-ID: <46DDC096.3040803@codewiz.org> On 09/04/2007 12:57 PM, Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: >> For instance, if I desired to come up with a spin that doesn't have >> Sendmail, why must I give up fetchmail, mutt or tor? > > Because they *require* a MTA to deliver/send the mail, at least in their > default configurations Seems to be the perfect case for a "Suggests" tag. dpkg/apt has had it for a long time and I find it very benefical. It would also solve things such as mkinitrd claming a hard dependency on lvm and dmraid for installation ordering purposes. Now that RPM is under active development again, would such a new feature be possible? -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From mackay_d at bellsouth.net Tue Sep 4 20:32:00 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 15:32:00 -0500 Subject: Python 3.0 In-Reply-To: <604aa7910709041251x1eeb5846i18bc71b1c973be85@mail.gmail.com> References: <1188586957.3151.7.camel@ignacio.lan> <1188748768.26358.6.camel@vorpal.macdev.com> <20070902172406.2ac86ab9@vader.jdub.homelinux.org> <1188828215.30160.43.camel@vorpal.macdev.com> <20070903094905.3d3b53af@vader.jdub.homelinux.org> <1188841712.31055.15.camel@vorpal.macdev.com> <46DC51EB.70207@fedoraunity.org> <1188910098.1394.28.camel@vorpal.macdev.com> <46DD863A.8040606@gmail.com> <1188934370.2670.12.camel@vorpal.macdev.com> <604aa7910709041251x1eeb5846i18bc71b1c973be85@mail.gmail.com> Message-ID: <1188937920.2670.39.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 11:51 -0800, Jeff Spaleta wrote: > On 9/4/07, David G. Mackay wrote: > > No offense, but it seems that you have set the standards for the compat > > maintainer far higher than Fedora or the python authors are willing to > > meet. It seems to be a disingenuous method of denying compat packages > > while claiming that Fedora hasn't done so. > > I don't necessarily think its unreasonable to set the bar higher for compat. > Most of the work to fix the bugs in any package is done as part of the > on-going development process that the upstream developers dictate. We So, why is it that the python developers can dictate that the bugs in 2.4.4 which is in the currently supported FC6 distro, won't be fixed for FC6, but Zope developers can't say they need to use python2.4.x? > strive to be in tune with that upstream process.. as a project. When > we introduce compat packages we are taking a step away from the normal > upstreaming process. Compat packages cannot rely on the forward > momentum of upstream developers, nor can we be as confident that the > work being done in the compat space is going to be applicable beyond > our project. As a result there is an explicit need for the maintainer > to take on a heavier burden of accountability, in recognition that we > are choosing to extend the servicable lifetime of a codebase that the > upstream developers themselves are no longer interested in. Why in the world would you assume that a compat package would suddenly develop problems when its usage base has most likely shrunken considerably? And, I'm sorry, but if you don't mind that the bugs aren't going to be fixed for the live version (and yes, I understand that the python developers don't consider 2.4.4 to be live, FC6 users do) then it's very much a double standard to insist that they be fixed for a compat package that's going to be used by a much smaller group for a specific purpose. Dave From mackay_d at bellsouth.net Tue Sep 4 20:42:35 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 15:42:35 -0500 Subject: Python 3.0 In-Reply-To: <20070904150457.48894ae6@weaponx.rchland.ibm.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904150457.48894ae6@weaponx.rchland.ibm.com> Message-ID: <1188938555.2670.45.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 15:04 -0500, Josh Boyer wrote: > > Last I heard, Fedora was a derivative of RHEL, and perhaps early on RH9. > > As I understand it, Red Hat expects Fedora to be an upstream provider. > > One of several. > > Um, no. In fact, these days it's often the opposite. RHEL is a > derivative of Fedora. Well, there's no doubt that Fedora is breaking new ground a lot faster. In spite of my opinions on a few things, I do very much like having a distro that gives me a chance to try out the latest and (mostly) greatest open source products. Dave From mike at miketc.com Tue Sep 4 21:04:02 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 04 Sep 2007 16:04:02 -0500 Subject: iced-tea backport to f7? In-Reply-To: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> Message-ID: <1188939842.3012.1.camel@scrappy.miketc.com> On Tue, 2007-09-04 at 12:33 -0700, Dan Young wrote: > On 9/4/07, Neal Becker wrote: > > Would be nice to try this on f7. > > yum --enablerepo=development install java-1.7.0-icedtea I don't know much about this icedtea java stuff. I read it includes a browser plug-in with the rpm? Is this the same plugin as the java one from sun, or at least works the same? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From s.adam at diffingo.com Tue Sep 4 21:05:47 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Tue, 04 Sep 2007 17:05:47 -0400 Subject: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are... In-Reply-To: <1188917146.4464.41.camel@localhost.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188917146.4464.41.camel@localhost.localdomain> Message-ID: <1188939947.10471.10.camel@Diffingo.localdomain> On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote: > > Actually, the bigger problem is the concept that everything has to be a > "system service run from an initscript". To pick a specific case -- the > fact that bluetooth daemons get started by an initscript as a service is > really not what you want at this point. You instead want them being > started based on the existence of the hardware probably as a hal > callout[1]. +1 The ideal solution would be to run bluetooth only when bluetooth hardware is present, the same when applicable to all other services. About the defaults - If/When should we reselect what will be the defaults? I forget which release it was planned for, but I do remember seeing a page on the Wiki at one point about disabling sendmail and the rpc* services, but it never seemed to have happened. I think it would be a good change to make for F8. A small one, but a change nonetheless. Stewart From snecklifter at gmail.com Tue Sep 4 21:13:21 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 4 Sep 2007 22:13:21 +0100 Subject: Important change if you use python-setuptools In-Reply-To: <20070828201316.GE20753@crow.myhome.westell.com> References: <20070828201316.GE20753@crow.myhome.westell.com> Message-ID: <364d303b0709041413w62793989u8fa30fee4f12727b@mail.gmail.com> On 28/08/07, Luke Macken wrote: > > On Tue, Aug 28, 2007 at 01:32:31PM -0400, Konstantin Ryabitsev wrote: > > Hello, all: > > > > The python-setuptools package was split into two: python-setuptools, > > containing runtime-specific files (pkg_resources.py) and > > python-setuptools-devel, containing all other stuff necessary for > > building python packages. If your package uses python-setuptools in > > order to build, you will need to modify BuildRequires to reflect this > > change: > > > > bad: BuildRequires: python-setuptools > > good: BuildRequires: python-setuptools-devel > > > > Applies to: > > F8 (current development) and up > > > > Reasons for change: > > Avoiding unnecessary dependencies on python-devel for those packages > > that use the runtime components of python-setuptools . > > See https://bugzilla.redhat.com/show_bug.cgi?id=251645 for more info. > > After a quick grep, it looks like these are the owners/packages that need > to be modified to reflect this change. > > 'snecker': ['jokosher'], > > Thanks for the heads up Konstantin and for generating the list Luke. Above is fixed and built in Koji. http://koji.fedoraproject.org/koji/buildinfo?buildID=17734 Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Tue Sep 4 21:20:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 04 Sep 2007 16:20:55 -0500 Subject: ubuntu bulletproof x In-Reply-To: <1188918070.24181.25.camel@localhost.localdomain> References: <1188480206.7545.9.camel@dawkins.stavtrup-st.dk> <1c847b0708300649n4a91a686vab2c355e0c7d7c5e@mail.gmail.com> <1188550495.6085.6.camel@clockmaker.usersys.redhat.com> <46D75259.8070208@filteredperception.org> <1188676474.1175.720.camel@localhost.localdomain> <46D9D3B5.6080305@filteredperception.org> <1188845697.22573.27.camel@localhost.localdomain> <46DC6643.40308@filteredperception.org> <1188918070.24181.25.camel@localhost.localdomain> Message-ID: <46DDCC37.6090909@filteredperception.org> Adam Jackson wrote: > On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote: >> Adam Jackson wrote: >>> Yeah, okay, force me to clarify. Grumble. >>> >>> There are cases where we can't tell what monitor the user has. They're >>> almost completely described by "either the card can't do DDC, or the >>> cable is broken". The former is a vanishingly small class of hardware, >>> voodoo1 basically. The latter happens depressingly often particularly >>> with projector setups. > >> So, to save you the trouble of rereading all of my posts. Can you >> explicitly confirm this (which it sounds like you did, but not in a way >> that clearly addressed the point I tried to make half a dozen times last >> night). >> >> Repeat after me- >> >> "There is *NEVER* a situation, when the monitor fails to provide correct >> information, due to a broken or absent edid implementation, and which at >> the same time, sufficient information could be parsed from the .inf that >> came on the CD with the monitor, to provide the user, a reasonable >> experience requiring no user interaction beyond putting the cd in the >> drive". (and at which time, the X driver could not have accomplished >> the same thing automatically without the .inf) > First, thanks for many of these recent educational responses. Something like cvt I do personally find cool, though clearly it has nothing to do with the type of situation ubuntu-bulletproof-x is targeting. > Absent EDID in the sink device never happens anymore. It's a > requirement for Vista certification. I'm fairly sure it was required > for XP cert. It's a requirement for shipping any DVI sink device. It > is _mandatory_. > > We can fail to get EDID, either because the cable broke the DDC pins, or > timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or > it's a really old monitor, or there's a crap KVM switch in the middle, > or phase of the moon, or whatever. This sounds like an aweful lot of situations. I suspect my micron apt150t falls into more than one of them (not DVI, not vista certified, probably not xp certified, 'really old', who knows about about i2c timing and/or bios bugs...). I'll save the details of my s-c-d fun yesterday for a bug report, but suffice it to say that after selecting 'generic 1024x768 lcd panel' and seeing that in xorg.conf, it decided to start up in 1378x768... Not reproducibly though. My point, if I even have one anymore, is that it sounds like the above (my situation, and what you said), are a multitude of situations where .inf info might come in useful. But you did clarify below... > > I have not found ISOs for every OEM CD for every monitor that ever > shipped. I doubt I ever could. Therefore the following claim is merely > statistical. However, on no OEM CD that I've ever found does the > included INF file - or any other resource intended to be parsed by the > machine - provide the same set of information as the EDID block for the > monitor. It may provide a subset. The only subset I've ever seen is > sync ranges. From Richi Plana's posted .inf " [1280] HKR,,MaxResolution,,"1280,1024" " > > I'm not saying I'm happy about that. I would love to see a > counterexample. But it's all the empirical evidence I have. I would truly love to provide a counterexample with my micron ap150t, but as was pointed out elsewhere in this thread, that is one example where the .inf truly does not exist on the face of the earth. But if it did, and had something like the MaxResolution quoted above, that would be a valid counterexample, right? -dmc P.S. I honestly don't care enough about this thread to restore my copy of vista on my laptop (haven't had winblowz in my home for >6months) which has a vga-out, to see if windows can do better with that monitor than F7. From mackay_d at bellsouth.net Tue Sep 4 21:01:36 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 16:01:36 -0500 Subject: Python 3.0 In-Reply-To: <20070904160830.55ee18e9@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> Message-ID: <1188939696.2670.59.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 16:08 -0400, Jesse Keating wrote: > On Tue, 04 Sep 2007 15:00:15 -0500 > "David G. Mackay" wrote: > > > Last I heard, Fedora was a derivative of RHEL, and perhaps early on > > RH9. > > Then you've been sadly misinformed. Red Hat Enterprise Linux has > always been built from either Red Hat Linux of the day, or Fedora. > Never (that I am aware of) have we taken an existing RHEL and turned it > into RHL or Fedora. No. I was thinking specifically of FC1. Since all of the succeeding Fedora releases build on each other, they are all, in that sense derived from RHEL and RH9. Of course, you could claim that everything for FC1 was conjured into existence independently, which would give a whole new meaning to "installation wizard". > > > think that they have nothing to do with the Fedora universe is just > > > plain silly. To think that they aren't valid alternatives when > > > looking for say a long term supported Fedora, or a build of Fedora > > > with more thought to backward compatibility is just ignorant (not > > > in a mean way, just in a "the person doesn't possess the > > > information" kind of way). > > > > And, to think that you can discard functionality for the sake of > > staying on the cutting edge while improving the distro seems a bit > > short sighted. I would have thought that Fedora was trying to stake > > out their own "mind share". > > We have our mind share, it's forward looking. We are targeting new > software rather than trying to continually run old software. I understand that "Modern" is the mantra. I just hope it's not the whole koan. > > On the other hand, thanks for the mental image. It makes me wonder > > how many DVD isos are in the "Fedora Universe" install set, and where > > the torrent is. > It all depends on how many folks create something from the Fedora > packages that isn't Fedora. Somewhat impossible to track. That's like > asking for a torrent for "Opensource Software", or "The Internet". Sigh. I was afraid that you might take that seriously. > Fedora doesn't have to be everything to every person. It doesn't have > to solve all the problems. There are perfectly viable alternatives to > Fedora, that are even based on Fedora, that solve some problem spaces > that Fedora itself just isn't interested in. Duplication of effort is > not fun for anybody. Oh, I don't know. Take a look at xen and kvm. Those of us that aren't down in the trenches for those stand to win either way. Dave From kevinverma at gmail.com Tue Sep 4 22:57:01 2007 From: kevinverma at gmail.com (Kevin Verma) Date: Wed, 05 Sep 2007 04:27:01 +0530 Subject: iced-tea backport to f7? In-Reply-To: <1188939842.3012.1.camel@scrappy.miketc.com> References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> <1188939842.3012.1.camel@scrappy.miketc.com> Message-ID: Mike Chambers wrote: > On Tue, 2007-09-04 at 12:33 -0700, Dan Young wrote: >> On 9/4/07, Neal Becker wrote: >>> Would be nice to try this on f7. >> yum --enablerepo=development install java-1.7.0-icedtea > > I don't know much about this icedtea java stuff. I read it includes a > browser plug-in with the rpm? Is this the same plugin as the java one > from sun, or at least works the same? > See - http://spindazzle.org/greenblog/index.php?/archives/73-IcedTea-is-Fedorable.html At-least I tested the IcedTea web plugin on F8-rawhide, at it works like charm for most usage, but it did not worked for an Oracle legacy app at my work. The legacy app in question did detected the plugin an fired the applet but the app seems to have faced some in-compatibilities. I'll be glad to know if its possible to have any workarounds. Cheers, Kevin From lesmikesell at gmail.com Tue Sep 4 21:38:29 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 04 Sep 2007 16:38:29 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <604aa7910709041327l312b8a86yf98a0dc904ce386a@mail.gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <604aa7910709041327l312b8a86yf98a0dc904ce386a@mail.gmail.com> Message-ID: <46DDD055.1050605@gmail.com> Jeff Spaleta wrote: > On 9/4/07, Les Mikesell wrote: >> Has anyone considered a system that 'makes sense' for multiuser >> operation where different users want different alternative targets at >> once - or the same user wants alternative JVMs for different >> applications at the same time? > > Are you suggesting that the alternatives system, in association with > shell PATH variables isn't adequate enough for a user who knows enough > about things such as sendmail alternatives to reconfigure to their > hearts content? MTA's are sort-of system wide by nature, since only one thing can be listening on the inbound port. I'm more concerned with different JVMs since it is fairly likely that some users/applications won't be satisfied with included version(s), and some apps that you might want to run at the same time require different JVM versions. > I'm pretty sure alternatives allows for per-user > configurations, into per-user defined paths for executables and > manpages and what not. I haven't found documentation for the alternatives system that explains it at that level, and I haven't had a strong enough stomach to wade my way through the multi-level symlink morass to figure out what the right values for JAVA_HOME and PATH should be to execute any specific JVM version. Is it really designed to handle that? -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Tue Sep 4 21:35:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 17:35:54 -0400 Subject: History Lesson (was Re: Python 3.0) In-Reply-To: <1188939696.2670.59.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> <1188939696.2670.59.camel@vorpal.macdev.com> Message-ID: <20070904173554.327d051e@ender> On Tue, 04 Sep 2007 16:01:36 -0500 "David G. Mackay" wrote: > No. I was thinking specifically of FC1. Since all of the succeeding > Fedora releases build on each other, they are all, in that sense > derived from RHEL and RH9. Of course, you could claim that > everything for FC1 was conjured into existence independently, which > would give a whole new meaning to "installation wizard". > You have it wrong still. FC1 was literally RHL10 until the project name changed. It was not built on top of anything RHEL, it was built on top of RHL9. This thread has turned into a history lesson, and that's too bad, because we're no where near the original point of this topic. > > Fedora doesn't have to be everything to every person. It doesn't > > have to solve all the problems. There are perfectly viable > > alternatives to Fedora, that are even based on Fedora, that solve > > some problem spaces that Fedora itself just isn't interested in. > > Duplication of effort is not fun for anybody. > > Oh, I don't know. Take a look at xen and kvm. Those of us that > aren't down in the trenches for those stand to win either way. Not the same duplication I was talking about, but oh well. You do bring up an interesting topic in Xen, in that what we have in Fedora for Xen is a very sad case of dragging something forward. xensource has no interest in tracking upstream kernel unlike Fedora, so we have to continually forward port their release to newer kernels. Not Fun. I wouldn't expect it to last for too many more releases (just my opinion, nothing of authority here). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Tue Sep 4 21:43:30 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 04 Sep 2007 17:43:30 -0400 Subject: Python 3.0 In-Reply-To: <1188939696.2670.59.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> <1188939696.2670.59.camel@vorpal.macdev.com> Message-ID: <1188942210.14826.50.camel@cutter> On Tue, 2007-09-04 at 16:01 -0500, David G. Mackay wrote: > On Tue, 2007-09-04 at 16:08 -0400, Jesse Keating wrote: > > On Tue, 04 Sep 2007 15:00:15 -0500 > > "David G. Mackay" wrote: > > > > > Last I heard, Fedora was a derivative of RHEL, and perhaps early on > > > RH9. > > > > Then you've been sadly misinformed. Red Hat Enterprise Linux has > > always been built from either Red Hat Linux of the day, or Fedora. > > Never (that I am aware of) have we taken an existing RHEL and turned it > > into RHL or Fedora. > > No. I was thinking specifically of FC1. Since all of the succeeding > Fedora releases build on each other, they are all, in that sense derived > from RHEL and RH9. Of course, you could claim that everything for FC1 > was conjured into existence independently, which would give a whole new > meaning to "installation wizard". FC1 came from Red Hat Linux 9 It never passed through RHEL to get there. -sv From nicolas.mailhot at laposte.net Tue Sep 4 21:52:38 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Sep 2007 23:52:38 +0200 Subject: Python 3.0 In-Reply-To: <1188939696.2670.59.camel@vorpal.macdev.com> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> <1188939696.2670.59.camel@vorpal.macdev.com> Message-ID: <1188942758.23255.3.camel@rousalka.dyndns.org> Le mardi 04 septembre 2007 ? 16:01 -0500, David G. Mackay a ?crit : > On Tue, 2007-09-04 at 16:08 -0400, Jesse Keating wrote: > > On Tue, 04 Sep 2007 15:00:15 -0500 > > "David G. Mackay" wrote: > > > > > Last I heard, Fedora was a derivative of RHEL, and perhaps early on > > > RH9. > > > > Then you've been sadly misinformed. Red Hat Enterprise Linux has > > always been built from either Red Hat Linux of the day, or Fedora. > > Never (that I am aware of) have we taken an existing RHEL and turned it > > into RHL or Fedora. > > No. I was thinking specifically of FC1. Since all of the succeeding > Fedora releases build on each other, they are all, in that sense derived > from RHEL and RH9. Of course, you could claim that everything for FC1 > was conjured into existence independently, which would give a whole new > meaning to "installation wizard". What Jess told you is FC1 = RHL10 The RHEL releases are branches of the RHL/FC/F trunk (once could say dead branches as they are rebased from the free line periodically), and Fedora is certainly not derived from them -- 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 martin.sourada at seznam.cz Tue Sep 4 21:53:38 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 04 Sep 2007 23:53:38 +0200 Subject: Redesigning System Services (Re: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are...) In-Reply-To: <1188939947.10471.10.camel@Diffingo.localdomain> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188917146.4464.41.camel@localhost.localdomain> <1188939947.10471.10.camel@Diffingo.localdomain> Message-ID: <1188942818.9729.143.camel@pc-notebook> On Tue, 2007-09-04 at 23:05 +0200, Stewart Adam wrote: > On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote: > > > > Actually, the bigger problem is the concept that everything has to be a > > "system service run from an initscript". To pick a specific case -- the > > fact that bluetooth daemons get started by an initscript as a service is > > really not what you want at this point. You instead want them being > > started based on the existence of the hardware probably as a hal > > callout[1]. > +1 > > The ideal solution would be to run bluetooth only when bluetooth > hardware is present, the same when applicable to all other services. > > About the defaults - If/When should we reselect what will be the > defaults? I forget which release it was planned for, but I do remember > seeing a page on the Wiki at one point about disabling sendmail and the > rpc* services, but it never seemed to have happened. I think it would be > a good change to make for F8. A small one, but a change nonetheless. > > Stewart > We are past the feature freeze, I don't think this is possible... BUT. This thread is finally getting some shape as well as my ideas on this issue. The firstboot services screen was bad idea and I take it back, we should focus our efforts better. That means, as you and some others also suggested: 1. redefine the default set of services. Should be runlevel dependent and it should include only the services that are crucial to non-problematic run on every machine and that provide good user experience as well (like automounting CD's) 2. add support for automatically turning on services dependant on hardware. If you plug in bluetooth, HAL detects it and turn on the bluetooth services. Should be however handled in a way where user can have control over the service if (s)he want. That would mean that we would need three states for such a service: turned off by default, turned on by default, automatic. 3. Improve the system-config-services. Its great tool and has great potential but its confusing at first look. We need to provide to each service such a description *AND* name that everyone (well, I exaggerate here a little...) will understand it. 4. Some services that require a change of firewall rules to run correctly should offer such a change (but not do the change automatically, sometimes you want to have specific rules for the firewall, like opening ports only to specific IPs). These are mostly server services like sendmail, postfix, vsftpd, ... 5. Would be good if we provide gui utilities for easy (and only basic) configuration of services that has configuration capabilities. Should be accessible from system-config-services. I hope this list makes sense, I think I learned a lot in this particular thread... We could maybe, if the changes are desirable and sane, add this on the F9 feature list. Thanks, Martin -------------- 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 Tue Sep 4 22:26:31 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 04 Sep 2007 18:26:31 -0400 Subject: packages linked against libpoppler.so.1 need rebuilding Message-ID: <1188944791.4681.5.camel@localhost.localdomain> Kristian pushed poppler 0.6 into rawhide. Packages which link against libpoppler.so.1 or libpoppler-glib.so.1 need to be rebuilt. Thankfully, the list is pretty short: gimp pdfcube claws-mail-plugins-pdfviewer ruby-poppler referencer tracker From dmc.fedora at filteredperception.org Tue Sep 4 22:33:09 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 04 Sep 2007 17:33:09 -0500 Subject: Redesigning System Services (Re: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are...) In-Reply-To: <1188942818.9729.143.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188917146.4464.41.camel@localhost.localdomain> <1188939947.10471.10.camel@Diffingo.localdomain> <1188942818.9729.143.camel@pc-notebook> Message-ID: <46DDDD25.4020709@filteredperception.org> Martin Sourada wrote: > On Tue, 2007-09-04 at 23:05 +0200, Stewart Adam wrote: >> On Tue, 2007-09-04 at 10:45 -0400, Jeremy Katz wrote: >>> Actually, the bigger problem is the concept that everything has to be a >>> "system service run from an initscript". To pick a specific case -- the >>> fact that bluetooth daemons get started by an initscript as a service is >>> really not what you want at this point. You instead want them being >>> started based on the existence of the hardware probably as a hal >>> callout[1]. >> +1 >> >> The ideal solution would be to run bluetooth only when bluetooth >> hardware is present, the same when applicable to all other services. >> >> About the defaults - If/When should we reselect what will be the >> defaults? I forget which release it was planned for, but I do remember >> seeing a page on the Wiki at one point about disabling sendmail and the >> rpc* services, but it never seemed to have happened. I think it would be >> a good change to make for F8. A small one, but a change nonetheless. >> >> Stewart >> > > We are past the feature freeze, I don't think this is possible... BUT. As someone who was recently educated about this - remember, the feature freeze has nothing to do with keeping features out of F8 past the feature freeze deadline. It *only* has to do with what features are going to be heavily marketed. I was confused as well, thinking that the motivation for feature freeze had something to do with preventing de-stabalizing things from being added past the freeze. That is what feature freeze means in many organizations. Not so in fedora. In fedora, de-stabalizing things cannot be added after devel-freeze. -dmc From myfedora at richip.dhs.org Tue Sep 4 22:41:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 16:41:58 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DDBE45.7080703@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> Message-ID: <1188945718.19408.4.camel@localhost6.localdomain6> On Tue, 2007-09-04 at 15:21 -0500, Les Mikesell wrote: > Has anyone considered a system that 'makes sense' for multiuser > operation where different users want different alternative targets at > once - or the same user wants alternative JVMs for different > applications at the same time? Perhaps for certain things, alternative isn't the correct device to use. Personally, I set JAVA_HOME (along with PATH=$JAVA_HOME/bin:$PATH). For other packages, I still do PATH=$PACKAGE/bin:$PATH and LD_LIBRARY_PATH= $PACKAGE/lib:$LD_LIBRARY_PATH. It's old-school but it still works, specially on a per-user level. -- Richi Plana From mark at klomp.org Tue Sep 4 22:46:57 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 4 Sep 2007 22:46:57 +0000 (UTC) Subject: iced-tea backport to f7? References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> <1188939842.3012.1.camel@scrappy.miketc.com> Message-ID: Mike Chambers miketc.com> writes: > I don't know much about this icedtea java stuff. I read it includes a > browser plug-in with the rpm? Is this the same plugin as the java one > from sun, or at least works the same? That is the java-1.7.0-icedtea-plugin package. It isn't the same plugin code as the sun one since sun hasn't released their code (yet). This is the gcjwebplugin code made to work with the openjdk code base. We do hope it works the same, if not please do report bugs! http://icedtea.classpath.org/bugzilla One known issue is that the plugin doesn't support Liveconnect, the Javascript - Java bridge. Cheers, Mark From buildsys at fedoraproject.org Tue Sep 4 23:13:15 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 04 Sep 2007 23:13:15 -0000 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 Message-ID: <20070904231315.18546.7539@extras64.linux.duke.edu> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de koffice-karbon - 1.6.2-3.fc7.i386 (19 days) koffice-kivio - 1.6.2-3.fc7.i386 (19 days) koffice-kspread - 1.6.2-3.fc7.i386 (19 days) bjohnson AT symetrix.com dbmail - 2.2.4-4.fc7.i386 (61 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (15 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.i586 (11 days) kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.i686 (11 days) kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.x86_64 (11 days) kmod-sysprof-PAE - 1.0.8-1.2.6.22.1_41.fc7.i686 (11 days) jeff AT ocjtech.us libeXosip2 - 3.0.1-1.fc7.i386 (6 days) libeXosip2 - 3.0.1-1.fc7.i386 (6 days) libeXosip2 - 3.0.1-1.fc7.ppc (6 days) libeXosip2 - 3.0.1-1.fc7.x86_64 (6 days) lxtnow AT gmail.com python-gammu - 0.20-1.fc7.i386 (32 days) python-gammu - 0.20-1.fc7.ppc (32 days) python-gammu - 0.20-1.fc7.x86_64 (32 days) oliver AT linux-kernel.at syck-php - 0.55-16.fc7.i386 (51 days) syck-php - 0.55-16.fc7.ppc (51 days) syck-php - 0.55-16.fc7.x86_64 (51 days) peter AT thecodergeek.com empathy - 0.8-1.fc7.i386 (8 days) empathy - 0.8-1.fc7.ppc (8 days) empathy - 0.8-1.fc7.x86_64 (8 days) tcallawa AT redhat.com compat-wxGTK-devel - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-devel - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-devel - 2.4.2-21.fc6.ppc (50 days) compat-wxGTK-devel - 2.4.2-21.fc6.x86_64 (50 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-gl - 2.4.2-21.fc6.ppc (50 days) compat-wxGTK-gl - 2.4.2-21.fc6.x86_64 (50 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-stc - 2.4.2-21.fc6.ppc (50 days) compat-wxGTK-stc - 2.4.2-21.fc6.x86_64 (50 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (50 days) compat-wxGTK-xrc - 2.4.2-21.fc6.ppc (50 days) compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64 (50 days) twoerner AT redhat.com postfix-pflogsumm - 2:2.4.3-2.fc7.i386 (81 days) postfix-pflogsumm - 2:2.4.3-2.fc7.ppc (81 days) postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64 (81 days) ====================================================================== Broken packages in fedora-7-i386: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 libeXosip2-3.0.1-1.fc7.i386 requires libosipparser2.so.4 libeXosip2-3.0.1-1.fc7.i386 requires libosip2.so.4 ====================================================================== Broken packages in fedora-7-ppc: compat-wxGTK-devel-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.ppc requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 libeXosip2-3.0.1-1.fc7.ppc requires libosipparser2.so.4 libeXosip2-3.0.1-1.fc7.ppc requires libosip2.so.4 ====================================================================== Broken packages in fedora-7-x86_64: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires libwx_gtk-2.4.so.0()(64bit) compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-gl-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 dbmail-2.2.4-4.fc7.i386 requires dbmail-database-driver = 0:2.2.4-4.fc7 koffice-karbon-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kivio-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kspread-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 libeXosip2-3.0.1-1.fc7.i386 requires libosipparser2.so.4 libeXosip2-3.0.1-1.fc7.i386 requires libosip2.so.4 libeXosip2-3.0.1-1.fc7.x86_64 requires libosipparser2.so.4()(64bit) libeXosip2-3.0.1-1.fc7.x86_64 requires libosip2.so.4()(64bit) ====================================================================== Broken packages in fedora-updates-7-i386: empathy-0.8-1.fc7.i386 requires libmissioncontrol-config.so.0 empathy-0.8-1.fc7.i386 requires libmissioncontrol.so.0 kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.i586 requires kernel-i586 = 0:2.6.22.1-41.fc7 kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.i686 requires kernel-i686 = 0:2.6.22.1-41.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.22.1_41.fc7.i686 requires kernel-i686 = 0:2.6.22.1-41.fc7PAE postfix-pflogsumm-2:2.4.3-2.fc7.i386 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.i386 requires libGammu.so.1 syck-php-0.55-16.fc7.i386 requires php = 0:5.2.2 ====================================================================== Broken packages in fedora-updates-7-ppc: empathy-0.8-1.fc7.ppc requires libmissioncontrol-config.so.0 empathy-0.8-1.fc7.ppc requires libmissioncontrol.so.0 postfix-pflogsumm-2:2.4.3-2.fc7.ppc requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.ppc requires libGammu.so.1 syck-php-0.55-16.fc7.ppc requires php = 0:5.2.2 ====================================================================== Broken packages in fedora-updates-7-x86_64: empathy-0.8-1.fc7.x86_64 requires libmissioncontrol.so.0()(64bit) empathy-0.8-1.fc7.x86_64 requires libmissioncontrol-config.so.0()(64bit) kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.x86_64 requires kernel-x86_64 = 0:2.6.22.1-41.fc7 postfix-pflogsumm-2:2.4.3-2.fc7.x86_64 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.x86_64 requires libGammu.so.1()(64bit) syck-php-0.55-16.fc7.x86_64 requires php = 0:5.2.2 From mackay_d at bellsouth.net Wed Sep 5 00:10:45 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 19:10:45 -0500 Subject: History Lesson (was Re: Python 3.0) In-Reply-To: <20070904173554.327d051e@ender> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> <1188939696.2670.59.camel@vorpal.macdev.com> <20070904173554.327d051e@ender> Message-ID: <1188951045.2670.64.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 17:35 -0400, Jesse Keating wrote: > On Tue, 04 Sep 2007 16:01:36 -0500 > "David G. Mackay" wrote: > > > No. I was thinking specifically of FC1. Since all of the succeeding > > Fedora releases build on each other, they are all, in that sense > > derived from RHEL and RH9. Of course, you could claim that > > everything for FC1 was conjured into existence independently, which > > would give a whole new meaning to "installation wizard". > > > > You have it wrong still. FC1 was literally RHL10 until the project > name changed. It was not built on top of anything RHEL, it was built > on top of RHL9. This thread has turned into a history lesson, and > that's too bad, because we're no where near the original point of this > topic. OK. I suppose things like gfs, which did migrate from RHEL to the kernel, and thus to Fedora are extremely rare. And yes, we've degenerated into discussing semantics. > > > Fedora doesn't have to be everything to every person. It doesn't > > > have to solve all the problems. There are perfectly viable > > > alternatives to Fedora, that are even based on Fedora, that solve > > > some problem spaces that Fedora itself just isn't interested in. > > > Duplication of effort is not fun for anybody. > > > > Oh, I don't know. Take a look at xen and kvm. Those of us that > > aren't down in the trenches for those stand to win either way. > > Not the same duplication I was talking about, but oh well. You do > bring up an interesting topic in Xen, in that what we have in Fedora > for Xen is a very sad case of dragging something forward. xensource > has no interest in tracking upstream kernel unlike Fedora, so we have > to continually forward port their release to newer kernels. Not Fun. > I wouldn't expect it to last for too many more releases (just my > opinion, nothing of authority here). May the best hypervisor win. Dave From mackay_d at bellsouth.net Wed Sep 5 00:11:33 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 04 Sep 2007 19:11:33 -0500 Subject: Python 3.0 In-Reply-To: <1188942210.14826.50.camel@cutter> References: <1188586957.3151.7.camel@ignacio.lan> <20070831143511.23586a7f@weaponx.rchland.ibm.com> <20070901083807.GA25737@free.fr> <20070901072559.51664309@vader.jdub.homelinux.org> <20070901192352.GA27309@free.fr> <46D9C276.60103@fedoraproject.org> <1188699232.24368.12.camel@vorpal.macdev.com> <46DA1CB0.7080509@fedoraproject.org> <20070901224320.77fdd46a@vader.jdub.homelinux.org> <1188748768.26358.6.camel@vorpal.macdev.com> <645d17210709021544w3a1f223el5d775adfa49cbbab@mail.gmail.com> <1188828480.30160.49.camel@vorpal.macdev.com> <20070903142716.38a70949@ender> <1188910748.1394.39.camel@vorpal.macdev.com> <20070904090032.228151a8@ender> <1188916783.1916.7.camel@vorpal.macdev.com> <20070904122349.41e55090@ender> <1188936015.2670.25.camel@vorpal.macdev.com> <20070904160830.55ee18e9@ender> <1188939696.2670.59.camel@vorpal.macdev.com> <1188942210.14826.50.camel@cutter> Message-ID: <1188951093.2670.66.camel@vorpal.macdev.com> On Tue, 2007-09-04 at 17:43 -0400, seth vidal wrote: > > > Then you've been sadly misinformed. Red Hat Enterprise Linux has > > > always been built from either Red Hat Linux of the day, or Fedora. > > > Never (that I am aware of) have we taken an existing RHEL and turned it > > > into RHL or Fedora. > > > > No. I was thinking specifically of FC1. Since all of the succeeding > > Fedora releases build on each other, they are all, in that sense derived > > from RHEL and RH9. Of course, you could claim that everything for FC1 > > was conjured into existence independently, which would give a whole new > > meaning to "installation wizard". > > FC1 came from Red Hat Linux 9 > > It never passed through RHEL to get there. I yield. Dave From yabraham2 at gmail.com Wed Sep 5 00:20:05 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Tue, 4 Sep 2007 20:20:05 -0400 Subject: fedora background images and main menu icons gone Message-ID: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> on rahawid, my beautiful high fly balloon backgrounds are gone. my main menu icons are gone to. From myfedora at richip.dhs.org Wed Sep 5 00:22:35 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 04 Sep 2007 18:22:35 -0600 Subject: Classifying Packages By Priority Message-ID: <1188951755.21298.6.camel@localhost6.localdomain6> Hi, Is there work or a proposal on incorporating Priority (TRIVIAL, FEATURE_ENHANCEMENT, BUGFIX, SECURITY, etc.) meta-info into RPM packages? Then it would be a simple thing to do "yum update --priority=SECURITY|BUGFIX". The "Priority" here would of course mean the incremental difference between it and some prior package version. I was just reminded of the old days when I used to administer Solaris boxes and would be so conservative with changes that only Security type of patches would be applied. -- Richi Plana From jkeating at redhat.com Wed Sep 5 01:05:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Sep 2007 21:05:48 -0400 Subject: Redesigning System Services (Re: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are...) In-Reply-To: <46DDDD25.4020709@filteredperception.org> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188917146.4464.41.camel@localhost.localdomain> <1188939947.10471.10.camel@Diffingo.localdomain> <1188942818.9729.143.camel@pc-notebook> <46DDDD25.4020709@filteredperception.org> Message-ID: <20070904210548.6b404987@ender> On Tue, 04 Sep 2007 17:33:09 -0500 Douglas McClendon wrote: > I was confused as well, thinking that the motivation for feature > freeze had something to do with preventing de-stabalizing things from > being added past the freeze. That is what feature freeze means in > many organizations. Not so in fedora. In fedora, de-stabalizing > things cannot be added after devel-freeze. I guess we're not all messaging the same thing. We'd rather far reaching de-stabalizing feature type stuff doesn't happen after the feature freeze as well. Sometimes it's just hard to tell somebody "No, wait 'till next release." -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Sep 5 01:38:14 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 4 Sep 2007 21:38:14 -0400 Subject: Classifying Packages By Priority In-Reply-To: <1188951755.21298.6.camel@localhost6.localdomain6> References: <1188951755.21298.6.camel@localhost6.localdomain6> Message-ID: <20070905013814.GA5694@jadzia.bu.edu> On Tue, Sep 04, 2007 at 06:22:35PM -0600, Richi Plana wrote: > Is there work or a proposal on incorporating Priority (TRIVIAL, > FEATURE_ENHANCEMENT, BUGFIX, SECURITY, etc.) meta-info into RPM > packages? Then it would be a simple thing to do "yum update > --priority=SECURITY|BUGFIX". The "Priority" here would of course mean > the incremental difference between it and some prior package version. sudo yum install yum-security -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mike at miketc.com Wed Sep 5 02:42:04 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 04 Sep 2007 21:42:04 -0500 Subject: iced-tea backport to f7? In-Reply-To: References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> <1188939842.3012.1.camel@scrappy.miketc.com> Message-ID: <1188960124.3012.3.camel@scrappy.miketc.com> On Tue, 2007-09-04 at 22:46 +0000, Mark Wielaard wrote: > Mike Chambers miketc.com> writes: > > I don't know much about this icedtea java stuff. I read it includes a > > browser plug-in with the rpm? Is this the same plugin as the java one > > from sun, or at least works the same? > > That is the java-1.7.0-icedtea-plugin package. > It isn't the same plugin code as the sun one since sun hasn't released their > code (yet). This is the gcjwebplugin code made to work with the openjdk code > base. We do hope it works the same, if not please do report bugs! > http://icedtea.classpath.org/bugzilla > > One known issue is that the plugin doesn't support Liveconnect, the Javascript - > Java bridge. I've got it installed now and removed the sun java link and it did load. Even tested to see if it's loaded on sun's java page and was successful. So far so good I guess. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From debarshi.ray at gmail.com Wed Sep 5 04:08:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 5 Sep 2007 09:38:03 +0530 Subject: fedora background images and main menu icons gone In-Reply-To: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> Message-ID: <3170f42f0709042108w10ab1082i59d06c90b2e48ff5@mail.gmail.com> > on rahawid, my beautiful high fly balloon backgrounds are gone. my > main menu icons are gone to. Did you update something before this happened? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From james.antill at redhat.com Wed Sep 5 04:38:13 2007 From: james.antill at redhat.com (James Antill) Date: Wed, 05 Sep 2007 00:38:13 -0400 Subject: Classifying Packages By Priority In-Reply-To: <20070905013814.GA5694@jadzia.bu.edu> References: <1188951755.21298.6.camel@localhost6.localdomain6> <20070905013814.GA5694@jadzia.bu.edu> Message-ID: <1188967093.9457.30.camel@code.and.org> On Tue, 2007-09-04 at 21:38 -0400, Matthew Miller wrote: > On Tue, Sep 04, 2007 at 06:22:35PM -0600, Richi Plana wrote: > > Is there work or a proposal on incorporating Priority (TRIVIAL, > > FEATURE_ENHANCEMENT, BUGFIX, SECURITY, etc.) meta-info into RPM > > packages? Then it would be a simple thing to do "yum update > > --priority=SECURITY|BUGFIX". The "Priority" here would of course mean > > the incremental difference between it and some prior package version. > > sudo yum install yum-security Note that while the above contains all the code, for updating based on bugzilla numbers, advisories, CVE numbers or security designation. The information is currently not generated past FC-6[1], AFAICS. For more details see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251135 [1] And then only for core. -- James Antill Red Hat -------------- 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 nigel.metheringham at dev.intechnology.co.uk Wed Sep 5 08:32:34 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 5 Sep 2007 09:32:34 +0100 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <16de708d0709041224t29d32129ufd52d5106bb393eb@mail.gmail.com> References: <1187628864.3382.27.camel@localhost.localdomain> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709041224t29d32129ufd52d5106bb393eb@mail.gmail.com> Message-ID: <6EC766F7-93AC-4C62-B7A1-F89C6133CF38@dev.intechnology.co.uk> How about each service dropping a config snippet (as a separate file) into something like /etc/sysconfig/service-firewall-rules and having a setting on the firewall config GUI which allowed these to be included in [or not]. You could also provide an appropriately rich environment setup to allow all the standard requirements of basic firewall rules (ie interface name/addr etc). It would obviously take work to get this infrastructure in place. Nigel. From rjones at redhat.com Wed Sep 5 08:48:50 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 05 Sep 2007 09:48:50 +0100 Subject: Can't even rebuild ocaml-labgl Message-ID: <46DE6D72.4090002@redhat.com> http://koji.fedoraproject.org/koji/taskinfo?taskID=147396 http://koji.fedoraproject.org/koji/getfile?taskID=147398&name=root.log This is plain weird. It seems to me that someone could create a package with a bogus "Provides: glibc" which was otherwise uninstallable and bring the whole distribution to a halt. Is there not a way to say "I do _not_ want this package, whatever that package may claim about its provides"? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 09:21:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 11:21:09 +0200 Subject: Can't even rebuild ocaml-labgl In-Reply-To: <46DE6D72.4090002@redhat.com> References: <46DE6D72.4090002@redhat.com> Message-ID: <20070905112109.26719f3d.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Sep 2007 09:48:50 +0100, Richard W.M. Jones wrote: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=147396 > http://koji.fedoraproject.org/koji/getfile?taskID=147398&name=root.log > > This is plain weird. It seems to me that someone could create a package > with a bogus "Provides: glibc" which was otherwise uninstallable and > bring the whole distribution to a halt. Is there not a way to say "I do > _not_ want this package, whatever that package may claim about its > provides"? rel-eng can block ocaml-lablgl from dist-f8 I think. If not, it can be worked around with a dummy-build (i.e. build an empty ocaml-lablgl update without any BR ocaml*). And yes, one can break the buildroot with such Provides as you mention. From nicolas.mailhot at laposte.net Wed Sep 5 09:25:38 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Sep 2007 11:25:38 +0200 (CEST) Subject: Can't even rebuild ocaml-labgl In-Reply-To: <20070905112109.26719f3d.mschwendt.tmp0701.nospam@arcor.de> References: <46DE6D72.4090002@redhat.com> <20070905112109.26719f3d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <12712.192.54.193.51.1188984338.squirrel@rousalka.dyndns.org> Le Mer 5 septembre 2007 11:21, Michael Schwendt a ?crit : > And yes, one can break the buildroot with such Provides as you > mention. And the problem will be identified instead of being hidden behind a silent workaround -- Nicolas Mailhot From nphilipp at redhat.com Wed Sep 5 09:28:50 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 05 Sep 2007 11:28:50 +0200 Subject: RFC: Naming guidelines for packages extending GIMP Message-ID: <1188984530.12274.55.camel@wombat.tiptoe.de> Hi, during the review of the resynthesizer plugin for GIMP [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the package to be named "gimp-plugin-resynthesizer" rather than "gimp-resynthesizer". Ewan brought up the point that there isn't really a naming guideline for it, therefore I'd like to propose one: For packages specific to GIMP (i.e. not just extensions of a separate application like xsane, ufraw): Plugins and scripts(*): "gimp-plugin-" Patterns: "gimp-pattern-" Brushes: "gimp-brush-" Themes: "gimp-theme-" If a package provides several distinct features that have value of their own (use your own discretion on that), it must ship them as separate subpackages. In that case, the source package is named "gimp-extension-" where is a sensible name for the collection (see examples). That's all of the different kinds of extensions for GIMP I can think about right now, feel free to add to the list ;-). For packages that contain e.g. a plugin and some brushes, I would separate them into subpackages if it is sensible to do so. If not, I would name the package after the main feature (in this case, likely "gimp-plugin-..." (*): the differences between gimp plugins and scripts are more and more blurred. For instance, gimp-2.4 has all these in the "Filters" menu, there's no separate Script-Fu menu anymore. I'm open to calling these "gimp-filter(s)-..." but I guess that doesn't cover plugins that render new content (i.e. not filtering existing images) IMO. For packages not specific to GIMP, i.e. subpackages of otherwise separate packages (e.g. xsane, ufraw): Plugins and scripts: "-gimp-plugin" Patterns: "gimp-pattern" ... and so forth. Their source packages are of course named after their main package. Examples: GIMP-specific: - "gimp-plugin-resynthesizer": one plugin, two additional, non-distinct scripts (this one actually exists) - "gimp-extension-underwater" (SRPM) -> "gimp-plugin-removetheblue", "gimp-plugin-removetheflashspeckles": two thematically related, but distinct plugins - "gimp-plugin-flowers": plugin to generate flowers with associated brushes and patterns (that provide little value separate from the plugin) non-GIMP-specific: - "xsane" -> "xsane-gimp-plugin" - "ufraw" -> "ufraw-gimp-plugin" Note that I haven't renamed the latter two yet, I want to await the results of the discussion first. Please comment. Ewan also expressed concern about the proliferation of package specific naming guidelines. Tell me what you think about that as well. Thanks, Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nicolas.mailhot at laposte.net Wed Sep 5 09:30:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Sep 2007 11:30:31 +0200 (CEST) Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <6EC766F7-93AC-4C62-B7A1-F89C6133CF38@dev.intechnology.co.uk> References: <1187628864.3382.27.camel@localhost.localdomain> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709041224t29d32129ufd52d5106bb393eb@mail.gmail.com> <6EC766F7-93AC-4C62-B7A1-F89C6133CF38@dev.intechnology.co.uk> Message-ID: <42825.192.54.193.51.1188984631.squirrel@rousalka.dyndns.org> Le Mer 5 septembre 2007 10:32, Nigel Metheringham a ?crit : > How about each service dropping a config snippet (as a separate file) > into something like /etc/sysconfig/service-firewall-rules and having > a setting on the firewall config GUI which allowed these to be > included in [or not]. > > You could also provide an appropriately rich environment setup to > allow all the standard requirements of basic firewall rules (ie > interface name/addr etc). > > It would obviously take work to get this infrastructure in place. In an handwaved perfect word, service-firewall-rules would display a graph of the current firewall network ruleset (showing the packet flow through blocks of rules), and services would just dump new blocks in this graph that'd be grayed out till activated by the admin. This is something like a SoC project though. Regards, -- Nicolas Mailhot From buildsys at redhat.com Wed Sep 5 10:12:31 2007 From: buildsys at redhat.com (Build System) Date: Wed, 5 Sep 2007 06:12:31 -0400 Subject: rawhide report: 20070905 changes Message-ID: <200709051012.l85ACVN2020606@porkchop.devel.redhat.com> New package hamlib Run-time library to control radio transceivers and receivers New package libedit The NetBSD Editline library (libedit) Updated Packages: apr-1.2.9-4 ----------- * Sun Sep 02 2007 Joe Orton 1.2.9-4 - fix API/ABI of 32-bit builds (#254241) * Tue Aug 21 2007 Joe Orton 1.2.9-2 - fix License * Mon Jun 25 2007 Bojan Smojver 1.2.9-1 - bump up to 1.2.9 apr-util-1.2.8-12 ----------------- * Sun Sep 02 2007 Joe Orton 1.2.8-12 - rebuild for fixed APR 32-bit ABI - remove sqlite driver from main package (#274521) comps-extras-13-1 ----------------- * Tue Sep 04 2007 Bill Nottingham - 13-1 - add fonts icons, tweak sound & video, system tools desktop-backgrounds-7.92-2 -------------------------- * Thu Aug 30 2007 Jeremy Katz - 7.92-2 - need to include less infinity backgrounds for now; the space usage kill livecds httpd-2.2.4-10 -------------- * Sun Sep 02 2007 Joe Orton 2.2.4-10 - rebuild for fixed APR kdesvn-0.13.0-4.fc8 ------------------- * Mon Sep 03 2007 Joe Orton 0.13.0-4 - rebuild for fixed 32-bit APR (#254241) kernel-2.6.23-0.164.rc5.fc8 --------------------------- * Tue Sep 04 2007 Chuck Ebbert - fix DMA mode on VIA 6421 * Tue Sep 04 2007 Chuck Ebbert - Fix oops in cpuidle under QEMU * Tue Sep 04 2007 Roland McGrath - utrace update (#232837, #248532) mash-0.2.2-1.fc8 ---------------- * Tue Sep 04 2007 Bill Nottingham 0.2.2-1 - add nspluginwrapper to multilib whitelist (#275021) - fix kernel-devel (#247321) mod_auth_kerb-5.3-5 ------------------- * Sun Sep 02 2007 Joe Orton 5.3-5 - rebuild for fixed 32-bit APR * Thu Aug 30 2007 Joe Orton 5.3-4 - clarify License tag mod_auth_pgsql-2.0.3-6 ---------------------- * Sun Sep 02 2007 Joe Orton 2.0.3-6 - rebuild for fixed APR mod_fcgid-2.1-6.fc8 ------------------- * Mon Sep 03 2007 Joe Orton 2.1-6 - rebuild for fixed 32-bit APR (#254241) mod_perl-2.0.3-13 ----------------- * Sun Sep 02 2007 Joe Orton 2.0.3-13 - rebuild for fixed 32-bit APR mod_python-3.3.1-5 ------------------ * Sun Sep 02 2007 Joe Orton 3.3.1-5 - rebuild for fixed 32-bit APR php-5.2.3-9 ----------- * Sun Sep 02 2007 Joe Orton 5.2.3-9 - rebuild for fixed APR pygsl-0.9.1-5.fc8 ----------------- * Thu Aug 30 2007 Jos?? Matos - 0.9.1-5 - Fix typo in Requires for subpackage devel. rapidsvn-0.9.4-6.fc8 -------------------- * Mon Sep 03 2007 Joe Orton 0.9.4-6 - rebuild for fixed 32-bit APR subversion-1.4.4-7 ------------------ * Sun Sep 02 2007 Joe Orton 1.4.4-7 - rebuild for fixed 32-bit APR * Thu Aug 30 2007 Joe Orton 1.4.4-6 - clarify License tag; re-enable test suite * Thu Aug 23 2007 Joe Orton 1.4.4-5 - rebuild for neon 0.27 Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From lamont at gurulabs.com Wed Sep 5 11:01:24 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 5 Sep 2007 05:01:24 -0600 Subject: old_passwords=1 in /etc/my.cnf Message-ID: <20070905050124.3a83b47a@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm wondering just how many packages still in Fedora need MySQL 5.0.x to continue to support some things (and not others?) for MySQL 3.x clients. Are there any that have to use the old_passwords format, for example. If not, could we please have MySQL 5.x packages ship an /etc/my.cnf file with "old_passwords=0"? Currently (and for quite some time, now) it's had: # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG3oyE+YBsl9wN1AkRAod1AJ4uoZPPClLHUMmKQL9yJBHC2p1M7ACfQ6hS hXfvRUYSM+c7G0WtgIhRY4g= =WzLx -----END PGP SIGNATURE----- From k.georgiou at imperial.ac.uk Wed Sep 5 11:14:31 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Wed, 5 Sep 2007 12:14:31 +0100 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <20070903135335.4172fcd8@lain.camperquake.de> References: <46C9BF64.9040103@hi.is> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <200709010825.35407.sgrubb@redhat.com> <20070901153242.GB16761@wolff.to> <20070903135335.4172fcd8@lain.camperquake.de> Message-ID: <20070905111431.GA21178@imperial.ac.uk> On Mon, Sep 03, 2007 at 01:53:35PM +0200, Ralf Ertzinger wrote: > On Sat, 1 Sep 2007 10:32:42 -0500, Bruno Wolff III wrote > > > For the disk drive part of this, it already exists. smartd does self > > tests on disks and logs the messages. These messages get reported by > > logwatch in an email message once a day. > > It would be nicer if smartd could call out to the notify daemon to make > a window appear on the users desktop. > > Users do not read logwatch reports, the usually do not even get them. Not that for many setups the person in front of the computer does not have a root password and would prefer not to get spammed with messages about things he can do nothing about (even if he did care). For the record smartd does send emails right away if it detects something wrong with the disk. Cheers, Kostas Georgiou From jkeating at redhat.com Wed Sep 5 11:08:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Sep 2007 07:08:05 -0400 Subject: Can't even rebuild ocaml-labgl In-Reply-To: <46DE6D72.4090002@redhat.com> References: <46DE6D72.4090002@redhat.com> Message-ID: <20070905070805.018021ad@ender> On Wed, 05 Sep 2007 09:48:50 +0100 "Richard W.M. Jones" wrote: > http://koji.fedoraproject.org/koji/taskinfo?taskID=147396 > http://koji.fedoraproject.org/koji/getfile?taskID=147398&name=root.log > > This is plain weird. It seems to me that someone could create a > package with a bogus "Provides: glibc" which was otherwise > uninstallable and bring the whole distribution to a halt. Is there > not a way to say "I do _not_ want this package, whatever that package > may claim about its provides"? I think what might be best here is to just untag the improperly built package, and replacing it with an older version. Can you send mail to 'rel-eng at fedoraproject.org' with what build needs to "go away" and which build should take it's place? It's just a simple case of buildroot maintenance. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 11:30:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 13:30:03 +0200 Subject: Conflicting Provides - Re: Can't even rebuild ocaml-labgl In-Reply-To: <12712.192.54.193.51.1188984338.squirrel@rousalka.dyndns.org> References: <46DE6D72.4090002@redhat.com> <20070905112109.26719f3d.mschwendt.tmp0701.nospam@arcor.de> <12712.192.54.193.51.1188984338.squirrel@rousalka.dyndns.org> Message-ID: <20070905133003.ef5f75bb.mschwendt.tmp0701.nospam@arcor.de> On Wed, 5 Sep 2007 11:25:38 +0200 (CEST), Nicolas Mailhot wrote: > > Le Mer 5 septembre 2007 11:21, Michael Schwendt a ?crit : > > > And yes, one can break the buildroot with such Provides as you > > mention. > > And the problem will be identified instead of being hidden behind a > silent workaround Don't understand you here. For ocaml-lablgl certainly a clean work-around would be to replace it with a dummy update temporarily, so subsequent build jobs don't fail due to broken deps. Then a build of a new ocaml-lablgl update would not fail either. Staying at the topic, does anybody have a quick clue where these Provides: python Provides: ... Provides: perl Provides: gpg come from? https://bugzilla.redhat.com/278181 From rjones at redhat.com Wed Sep 5 11:32:23 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 05 Sep 2007 12:32:23 +0100 Subject: Can't even rebuild ocaml-labgl In-Reply-To: <20070905070805.018021ad@ender> References: <46DE6D72.4090002@redhat.com> <20070905070805.018021ad@ender> Message-ID: <46DE93C7.4010103@redhat.com> Jesse Keating wrote: > On Wed, 05 Sep 2007 09:48:50 +0100 > "Richard W.M. Jones" wrote: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=147396 >> http://koji.fedoraproject.org/koji/getfile?taskID=147398&name=root.log >> >> This is plain weird. It seems to me that someone could create a >> package with a bogus "Provides: glibc" which was otherwise >> uninstallable and bring the whole distribution to a halt. Is there >> not a way to say "I do _not_ want this package, whatever that package >> may claim about its provides"? > > I think what might be best here is to just untag the improperly built > package, and replacing it with an older version. Can you send mail to > 'rel-eng at fedoraproject.org' with what build needs to "go away" and > which build should take it's place? It's just a simple case of > buildroot maintenance. I think the easiest thing is going to be if rel-eng could just delete ocaml-lablgl & ocaml-lablgl-devel from the buildroot (and any dependencies: possibly ocaml-lablgtk, freetennis if they are there too). The ocaml-lablgl package which is in there at the moment has a collection of bogus "Provides" which are actually provided by the base ocaml-runtime package. AIUI because strlen ("ocaml-labgl") < strlen ("ocaml-runtime"), the bogus package "wins". That will allow me to rebuild all the other ocaml packages, which have been failing for over a week now, and then we can look at why it was that ocaml-lablgl got the wrong "Provides". There must be a problem with the custom ocaml-find-provides.sh script that we use, but to be honest I've never seen it fail this way at any other time so I'm not sure what happened. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 11:51:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 13:51:02 +0200 Subject: Can't even rebuild ocaml-labgl In-Reply-To: <46DE93C7.4010103@redhat.com> References: <46DE6D72.4090002@redhat.com> <20070905070805.018021ad@ender> <46DE93C7.4010103@redhat.com> Message-ID: <20070905135102.d2227b5c.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Sep 2007 12:32:23 +0100, Richard W.M. Jones wrote: > The ocaml-lablgl package which is in there at the moment has a > collection of bogus "Provides" which are actually provided by the base > ocaml-runtime package. AIUI because strlen ("ocaml-labgl") < strlen > ("ocaml-runtime"), the bogus package "wins". > > That will allow me to rebuild all the other ocaml packages, which have > been failing for over a week now, and then we can look at why it was > that ocaml-lablgl got the wrong "Provides". There must be a problem > with the custom ocaml-find-provides.sh script that we use, but to be > honest I've never seen it fail this way at any other time so I'm not > sure what happened. For completeness, here's the output from one of my be-a-pain-for-packagers scripts: ocaml-camlp4 provides ocaml(Topdirs) EQ 0 2d07b01227af22b60aee18498198c35e ocaml-runtime provides ocaml(Topdirs) EQ 0 2d07b01227af22b60aee18498198c35e required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-ocamldoc provides ocaml(Ident) EQ 0 ba1acc56fc179d27bd55278cbc2abf40 ocaml-runtime provides ocaml(Ident) EQ 0 ba1acc56fc179d27bd55278cbc2abf40 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-ocamldoc provides ocaml(Consistbl) EQ 0 47f9cdffda6ba2de99c8e9f0c0c1b34d ocaml-runtime provides ocaml(Consistbl) EQ 0 47f9cdffda6ba2de99c8e9f0c0c1b34d required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-ocamldoc provides ocaml(Path) EQ 0 d8bc8e7163bac3a9a0a93f1cb07092d1 ocaml-runtime provides ocaml(Path) EQ 0 d8bc8e7163bac3a9a0a93f1cb07092d1 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-expat provides ocaml(Pervasives) EQ 0 8ba3d1faa24d659525c9025f41fd0c57 ocaml-runtime provides ocaml(Pervasives) EQ 0 8ba3d1faa24d659525c9025f41fd0c57 required by: ocaml - 3.10.0-4.fc8.i386 required by: ocaml-calendar - 1.10-6.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-curl - 0.2.1-3.fc8.i386 required by: ocaml-extlib - 1.5-5.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-libvirt - 0.3.2.4-1.fc8.i386 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 required by: ocaml-pcre - 5.11.4-6.fc8.i386 required by: ocaml-ssl - 0.4.2-3.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-x11 - 3.10.0-4.fc8.i386 required by: ocaml - 3.10.0-4.fc8.i386 required by: ocaml-calendar - 1.10-6.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-curl - 0.2.1-3.fc8.i386 required by: ocaml-extlib - 1.5-5.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-libvirt - 0.3.2.4-1.fc8.i386 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 required by: ocaml-pcre - 5.11.4-6.fc8.i386 required by: ocaml-ssl - 0.4.2-3.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-x11 - 3.10.0-4.fc8.i386 ocaml-camlp4 provides ocaml(Dynlink) EQ 0 69a6392e1ed51c60a9eb78a769019c50 ocaml-runtime provides ocaml(Dynlink) EQ 0 69a6392e1ed51c60a9eb78a769019c50 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 ocaml-camlp4 provides ocaml(Longident) EQ 0 46fb8aad4fb2c12a0f301b02d8139f07 ocaml-ocamldoc provides ocaml(Longident) EQ 0 46fb8aad4fb2c12a0f301b02d8139f07 ocaml-runtime provides ocaml(Longident) EQ 0 46fb8aad4fb2c12a0f301b02d8139f07 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 ocaml-ocamldoc provides ocaml(Primitive) EQ 0 43a2770aed8fbcc536ab39d717fe9a7b ocaml-runtime provides ocaml(Primitive) EQ 0 43a2770aed8fbcc536ab39d717fe9a7b required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-ocamldoc provides ocaml(Types) EQ 0 c2ef3369acfd38dafc8294786964051c ocaml-runtime provides ocaml(Types) EQ 0 c2ef3369acfd38dafc8294786964051c required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-camlp4 provides ocaml(Location) EQ 0 eed044ad1204a633caad97bdd9048f8c ocaml-ocamldoc provides ocaml(Location) EQ 0 eed044ad1204a633caad97bdd9048f8c ocaml-runtime provides ocaml(Location) EQ 0 eed044ad1204a633caad97bdd9048f8c required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 ocaml-camlp4 provides ocaml(Toploop) EQ 0 ead8879d71c4d5137fe5100fdd682a0b ocaml-runtime provides ocaml(Toploop) EQ 0 ead8879d71c4d5137fe5100fdd682a0b required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-runtime provides ocaml(Unix) EQ 0 9a46a8db115947409e54686ada118599 ocaml-ssl provides ocaml(Unix) EQ 0 9a46a8db115947409e54686ada118599 required by: ocaml - 3.10.0-4.fc8.i386 required by: ocaml-calendar - 1.10-6.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 required by: ocaml - 3.10.0-4.fc8.i386 required by: ocaml-calendar - 1.10-6.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-ocamldoc - 3.10.0-4.fc8.i386 ocaml-camlp4 provides ocaml(Warnings) EQ 0 abcb1589615da86f20f475b0ed3bbabc ocaml-ocamldoc provides ocaml(Warnings) EQ 0 abcb1589615da86f20f475b0ed3bbabc ocaml-runtime provides ocaml(Warnings) EQ 0 abcb1589615da86f20f475b0ed3bbabc required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 ocaml-labltk provides ocaml(StdLabels) EQ 0 afc5c70a95593ab1b2f875fcfe758714 ocaml-runtime provides ocaml(StdLabels) EQ 0 afc5c70a95593ab1b2f875fcfe758714 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 ocaml-ocamldoc provides ocaml(Parsetree) EQ 0 b59a1a6771867acd824bde52e6512b5c ocaml-runtime provides ocaml(Parsetree) EQ 0 b59a1a6771867acd824bde52e6512b5c required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-ulex - 1.0-3.fc8.i386 ocaml-ocamldoc provides ocaml(Env) EQ 0 6d0215253b3fde95601c34944cacb607 ocaml-runtime provides ocaml(Env) EQ 0 6d0215253b3fde95601c34944cacb607 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 required by: ocaml-camlp4 - 3.10.0-4.fc8.i386 required by: ocaml-findlib - 1.1.2pl1-10.fc8.i386 ocaml-camlp4 provides camlp4 EQ 0 3.10.0 4.fc8 ocaml-camlp4-devel provides camlp4 EQ 0 3.10.0 4.fc8 required by: orpie - 1.4.3-5.fc6.i386 required by: orpie - 1.4.3-5.fc6.i386 ocaml-expat provides ocaml(Callback) EQ 0 e5ca1fb5990fac2b7b17cbb1712cffe2 ocaml-runtime provides ocaml(Callback) EQ 0 e5ca1fb5990fac2b7b17cbb1712cffe2 required by: ocaml-curl - 0.2.1-3.fc8.i386 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-libvirt - 0.3.2.4-1.fc8.i386 required by: ocaml-pcre - 5.11.4-6.fc8.i386 required by: ocaml-ssl - 0.4.2-3.fc8.i386 required by: ocaml-curl - 0.2.1-3.fc8.i386 required by: ocaml-lablgl - 1.02-12.fc8.i386 required by: ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 required by: ocaml-labltk - 3.10.0-4.fc8.i386 required by: ocaml-libvirt - 0.3.2.4-1.fc8.i386 required by: ocaml-pcre - 5.11.4-6.fc8.i386 required by: ocaml-ssl - 0.4.2-3.fc8.i386 Helpful? ;-) From rdieter at math.unl.edu Wed Sep 5 11:46:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Sep 2007 06:46:44 -0500 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 References: <20070904231315.18546.7539@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > > andreas.bierfert AT lowlatency.de > koffice-karbon - 1.6.2-3.fc7.i386 (19 days) > koffice-kivio - 1.6.2-3.fc7.i386 (19 days) > koffice-kspread - 1.6.2-3.fc7.i386 (19 days) > Broken packages in fedora-7-x86_64: > ... > koffice-karbon-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 > koffice-kivio-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 > koffice-kspread-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 Anyone have an idea where this one is coming from? koffice-1.6.3-9.fc7 is the latest build. One of the recent changes was to fix things so that these extraneous pkgs wouldn't get pulled into the multilib mix (ie, by inadvertantly providing things required by koffice-devel). -- Rex From mattdm at mattdm.org Wed Sep 5 11:48:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Sep 2007 07:48:02 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? Message-ID: <20070905114802.GA17653@jadzia.bu.edu> Although technically wireless SSIDs have to be alphanumeric, practically speaking other "asciibetic" characters work fine in MS Windows and MacOS. Therefore, people use them. In multiple places I frequent (like, say, my house), iwlist scan will show one or more SSIDs in the form of a URL, containing ":", ".", and "/" characters. In these locations, NetworkManager crashes on startup. Anyone else recognize this behavior? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kwizart at gmail.com Wed Sep 5 12:00:45 2007 From: kwizart at gmail.com (KH KH) Date: Wed, 5 Sep 2007 14:00:45 +0200 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <1188984530.12274.55.camel@wombat.tiptoe.de> References: <1188984530.12274.55.camel@wombat.tiptoe.de> Message-ID: 2007/9/5, Nils Philippsen : > Hi, > > during the review of the resynthesizer plugin for GIMP > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > package to be named "gimp-plugin-resynthesizer" rather than > "gimp-resynthesizer". Ewan brought up the point that there isn't really > a naming guideline for it, therefore I'd like to propose one: cinepaint should probably follow the same guideline if ever there is plugins... I've recently discovered that there is perl scripts to be used with gimp http://search.cpan.org/~sjburges/Gimp-2.0/Gimp.pm If ever someone want to package them, the guideline may need to cover the case... Nicolas (kwizart) From yabraham2 at gmail.com Wed Sep 5 12:11:43 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Wed, 5 Sep 2007 08:11:43 -0400 Subject: fedora background images and main menu icons gone In-Reply-To: <3170f42f0709042108w10ab1082i59d06c90b2e48ff5@mail.gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <3170f42f0709042108w10ab1082i59d06c90b2e48ff5@mail.gmail.com> Message-ID: <47324ed80709050511t5135274ek200553b4986b6a57@mail.gmail.com> On 9/5/07, Debarshi 'Rishi' Ray wrote: > > on rahawid, my beautiful high fly balloon backgrounds are gone. my > > main menu icons are gone to. yeah. I did `yum update` /yonas From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 12:20:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 14:20:35 +0200 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: References: <20070904231315.18546.7539@extras64.linux.duke.edu> Message-ID: <20070905142035.dbcbb00a.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Sep 2007 06:46:44 -0500, Rex Dieter wrote: > Fedora Extras repoclosure wrote: > > > Summary of broken packages (by owner): > > > > andreas.bierfert AT lowlatency.de > > koffice-karbon - 1.6.2-3.fc7.i386 (19 days) > > koffice-kivio - 1.6.2-3.fc7.i386 (19 days) > > koffice-kspread - 1.6.2-3.fc7.i386 (19 days) > > Broken packages in fedora-7-x86_64: > > ... > > koffice-karbon-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 > > koffice-kivio-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 > > koffice-kspread-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 > > Anyone have an idea where this one is coming from? koffice-1.6.3-9.fc7 is > the latest build. One of the recent changes was to fix things so that > these extraneous pkgs wouldn't get pulled into the multilib mix (ie, by > inadvertantly providing things required by koffice-devel). It is a broken multi-lib dependency. In repository "fedora-7-x86_64" (i.e. the "Everything" repo for x86_64) there are three i386 koffice-foo packages which require something that isn't available in the combined set of repositories for F7, F7 Updates and F7 Test Updates. koffice-core.i386 with version-release 1.6.2-3.fc7 is not seen anymore in these x86_64 metadata. You cannot remove old multi-lib packages from the repos (unless rel-eng supports doing that on request). You can only upgrade packages with proper dependencies. Most likely the koffice-1.6.3-9.fc7 update you mention upgrades the koffice-core NEVR to 1.6.3-9.fc7, and no updates for the three i386 packages or the new koffice-core have been copied into the x86_64. From P at draigBrady.com Wed Sep 5 12:36:33 2007 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 5 Sep 2007 13:36:33 +0100 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905114802.GA17653@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> Message-ID: <46DEA2D1.80506@draigBrady.com> Matthew Miller wrote: > Although technically wireless SSIDs have to be alphanumeric, practically > speaking other "asciibetic" characters work fine in MS Windows and MacOS. > Therefore, people use them. > > In multiple places I frequent (like, say, my house), iwlist scan will show > one or more SSIDs in the form of a URL, containing ":", ".", and > "/" characters. In these locations, NetworkManager crashes on startup. > > > Anyone else recognize this behavior? I had this happen once while travelling on a train. The Network manager applet crashed. I could give you details if I knew where bug buddy stores it's reports. P?draig. From rdieter at math.unl.edu Wed Sep 5 12:40:52 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Sep 2007 07:40:52 -0500 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 References: <20070904231315.18546.7539@extras64.linux.duke.edu> <20070905142035.dbcbb00a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > You cannot remove old multi-lib packages from the repos (unless > rel-eng supports doing that on request). You can only upgrade packages > with proper dependencies. > > Most likely the koffice-1.6.3-9.fc7 update you mention upgrades the > koffice-core NEVR to 1.6.3-9.fc7, and no updates for the three i386 > packages or the new koffice-core have been copied into the x86_64. Once a (sub)package is pulled into multilib, it stays forever? eww. -- Rex From ssorce at redhat.com Wed Sep 5 13:04:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Sep 2007 09:04:22 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905114802.GA17653@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> Message-ID: <1188997462.3329.23.camel@localhost.localdomain> On Wed, 2007-09-05 at 07:48 -0400, Matthew Miller wrote: > Although technically wireless SSIDs have to be alphanumeric, practically > speaking other "asciibetic" characters work fine in MS Windows and MacOS. > Therefore, people use them. > > In multiple places I frequent (like, say, my house), iwlist scan will show > one or more SSIDs in the form of a URL, containing ":", ".", and > "/" characters. In these locations, NetworkManager crashes on startup. > > > Anyone else recognize this behavior? I always had a '.' in my home SSID and never had a problem (FC6/F7/Ubuntu) Simo. From pp at ee.oulu.fi Wed Sep 5 13:13:29 2007 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 5 Sep 2007 16:13:29 +0300 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905114802.GA17653@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> Message-ID: <20070905131329.GA6375@ee.oulu.fi> On Wed, Sep 05, 2007 at 07:48:02AM -0400, Matthew Miller wrote: > Although technically wireless SSIDs have to be alphanumeric, practically > speaking other "asciibetic" characters work fine in MS Windows and MacOS. > Therefore, people use them. Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug and should be fixed (Showing unprintable chars using escape codes to the user etc.) -- Pekka Pietikainen From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 14:10:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 16:10:30 +0200 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: References: <20070904231315.18546.7539@extras64.linux.duke.edu> <20070905142035.dbcbb00a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070905161030.8dd1cd63.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Sep 2007 07:40:52 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > You cannot remove old multi-lib packages from the repos (unless > > rel-eng supports doing that on request). You can only upgrade packages > > with proper dependencies. > > > > Most likely the koffice-1.6.3-9.fc7 update you mention upgrades the > > koffice-core NEVR to 1.6.3-9.fc7, and no updates for the three i386 > > packages or the new koffice-core have been copied into the x86_64. > > Once a (sub)package is pulled into multilib, it stays forever? eww. > > -- Rex > > Yes, "eww" for ping-pong updates. This week we release firefox.i386 for x86_64, next week we take it away again. You'd like packages in the [fedora-updates] repository delete packages in the [fedora] repository? And the user must clean up the already installed i386 orphans? From mattdm at mattdm.org Wed Sep 5 14:36:29 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Sep 2007 10:36:29 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905131329.GA6375@ee.oulu.fi> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> Message-ID: <20070905143629.GA31388@jadzia.bu.edu> On Wed, Sep 05, 2007 at 04:13:29PM +0300, Pekka Pietikainen wrote: > Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't > have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug > and should be fixed (Showing unprintable chars using escape codes > to the user etc.) It's not even unprintable characters -- just punctuation. I'm not 100% sure this is the problem, but it seems highly likely given that the two places it reliably crashes are the two places iwlist scan shows url-formatted ssids. And yes, it's certainly a bug -- data literally *floating out there in the air* should not crash any program. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Sep 5 14:37:52 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Sep 2007 10:37:52 -0400 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: References: <20070904231315.18546.7539@extras64.linux.duke.edu> <20070905142035.dbcbb00a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070905143752.GB31388@jadzia.bu.edu> On Wed, Sep 05, 2007 at 07:40:52AM -0500, Rex Dieter wrote: > Once a (sub)package is pulled into multilib, it stays forever? eww. There's no way to do cross-architecture obsoletes in RPM. So there's no way to clean them up (except via a separate program or yum plugin). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Wed Sep 5 15:21:14 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 09:21:14 -0600 Subject: Services automaticly change firewall rules to open access to themselfs. In-Reply-To: <42825.192.54.193.51.1188984631.squirrel@rousalka.dyndns.org> References: <1187628864.3382.27.camel@localhost.localdomain> <16de708d0708201033n1268bd8dr516c38cb590a6419@mail.gmail.com> <1188568361.27611.7.camel@home.alexander.bostrom.net> <16de708d0708311107y268f14eeq8b18dcb40b85b538@mail.gmail.com> <1188635620.16306.97.camel@home.alexander.bostrom.net> <16de708d0709010228g15d68ee3s779af4cf5dadf9e9@mail.gmail.com> <20070901152942.GA16761@wolff.to> <16de708d0709041224t29d32129ufd52d5106bb393eb@mail.gmail.com> <6EC766F7-93AC-4C62-B7A1-F89C6133CF38@dev.intechnology.co.uk> <42825.192.54.193.51.1188984631.squirrel@rousalka.dyndns.org> Message-ID: <1189005674.1641.12.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 11:30 +0200, Nicolas Mailhot wrote: > In an handwaved perfect word, service-firewall-rules would display a > graph of the current firewall network ruleset (showing the packet flow > through blocks of rules), and services would just dump new blocks in > this graph that'd be grayed out till activated by the admin. > > This is something like a SoC project though. What's Fedora's stance on firewall / iptables management, anyway. Specifically with regards to other "iptables applications"? So far, the only way I see that external apps can co-exist with s-c-s is by using the "Custom Rules File" which simply appends rules to the end of the rules generated by s-c-s. I have two applications right now (one to limit DROP successive ssh accesses and another to DROP access from spam sources configured dynamically) and the use of the Custom Rules File is insufficient for the way it works (some rules need to be inserted at an arbitrary position relative to the rules generated by s-c-s and a regeneration of the integrated /etc/sysconfig/iptables file is needed whenever dynamic changes are made). How does Fedora intend to handle firewall management requests from external apps? Will it export some kind of IPC API? Or is Custom Rules File finally it? -- Richi Plana From myfedora at richip.dhs.org Wed Sep 5 15:26:56 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 09:26:56 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905131329.GA6375@ee.oulu.fi> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> Message-ID: <1189006016.1641.17.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 16:13 +0300, Pekka Pietikainen wrote: > Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't > have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug > and should be fixed (Showing unprintable chars using escape codes > to the user etc.) Shouldn't those octet character strings be converted to Unicode strings, anyway? I thought that Gtk (via Pango) had displaying international character down pat. I remember seeing unprintable characters in the SSID field once (or was it the network name field? I forget. I thought it was a bug). I think it was U+0000 so that really doesn't tell me whether a proper 8-bit ASCII->Unicode (UTF-8?) conversion was made. -- Richi Plana From billcrawford1970 at gmail.com Wed Sep 5 15:58:37 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 5 Sep 2007 16:58:37 +0100 Subject: Goal: Increased Modularity? In-Reply-To: <20070904165703.GB30334@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> Message-ID: <544eb990709050858k2de1aa27wc1fda51be0f2a076@mail.gmail.com> On 04/09/07, Bill Nottingham wrote: > > Why is it that so > > many packages can't stand alone without libvorbis? I know that some of > > the packages NEED libvorbis, but for many, shouldn't it be optional and > > something that isn't required to be compiled against (think dlopen(3) > > instead of ld(1)) like gstreamer-plugins-* (which all seem to require > > libvorbis)? > > dlopen will cause you to break at runtime instead of buildtime if > ABI changes - that's not good. Eh? You have a plugin that's linked to libvorbis, and then load *that* at runtime; and you can rebuild the plugin independently of the main application if the libvorbis API or ABI change. The point is to make the need for (libvorbis is probably not the best example) the plugin optional. The plugin has all the right dependencies so it depends on the correct soname etc etc. There is a good use case, and that was mentioned further down: pulling in all the gstreamer-plugins packages gets me a shedload of dependencies for various sound + video libraries that I never, ever use, and that in combination with all the work-related stuff I have on my machine here pushed me over the limit for prelinking everything (prelink -av reported being unable to find an address slot for something). Before everyone chimes in with "use -m" ... that kinda makes prelinking pointless when a lot of libs are plugins that are loaded dynamically, because prelink can't tell when they're used in the same application based on the dependencies between the binaries and libraries ... From lesmikesell at gmail.com Wed Sep 5 16:12:47 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 11:12:47 -0500 Subject: Goal: Increased Modularity? In-Reply-To: References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> Message-ID: <46DED57F.7080607@gmail.com> Colin Walters wrote: > > Has anyone considered a system that 'makes sense' for multiuser > operation where different users want different alternative targets at > once - or the same user wants alternative JVMs for different > applications at the same time? > > > Java has long supported this via JAVA_HOME and the like, what else do > you want? I want to know the correct JAVA_HOME and PATH settings for all the possible JVMs when they are installed as alternatives-conforming RPM packages but are not the system default. Is this documented somewhere? -- Les Mikesell lesmikesell at gmail.com From bpepple at fedoraproject.org Wed Sep 5 16:11:43 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 12:11:43 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting Message-ID: <1189008703.2702.2.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 /topic FESCO-Meeting -- Misc -- Automatic pushing of updates after 14 days? - nirik /topic FESCO-Meeting -- MISC -- Update on packages missing from buildroot - f13 /topic Status-Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy /topic Status-Update: FESCo Proposal Template - f13 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From myfedora at richip.dhs.org Wed Sep 5 16:23:33 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 10:23:33 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DED57F.7080607@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> Message-ID: <1189009413.1641.22.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 11:12 -0500, Les Mikesell wrote: > I want to know the correct JAVA_HOME and PATH settings for all the > possible JVMs when they are installed as alternatives-conforming RPM > packages but are not the system default. Is this documented somewhere? It seems the current convention is to put the JAVA packages under /usr/lib/jvm/(java|jre)--- with certain packages going to /usr/lib/jvm-exports/ and /usr/lib/jvm-private/ Who's convention is this, anyway? And what's it called? It seems Fedora and jpackage both honor this convention (and alternatives uses it. Or maybe it's the other way around ... this convention uses was designed around alternatives). Just my guesses. -- Richi Plana From lesmikesell at gmail.com Wed Sep 5 16:23:54 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 11:23:54 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <20070904165703.GB30334@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> Message-ID: <46DED81A.9030004@gmail.com> Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: >> For instance, if I desired to come up with a spin that doesn't have >> Sendmail, why must I give up fetchmail, mutt or tor? > > Because they *require* a MTA to deliver/send the mail, at least in their > default configurations > >> Why is it that so >> many packages can't stand alone without libvorbis? I know that some of >> the packages NEED libvorbis, but for many, shouldn't it be optional and >> something that isn't required to be compiled against (think dlopen(3) >> instead of ld(1)) like gstreamer-plugins-* (which all seem to require >> libvorbis)? > > dlopen will cause you to break at runtime instead of buildtime if > ABI changes - that's not good. You should expect things to break when you change an interface - pretty much by definition. If it hurts, don't do it. -- Les Mikesell lesmikesell at gmail.com From ville.skytta at iki.fi Wed Sep 5 16:31:17 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 5 Sep 2007 19:31:17 +0300 Subject: Goal: Increased Modularity? In-Reply-To: <1189009413.1641.22.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> Message-ID: <200709051931.17830.ville.skytta@iki.fi> On Wednesday 05 September 2007, Richi Plana wrote: > > It seems the current convention is to put the JAVA packages > under /usr/lib/jvm/(java|jre)--- with > certain packages going to /usr/lib/jvm-exports/ > and /usr/lib/jvm-private/ > > Who's convention is this, anyway? It originates from JPackage. From bruno at wolff.to Wed Sep 5 14:19:57 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 5 Sep 2007 09:19:57 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1188926548.12969.64.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> Message-ID: <20070905141957.GA17428@wolff.to> On Tue, Sep 04, 2007 at 11:22:28 -0600, Richi Plana wrote: > > Besides, you said it requires an MTA. Would an effort to add the ability > to detect the availability of /sbin/sendmail in the above-mentioned > packages and use it if available or speak SMTP over port 25 if not be > desirable? Packages like evolution and thunderbird do that and therefore > don't "Require: sendmail". Mutt isn't going to be able to use smtp. You really do want something local to store messages in case there is a temporary problem in sending the mail out. However, you could conceivably use mutt just to read email from a remote imap server. That is probably not a likely use case though. From icon at fedoraproject.org Wed Sep 5 16:37:16 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 5 Sep 2007 12:37:16 -0400 Subject: Daemons as user "nobody" Message-ID: Hi, all: I recall there being something about running daemons as user "nobody." Is that still a policy? Cursory search in the wiki revealed nothing, but searching for "user nobody" is near-futile. :) Don't we normally create daemon-specific users? Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From myfedora at richip.dhs.org Wed Sep 5 16:37:24 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 10:37:24 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <604aa7910709041315x7b3861c9ld865fde0b477b12c@mail.gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <1188935077.12969.124.camel@localhost6.localdomain6> <604aa7910709041315x7b3861c9ld865fde0b477b12c@mail.gmail.com> Message-ID: <1189010244.1641.34.camel@localhost6.localdomain6> Speaking of Modularization, The FESCo meeting announcement (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00373.html) mentions the proposal to pack up all kmods into the kernel package (http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal) ... if I understand that correctly. While it solves the problem of having things "just work" when hardware is introduced, it's a pale surrender to the arduous task of breaking down the kernel into modules and detecting the hardware and pulling in the appropriate kmod package. Here's where many people come clamoring for a thinner, more optimized distribution. Would it be possible to come up with a thinner spin of Fedora if all the kernel modules are in "kernel"? How do smaller devices with limited storage use Fedora, anyway? I know the OLPC XO device is based off of Fedora. Does it have all the kernel mods installed, as well? I know people like Axel Thimm are doing their best to come up with elegant ways to package kernel modules and fix the versioning issues associated with kernel updates. He's coming up with what he calls kmdl2. Wouldn't Fedora be interested in his efforts? It would really be nice if Fedora blessed a system for handling kernel modules because the external repos seem to have their own (livna uses kmod, atrpms use kmdl, etc.) and it confuses me. (but I could just be the minority) -- Richi Plana From myfedora at richip.dhs.org Wed Sep 5 16:42:03 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 10:42:03 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <200709051931.17830.ville.skytta@iki.fi> References: <1188923882.12969.36.camel@localhost6.localdomain6> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <200709051931.17830.ville.skytta@iki.fi> Message-ID: <1189010523.1641.39.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 19:31 +0300, Ville Skytt? wrote: > It originates from JPackage. I'm just glad there is one. And that Fedora has officially (or unofficially) adopted it. It's sort of like the Linux Standards Base of Java on Linux, ;). If someone wanted to make proposals to include per-user configurations of JVMs (possibly through a set of utilities to set JAVA_HOME and PATH), I take it JPackage is the place to do this (the upstream) and that Fedora will follow suit? -- Richi Plana From otaylor at redhat.com Wed Sep 5 16:44:19 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 5 Sep 2007 12:44:19 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189006016.1641.17.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> Message-ID: <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> On 9/5/07, Richi Plana wrote: > On Wed, 2007-09-05 at 16:13 +0300, Pekka Pietikainen wrote: > > Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't > > have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug > > and should be fixed (Showing unprintable chars using escape codes > > to the user etc.) > > Shouldn't those octet character strings be converted to Unicode strings, > anyway? I thought that Gtk (via Pango) had displaying international > character down pat. In order to "convert octet character strings" into Unicode and display them, you have to know what encoding the strings are in. Bytes are just bytes until you have an encoding. - Owen From nicolas.mailhot at laposte.net Wed Sep 5 16:46:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Sep 2007 18:46:40 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <1189009413.1641.22.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> Message-ID: <1189010800.32292.19.camel@rousalka.dyndns.org> Le mercredi 05 septembre 2007 ? 10:23 -0600, Richi Plana a ?crit : > On Wed, 2007-09-05 at 11:12 -0500, Les Mikesell wrote: > > I want to know the correct JAVA_HOME and PATH settings for all the > > possible JVMs when they are installed as alternatives-conforming RPM > > packages but are not the system default. Is this documented somewhere? > > It seems the current convention is to put the JAVA packages > under /usr/lib/jvm/(java|jre)--- with > certain packages going to /usr/lib/jvm-exports/ > and /usr/lib/jvm-private/ > > Who's convention is this, anyway? Originally, mine when I was active @jpp and was packaging jvms > And what's it called? You know, you're the first person to ask this question I know of:) The layout and its intent is described in the jpackage-1.5-policy document shipped with jpackage utils. IIRC I wrote this file a week after baking the layout and the associated shell scripts, so that would date its definition around March 10, 2003. I never thought of giving it a name. Today that would be JPackage conventions for most people. > It seems Fedora > and jpackage both honor this convention (and alternatives uses it. Or > maybe it's the other way around ... this convention uses was designed > around alternatives). Fedora Java packaging as it's known today is a JPackage fork (periodically rebased). The Red Hat Java group originally started from its own package repository IIRC, but struggled to package the Java world and decided later to use a JPackage base as its repo was more complete. -- 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 myfedora at richip.dhs.org Wed Sep 5 16:50:13 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 10:50:13 -0600 Subject: Daemons as user "nobody" In-Reply-To: References: Message-ID: <1189011013.1641.48.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 12:37 -0400, Konstantin Ryabitsev wrote: > I recall there being something about running daemons as user "nobody." > Is that still a policy? Cursory search in the wiki revealed nothing, > but searching for "user nobody" is near-futile. :) > > Don't we normally create daemon-specific users? On my system, nobody isn't running any daemon process, :). *snicker* Seriously, though, it seems that most Fedora packages have daemons running with their own uid (apache, tomcat5, rpc, rpcuser, dovecot, asterisk, smmsp, xfs, avahi, toranon, 68 ... 68?!? oh wait .. that's hald, named and of course, the desktop user for various desktop daemons). I've so many processes living in my system. I've grown so close to them, they're almost like family, ;). Whether it's in a policy, i don't know. Actually, there doesn't seem to be a lot of policies showing on the wiki. It's probably on the TODO list. I was just asking about policies myself in a thread on Modularization. -- Richi From myfedora at richip.dhs.org Wed Sep 5 16:55:20 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 10:55:20 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> Message-ID: <1189011320.1641.52.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote: > > Shouldn't those octet character strings be converted to Unicode strings, > > anyway? I thought that Gtk (via Pango) had displaying international > > character down pat. > > In order to "convert octet character strings" into Unicode and display > them, you have to know what encoding the strings are in. Bytes are > just bytes until you have an encoding. I was under the assumption they were 8-bit ASCII strings. Anyway, it's a NetworkManager issue. They would know what the drivers are returning, right? -- Richi Plana From dcbw at redhat.com Wed Sep 5 16:59:40 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Sep 2007 12:59:40 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189011320.1641.52.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> Message-ID: <1189011580.24933.4.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-05 at 10:55 -0600, Richi Plana wrote: > On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote: > > > Shouldn't those octet character strings be converted to Unicode strings, > > > anyway? I thought that Gtk (via Pango) had displaying international > > > character down pat. > > > > In order to "convert octet character strings" into Unicode and display > > them, you have to know what encoding the strings are in. Bytes are > > just bytes until you have an encoding. > > I was under the assumption they were 8-bit ASCII strings. Anyway, it's a > NetworkManager issue. They would know what the drivers are returning, > right? Right; it is an NM issue. If NM crashes or misbehaves with a weird SSID, we need to fix it. As specified in the 802.11 standard, the ESSID is a 32-byte byte array, there are no restrictions made as to what content that 32-bytes may contain. It is up to the program to attempt to coerce that value into something to present to the user. Dan From nicolas.mailhot at laposte.net Wed Sep 5 16:59:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Sep 2007 18:59:29 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <1189010523.1641.39.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <200709051931.17830.ville.skytta@iki.fi> <1189010523.1641.39.camel@localhost6.localdomain6> Message-ID: <1189011569.32292.24.camel@rousalka.dyndns.org> Le mercredi 05 septembre 2007 ? 10:42 -0600, Richi Plana a ?crit : > On Wed, 2007-09-05 at 19:31 +0300, Ville Skytt? wrote: > > It originates from JPackage. > > I'm just glad there is one. And that Fedora has officially (or > unofficially) adopted it. It's sort of like the Linux Standards Base of > Java on Linux, ;). > > If someone wanted to make proposals to include per-user configurations > of JVMs (possibly through a set of utilities to set JAVA_HOME and PATH), > I take it JPackage is the place to do this (the upstream) and that > Fedora will follow suit? Any script or convention you get adopted at JPackage and included in jpackage-utils will percolate to Fedora and many other distributions besides. If you browse the jpackage-discuss list archive you may find interesting exchanges on the subject (including master plans never implemented, but that can serve as inspiration) -- 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 dcbw at redhat.com Wed Sep 5 17:00:44 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Sep 2007 13:00:44 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905143629.GA31388@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <20070905143629.GA31388@jadzia.bu.edu> Message-ID: <1189011644.24933.6.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-05 at 10:36 -0400, Matthew Miller wrote: > On Wed, Sep 05, 2007 at 04:13:29PM +0300, Pekka Pietikainen wrote: > > Actually 802.11 says SSID's are octet strings of 1-32 bytes, doesn't > > have to be alphanumeric. If NM barfs on unprintable chars, then it's a bug > > and should be fixed (Showing unprintable chars using escape codes > > to the user etc.) > > It's not even unprintable characters -- just punctuation. > > I'm not 100% sure this is the problem, but it seems highly likely given that > the two places it reliably crashes are the two places iwlist scan shows > url-formatted ssids. > > And yes, it's certainly a bug -- data literally *floating out there in the > air* should not crash any program. Definitely. Can you get a backtrace of where it's crashing? It should dump output to /var/log/messages, including a backtrace. If that doesn't work, maybe hooking up to it with gdb would help. Dan > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > From dcbw at redhat.com Wed Sep 5 17:01:45 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Sep 2007 13:01:45 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070905114802.GA17653@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> Message-ID: <1189011705.24933.8.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-05 at 07:48 -0400, Matthew Miller wrote: > Although technically wireless SSIDs have to be alphanumeric, practically > speaking other "asciibetic" characters work fine in MS Windows and MacOS. > Therefore, people use them. > > In multiple places I frequent (like, say, my house), iwlist scan will show > one or more SSIDs in the form of a URL, containing ":", ".", and > "/" characters. In these locations, NetworkManager crashes on startup. > > > Anyone else recognize this behavior? RPM versions, kernel version, wpa_supplicant version, and any changes you may have made to drivers or whatever could help. Also, was it NM, or the applet that died? Dan From jspaleta at gmail.com Wed Sep 5 17:01:46 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Sep 2007 09:01:46 -0800 Subject: fedora background images and main menu icons gone In-Reply-To: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> Message-ID: <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> On 9/4/07, yonas Abraham wrote: > on rahawid, my beautiful high fly balloon backgrounds are gone. my > main menu icons are gone to. I'm guessing this is a packaging bug. The old F7 thematic defaults were removed. But I don't think the new defaults were placed consistently back into the same locations in the filesystem. This is most likely a filable bug against fedora-logos. The default.jpg filelocation is missing in the latest fedora-logos package. rpm -q --changelog fedora-logos * Tue Aug 28 2007 M?ir?n Duffy - 7.92.0-1 - update the anaconda artwork - changed default backgrounds -jef From sundaram at fedoraproject.org Wed Sep 5 17:01:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 05 Sep 2007 22:31:04 +0530 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189008703.2702.2.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> Message-ID: <46DEE0D0.2070209@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: > http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 Is the alternative proposal using DKMS at http://fedoraproject.org/wiki/JefSpaleta/DKMSProposal being discussed too? > /topic Status-Update: Compat Policy > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy This proposal seems to allow the maintainer to veto any compatibility packages. Would FESCo retained the authority to override maintainer's wishes here? The rationale for limiting compatibility packages seem weak. Rahul From myfedora at richip.dhs.org Wed Sep 5 17:08:09 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 11:08:09 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <1189011569.32292.24.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <200709051931.17830.ville.skytta@iki.fi> <1189010523.1641.39.camel@localhost6.localdomain6> <1189011569.32292.24.camel@rousalka.dyndns.org> Message-ID: <1189012089.1641.60.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 18:59 +0200, Nicolas Mailhot wrote: > Any script or convention you get adopted at JPackage and included in > jpackage-utils will percolate to Fedora and many other distributions > besides. If you browse the jpackage-discuss list archive you may find > interesting exchanges on the subject (including master plans never > implemented, but that can serve as inspiration) As with most projects. There was this proposal once to integrate wikis and mailing list forums once (actually, it might have just gotten stuck in my head). You know how MediaWiki has this discussion tab per page? If that could be combined with a mailing list (web interface as well as mail interface), it might actually be a step in the direction of taking any good ideas and putting them in an edited, summarized and possibly resolved state on the wiki page sans the cruft. Thanks for the work on JPackage. -- Richi Plana From bpepple at fedoraproject.org Wed Sep 5 17:11:28 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 13:11:28 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DEE0D0.2070209@fedoraproject.org> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> Message-ID: <1189012288.2702.5.camel@kennedy> On Wed, 2007-09-05 at 22:31 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > /topic Status-Update: Compat Policy > > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > This proposal seems to allow the maintainer to veto any compatibility > packages. Would FESCo retained the authority to override maintainer's > wishes here? The rationale for limiting compatibility packages seem weak. I have this on the schedule to just to see what the status was on Jeremy's proposal. This has been discussed yet, or sent to the mailing lists. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From myfedora at richip.dhs.org Wed Sep 5 17:15:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 11:15:58 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189011580.24933.4.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> Message-ID: <1189012558.1641.69.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote: > Right; it is an NM issue. If NM crashes or misbehaves with a weird > SSID, we need to fix it. > > As specified in the 802.11 standard, the ESSID is a 32-byte byte array, > there are no restrictions made as to what content that 32-bytes may > contain. It is up to the program to attempt to coerce that value into > something to present to the user. Since no semantics has been proposed, then it stands to reason that one can just assume 1 byte = 1 character and a straight "byte value = Unicode value" conversion should be adopted, right? (No codepage conversions). Come to think of it, if they're just a generic 32-byte byte array, why even convert them to strings? They only make sense if they happen to contain alphanumeric and some symbolic characters (which isn't even a convention or restriction). Alright, maybe it's useful for displaying to humans when they just happen to be alphanumeric. Forget I asked. -- Richi Plana From a.badger at gmail.com Wed Sep 5 17:18:58 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 05 Sep 2007 10:18:58 -0700 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DEE0D0.2070209@fedoraproject.org> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> Message-ID: <46DEE502.1050009@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > Brian Pepple wrote: >> /topic Status-Update: Compat Policy >> http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > This proposal seems to allow the maintainer to veto any compatibility > packages. Would FESCo retained the authority to override maintainer's > wishes here? The rationale for limiting compatibility packages seem weak. > I also find this a bit too arbitrarily weighted in favor of the non-compat maintainer's preference. I would find it much better to have a list of extra criteria that are needed for a compat package to be accepted and the reasons for each criteria. This would be similar to how the Games SIG has additional Packaging Guidelines that are specific to games. (But in this case, the additional criteria would not necessarily be packaging related as it's coming from FESCo.) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3uUBX6yAic2E7kgRAlebAKCMj8k2/c44gnbdrjxdPH/WzSX7lACgjJ3w PkEbyZFB9yOQNefz7cy2JHQ= =3z8h -----END PGP SIGNATURE----- From lesmikesell at gmail.com Wed Sep 5 17:33:44 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 12:33:44 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189010800.32292.19.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> Message-ID: <46DEE878.4080006@gmail.com> Nicolas Mailhot wrote: >>> I want to know the correct JAVA_HOME and PATH settings for all the >>> possible JVMs when they are installed as alternatives-conforming RPM >>> packages but are not the system default. Is this documented somewhere? >> It seems the current convention is to put the JAVA packages >> under /usr/lib/jvm/(java|jre)--- with >> certain packages going to /usr/lib/jvm-exports/ >> and /usr/lib/jvm-private/ >> >> Who's convention is this, anyway? > > Originally, mine when I was active @jpp and was packaging jvms > >> And what's it called? > > You know, you're the first person to ask this question I know of:) > > The layout and its intent is described in the jpackage-1.5-policy > document shipped with jpackage utils. IIRC I wrote this file a week > after baking the layout and the associated shell scripts, so that would > date its definition around March 10, 2003. > > I never thought of giving it a name. Today that would be JPackage > conventions for most people. So, where do I find the answer to the question above regarding the correct JAVA_HOME and PATH to use a JVM that is not the system default? How is the split exports/private directory supposed to relate to that? >> It seems Fedora >> and jpackage both honor this convention (and alternatives uses it. Or >> maybe it's the other way around ... this convention uses was designed >> around alternatives). > > Fedora Java packaging as it's known today is a JPackage fork > (periodically rebased). The Red Hat Java group originally started from > its own package repository IIRC, but struggled to package the Java world > and decided later to use a JPackage base as its repo was more complete. And what's the current situation with this now that Fedora and RHEL5 include some stuff that looks jpackage'd but isn't? How do you control, for example, which tomcat version you install? -- Les Mikesell lesmikesell at gmail.com From myfedora at richip.dhs.org Wed Sep 5 17:44:39 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 11:44:39 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DEE878.4080006@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> Message-ID: <1189014279.1641.91.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 12:33 -0500, Les Mikesell wrote: > So, where do I find the answer to the question above regarding the > correct JAVA_HOME and PATH to use a JVM that is not the system default? > How is the split exports/private directory supposed to relate to that? On my system where I have java-1.5.0-sun-1.5.0.12-1jpp.x86_64 and java-1.5.0-sun-devel-1.5.0.12-1jpp.x86_64 installed, I use JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.12 # and PATH=$JAVA_HOME/bin:$PATH which works regardless of what alternatives has set up. If you use /usr/bin/java, though, I assume it overwrites JAVA_HOME. But if you just the executable loader find java, then it should use the above-mentioned properly. At least I haven't had any issues. > And what's the current situation with this now that Fedora and RHEL5 > include some stuff that looks jpackage'd but isn't? How do you > control, for example, which tomcat version you install? As far as I can tell, the init scripts that come with tomcat5 for Fedora Core 6 (the only ones I've tested so far) uses $(JAVA_HOME)/bin/java ... that's the JAVA_HOME set for the tomcat5 user. It's CATALINA_HOME is set to /usr/share/tomcat5/ and it configured (again for the Fedora package) via /etc/tomcat5/tomcat5.conf -- Richi Plana From caillon at redhat.com Wed Sep 5 17:46:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 05 Sep 2007 13:46:56 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189008703.2702.2.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> Message-ID: <46DEEB90.20602@redhat.com> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: > http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 > > /topic FESCO-Meeting -- Misc -- Automatic pushing of updates after 14 > days? - nirik > > /topic FESCO-Meeting -- MISC -- Update on packages missing from > buildroot - f13 > > /topic Status-Update: Compat Policy > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > /topic Status-Update: FESCo Proposal Template - f13 > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. Several people were displeased at the removal of the Bluetooth Feature, and hadess has said he can appear at tomorrow's meeting to champion and explain why it is a dramatic improvement and we should be making lots of noise about it. From dcbw at redhat.com Wed Sep 5 17:49:47 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Sep 2007 13:49:47 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189012558.1641.69.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> Message-ID: <1189014587.24933.14.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-05 at 11:15 -0600, Richi Plana wrote: > On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote: > > Right; it is an NM issue. If NM crashes or misbehaves with a weird > > SSID, we need to fix it. > > > > As specified in the 802.11 standard, the ESSID is a 32-byte byte array, > > there are no restrictions made as to what content that 32-bytes may > > contain. It is up to the program to attempt to coerce that value into > > something to present to the user. > > Since no semantics has been proposed, then it stands to reason that one > can just assume 1 byte = 1 character and a straight "byte value = > Unicode value" conversion should be adopted, right? (No codepage > conversions). > > Come to think of it, if they're just a generic 32-byte byte array, why > even convert them to strings? They only make sense if they happen to > contain alphanumeric and some symbolic characters (which isn't even a > convention or restriction). Alright, maybe it's useful for displaying to > humans when they just happen to be alphanumeric. Forget I asked. Well, it's a really tricky problem. I'd personally do: try UTF-8 validation try validation from the encoding in LANG fall back to a lot of ? for unprintables For example, if I live in Shanghai, I should be able to make my AP SSID some native character like ?. However, if I live in Central Europoe and for some reason I use ISO 8859-15 (or whatever it is) I'd probably like my ? to show up. I believe NM should try at least a few ways of parsing the SSID (not too many) and just fall back to ? in the end. This is what it currently does, but apparently somewhat badly. Dan From tibbs at math.uh.edu Wed Sep 5 17:53:10 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Sep 2007 12:53:10 -0500 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189008703.2702.2.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> Message-ID: Note that due to a rare burst of actual pseudo-appreciation from my employer, I will be away at a staff appreciation luncheon during the meeting tomorrow and will almost certainly miss all of it. - J< From jwboyer at jdub.homelinux.org Wed Sep 5 17:59:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 5 Sep 2007 12:59:08 -0500 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DEEB90.20602@redhat.com> References: <1189008703.2702.2.camel@kennedy> <46DEEB90.20602@redhat.com> Message-ID: <20070905125908.57076137@weaponx.rchland.ibm.com> On Wed, 05 Sep 2007 13:46:56 -0400 Christopher Aillon wrote: > Brian Pepple wrote: > > Hi, > > > > Please find below the list of topics that are likely to come up in the > > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > > in #fedora-meeting on irc.freenode.org: > > > > /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: > > http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 > > > > /topic FESCO-Meeting -- Misc -- Automatic pushing of updates after 14 > > days? - nirik > > > > /topic FESCO-Meeting -- MISC -- Update on packages missing from > > buildroot - f13 > > > > /topic Status-Update: Compat Policy > > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > > > /topic Status-Update: FESCo Proposal Template - f13 > > > > /topic FESCo meeting -- Free discussion around Fedora > > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > Several people were displeased at the removal of the Bluetooth Feature, > and hadess has said he can appear at tomorrow's meeting to champion and > explain why it is a dramatic improvement and we should be making lots of > noise about it. Sounds great... perhaps if they had updated the status on the feature page in the first place we wouldn't have dropped it. josh From myfedora at richip.dhs.org Wed Sep 5 18:00:46 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 12:00:46 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189014587.24933.14.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: <1189015246.1641.98.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 13:49 -0400, Dan Williams wrote: > try UTF-8 validation UTF-8 validation is easy, but it would've been easierhad they actually put in the BOM character, :). > try validation from the encoding in LANG Pretty slim chances that whoever configured the wireless network is using the same encoding as whoever configured LANG. > fall back to a lot of ? for unprintables Either that or use "byte value = unicode value" (ie. 0x01 = , 0x7F = , 0x80 = ?, 0xFF = ?, etc.) and let Pango render the characters (to at least differentiate the characters from each other and from the "?" character). > For example, if I live in Shanghai, I should be able to make my AP SSID > some native character like ?. However, if I live in Central Europoe > and for some reason I use ISO 8859-15 (or whatever it is) I'd probably > like my ? to show up. I believe NM should try at least a few ways of > parsing the SSID (not too many) and just fall back to ? in the end. > This is what it currently does, but apparently somewhat badly. Or go upstream and have IEEE settle it, :-p. -- Richi Plana From bpepple at fedoraproject.org Wed Sep 5 17:59:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 13:59:48 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DEEB90.20602@redhat.com> References: <1189008703.2702.2.camel@kennedy> <46DEEB90.20602@redhat.com> Message-ID: <1189015188.2702.10.camel@kennedy> On Wed, 2007-09-05 at 13:46 -0400, Christopher Aillon wrote: > > Several people were displeased at the removal of the Bluetooth Feature, > and hadess has said he can appear at tomorrow's meeting to champion and > explain why it is a dramatic improvement and we should be making lots of > noise about it. I'll add it to the schedule. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Wed Sep 5 18:27:13 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Sep 2007 18:27:13 +0000 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189014587.24933.14.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: <1189016833.3329.27.camel@localhost.localdomain> On Wed, 2007-09-05 at 13:49 -0400, Dan Williams wrote: > > try UTF-8 validation I'd try UCS-2/UCS-4/UTF-16 as well, Windows and Macs use those. Simo. From overholt at redhat.com Wed Sep 5 18:47:54 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 5 Sep 2007 14:47:54 -0400 Subject: Development SIG mailing list name suggestions? Message-ID: <20070905184754.GA16115@redhat.com> Hi, We'd like to have a mailing list to discuss issues pertaining to the Development SIG and the "Fedora: Developer Edition" spin. What should the list be called? fedora-developer ? fedora-develsig ? 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 otaylor at redhat.com Wed Sep 5 18:57:41 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 5 Sep 2007 14:57:41 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189011320.1641.52.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> Message-ID: <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> On 9/5/07, Richi Plana wrote: > On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote: > > > Shouldn't those octet character strings be converted to Unicode strings, > > > anyway? I thought that Gtk (via Pango) had displaying international > > > character down pat. > > > > In order to "convert octet character strings" into Unicode and display > > them, you have to know what encoding the strings are in. Bytes are > > just bytes until you have an encoding. > > I was under the assumption they were 8-bit ASCII strings. There's actually no 8-bit ASCII. People sometimes use that to mean Windows codepage 1252 (http://en.wikipedia.org/wiki/Windows_code_page). > Anyway, it's a NetworkManager issue. They would know what the drivers are returning, > right? The drivers may well just be returning whatever bytes were sent over the wire. Now, in any *sane* protocol, the protocol docs would define what encoding the bytes over the wire are in, but it took a very long time for people to realize this, so it wouldn't shock me if 802.11b doesn't specify. Then you'd basically have to do experiments with common access points to see how they encode things, then add appropriate heuristics to NetworkManager. - Owen From dcbw at redhat.com Wed Sep 5 19:06:06 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Sep 2007 15:06:06 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> Message-ID: <1189019166.24933.29.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-05 at 14:57 -0400, Owen Taylor wrote: > On 9/5/07, Richi Plana wrote: > > On Wed, 2007-09-05 at 12:44 -0400, Owen Taylor wrote: > > > > Shouldn't those octet character strings be converted to Unicode strings, > > > > anyway? I thought that Gtk (via Pango) had displaying international > > > > character down pat. > > > > > > In order to "convert octet character strings" into Unicode and display > > > them, you have to know what encoding the strings are in. Bytes are > > > just bytes until you have an encoding. > > > > I was under the assumption they were 8-bit ASCII strings. > > There's actually no 8-bit ASCII. People sometimes use that to mean > Windows codepage 1252 > (http://en.wikipedia.org/wiki/Windows_code_page). > > > Anyway, it's a NetworkManager issue. They would know what the drivers are returning, > > right? > > The drivers may well just be returning whatever bytes were sent over > the wire. Now, in any *sane* protocol, the protocol docs would define > what encoding the bytes over the wire are in, but it took a very long > time for people to realize this, so it wouldn't shock me if 802.11b > doesn't specify. Then you'd basically have to do experiments with > common access points to see how they encode things, then add > appropriate heuristics to NetworkManager. The drivers return a 32-byte array containing arbitrary values to NetworkManager, which is technically correct. It's up to NM and userspace to deal with this somehow. 802.11 specifies nothing about encoding or anything other than a max length of 32 bytes. Dan From notting at redhat.com Wed Sep 5 19:17:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Sep 2007 15:17:26 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <46DED81A.9030004@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> Message-ID: <20070905191726.GE13750@nostromo.devel.redhat.com> Les Mikesell (lesmikesell at gmail.com) said: >> dlopen will cause you to break at runtime instead of buildtime if >> ABI changes - that's not good. > > You should expect things to break when you change an interface - pretty > much by definition. If it hurts, don't do it. I was discussing a case where instead of linking against libvorbis, you dlopen() it - that's the sort of thing which is really much better to catch at buildtime. If you're dlopening the plugin that is itself linked against libvorbis (or whatever), that's better. Bill From ianburrell at gmail.com Wed Sep 5 19:27:33 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 5 Sep 2007 12:27:33 -0700 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189012558.1641.69.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> Message-ID: On 9/5/07, Richi Plana wrote: > On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote: > > Right; it is an NM issue. If NM crashes or misbehaves with a weird > > SSID, we need to fix it. > > > > As specified in the 802.11 standard, the ESSID is a 32-byte byte array, > > there are no restrictions made as to what content that 32-bytes may > > contain. It is up to the program to attempt to coerce that value into > > something to present to the user. > > Since no semantics has been proposed, then it stands to reason that one > can just assume 1 byte = 1 character and a straight "byte value = > Unicode value" conversion should be adopted, right? (No codepage > conversions). > That would be ISO-8859-1 encoding since Unicode < U+00FF is equal to ISO-8859-1. > Come to think of it, if they're just a generic 32-byte byte array, why > even convert them to strings? They only make sense if they happen to > contain alphanumeric and some symbolic characters (which isn't even a > convention or restriction). Alright, maybe it's useful for displaying to > humans when they just happen to be alphanumeric. Forget I asked. - Ian From nicolas.mailhot at laposte.net Wed Sep 5 19:29:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Sep 2007 21:29:45 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <46DEE878.4080006@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> Message-ID: <1189020585.3241.23.camel@rousalka.dyndns.org> Le mercredi 05 septembre 2007 ? 12:33 -0500, Les Mikesell a ?crit : > Nicolas Mailhot wrote: > > >>> I want to know the correct JAVA_HOME and PATH settings for all the > >>> possible JVMs when they are installed as alternatives-conforming RPM > >>> packages but are not the system default. Is this documented somewhere? > >> > So, where do I find the answer to the question above regarding the > correct JAVA_HOME and PATH to use a JVM that is not the system default? If the question is "what is the list of the roots of all the possible JVMs that may be released for Linux and packaged using jpp conventions" ? no one has the answer because no one knows the JVM list in the first place. Given the vendor name, java standard version, build number etc one can make an educated guess because people tend to use the same template but there is no absolute naming requirement. The packager must choose a unique directory name and it must be under %{libdir}/jvm that's about it. If the question is "how does a particular jpp-packaged app choose its JVM" the answer is it follows the JAVA_HOME env var, and which can be set: 1. in the user environment 2. in app-specific conf file 3. in user-level conf file 4. in system-level conf file 4. or falling all that trying pre-defined fallbacks (meaning java apps require java or java-devel, if a java package is installed %{libdir}/jvm/jre must exist and if a java-devel package is installed ditto for %{libdir}/jvm/java It's the responsability of the admin or user that overrides JAVA_HOME instead of letting the scripts fallback to the defaults to make sure JAVA_HOME is set properly (ie if you set it as something stupid things will go boom) > How is the split exports/private directory supposed to relate to that? Read the documentation bundled with jpackage-utils > > Fedora Java packaging as it's known today is a JPackage fork > > (periodically rebased). The Red Hat Java group originally started from > > its own package repository IIRC, but struggled to package the Java world > > and decided later to use a JPackage base as its repo was more complete. > > And what's the current situation with this now that Fedora and RHEL5 > include some stuff that looks jpackage'd but isn't? How do you > control, for example, which tomcat version you install? How do you control the installed apache version ? You get the one the Fedora maintainer selected. Same for Tomcat. You get the one Fedora selected if you source Fedora, and you get the one JPP selected if you source JPP. And the version will change from Fedora release to Fedora release, and JPP release to JPP release. If you're not happy with the choices you can contribute another parallel-installable tomcat to Fedora or JPP, they're both projects open to external contributions. But speaking as a former Tomcat packager ? it's a beast with tentacular dependencies, so you better allocate a lot of packaging time. If you have more java packaging questions I suggest posting on jpackage-discuss, and not be offended if the answer is long in coming ? the project is ressource-starved. -- 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 lesmikesell at gmail.com Wed Sep 5 20:06:25 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 15:06:25 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <20070905191726.GE13750@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> Message-ID: <46DF0C41.8050705@gmail.com> Bill Nottingham wrote: > Les Mikesell (lesmikesell at gmail.com) said: >>> dlopen will cause you to break at runtime instead of buildtime if >>> ABI changes - that's not good. >> You should expect things to break when you change an interface - pretty >> much by definition. If it hurts, don't do it. > > I was discussing a case where instead of linking against libvorbis, you > dlopen() it - that's the sort of thing which is really much better to > catch at buildtime. If you're dlopening the plugin that is itself linked > against libvorbis (or whatever), that's better. Won't anything using a shared library break if you replace that library with one that does not follow the same interface definition whether it's dlopen()ed or not? That's kind of the whole concept of interfaces - they aren't supposed to change. If you write a new one, call it something else. -- Les Mikesell lesmikesell at gmail.com From benny+usenet at amorsen.dk Wed Sep 5 20:11:01 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 05 Sep 2007 22:11:01 +0200 Subject: NetworkManager and "illegal" SSID chars = crash? References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> Message-ID: >>>>> "RP" == Richi Plana writes: RP> Since no semantics has been proposed, then it stands to reason RP> that one can just assume 1 byte = 1 character and a straight "byte RP> value = Unicode value" conversion should be adopted, right? (No RP> codepage conversions). Those two are incompatible. If you have 1 byte = 1 character, then you're not using Unicode (ok, you could be doing UTF-8 without any high bits set, but that's better known as ASCII). /Benny From notting at redhat.com Wed Sep 5 20:24:58 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Sep 2007 16:24:58 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <46DF0C41.8050705@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> <46DF0C41.8050705@gmail.com> Message-ID: <20070905202458.GC29272@nostromo.devel.redhat.com> Les Mikesell (lesmikesell at gmail.com) said: >> I was discussing a case where instead of linking against libvorbis, you >> dlopen() it - that's the sort of thing which is really much better to >> catch at buildtime. If you're dlopening the plugin that is itself linked >> against libvorbis (or whatever), that's better. > > Won't anything using a shared library break if you replace that library > with one that does not follow the same interface definition whether it's > dlopen()ed or not? That's kind of the whole concept of interfaces - they > aren't supposed to change. If you write a new one, call it something else. Sure. But DT_NEEDED is tracked at the package level and can be easily caught. Bill From myfedora at richip.dhs.org Wed Sep 5 20:27:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 14:27:26 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DF0C41.8050705@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> <46DF0C41.8050705@gmail.com> Message-ID: <1189024046.1641.136.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 15:06 -0500, Les Mikesell wrote: > Bill Nottingham wrote: > > Les Mikesell (lesmikesell at gmail.com) said: > >>> dlopen will cause you to break at runtime instead of buildtime if > >>> ABI changes - that's not good. > >> You should expect things to break when you change an interface - pretty > >> much by definition. If it hurts, don't do it. > > > > I was discussing a case where instead of linking against libvorbis, you > > dlopen() it - that's the sort of thing which is really much better to > > catch at buildtime. If you're dlopening the plugin that is itself linked > > against libvorbis (or whatever), that's better. > > Won't anything using a shared library break if you replace that library > with one that does not follow the same interface definition whether it's > dlopen()ed or not? That's kind of the whole concept of interfaces - > they aren't supposed to change. If you write a new one, call it > something else. That's what I meant when I said that catching interface changes like that should be escalated to a higher layer: the version. It won't get caught during loading of the executable (primarily because it's not linked against it), but it's like any software you develop. You can put error-checks at the lowest level function call and be assured of catching everything, or putting them at a higher level making sure that all entrances are checked. Coneptually, you could make changes to the library that doesn't change the ABI but changes the semantics of the function calls totally breaking the software that uses it but isn't caught during linking (far-fetched though it may be). The primary benefit to doing it this way (and a main concern of distro-makers) is, of course, that packages don't need to hard-Require optional modules (assuming they're optional to begin with). Other issues aren't as interesting to distribution-makers and one could spend weeks discussing the merits of doing it one way or another. Personally I've written software that does both and I'm not convinced one is always better over the other from a software developer's standpoint. Such isn't the case for distro-makers. -- Richi Plana From myfedora at richip.dhs.org Wed Sep 5 20:34:03 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 14:34:03 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <1189020585.3241.23.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> Message-ID: <1189024443.1641.143.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 21:29 +0200, Nicolas Mailhot wrote: > Le mercredi 05 septembre 2007 ? 12:33 -0500, Les Mikesell a ?crit : > > Nicolas Mailhot wrote: > > > > >>> I want to know the correct JAVA_HOME and PATH settings for all the > > >>> possible JVMs when they are installed as alternatives-conforming RPM > > >>> packages but are not the system default. Is this documented somewhere? > > >> > > So, where do I find the answer to the question above regarding the > > correct JAVA_HOME and PATH to use a JVM that is not the system default? > > If the question is "what is the list of the roots of all the possible > VMs that may be released for Linux and packaged using jpp conventions" Well, one method (and this isn't official AFAIK) is to run "alternatives --config java" or "alternatives --config javac" and that should give you a starting point for figuring out the list of JAVA_HOME paths for packages installed that are blessed by JPackage (or was it Fedora? since I'm not sure where alternatives support was introduced). -- Richi Plana From lesmikesell at gmail.com Wed Sep 5 20:34:59 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 15:34:59 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189020585.3241.23.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> Message-ID: <46DF12F3.4030405@gmail.com> Nicolas Mailhot wrote: >>>>> I want to know the correct JAVA_HOME and PATH settings for all the >>>>> possible JVMs when they are installed as alternatives-conforming RPM >>>>> packages but are not the system default. Is this documented somewhere? >> So, where do I find the answer to the question above regarding the >> correct JAVA_HOME and PATH to use a JVM that is not the system default? > > If the question is "what is the list of the roots of all the possible > JVMs that may be released for Linux and packaged using jpp conventions" > ? no one has the answer because no one knows the JVM list in the first > place. OK, but how about the answer for the known universe of JVM's included in the fedora/RHEL repositories plus the jpackage repository, including the ones that don't actually contain the JVM, but do determine the location where it will be installed? > Given the vendor name, java standard version, build number etc > one can make an educated guess because people tend to use the same > template but there is no absolute naming requirement. The packager must > choose a unique directory name and it must be under %{libdir}/jvm that's > about it. > If the question is "how does a particular jpp-packaged app choose its > JVM" the answer is it follows the JAVA_HOME env var, and which can be > set: > 1. in the user environment > 2. in app-specific conf file > 3. in user-level conf file > 4. in system-level conf file > 4. or falling all that trying pre-defined fallbacks (meaning java apps > require java or java-devel, if a java package is installed > %{libdir}/jvm/jre must exist and if a java-devel package is installed > ditto for %{libdir}/jvm/java > > It's the responsability of the admin or user that overrides JAVA_HOME > instead of letting the scripts fallback to the defaults to make sure > JAVA_HOME is set properly (ie if you set it as something stupid things > will go boom) No, I wouldn't limit a question like that to just packaged apps. The main issue is whether everything expected to be under JAVA_HOME is still in the correct relative position with all the matching binaries in $JAVA_HOME/bin. >> How is the split exports/private directory supposed to relate to that? > > Read the documentation bundled with jpackage-utils $ rpm -q jpackage-utils jpackage-utils-1.7.3-1jpp.3.fc6 $ man jpackage-utils No manual entry for jpackage-utils Does jpackage have its own convention about what to do with documentation as well? >>> Fedora Java packaging as it's known today is a JPackage fork >>> (periodically rebased). The Red Hat Java group originally started from >>> its own package repository IIRC, but struggled to package the Java world >>> and decided later to use a JPackage base as its repo was more complete. >> And what's the current situation with this now that Fedora and RHEL5 >> include some stuff that looks jpackage'd but isn't? How do you >> control, for example, which tomcat version you install? > > How do you control the installed apache version ? I didn't know anyone offered more than one. > You get the one the > Fedora maintainer selected. Same for Tomcat. You get the one Fedora > selected if you source Fedora, and you get the one JPP selected if you > source JPP. And the version will change from Fedora release to Fedora > release, and JPP release to JPP release. What if you source both fedora and jpackage repositories? Is that not a reasonable thing to do? Or you need both tomcat4 and 5 installed on the same machine? > If you're not happy with the choices you can contribute another > parallel-installable tomcat to Fedora or JPP, they're both projects open > to external contributions. I did not have any problem installing both tomcat4 and tomcat55 from the jpackage repo before fedora/RHEL incorporated parts that don't seem to play well with others. > But speaking as a former Tomcat packager ? > it's a beast with tentacular dependencies, so you better allocate a lot > of packaging time. That's precisely the sort of thing that you want someone else to get right in the repositories. I can do the easy stuff myself... > If you have more java packaging questions I suggest posting on > jpackage-discuss, and not be offended if the answer is long in coming ? > the project is ressource-starved. No, I'm more interested in the relationship between the embedded jpackage-looking stuff in fedora/RHEL5 and whether it is intended to break access to jpackage. Or if they are supposed to work together, how do you do it? -- Les Mikesell lesmikesell at gmail.com From ssorce at redhat.com Wed Sep 5 20:36:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Sep 2007 16:36:05 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> Message-ID: <1189024565.3329.32.camel@localhost.localdomain> On Wed, 2007-09-05 at 12:27 -0700, Ian Burrell wrote: > > That would be ISO-8859-1 encoding since Unicode < U+00FF is equal to > ISO-8859-1. I guess you mean "<= U+007F" (127) when the encoding is UTF-8 Simo. From myfedora at richip.dhs.org Wed Sep 5 20:39:59 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 14:39:59 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> Message-ID: <1189024799.1641.147.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 22:11 +0200, Benny Amorsen wrote: > >>>>> "RP" == Richi Plana writes: > > RP> Since no semantics has been proposed, then it stands to reason > RP> that one can just assume 1 byte = 1 character and a straight "byte > RP> value = Unicode value" conversion should be adopted, right? (No > RP> codepage conversions). > > Those two are incompatible. If you have 1 byte = 1 character, then > you're not using Unicode (ok, you could be doing UTF-8 without any > high bits set, but that's better known as ASCII). Sorry. I have to remind myself that when I write, I shouldn't leave any room for misinterpretation. What I meant was that for character lengths, we can assume a fixed width of 1 byte. And for the Unicode values, we just assume the byte value. And as Ian mentioned in a previous post, apparently that's exactly what ISO-8859-1 is so scrap any explanation I gave and let's just say ISO-8859-1, :). -- Richi Plana From myfedora at richip.dhs.org Wed Sep 5 20:44:35 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 14:44:35 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189019166.24933.29.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> <1189019166.24933.29.camel@xo-3E-67-34.localdomain> Message-ID: <1189025075.1641.152.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 15:06 -0400, Dan Williams wrote: > The drivers return a 32-byte array containing arbitrary values to > NetworkManager, which is technically correct. It's up to NM and > userspace to deal with this somehow. 802.11 specifies nothing about > encoding or anything other than a max length of 32 bytes. Right-o. And it's probably only chance coincidence that most wireless dev manufacturers allowed text input for the ESSID (or maybe it was a common stroke of brilliance). At any rate, because of a lack of specification, we have to deal with partial chaos (a recurring theme. Yay well-written specs!). -- Richi Plana From peter at thecodergeek.com Wed Sep 5 20:47:14 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 05 Sep 2007 13:47:14 -0700 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: <20070904231315.18546.7539@extras64.linux.duke.edu> References: <20070904231315.18546.7539@extras64.linux.duke.edu> Message-ID: <1189025234.3189.8.camel@tuxhugs> On Tue, 2007-09-04 at 23:13 +0000, Fedora Extras repoclosure wrote: > peter AT thecodergeek.com > empathy - 0.8-1.fc7.i386 (8 days) > empathy - 0.8-1.fc7.ppc (8 days) > empathy - 0.8-1.fc7.x86_64 (8 days) I don't understand why this is appearing. empathy-0.12-1.fc7 is the most recent testing update (FEDORA-2007-1933, Koji build 17458); and that was built explicitly against the in-testing telepathy-mission-control package (4.24-1.fc7). Is the script merely not catching these? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From myfedora at richip.dhs.org Wed Sep 5 20:55:57 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 14:55:57 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DF12F3.4030405@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> Message-ID: <1189025757.1641.161.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 15:34 -0500, Les Mikesell wrote: > OK, but how about the answer for the known universe of JVM's included in > the fedora/RHEL repositories plus the jpackage repository, including > the ones that don't actually contain the JVM, but do determine the > location where it will be installed? This is what I'm starting to learn: supposedly, something like "repoquery --whatprovides java-sdk" or "repoquery --whatprovides java-jre" is the way to go. It's a virtual Provides thing, but when I checked, JPackage's packages didn't come up (perhaps because they don't provide binary packages or maybe the virtual Provides). The rpm, yum and repo query mechanisms coupled with their virtual provides are proving to be pretty cool. P.S. Change of Subject: and thread? -- Richi Plana From ssorce at redhat.com Wed Sep 5 21:01:31 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Sep 2007 17:01:31 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189025075.1641.152.camel@localhost6.localdomain6> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> <1189019166.24933.29.camel@xo-3E-67-34.localdomain> <1189025075.1641.152.camel@localhost6.localdomain6> Message-ID: <1189026091.3329.36.camel@localhost.localdomain> On Wed, 2007-09-05 at 14:44 -0600, Richi Plana wrote: > On Wed, 2007-09-05 at 15:06 -0400, Dan Williams wrote: > > The drivers return a 32-byte array containing arbitrary values to > > NetworkManager, which is technically correct. It's up to NM and > > userspace to deal with this somehow. 802.11 specifies nothing about > > encoding or anything other than a max length of 32 bytes. > > Right-o. And it's probably only chance coincidence that most wireless > dev manufacturers allowed text input for the ESSID (or maybe it was a > common stroke of brilliance). > > At any rate, because of a lack of specification, we have to deal with > partial chaos (a recurring theme. Yay well-written specs!). Yeah and also keep in mind that if they are 32bytes with anything inside, you can find also embedded NULLs, so NM should cope with that too in theory. This would be valid I guess: EVIL\0\0SSID\0\0HERE\0\0\0\0\0\0\0\0\0\0\0\0\0\032 Simo. From myfedora at richip.dhs.org Wed Sep 5 21:02:36 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 15:02:36 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <1189025757.1641.161.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189025757.1641.161.camel@localhost6.localdomain6> Message-ID: <1189026156.1641.166.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 14:55 -0600, Richi Plana wrote: > This is what I'm starting to learn: supposedly, something like > "repoquery --whatprovides java-sdk" or "repoquery --whatprovides > java-jre" is the way to go. It's a virtual Provides thing, but when I > checked, JPackage's packages didn't come up (perhaps because they don't > provide binary packages or maybe the virtual Provides). Whoops. Typo. That should be "repoquery --whatprovides jre" And it turns out that I don't have the JPackage repo configured in my yum repo list so disregard what I said. -- Richi Plana From myfedora at richip.dhs.org Wed Sep 5 21:06:36 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 15:06:36 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189026091.3329.36.camel@localhost.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <190e0dab0709051157x28425169j4e1cfcb3e1459de3@mail.gmail.com> <1189019166.24933.29.camel@xo-3E-67-34.localdomain> <1189025075.1641.152.camel@localhost6.localdomain6> <1189026091.3329.36.camel@localhost.localdomain> Message-ID: <1189026396.1641.170.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 17:01 -0400, Simo Sorce wrote: > Yeah and also keep in mind that if they are 32bytes with anything > inside, you can find also embedded NULLs, so NM should cope with that > too in theory. > > This would be valid I guess: > EVIL\0\0SSID\0\0HERE\0\0\0\0\0\0\0\0\0\0\0\0\0\032 Right! Good catch. There goes Unicode. As far as I remember, U+0000 does not exist. And even if it did exist, to accurately capture the ESSID, you'd end up with a string that's 32 characters long _all the time_. -- Richi Plana From skvidal at fedoraproject.org Wed Sep 5 21:09:18 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 05 Sep 2007 17:09:18 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <1189025757.1641.161.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189025757.1641.161.camel@localhost6.localdomain6> Message-ID: <1189026558.16157.7.camel@cutter> On Wed, 2007-09-05 at 14:55 -0600, Richi Plana wrote: > On Wed, 2007-09-05 at 15:34 -0500, Les Mikesell wrote: > > OK, but how about the answer for the known universe of JVM's included in > > the fedora/RHEL repositories plus the jpackage repository, including > > the ones that don't actually contain the JVM, but do determine the > > location where it will be installed? > > This is what I'm starting to learn: supposedly, something like > "repoquery --whatprovides java-sdk" or "repoquery --whatprovides > java-jre" is the way to go. It's a virtual Provides thing, but when I > checked, JPackage's packages didn't come up (perhaps because they don't > provide binary packages or maybe the virtual Provides). > > The rpm, yum and repo query mechanisms coupled with their virtual > provides are proving to be pretty cool. > > P.S. Change of Subject: and thread? I just added a patch to repoquery to allow it to handle arbitrary url as repos. So you can: repoquery --repofrompath=http://some/repo/I/want/toquery --repofrompath=/some/local/path/also --repoid=toquery --repoid=also -q -a and it will grab the metadata from those to repositories and query them instead. -sv From mschwendt.tmp0701.nospam at arcor.de Wed Sep 5 21:21:07 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 5 Sep 2007 23:21:07 +0200 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: <1189025234.3189.8.camel@tuxhugs> References: <20070904231315.18546.7539@extras64.linux.duke.edu> <1189025234.3189.8.camel@tuxhugs> Message-ID: <20070905232107.555927f3.mschwendt.tmp0701.nospam@arcor.de> On Wed, 05 Sep 2007 13:47:14 -0700, Peter Gordon wrote: > On Tue, 2007-09-04 at 23:13 +0000, Fedora Extras repoclosure wrote: > > peter AT thecodergeek.com > > empathy - 0.8-1.fc7.i386 (8 days) > > empathy - 0.8-1.fc7.ppc (8 days) > > empathy - 0.8-1.fc7.x86_64 (8 days) > > I don't understand why this is appearing. empathy-0.12-1.fc7 is the most > recent testing update (FEDORA-2007-1933, Koji build 17458); and that was > built explicitly against the in-testing telepathy-mission-control > package (4.24-1.fc7). Is the script merely not catching these? Perhaps there are new issues with regard to the time-period between when the test update mails are sent and when the updated repodata appear on the master download server. Waiting longer (or checking whether the repodata files are "new enough") might help. From bruno at postle.net Wed Sep 5 21:15:19 2007 From: bruno at postle.net (Bruno Postle) Date: Wed, 5 Sep 2007 22:15:19 +0100 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <1188984530.12274.55.camel@wombat.tiptoe.de> References: <1188984530.12274.55.camel@wombat.tiptoe.de> Message-ID: <20070905211518.GN4137@postle.net> On Wed 05-Sep-2007 at 11:28 +0200, Nils Philippsen wrote: > > during the review of the resynthesizer plugin for GIMP > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > package to be named "gimp-plugin-resynthesizer" rather than > "gimp-resynthesizer". Ewan brought up the point that there isn't really > a naming guideline for it, therefore I'd like to propose one: > > For packages specific to GIMP (i.e. not just extensions of a separate > application like xsane, ufraw): > > Plugins and scripts(*): "gimp-plugin-" > Patterns: "gimp-pattern-" > Brushes: "gimp-brush-" > Themes: "gimp-theme-" This makes sense, but how many patterns, brushes and themes are there likely to be? I agree that plugins and scripts are all just 'plugins' to the end-user and shouldn't be differentiated. The fact that this is the first gimp plugin in fedora reminds me that fedora is very weak in this direction - Perhaps an 'imaging SIG' is needed? -- Bruno From jonathan.underwood at gmail.com Wed Sep 5 21:26:24 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 5 Sep 2007 22:26:24 +0100 Subject: Killing maintainers Message-ID: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> Hi, There's been a thread over on fedora-maintainers list for a few weeks proposing that fedora-maintainers be shut down, as it simply serves bifurcate discussion between here (devel) and there. All responses were in favour. Many people didn't respond, probably because they don't bother reading fedora-maintainers. As an aside, notice how quickly the discussion about naming F8 moved to devel simply because people weren't signed up to -maintainers. There has been a lot of discussion about list reorganization - let's not rehash that. One uncontentious point seems to be, -maintainers must die. What is the quickest way of getting this done? Which of the myriad committees does this need to go through? Jonathan. From bojan at rexursive.com Wed Sep 5 21:29:31 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 06 Sep 2007 07:29:31 +1000 Subject: clamav-0.91.2-2.fc7 update stuck Message-ID: <1189027771.22304.11.camel@shrek.rexursive.com> Looks like we have a problem with this package being stuck in pending. Could someone with enough privilege push this to stable updates? It is a security related release. -- Bojan From bpepple at fedoraproject.org Wed Sep 5 21:28:34 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 17:28:34 -0400 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: <1189025234.3189.8.camel@tuxhugs> References: <20070904231315.18546.7539@extras64.linux.duke.edu> <1189025234.3189.8.camel@tuxhugs> Message-ID: <1189027714.19643.1.camel@kennedy> On Wed, 2007-09-05 at 13:47 -0700, Peter Gordon wrote: > On Tue, 2007-09-04 at 23:13 +0000, Fedora Extras repoclosure wrote: > > peter AT thecodergeek.com > > empathy - 0.8-1.fc7.i386 (8 days) > > empathy - 0.8-1.fc7.ppc (8 days) > > empathy - 0.8-1.fc7.x86_64 (8 days) > > I don't understand why this is appearing. empathy-0.12-1.fc7 is the most > recent testing update (FEDORA-2007-1933, Koji build 17458); and that was > built explicitly against the in-testing telepathy-mission-control > package (4.24-1.fc7). Is the script merely not catching these? Have you actually pushed it to Stable? A quick look at updates system shows that it's still in testing. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 5 21:31:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Sep 2007 17:31:32 -0400 Subject: Killing maintainers In-Reply-To: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> Message-ID: <20070905173132.655bc3ae@mentok.boston.redhat.com> On Wed, 5 Sep 2007 22:26:24 +0100 "Jonathan Underwood" wrote: > What is the quickest way of getting this done? Which of the myriad > committees does this need to go through? I will be pushing this through FESCo tomorrow. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Wed Sep 5 21:40:38 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 5 Sep 2007 22:40:38 +0100 Subject: Killing maintainers In-Reply-To: <20070905173132.655bc3ae@mentok.boston.redhat.com> References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> <20070905173132.655bc3ae@mentok.boston.redhat.com> Message-ID: <645d17210709051440q1bd59f73q7cd0c2774311e781@mail.gmail.com> On 05/09/07, Jesse Keating wrote: > On Wed, 5 Sep 2007 22:26:24 +0100 > "Jonathan Underwood" wrote: > > > What is the quickest way of getting this done? Which of the myriad > > committees does this need to go through? > > I will be pushing this through FESCo tomorrow. Brilliant. Thanks!. From buildsys at fedoraproject.org Wed Sep 5 21:56:14 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 05 Sep 2007 21:56:14 -0000 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-05 Message-ID: <20070905215614.25710.77974@extras64.linux.duke.edu> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de koffice-karbon - 1.6.2-3.fc7.i386 (20 days) koffice-kivio - 1.6.2-3.fc7.i386 (20 days) koffice-kspread - 1.6.2-3.fc7.i386 (20 days) bjohnson AT symetrix.com dbmail - 2.2.4-4.fc7.i386 (62 days) gauret AT free.fr glest - 2.0.1-1.fc7.i386 glest - 2.0.1-1.fc7.x86_64 glest-data - 2.0.0-2.fc7.noarch (16 days) glest-data - 2.0.0-5.fc7.noarch glest-data - 2.0.0-5.fc7.noarch giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.i586 (12 days) kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.i686 (12 days) kmod-sysprof - 1.0.8-1.2.6.22.1_41.fc7.x86_64 (12 days) kmod-sysprof-PAE - 1.0.8-1.2.6.22.1_41.fc7.i686 (12 days) lxtnow AT gmail.com python-gammu - 0.20-1.fc7.i386 (33 days) python-gammu - 0.20-1.fc7.ppc (33 days) python-gammu - 0.20-1.fc7.x86_64 (33 days) oliver AT linux-kernel.at syck-php - 0.55-16.fc7.i386 (52 days) syck-php - 0.55-16.fc7.ppc (52 days) syck-php - 0.55-16.fc7.x86_64 (52 days) tcallawa AT redhat.com compat-wxGTK-devel - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-devel - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-devel - 2.4.2-21.fc6.ppc (51 days) compat-wxGTK-devel - 2.4.2-21.fc6.x86_64 (51 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-gl - 2.4.2-21.fc6.ppc (51 days) compat-wxGTK-gl - 2.4.2-21.fc6.x86_64 (51 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-stc - 2.4.2-21.fc6.ppc (51 days) compat-wxGTK-stc - 2.4.2-21.fc6.x86_64 (51 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (51 days) compat-wxGTK-xrc - 2.4.2-21.fc6.ppc (51 days) compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64 (51 days) twoerner AT redhat.com postfix-pflogsumm - 2:2.4.3-2.fc7.i386 (82 days) postfix-pflogsumm - 2:2.4.3-2.fc7.ppc (82 days) postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64 (82 days) ====================================================================== Broken packages in fedora-7-i386: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 ====================================================================== Broken packages in fedora-7-ppc: compat-wxGTK-devel-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.ppc requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 ====================================================================== Broken packages in fedora-7-x86_64: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires libwx_gtk-2.4.so.0()(64bit) compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-gl-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 dbmail-2.2.4-4.fc7.i386 requires dbmail-database-driver = 0:2.2.4-4.fc7 koffice-karbon-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kivio-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kspread-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 ====================================================================== Broken packages in fedora-updates-7-i386: glest-data-2.0.0-5.fc7.noarch requires glest = 0:2.0.0 kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.i586 requires kernel-i586 = 0:2.6.22.1-41.fc7 kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.i686 requires kernel-i686 = 0:2.6.22.1-41.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.22.1_41.fc7.i686 requires kernel-i686 = 0:2.6.22.1-41.fc7PAE postfix-pflogsumm-2:2.4.3-2.fc7.i386 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.i386 requires libGammu.so.1 syck-php-0.55-16.fc7.i386 requires php = 0:5.2.2 ====================================================================== Broken packages in fedora-updates-7-ppc: postfix-pflogsumm-2:2.4.3-2.fc7.ppc requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.ppc requires libGammu.so.1 syck-php-0.55-16.fc7.ppc requires php = 0:5.2.2 ====================================================================== Broken packages in fedora-updates-7-x86_64: glest-data-2.0.0-5.fc7.noarch requires glest = 0:2.0.0 kmod-sysprof-1.0.8-1.2.6.22.1_41.fc7.x86_64 requires kernel-x86_64 = 0:2.6.22.1-41.fc7 postfix-pflogsumm-2:2.4.3-2.fc7.x86_64 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.x86_64 requires libGammu.so.1()(64bit) syck-php-0.55-16.fc7.x86_64 requires php = 0:5.2.2 ====================================================================== Broken packages in fedora-updates-testing-7-i386: glest-2.0.1-1.fc7.i386 requires glest-data = 0:2.0.1 ====================================================================== Broken packages in fedora-updates-testing-7-x86_64: glest-2.0.1-1.fc7.x86_64 requires glest-data = 0:2.0.1 From lesmikesell at gmail.com Wed Sep 5 21:59:39 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 05 Sep 2007 16:59:39 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <20070905202458.GC29272@nostromo.devel.redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> <46DF0C41.8050705@gmail.com> <20070905202458.GC29272@nostromo.devel.redhat.com> Message-ID: <46DF26CB.30903@gmail.com> Bill Nottingham wrote: >>> I was discussing a case where instead of linking against libvorbis, you >>> dlopen() it - that's the sort of thing which is really much better to >>> catch at buildtime. If you're dlopening the plugin that is itself linked >>> against libvorbis (or whatever), that's better. >> Won't anything using a shared library break if you replace that library >> with one that does not follow the same interface definition whether it's >> dlopen()ed or not? That's kind of the whole concept of interfaces - they >> aren't supposed to change. If you write a new one, call it something else. > > Sure. But DT_NEEDED is tracked at the package level and can be > easily caught. Back to the beginning with this argument: if you are only planning to dlopen() libvorbis in the presence of ogg files there's no particular reason to expect it to be necessary at all, let alone a particular version of it. -- Les Mikesell lesmikesell at gmail.com From peter at thecodergeek.com Wed Sep 5 22:00:09 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 05 Sep 2007 15:00:09 -0700 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-04 In-Reply-To: <1189027714.19643.1.camel@kennedy> References: <20070904231315.18546.7539@extras64.linux.duke.edu> <1189025234.3189.8.camel@tuxhugs> <1189027714.19643.1.camel@kennedy> Message-ID: <1189029609.3189.11.camel@tuxhugs> On Wed, 2007-09-05 at 17:28 -0400, Brian Pepple wrote: > Have you actually pushed it to Stable? A quick look at updates system > shows that it's still in testing. No, both the empathy and telepathy-mission-control updates are in testing. However, it specifically says "The results in this summary consider Test Updates!" which leads me to believe that this should have not have been caught, since the testing updates *do* fix this broken dependency. :S -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Wed Sep 5 22:26:17 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 5 Sep 2007 18:26:17 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <20070905141957.GA17428@wolff.to> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> <20070905141957.GA17428@wolff.to> Message-ID: <20070905222617.GA18296@psilocybe.teonanacatl.org> Bruno Wolff III wrote: >> Besides, you said it requires an MTA. Would an effort to add the >> ability to detect the availability of /sbin/sendmail in the >> above-mentioned packages and use it if available or speak SMTP over >> port 25 if not be desirable? Packages like evolution and >> thunderbird do that and therefore don't "Require: sendmail". > > Mutt isn't going to be able to use smtp. As of 1.5.15 the world turned inside out and upside down and mutt grew support for SMTP: http://dev.mutt.org/trac/browser/ChangeLog#L1183 (The temperature in Hades may have even dropped by a few degrees, but that's not confirmed. :) > You really do want something local to store messages in case there > is a temporary problem in sending the mail out. However, you could > conceivably use mutt just to read email from a remote imap server. > That is probably not a likely use case though. Are there a lot of mutt users who aren't capable of doing the needed configuration to match their setup? It seems like one package that could survive without a "hold the users hand" approach to the possible things it might depend on. ;-) As of cvs rev 1.47, mutt.spec no longer requires sendmail. See: http://cvs.fedora.redhat.com/viewcvs/devel/mutt/mutt.spec?r1=1.46&r2=1.47&diff_format=u and https://bugzilla.redhat.com/show_bug.cgi?id=226167 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sex can be messy, but only if it's done right. -- Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tspauld98 at yahoo.com Wed Sep 5 22:29:56 2007 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Wed, 5 Sep 2007 15:29:56 -0700 (PDT) Subject: Killing maintainers In-Reply-To: <645d17210709051440q1bd59f73q7cd0c2774311e781@mail.gmail.com> Message-ID: <686290.64972.qm@web60524.mail.yahoo.com> Seems to me that the "-maintainers must die" slogan is screaming to be immortalized on a t-shirt soon. Kinda like "Vote for Pedro". :) Sorry for the late gallows humor but it just struck me as funny. Peace, tims Jonathan Underwood wrote: On 05/09/07, Jesse Keating wrote: > On Wed, 5 Sep 2007 22:26:24 +0100 > "Jonathan Underwood" wrote: > > > What is the quickest way of getting this done? Which of the myriad > > committees does this need to go through? > > I will be pushing this through FESCo tomorrow. Brilliant. Thanks!. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at thecodergeek.com Wed Sep 5 23:34:34 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 05 Sep 2007 16:34:34 -0700 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189008703.2702.2.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> Message-ID: <1189035274.3189.18.camel@tuxhugs> Hi, Brian. :) Jesse had mentioned on an earlier reply to a fedora-devel-list post about discussion with FESCo of killing the maintainers list. Will this be in the meeting, as well? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Sep 5 23:49:31 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 19:49:31 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189035274.3189.18.camel@tuxhugs> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> Message-ID: <1189036171.20671.1.camel@kennedy> On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > Hi, Brian. :) > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > about discussion with FESCo of killing the maintainers list. Will this > be in the meeting, as well? Probably, though I'm against killing it. I'll probably bring this up for discussion at the end of the meeting, since we have some other topics that are a lot more pressing. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Sep 5 23:57:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Sep 2007 01:57:22 +0200 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036171.20671.1.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> Message-ID: <1189036642.24848.631.camel@mccallum.corsepiu.local> On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > > Hi, Brian. :) > > > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > > about discussion with FESCo of killing the maintainers list. Will this > > be in the meeting, as well? > > Probably, though I'm against killing it. +1. I am also against killing it. maintainers@ and devel@ serve different purposes and are supposed to have different audiences (package maintenance vs. general fedora development) Ralf From jonathan.underwood at gmail.com Thu Sep 6 00:03:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 6 Sep 2007 01:03:07 +0100 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036642.24848.631.camel@mccallum.corsepiu.local> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> Message-ID: <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> On 06/09/07, Ralf Corsepius wrote: > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > > > Hi, Brian. :) > > > > > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > > > about discussion with FESCo of killing the maintainers list. Will this > > > be in the meeting, as well? > > > > Probably, though I'm against killing it. > +1. I am also against killing it. > > maintainers@ and devel@ serve different purposes and are supposed to > have different audiences (package maintenance vs. general fedora > development) That is the principle/ideal behind the two lists existing. However, the reality is there is no distinction between what is posted to either, just extra work in reading two lists. It's also interesting that there were no voices of opposition on -maintainers... From smooge at gmail.com Thu Sep 6 00:03:08 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 5 Sep 2007 18:03:08 -0600 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036642.24848.631.camel@mccallum.corsepiu.local> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> Message-ID: <80d7e4090709051703s2bd0cd4avb43265a3adddb8d6@mail.gmail.com> On 9/5/07, Ralf Corsepius wrote: > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > > > Hi, Brian. :) > > > > > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > > > about discussion with FESCo of killing the maintainers list. Will this > > > be in the meeting, as well? > > > > Probably, though I'm against killing it. > +1. I am also against killing it. > > maintainers@ and devel@ serve different purposes and are supposed to > have different audiences (package maintenance vs. general fedora > development) > In looking at the traffic on maintainers.. I think that distinction has been blurred long ago. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From bpepple at fedoraproject.org Thu Sep 6 00:04:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 20:04:20 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036642.24848.631.camel@mccallum.corsepiu.local> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> Message-ID: <1189037060.20671.4.camel@kennedy> On Thu, 2007-09-06 at 01:57 +0200, Ralf Corsepius wrote: > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > > > about discussion with FESCo of killing the maintainers list. Will this > > > be in the meeting, as well? > > > > Probably, though I'm against killing it. > +1. I am also against killing it. > > maintainers@ and devel@ serve different purposes and are supposed to > have different audiences (package maintenance vs. general fedora > development) Exactly, why I'm against killing it also. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Thu Sep 6 00:07:49 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 06 Sep 2007 09:07:49 +0900 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036642.24848.631.camel@mccallum.corsepiu.local> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> Message-ID: <46DF44D5.1080608@ioa.s.u-tokyo.ac.jp> Ralf Corsepius wrote, at 09/06/2007 08:57 AM +9:00: > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: >> On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: >>> Hi, Brian. :) >>> >>> Jesse had mentioned on an earlier reply to a fedora-devel-list post >>> about discussion with FESCo of killing the maintainers list. Will this >>> be in the meeting, as well? >> Probably, though I'm against killing it. > +1. I am also against killing it. > > maintainers@ and devel@ serve different purposes and are supposed to > have different audiences (package maintenance vs. general fedora > development) Also +1 for opposition to kill maintainers@ list. I don't think that general Fedora developers or non-Fedora users/developers who will see and comment on devel@ list also want to see comments about the procedures on build/updates system, package orphan issue, etc... Regards, Mamoru From smooge at gmail.com Thu Sep 6 00:09:41 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 5 Sep 2007 18:09:41 -0600 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> Message-ID: <80d7e4090709051709w6f64dd3bx9c81bbae841ad629@mail.gmail.com> On 9/5/07, Jonathan Underwood wrote: > On 06/09/07, Ralf Corsepius wrote: > > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > > On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > > > > Hi, Brian. :) > > > > > > > > Jesse had mentioned on an earlier reply to a fedora-devel-list post > > > > about discussion with FESCo of killing the maintainers list. Will this > > > > be in the meeting, as well? > > > > > > Probably, though I'm against killing it. > > +1. I am also against killing it. > > > > maintainers@ and devel@ serve different purposes and are supposed to > > have different audiences (package maintenance vs. general fedora > > development) > > That is the principle/ideal behind the two lists existing. However, > the reality is there is no distinction between what is posted to > either, just extra work in reading two lists. It's also interesting > that there were no voices of opposition on -maintainers... > Probably because few people maintain packages.. but a lot of people develop them :). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Thu Sep 6 00:15:27 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 5 Sep 2007 18:15:27 -0600 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DF44D5.1080608@ioa.s.u-tokyo.ac.jp> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <46DF44D5.1080608@ioa.s.u-tokyo.ac.jp> Message-ID: <80d7e4090709051715o314c7b2aka11860b672a586d3@mail.gmail.com> On 9/5/07, Mamoru Tasaka wrote: > Ralf Corsepius wrote, at 09/06/2007 08:57 AM +9:00: > > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > >> On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: > >>> Hi, Brian. :) > >>> > >>> Jesse had mentioned on an earlier reply to a fedora-devel-list post > >>> about discussion with FESCo of killing the maintainers list. Will this > >>> be in the meeting, as well? > >> Probably, though I'm against killing it. > > +1. I am also against killing it. > > > > maintainers@ and devel@ serve different purposes and are supposed to > > have different audiences (package maintenance vs. general fedora > > development) > > Also +1 for opposition to kill maintainers@ list. > I don't think that general Fedora developers or non-Fedora users/developers > who will see and comment on devel@ list also want to see comments about > the procedures on build/updates system, package orphan issue, etc... > If the build system were to have some radical change (You need a README.FRIBBLE file in your src.rpm or the new buildsystem dies..) that affects devel. I unsubscribed from -devel a while ago because all I wanted to see was maintainer issues.. I basically had to spend every day going through something on -devel to make sense of various posts... at which point it makes no sense to comment on something in -maintainer when I have to comment again on -devel. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From myfedora at richip.dhs.org Thu Sep 6 00:29:54 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 18:29:54 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DF26CB.30903@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> <46DF0C41.8050705@gmail.com> <20070905202458.GC29272@nostromo.devel.redhat.com> <46DF26CB.30903@gmail.com> Message-ID: <1189038594.16327.14.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 16:59 -0500, Les Mikesell wrote: > Back to the beginning with this argument: if you are only planning to > dlopen() libvorbis in the presence of ogg files there's no particular > reason to expect it to be necessary at all, let alone a particular > version of it. In the course of the discussion, certain information got blurred. First of all, the idea was that for optional modules in certain packages, it's desirable from a packaging perspective for the modules to be separable from the main package (as in the case of apache httpd, php, perl and gstreamer-plugins). Only if a library is optional and already supports separationg from the main package. If it's required (no point for having an Ogg vorbis player be separated from the vorbis library, right?), then that's fine. If it's optional but the software isn't written so that the optional module can be easily separated, then that should first be taken up with the software developer ... or fork. In the cases where the modules are optional and separable (because they're supported by the language ... Perl, python and java modules are separable by nature. C modules can be separable if they're dlopen(3)'d as opposed to ld(1)), I'm hoping that the packagers take advantage of this and package them separately (which is already done in a lot of packages). A couple of places where it COULD be done are a) gstreamer-plugins and b) kernel modules. I won't even go into kernel modules as even now there's a push to even make it even more monolitically packaged. gstreamer-plugins COULD be separated. They're only packaged as gstreamer-plugins-(base|good|bad| ugly) because that's the way the developers packaged them. Technically, a gstreamer-plugin-good.src.rpm could generate gstreamer-plugin-vorbis, gstreamer-plugin- and could all be pulled in by the virtual gstreamer-plugin-package-good. As I was contemplating on actually doing this, it occurred to me that I don't know how to do optional packaging in RPM spec files based on the existence of the lib*.so files. (no support in rpmbuild that I'm aware of, but I'm no expert.) Anyway, as the original poster who brought up this thread, I'm not even targetting specific packages but was wondering more about philosophy. If it's written down somewhere that Fedora developers should keep an eye out for making packages Modular so that distro-spinners have more flexibility, then perhaps that would help devs down the line. That's all. -- Richi Plana From bpepple at fedoraproject.org Thu Sep 6 00:32:25 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 05 Sep 2007 20:32:25 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <80d7e4090709051715o314c7b2aka11860b672a586d3@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <46DF44D5.1080608@ioa.s.u-tokyo.ac.jp> <80d7e4090709051715o314c7b2aka11860b672a586d3@mail.gmail.com> Message-ID: <1189038745.20671.14.camel@kennedy> On Wed, 2007-09-05 at 18:15 -0600, Stephen John Smoogen wrote: > On 9/5/07, Mamoru Tasaka wrote: > > Ralf Corsepius wrote, at 09/06/2007 08:57 AM +9:00: > > > > > > maintainers@ and devel@ serve different purposes and are supposed to > > > have different audiences (package maintenance vs. general fedora > > > development) > > > > Also +1 for opposition to kill maintainers@ list. > > I don't think that general Fedora developers or non-Fedora users/developers > > who will see and comment on devel@ list also want to see comments about > > the procedures on build/updates system, package orphan issue, etc... > > > I unsubscribed from -devel a while ago because all I wanted to see was > maintainer issues.. I basically had to spend every day going through > something on -devel to make sense of various posts... at which point > it makes no sense to comment on something in -maintainer when I have > to comment again on -devel. One of the main reasons the -maintainers list was created, was so maintainers didn't need to join a high volume list like -devel. If anything we should work more on making sure maintainer discussions stay on the -maintainers list and not bleed over to -devel, instead of killing the -maintainers list. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Thu Sep 6 00:41:02 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 05 Sep 2007 17:41:02 -0700 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189036171.20671.1.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> Message-ID: <1189039262.3189.20.camel@tuxhugs> On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > Probably, though I'm against killing it. I'll probably bring this up for > discussion at the end of the meeting, since we have some other topics > that are a lot more pressing. Yeah, I'm against killing it for the same reasons as have been stated. Just was curious, that's all. :) Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From myfedora at richip.dhs.org Thu Sep 6 00:56:39 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 18:56:39 -0600 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189038745.20671.14.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <46DF44D5.1080608@ioa.s.u-tokyo.ac.jp> <80d7e4090709051715o314c7b2aka11860b672a586d3@mail.gmail.com> <1189038745.20671.14.camel@kennedy> Message-ID: <1189040199.16327.21.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 20:32 -0400, Brian Pepple wrote: > One of the main reasons the -maintainers list was created, was so > maintainers didn't need to join a high volume list like -devel. If > anything we should work more on making sure maintainer discussions stay > on the -maintainers list and not bleed over to -devel, instead of > killing the -maintainers list. +1 on keeping, but I'm new to the list so my opinions don't carry much weight. ;) I was just going to ask if the discussion regarding NetworkManager a few threads up belong in fedora-devel or -maintainers ... or maybe even as far back as NetworkManager- or nm-applet-devel. If there's going to be a push for killing -maintainers, perhaps on the other spectrum there should also be a counterproposal for just improving guidelines (like politely asking the thread to be moved from -devel to -maint). -- Richi Plana From spng.yang at gmail.com Thu Sep 6 01:12:28 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 06 Sep 2007 09:12:28 +0800 Subject: fedora background images and main menu icons gone In-Reply-To: <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> Message-ID: <46DF53FC.8070500@gmail.com> Jeff Spaleta wrote: > On 9/4/07, yonas Abraham wrote: >> on rahawid, my beautiful high fly balloon backgrounds are gone. my >> main menu icons are gone to. > > I'm guessing this is a packaging bug. The old F7 thematic defaults > were removed. But I don't think the new defaults were placed > consistently back into the same locations in the filesystem. This is > most likely a filable bug against fedora-logos. The default.jpg > filelocation is missing in the latest fedora-logos package. > > rpm -q --changelog fedora-logos > > * Tue Aug 28 2007 M?ir?n Duffy - 7.92.0-1 > - update the anaconda artwork > - changed default backgrounds i have the same problems for more than two weeks, the "Main Menu" icon is missing: -(:09:10:$)-> rpm -q --changelog fedora-logos |head * Sat Sep 01 2007 Jeremy Katz - 7.92.0-3 - fix grub splash image to be an actual image * Wed Aug 29 2007 M?ir?n Duffy - 7.92.0-1 - update the anaconda artwork - changed default backgrounds * Tue Aug 28 2007 Ray Strode - 7.90.2-1 - update the firstboot artwork - update the grub artwork i am in f8 rawhide > > > -jef > From ewan at macmahon.me.uk Thu Sep 6 02:16:46 2007 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Thu, 6 Sep 2007 03:16:46 +0100 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <1188984530.12274.55.camel@wombat.tiptoe.de> References: <1188984530.12274.55.camel@wombat.tiptoe.de> Message-ID: <20070906021645.GG4640@macmahon.me.uk> On Wed, Sep 05, 2007 at 11:28:50AM +0200, Nils Philippsen wrote: > during the review of the resynthesizer plugin for GIMP > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > package to be named "gimp-plugin-resynthesizer" rather than > "gimp-resynthesizer". Ewan brought up the point that there isn't really > a naming guideline for it, therefore I'd like to propose one: > The name gimp-resynthesizer was chosen by applying the generic case of the package naming guidelines which cover anything that's not special cased. > If a package provides several distinct features that have value of their > own (use your own discretion on that), it must ship them as separate > subpackages. In that case, the source package is named > "gimp-extension-" where is a sensible > name for the collection (see examples). > > That's all of the different kinds of extensions for GIMP I can think > about right now, feel free to add to the list ;-). For packages that > contain e.g. a plugin and some brushes, I would separate them into > subpackages if it is sensible to do so. If not, I would name the package > after the main feature (in this case, likely "gimp-plugin-..." I think there are two related problems with this approach; from a user's perspective it's useful to know that a package is a gimp addon, but not all that useful to know whether it is implemented using a plugin, a script, brushes, or some combination of them. From a developers point of view it creates situations where it's not entirely clear how a package containing several different components should be named, or whether a package containing several components designed to be used together, but potentially useful apart should be split or not. There's also the potential to create inconsistency as people decide differently. Essentially the package name is too short to accurately describe the range of possibilities, so the best approach is to not try, and mislead, but to simply leave it as 'gimp-addon' and put the details in the description field. > Please comment. > > Ewan also expressed concern about the proliferation of package > specific naming guidelines. Tell me what you think about that as well. > In general I think the existing naming guidelines for addons work pretty well, and it's only worth making an exception if there's a really good case, such as pre-existing convention (e.g. CPAN naming for perl modules), or where a single 'parent' has so many addons that it's useful to classify them. I don't think either of those things are the case here. Short version: I don't think this is a terrible idea, I do think it's somewhat overkill, and on balance the downsides outweigh the upsides. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Sep 6 02:34:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Sep 2007 22:34:38 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189011705.24933.8.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <1189011705.24933.8.camel@xo-3E-67-34.localdomain> Message-ID: <20070906023438.GA20386@jadzia.bu.edu> On Wed, Sep 05, 2007 at 01:01:45PM -0400, Dan Williams wrote: > > Anyone else recognize this behavior? > RPM versions, kernel version, wpa_supplicant version, and any changes > you may have made to drivers or whatever could help. Also, was it NM, > or the applet that died? Originally NM itself. But see below... This is rawhide; it's been happening since Fedora 7-era or so, but it just dawned on me what the cause of the problem is. Or likely is -- I haven't actually proved it yet. Currently, NetworkManager 0.6.5-9.fc8, kernel 2.6.23-0.164.rc5.fc8, and wpa_supplicant-0.5.7-7. I'm using the stock orinoco_pci driver. In the last couple of days (weeks?) NM doesn't completely die, but instead logs crashy sorts of things while nm-applet vanishes and can't be restarted. There's backtraces like this in /var/log/messages, but I'm not exactly sure what's going on when they appear. (Note: see below the log message for more text.) Sep 3 11:37:16 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 3 11:37:17 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1 Sep 3 11:41:26 ylla NetworkManager: nm_hal_deinit(): libhal shutdown failed - Connection is closed Sep 3 11:41:26 ylla NetworkManager: nm_signal_handler(): Caught signal 11. Generating backtrace... Sep 3 11:41:26 ylla NetworkManager: Successfully reconnected to the system bus. Sep 3 11:41:27 ylla NetworkManager: ******************* START ********************************** Sep 3 11:41:28 ylla NetworkManager: (no debugging symbols found) Sep 3 11:41:29 ylla NetworkManager: Using host libthread_db library "/lib/libthread_db.so.1". Sep 3 11:41:29 ylla NetworkManager: (no debugging symbols found) Sep 3 11:41:29 ylla NetworkManager:last message repeated 12 times Sep 3 11:41:29 ylla NetworkManager: [Thread debugging using libthread_db enabled] Sep 3 11:41:29 ylla NetworkManager: [New Thread -1208538624 (LWP 1909)] Sep 3 11:41:29 ylla NetworkManager: [New Thread -1208542320 (LWP 15022)] Sep 3 11:41:29 ylla NetworkManager: [New Thread -1219032176 (LWP 15019)] Sep 3 11:41:29 ylla NetworkManager: [New Thread -1229522032 (LWP 2139)] Sep 3 11:41:29 ylla NetworkManager: (no debugging symbols found) Sep 3 11:41:29 ylla NetworkManager:last message repeated 6 times Sep 3 11:41:29 ylla NetworkManager: 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:29 ylla NetworkManager: #1 0x0035b47b in waitpid () from /lib/libpthread.so.0 Sep 3 11:41:29 ylla NetworkManager: #2 0x0806d3b0 in ?? () Sep 3 11:41:29 ylla NetworkManager: #3 0x0806d4a1 in ?? () Sep 3 11:41:29 ylla NetworkManager: #4 Sep 3 11:41:29 ylla NetworkManager: #5 0x08056147 in nm_get_device_by_iface () Sep 3 11:41:29 ylla NetworkManager: #6 0x0807bb9f in nm_dhcp_manager_process_signal () Sep 3 11:41:29 ylla NetworkManager: #7 0x0805faed in ?? () Sep 3 11:41:29 ylla NetworkManager: #8 0x001bc664 in dbus_connection_dispatch () from /lib/libdbus-1.so.3 Sep 3 11:41:29 ylla NetworkManager: #9 0x00198e7d in ?? () from /usr/lib/libdbus-glib-1.so.2 Sep 3 11:41:29 ylla NetworkManager: #10 0x0025917c in g_main_context_dispatch () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: #11 0x0025c5bf in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: #12 0x0025c969 in g_main_loop_run () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: #13 0x080693c8 in main () Sep 3 11:41:29 ylla NetworkManager: Sep 3 11:41:29 ylla NetworkManager: Thread 4 (Thread -1229522032 (LWP 2139)): Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #1 0x0035a52b in read () from /lib/libpthread.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #2 0x0025a11d in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #3 0x0027c77f in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #4 0x0035353b in start_thread () from /lib/libpthread.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #5 0x004380ee in clone () from /lib/libc.so.6 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: Sep 3 11:41:29 ylla NetworkManager: Thread 3 (Thread -1219032176 (LWP 15019)): Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #1 0x0042e053 in poll () from /lib/libc.so.6 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #2 0x0025c5f3 in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #3 0x0025c969 in g_main_loop_run () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #4 0x0805696e in ?? () Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #5 0x0027c77f in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #6 0x0035353b in start_thread () from /lib/libpthread.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #7 0x004380ee in clone () from /lib/libc.so.6 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: Sep 3 11:41:29 ylla NetworkManager: Thread 2 (Thread -1208542320 (LWP 15022)): Sep 3 11:41:29 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #1 0x0042e053 in poll () from /lib/libc.so.6 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #2 0x0025c5f3 in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #3 0x0025c969 in g_main_loop_run () from /lib/libglib-2.0.so.0 Sep 3 11:41:29 ylla NetworkManager: No symbol table info available. Sep 3 11:41:29 ylla NetworkManager: #4 0x0805696e in ?? () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #5 0x0027c77f in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #6 0x0035353b in start_thread () from /lib/libpthread.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #7 0x004380ee in clone () from /lib/libc.so.6 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: Sep 3 11:41:30 ylla NetworkManager: Thread 1 (Thread -1208538624 (LWP 1909)): Sep 3 11:41:30 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #1 0x0035b47b in waitpid () from /lib/libpthread.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #2 0x0806d3b0 in ?? () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #3 0x0806d4a1 in ?? () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #4 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #5 0x08056147 in nm_get_device_by_iface () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #6 0x0807bb9f in nm_dhcp_manager_process_signal () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #7 0x0805faed in ?? () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #8 0x001bc664 in dbus_connection_dispatch () from /lib/libdbus-1.so.3 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #9 0x00198e7d in ?? () from /usr/lib/libdbus-glib-1.so.2 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #10 0x0025917c in g_main_context_dispatch () from /lib/libglib-2.0.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #11 0x0025c5bf in ?? () from /lib/libglib-2.0.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #12 0x0025c969 in g_main_loop_run () from /lib/libglib-2.0.so.0 Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #13 0x080693c8 in main () Sep 3 11:41:30 ylla NetworkManager: No symbol table info available. Sep 3 11:41:30 ylla NetworkManager: #0 0x0012d402 in __kernel_vsyscall () Sep 3 11:41:30 ylla NetworkManager: The program is running. Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal] Sep 3 11:41:30 ylla NetworkManager: ******************* END ********************************** Just now, when I rebooted to try to generate a nice clean log of the problem under a semi-controlled environment, everything came up apparently fine and working. (First time ever at my house.) Then I realized that for whatever reason, iwlist scan wasn't showing the URL SSID. So I moved around the house until it showed up -- and boom, there goes nm-applet. When I try to restart nm-applet, I get this error (familiar to me from the times nm-applet isn't even there at boot time): process 2230: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted So I then try to restart NetworkManager (sudo service NetworkManager restart), and then I get this in the logs. (Again, more text below the log.) Sep 5 21:50:17 ylla NetworkManager: starting... Sep 5 21:50:18 ylla NetworkManager: New VPN service 'vpnc' (org.freedesktop.NetworkManager.vpnc). Sep 5 21:50:18 ylla NetworkManager: New VPN service 'openvpn' (org.freedesktop.NetworkManager.openvpn). Sep 5 21:50:18 ylla NetworkManager: wlan0: Device is fully-supported using driver 'orinoco_pci'. Sep 5 21:50:18 ylla NetworkManager: nm_device_init(): waiting for device's worker thread to start Sep 5 21:50:18 ylla NetworkManager: nm_device_init(): device's worker thread started, continuing. Sep 5 21:50:18 ylla NetworkManager: Now managing wireless (802.11) device 'wlan0'. Sep 5 21:50:18 ylla NetworkManager: Deactivating device wlan0. Sep 5 21:50:18 ylla NetworkManager: eth0: Device is fully-supported using driver 'e100'. Sep 5 21:50:18 ylla NetworkManager: nm_device_init(): waiting for device's worker thread to start Sep 5 21:50:18 ylla NetworkManager: nm_device_init(): device's worker thread started, continuing. Sep 5 21:50:18 ylla NetworkManager: Now managing wired Ethernet (802.3) device 'eth0'. Sep 5 21:50:18 ylla NetworkManager: Deactivating device eth0. Sep 5 21:50:18 ylla NetworkManager: Found dial up configuration for Verizon via Modem: Verizon Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 0 Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - nm_device_802_3_ethernet_link_deactivated (149) device eth0 scheduled link_deactivated_helper Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 1 Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - link_deactivated_helper (129) device eth0 will set active link to FALSE Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - link_activated_helper (102) device eth0 will set active link to TRUE Sep 5 21:50:18 ylla NetworkManager: nm-device.c - nm_device_set_active_link (596) device eth0 link state set to 1 Sep 5 21:50:18 ylla NetworkManager: Will activate wired connection 'eth0' because it now has a link. Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - nm_device_802_3_ethernet_link_activated (122) device eth0 scheduled link_activated_helper Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 0 Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - nm_device_802_3_ethernet_link_deactivated (149) device eth0 scheduled link_deactivated_helper Sep 5 21:50:18 ylla NetworkManager: nm-device-802-3-ethernet.c - link_deactivated_helper (129) device eth0 will set active link to FALSE Sep 5 21:50:18 ylla NetworkManager: nm-device.c - nm_device_set_active_link (596) device eth0 link state set to 0 Sep 5 21:50:18 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1 Sep 5 21:50:32 ylla NetworkManager: request_and_convert_scan_results(): card took too much time scanning. Get a better one. Sep 5 21:50:55 ylla NetworkManager: Updating allowed wireless network lists. Sep 5 21:50:55 ylla NetworkManager: nm_dbus_get_networks_cb(): error received: org.freedesktop.NetworkManagerInfo.NoNetworks - There are no wireless networks stored.. Sep 5 21:50:55 ylla NetworkManager: Updating VPN Connections... Sep 5 21:51:02 ylla NetworkManager: nm_hal_deinit(): libhal shutdown failed - Connection is closed Sep 5 21:51:02 ylla NetworkManager: nm_get_device_by_iface: assertion `data != NULL' failed Sep 5 21:51:02 ylla NetworkManager: Successfully reconnected to the system bus. Sep 5 21:51:52 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 5 21:51:54 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1 Sep 5 21:52:32 ylla NetworkManager: nm_hal_deinit(): libhal shutdown failed - Connection is closed Sep 5 21:52:32 ylla NetworkManager: Successfully reconnected to the system bus. Sep 5 21:54:42 ylla NetworkManager: nm_hal_deinit(): libhal shutdown failed - Connection is closed Sep 5 21:54:42 ylla NetworkManager: Successfully reconnected to the system bus. Sep 5 21:55:10 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 5 21:55:10 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 0 Sep 5 21:55:12 ylla NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device wlan0 link now 1 So then I say "screw it", and type "/sbin/ifup wlan0", which just works, enabling me to scp those logs to you over the network with the URL ssid. Oh -- hmmm, there's this NetworkManagerDispatcher thing -- sorry, I hadn't thought to restart that. Well, if I restart NetworkManagerDispatcher *and* NetworkManager, I can run nm-applet, and it'll be several seconds before it crashes with the above assertion failure again. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Sep 6 02:32:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Sep 2007 22:32:10 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189039262.3189.20.camel@tuxhugs> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> Message-ID: <20070905223210.356fef1a@ender> On Wed, 05 Sep 2007 17:41:02 -0700 Peter Gordon wrote: > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > Probably, though I'm against killing it. I'll probably bring this > > up for discussion at the end of the meeting, since we have some > > other topics that are a lot more pressing. > > Yeah, I'm against killing it for the same reasons as have been stated. > Just was curious, that's all. :) How's this for odd. We asked to kill it on -maintainers and nobody objected. We blurb about it on -devel and now we get objections? Crazy! So we have now 'fedora-devel-announce' which is used to announce things pertinent to the developers of (and on) Fedora. People who want low traffic, just the announces please can subscribe to that. I'd even like to force all new contributors to subscribe to it. This list echos to fedora-devel list right now, so that if you're on -devel, you get the postings, and all followup discussion. The reality is that development of, and development on Fedora are so closely tied that trying to have a different list for each just doesn't work. That's why I'm proposing that -maintainers gets shut down, all discussion goes back to -devel list, and people can subscribe to fedora-devel-announce if they just want the low traffic announcements. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Thu Sep 6 03:23:50 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 05 Sep 2007 23:23:50 -0400 Subject: iced-tea backport to f7? References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> <1188939842.3012.1.camel@scrappy.miketc.com> <1188960124.3012.3.camel@scrappy.miketc.com> Message-ID: Mike Chambers wrote: > On Tue, 2007-09-04 at 22:46 +0000, Mark Wielaard wrote: >> Mike Chambers miketc.com> writes: >> > I don't know much about this icedtea java stuff. I read it includes a >> > browser plug-in with the rpm? Is this the same plugin as the java one >> > from sun, or at least works the same? >> >> That is the java-1.7.0-icedtea-plugin package. >> It isn't the same plugin code as the sun one since sun hasn't released >> their code (yet). This is the gcjwebplugin code made to work with the >> openjdk code base. We do hope it works the same, if not please do report >> bugs! http://icedtea.classpath.org/bugzilla >> >> One known issue is that the plugin doesn't support Liveconnect, the >> Javascript - Java bridge. > > I've got it installed now and removed the sun java link and it did load. > Even tested to see if it's loaded on sun's java page and was successful. > So far so good I guess. > Worked OK with konqueror without any setup, but how to get firefox to notice it? Firefox still brings me to "install missing plugins". From lmacken at redhat.com Thu Sep 6 03:28:26 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 5 Sep 2007 23:28:26 -0400 Subject: clamav-0.91.2-2.fc7 update stuck In-Reply-To: <1189027771.22304.11.camel@shrek.rexursive.com> References: <1189027771.22304.11.camel@shrek.rexursive.com> Message-ID: <20070906032826.GA13784@crow.myhome.westell.com> On Thu, Sep 06, 2007 at 07:29:31AM +1000, Bojan Smojver wrote: > Looks like we have a problem with this package being stuck in pending. > Could someone with enough privilege push this to stable updates? It is a > security related release. Done. From myfedora at richip.dhs.org Thu Sep 6 03:36:24 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 05 Sep 2007 21:36:24 -0600 Subject: iced-tea backport to f7? In-Reply-To: References: <994441ae0709041233i2b79728bn616961c797f817d1@mail.gmail.com> <1188939842.3012.1.camel@scrappy.miketc.com> <1188960124.3012.3.camel@scrappy.miketc.com> Message-ID: <1189049784.16327.33.camel@localhost6.localdomain6> On Wed, 2007-09-05 at 23:23 -0400, Neal Becker wrote: > Worked OK with konqueror without any setup, but how to get firefox to > notice > it? Firefox still brings me to "install missing plugins". Worked okay on firefox for me. After installing java-1.7.0-icedtea-plugin, a symlink was automagically created in /usr/lib64/mozilla/plugins from libjavaplugin.so -> /etc/alternatives/libjavaplugin.so.x86_64 ... and from /etc/alternatives/libjavaplugin.so.x86_64 -> /usr/lib/jvm/jre-1.7.0-icedtea.x86_64/lib/amd64/gcjwebplugin.so Tested some applets on firefox and they were okay. -- Richi Plana From michel.sylvan at gmail.com Thu Sep 6 04:05:45 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 6 Sep 2007 00:05:45 -0400 Subject: XULRunner status Message-ID: Hello, Is XULRunner still intended to be included in Fedora 8? openSUSE has been using it since at least 10.2 (late last year) -- they don't build Firefox off it, but applications like Liferea are built against xulrunner, which makes it much easier to release Firefox security updates without triggering rebuilds of dependent apps. (Would be able to start testing Rawhide in a few weeks -- a bit short on disk space right now) Thanks, -- Michel From mattdm at mattdm.org Thu Sep 6 04:40:50 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Sep 2007 00:40:50 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189011644.24933.6.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <20070905143629.GA31388@jadzia.bu.edu> <1189011644.24933.6.camel@xo-3E-67-34.localdomain> Message-ID: <20070906044050.GA433@jadzia.bu.edu> On Wed, Sep 05, 2007 at 01:00:44PM -0400, Dan Williams wrote: > Definitely. Can you get a backtrace of where it's crashing? It should > dump output to /var/log/messages, including a backtrace. If that > doesn't work, maybe hooking up to it with gdb would help. Here's the gdb backtrace from nm-applet: Starting program: /usr/bin/nm-applet [Thread debugging using libthread_db enabled] [New process 2148] [New Thread -1208629488 (LWP 2148)] warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ea/8072ce47bbe621338d7d78b5a928669ed731f1.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/43/f019db05b32979c7605a988adb185caa653649.debug Program received signal SIGABRT, Aborted. [Switching to Thread -1208629488 (LWP 2148)] 0x0012d402 in __kernel_vsyscall () #0 0x0012d402 in __kernel_vsyscall () #1 0x00d46150 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00d47a51 in *__GI_abort () at abort.c:88 #3 0x00be7db5 in _dbus_abort () at dbus-sysdeps.c:86 #4 0x00be3a46 in _dbus_warn_check_failed ( format=0xbf07a0 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 #5 0x00bd7980 in dbus_message_new_method_call ( destination=0x806b2b8 "org.freedesktop.NetworkManager", path=0x88a3ad0 "/org/freedesktop/NetworkManager/Devices/wlan0/Networks/http_3a_//mattdm_2e_org/wifi", interface=0x806b620 "org.freedesktop.NetworkManager.Devices", method=0x806b41d "getProperties") at dbus-message.c:1071 #6 0x080572f7 in nma_dbus_device_update_one_network (applet=0x8652020, dev_path=0x88a7004 "/org/freedesktop/NetworkManager/Devices/wlan0", net_path=0x0, active_net_path=0x88a7100 "") at applet-dbus-devices.c:630 #7 0x0805842d in nma_dbus_device_properties_cb (pcall=0x878ece8, user_data=0x8652020) at applet-dbus-devices.c:831 #8 0x00bd9751 in _dbus_pending_call_complete (pending=0x878ece8) at dbus-pending-call.c:198 #9 0x00bc9773 in complete_pending_call_and_unlock (connection=0x8789220, pending=0x878ece8, message=) at dbus-connection.c:2170 #10 0x00bcb369 in dbus_connection_dispatch (connection=0x8789220) at dbus-connection.c:4296 #11 0x009fee7d in message_queue_dispatch (source=0x878b238, callback=0, user_data=0x0) at dbus-gmain.c:101 #12 0x00c6817c in IA__g_main_context_dispatch (context=0x861b8f8) at gmain.c:2061 #13 0x00c6b5bf in g_main_context_iterate (context=0x861b8f8, block=1, dispatch=1, self=0x85f8498) at gmain.c:2694 #14 0x00c6b969 in IA__g_main_loop_run (loop=0x8650930) at gmain.c:2898 #15 0x0074e714 in IA__gtk_main () at gtkmain.c:1144 #16 0x0804efa1 in main (argc=Cannot access memory at address 0x864 ) at main.c:67 #17 0x00d330f0 in __libc_start_main (main=0x804ee80
, argc=1, ubp_av=0xbf95a974, init=0x8069340 <__libc_csu_init>, fini=0x8069330 <__libc_csu_fini>, rtld_fini=0x11e560 <_dl_fini>, stack_end=0xbf95a96c) at libc-start.c:220 #18 0x0804edc1 in _start () -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Thu Sep 6 04:45:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 06:45:10 +0200 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> Message-ID: <46DF85D6.2090901@leemhuis.info> On 06.09.2007 02:03, Jonathan Underwood wrote: > On 06/09/07, Ralf Corsepius wrote: >> On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: >>> On Wed, 2007-09-05 at 16:34 -0700, Peter Gordon wrote: >>>> >>>> Jesse had mentioned on an earlier reply to a fedora-devel-list post >>>> about discussion with FESCo of killing the maintainers list. Will this >>>> be in the meeting, as well? >>> Probably, though I'm against killing it. >> +1. I am also against killing it. >> >> maintainers@ and devel@ serve different purposes and are supposed to >> have different audiences (package maintenance vs. general fedora >> development) > > That is the principle/ideal behind the two lists existing. However, > the reality is there is no distinction between what is posted to > either, just extra work in reading two lists. +1 The real solution IMHO is to make two lists: * a "developers" list, where only developers (be it Fedora developers, developers of other distributions or developers of Linux Software we ship) discuss. Make it moderated for a months or two to enforce the target audience -- I suppose afterwards it will work without moderation if we are a bit careful and point people to the right list. * one "devel-users" list, which would be successor for fedora-qa, fedora-test and all those user questions or feature-requests we get on fedora-devel now. Note that developers that have problems like "is foo broken on rawhide" should post to this list as well. Just my 2 cent. CU knurd From trever.adams at gmail.com Thu Sep 6 05:01:34 2007 From: trever.adams at gmail.com (Trever L. Adams) Date: Wed, 05 Sep 2007 23:01:34 -0600 Subject: Spins and other development issues In-Reply-To: <46DA6DD0.9040508@gmail.com> References: <46DA6DD0.9040508@gmail.com> Message-ID: <46DF89AE.5070907@gmail.com> Thank you to all who have responded. I think pungi and mock are the ones I am most interested in. Thank you, Trever Adams From bojan at rexursive.com Thu Sep 6 05:33:31 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 6 Sep 2007 05:33:31 +0000 (UTC) Subject: clamav-0.91.2-2.fc7 update stuck References: <1189027771.22304.11.camel@shrek.rexursive.com> <20070906032826.GA13784@crow.myhome.westell.com> Message-ID: Luke Macken redhat.com> writes: > Done. Thanks! -- Bojan From nicolas.mailhot at laposte.net Thu Sep 6 06:08:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Sep 2007 08:08:14 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <46DF12F3.4030405@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> Message-ID: <1189058894.3446.7.camel@rousalka.dyndns.org> Le mercredi 05 septembre 2007 ? 15:34 -0500, Les Mikesell a ?crit : > Nicolas Mailhot wrote: > > >>>>> I want to know the correct JAVA_HOME and PATH settings for all the > >>>>> possible JVMs when they are installed as alternatives-conforming RPM > >>>>> packages but are not the system default. Is this documented somewhere? > >> So, where do I find the answer to the question above regarding the > >> correct JAVA_HOME and PATH to use a JVM that is not the system default? > > > > If the question is "what is the list of the roots of all the possible > > JVMs that may be released for Linux and packaged using jpp conventions" > > ? no one has the answer because no one knows the JVM list in the first > > place. > > OK, but how about the answer for the known universe of JVM's included in > the fedora/RHEL repositories plus the jpackage repository, including > the ones that don't actually contain the JVM, but do determine the > location where it will be installed? For the FLOSS ones you can use yum tricks For the non-FLOSS ones you have to assemble them yourself starting from the non-free material @jpp, and you can check the paths at the same time. A jpp-style repository does *not* maintain a central JVM list. That's how it was done before I wrote the "new" guidelines in 2003 and it was hell to maintain. In a jpp-style repository any jvm that drops directories in the right place may be used through alternatives, but the rest of the system need not care about the jvms that may or may not be packaged this way. If you want to bring back central lists from the dead you're welcome to try, but anyone who touched pre-1.5 jpp won't follow you. For more information, read jpackage-discuss archives around march 2003. -- 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 rc040203 at freenet.de Thu Sep 6 06:46:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Sep 2007 08:46:42 +0200 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <20070905223210.356fef1a@ender> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> Message-ID: <1189061202.24848.662.camel@mccallum.corsepiu.local> On Wed, 2007-09-05 at 22:32 -0400, Jesse Keating wrote: > On Wed, 05 Sep 2007 17:41:02 -0700 > Peter Gordon wrote: > > > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > > Probably, though I'm against killing it. I'll probably bring this > > > up for discussion at the end of the meeting, since we have some > > > other topics that are a lot more pressing. > > > > Yeah, I'm against killing it for the same reasons as have been stated. > > Just was curious, that's all. :) > > How's this for odd. We asked to kill it on -maintainers and nobody > objected. We blurb about it on -devel and now we get objections? Because subscription to -maintainers isn't mandatory? > So we have now 'fedora-devel-announce' which is used to announce things > pertinent to the developers of (and on) Fedora. People who want low > traffic, just the announces please can subscribe to that. IMO, all maintainers should be interested in reading maintainers, or they better should not call themselves maintainers. > I'd even > like to force all new contributors to subscribe to it. To maintainers@, yes. > This list echos > to fedora-devel list right now, so that if you're on -devel, you get > the postings, and all followup discussion. The reality is that > development of, and development on Fedora are so closely tied that > trying to have a different list for each just doesn't work. Only because some people don't want to learn to distinguish between devel and maintainers? To me things like "nouveau vs. nv" are clearly devel questions, while buildsystem ("bodhi/koji/plague") issues or "AWOL" issues are maintainer questions which are highly non interesting to "general developers". > That's why > I'm proposing that -maintainers gets shut down, all discussion goes > back to -devel list, and people can subscribe to fedora-devel-announce > if they just want the low traffic announcements. It you go this route, consider to close down all other devel, test packaging etc lists and to merge them with @-devel, because anything discussed their-in is somehow "development of the distro". ;) Ralf From lesmikesell at gmail.com Thu Sep 6 06:57:04 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 06 Sep 2007 01:57:04 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189058894.3446.7.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> Message-ID: <46DFA4C0.1000007@gmail.com> Nicolas Mailhot wrote: >> OK, but how about the answer for the known universe of JVM's included in >> the fedora/RHEL repositories plus the jpackage repository, including >> the ones that don't actually contain the JVM, but do determine the >> location where it will be installed? > > For the FLOSS ones you can use yum tricks > For the non-FLOSS ones you have to assemble them yourself starting from > the non-free material @jpp, and you can check the paths at the same > time. > > A jpp-style repository does *not* maintain a central JVM list. That's > how it was done before I wrote the "new" guidelines in 2003 and it was > hell to maintain. In a jpp-style repository any jvm that drops > directories in the right place may be used through alternatives, but the > rest of the system need not care about the jvms that may or may not be > packaged this way. I could have sworn I ran into dependencies on specific JVM versions when trying to install some packages from the jpackage repo. How can that be if you don't keep track of the JVMs themselves? Or if the packages are supposed to be usable with unpackaged JVMs? > If you want to bring back central lists from the dead you're welcome to > try, but anyone who touched pre-1.5 jpp won't follow you. For more > information, read jpackage-discuss archives around march 2003. I don't particularly care how the files are managed or where they live. I'm just trying to learn how to find what alternatives are available and how to access them when certain apps require different JVMs and you want to run them at the same time - and I haven't found much documentation on the topic. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Thu Sep 6 07:54:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Sep 2007 09:54:04 +0200 (CEST) Subject: Goal: Increased Modularity? In-Reply-To: <46DFA4C0.1000007@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> Message-ID: <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> Le Jeu 6 septembre 2007 08:57, Les Mikesell a ?crit : > How can that be > if you don't keep track of the JVMs themselves? Or if the packages are > supposed to be usable with unpackaged JVMs? They are *not* supposed to be usable with unpackaged JVMs. Sorry. JPP won't maintain a huge pile of workarounds just because vendors are too lazy to follow common conventions and stick to them. Sometimes people release an adaptation layer for a specific vendor jvm and yes this layer is specific to this jvm but that's about it. > I don't particularly care how the files are managed or where they > live. Then you won't ever understand why something works or not and how to fix your problems. The default is "just use the system jvm" if you don't want to follow the defaults you have to understand the conventions. That means reading the docs not deciding beforehand what's relevant and what's not. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Sep 6 08:08:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Sep 2007 10:08:17 +0200 (CEST) Subject: Goal: Increased Modularity? In-Reply-To: <53854.192.54.193.51.1189065247.squirrel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065247.squirrel@rousalka.dyndns.org> Message-ID: <61417.192.54.193.51.1189066097.squirrel@rousalka.dyndns.org> Le Jeu 6 septembre 2007 09:54, Nicolas Mailhot a ?crit : >> I don't particularly care how the files are managed or where they >> live. > > Then you won't ever understand why something works or not and how to > fix your problems. To expand a little more: all the jpp packaging of closed jvm does is moving files to standardised places and/or symlinking them there. So file layout is the alpha and omega of what you need to know. (Plus some virtual provides and font stuff that's better forgotten, because the legacy core font backend proprietary java uses is just plain inadequate for current needs.) -- Nicolas Mailhot From fedora at leemhuis.info Thu Sep 6 08:37:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 10:37:35 +0200 Subject: fedora background images and main menu icons gone In-Reply-To: <46DF53FC.8070500@gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> <46DF53FC.8070500@gmail.com> Message-ID: <46DFBC4F.4010002@leemhuis.info> On 06.09.2007 03:12, Ken YANG wrote: > Jeff Spaleta wrote: >> On 9/4/07, yonas Abraham wrote: >>> on rahawid, my beautiful high fly balloon backgrounds are gone. my >>> main menu icons are gone to. >> I'm guessing this is a packaging bug. The old F7 thematic defaults >> were removed. But I don't think the new defaults were placed >> consistently back into the same locations in the filesystem. This is >> most likely a filable bug against fedora-logos. The default.jpg >> filelocation is missing in the latest fedora-logos package. >> >> rpm -q --changelog fedora-logos >> >> * Tue Aug 28 2007 M?ir?n Duffy - 7.92.0-1 >> - update the anaconda artwork >> - changed default backgrounds > > i have the same problems for more than two weeks, the "Main Menu" > icon is missing: Did you file a bug report or found one? I noticed the same when I updated to rawhide some days ago, but didn't come around yet to ask bugzilla about it. tia CU knurd From nphilipp at redhat.com Thu Sep 6 08:39:11 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Sep 2007 10:39:11 +0200 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: References: <1188984530.12274.55.camel@wombat.tiptoe.de> Message-ID: <1189067951.6847.20.camel@wombat.tiptoe.de> On Wed, 2007-09-05 at 14:00 +0200, KH KH wrote: > 2007/9/5, Nils Philippsen : > > Hi, > > > > during the review of the resynthesizer plugin for GIMP > > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > > package to be named "gimp-plugin-resynthesizer" rather than > > "gimp-resynthesizer". Ewan brought up the point that there isn't really > > a naming guideline for it, therefore I'd like to propose one: > > cinepaint should probably follow the same guideline if ever there is plugins... > > I've recently discovered that there is perl scripts to be used with gimp > http://search.cpan.org/~sjburges/Gimp-2.0/Gimp.pm > > If ever someone want to package them, the guideline may need to cover > the case... This is very old and has in fact been distributed in old versions of GIMP, but I don't think it's up to snuff with current versions. If someone thinks about packaging it, please check whether it is ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Sep 6 08:39:48 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Sep 2007 10:39:48 +0200 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <20070905211518.GN4137@postle.net> References: <1188984530.12274.55.camel@wombat.tiptoe.de> <20070905211518.GN4137@postle.net> Message-ID: <1189067988.6847.22.camel@wombat.tiptoe.de> On Wed, 2007-09-05 at 22:15 +0100, Bruno Postle wrote: > On Wed 05-Sep-2007 at 11:28 +0200, Nils Philippsen wrote: > > > > during the review of the resynthesizer plugin for GIMP > > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > > package to be named "gimp-plugin-resynthesizer" rather than > > "gimp-resynthesizer". Ewan brought up the point that there isn't really > > a naming guideline for it, therefore I'd like to propose one: > > > > For packages specific to GIMP (i.e. not just extensions of a separate > > application like xsane, ufraw): > > > > Plugins and scripts(*): "gimp-plugin-" > > Patterns: "gimp-pattern-" > > Brushes: "gimp-brush-" > > Themes: "gimp-theme-" > > This makes sense, but how many patterns, brushes and themes are > there likely to be? I agree that plugins and scripts are all just > 'plugins' to the end-user and shouldn't be differentiated. > > The fact that this is the first gimp plugin in fedora reminds me > that fedora is very weak in this direction - Perhaps an 'imaging > SIG' is needed? Good idea. What do we have to do for that? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From spng.yang at gmail.com Thu Sep 6 08:45:59 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 06 Sep 2007 16:45:59 +0800 Subject: fedora background images and main menu icons gone In-Reply-To: <46DFBC4F.4010002@leemhuis.info> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> <46DF53FC.8070500@gmail.com> <46DFBC4F.4010002@leemhuis.info> Message-ID: <46DFBE47.8080904@gmail.com> Thorsten Leemhuis wrote: > On 06.09.2007 03:12, Ken YANG wrote: >> Jeff Spaleta wrote: >>> On 9/4/07, yonas Abraham wrote: >>>> on rahawid, my beautiful high fly balloon backgrounds are gone. my >>>> main menu icons are gone to. >>> I'm guessing this is a packaging bug. The old F7 thematic defaults >>> were removed. But I don't think the new defaults were placed >>> consistently back into the same locations in the filesystem. This is >>> most likely a filable bug against fedora-logos. The default.jpg >>> filelocation is missing in the latest fedora-logos package. >>> >>> rpm -q --changelog fedora-logos >>> >>> * Tue Aug 28 2007 M?ir?n Duffy - 7.92.0-1 >>> - update the anaconda artwork >>> - changed default backgrounds >> i have the same problems for more than two weeks, the "Main Menu" >> icon is missing: > > Did you file a bug report or found one? I noticed the same when I > updated to rawhide some days ago, but didn't come around yet to ask > bugzilla about it. i had not file a bug, i think this sort of problem is obvious, and others will fix it in future, this kind of problem is common in rawhide. > > tia > > CU > knurd > From nphilipp at redhat.com Thu Sep 6 08:52:20 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Sep 2007 10:52:20 +0200 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <20070906021645.GG4640@macmahon.me.uk> References: <1188984530.12274.55.camel@wombat.tiptoe.de> <20070906021645.GG4640@macmahon.me.uk> Message-ID: <1189068740.6847.36.camel@wombat.tiptoe.de> On Thu, 2007-09-06 at 03:16 +0100, Ewan Mac Mahon wrote: > On Wed, Sep 05, 2007 at 11:28:50AM +0200, Nils Philippsen wrote: > > during the review of the resynthesizer plugin for GIMP > > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the > > package to be named "gimp-plugin-resynthesizer" rather than > > "gimp-resynthesizer". Ewan brought up the point that there isn't really > > a naming guideline for it, therefore I'd like to propose one: > > > The name gimp-resynthesizer was chosen by applying the generic case of > the package naming guidelines which cover anything that's not special > cased. That's what I meant (should have been "... there isn't a special naming guideline for it."). > > If a package provides several distinct features that have value of their > > own (use your own discretion on that), it must ship them as separate > > subpackages. In that case, the source package is named > > "gimp-extension-" where is a sensible > > name for the collection (see examples). > > > > That's all of the different kinds of extensions for GIMP I can think > > about right now, feel free to add to the list ;-). For packages that > > contain e.g. a plugin and some brushes, I would separate them into > > subpackages if it is sensible to do so. If not, I would name the package > > after the main feature (in this case, likely "gimp-plugin-..." > > I think there are two related problems with this approach; from a user's > perspective it's useful to know that a package is a gimp addon, but not > all that useful to know whether it is implemented using a plugin, a > script, brushes, or some combination of them. From a developers point of > view it creates situations where it's not entirely clear how a package > containing several different components should be named, or whether a > package containing several components designed to be used together, but > potentially useful apart should be split or not. There's also the > potential to create inconsistency as people decide differently. > > Essentially the package name is too short to accurately describe the > range of possibilities, so the best approach is to not try, and mislead, > but to simply leave it as 'gimp-addon' and put the details in the > description field. Hmm. I like to keep things nice and tidy and it seems that I've got a serious crush on namespaces ;-). > > Please comment. > > > > Ewan also expressed concern about the proliferation of package > > specific naming guidelines. Tell me what you think about that as well. > > > In general I think the existing naming guidelines for addons work pretty > well, and it's only worth making an exception if there's a really good > case, such as pre-existing convention (e.g. CPAN naming for perl > modules), or where a single 'parent' has so many addons that it's useful > to classify them. I don't think either of those things are the case > here. Not yet maybe, but there is a huge number of 3rd party GIMP plugins out there that could be packaged. > Short version: I don't think this is a terrible idea, I do think it's > somewhat overkill, and on balance the downsides outweigh the upsides. I'd say unless someone else provides some arguments beyond what I said pro "namespacing" I'd give in to stay with just "gimp-" but I reserve bringing this issue up again if we at some point in the future have a huge number of plugins. Sounds okay? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Sep 6 09:19:48 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Sep 2007 11:19:48 +0200 Subject: Making "upstream" tarballs available In-Reply-To: <1188588490.29226.31.camel@cutter> References: <20070831160101.GA978@atlas.linux2go.dk> <1188588490.29226.31.camel@cutter> Message-ID: <1189070388.6847.61.camel@wombat.tiptoe.de> On Fri, 2007-08-31 at 15:28 -0400, seth vidal wrote: > Nils, > Would you be willing to move things off of elvis and onto > hosted.fedoraproject.org to help with the use of system-config-samba by > other distros? Sorry for the late reply, been busy and all that. In fact, I've been prodding Soren to ask the question here -- he approached me about it on IRC and I thought that this is an issue of general interest, not only for system-config-samba. Some points/ideas: - I've already moved my system-config packages from elvis CVS to hosted Mercurial. - I think it's a good idea to offer the tarballs for download there as well. - I'm not sure whether having one project per system-config tool would be wise, perhaps we can keep them under on larger "system configuration tools" umbrella (as is done today in the Wiki). - Uploading the tarballs must be possible to be done automatically/from the command line. Having to do this manually (via a web browser) won't fly, because sometimes my memory is more like a "forgettory". - I'm willing to sacrifice my workflow a bit, but if at all possible I'd like to keep it this way: 1. Change things, try them out in locally checked out source code 2. "hg commit" 2.1 bump version 3. "make [...] archive" (which tags and pushes to hosted) 4. copy over stuff to Fedora dist CVS 5. "make new-source", "cvs commit", "make [force-]tag build" 6. If the build doesn't succeed, repeat from step 1 on, skipping step 2.1 (avoid version creep), force-tagging etc. This works because the tarball hasn't been published yet -- being stored behind an anonymous hash in the lookaside cache doesn't count ;-). My idea would be: 7. Use a small script that (for a certain package) would do this: - checks what versions are on the "upstream" download site - checks what version are available for Rawhide in koji - for all versions not yet available, pulls the SRPMS from koji, extracts the tarballs and uploads them to the "upstream" download site Ideally this script would kick off automatically after a successful build in Rawhide, but I don't know if this would be easily doable. It could be hooked after "make build" or could be a separate "make publish" target in which case step 5 would become: 5. "make new-source", "cvs commit", "make [force-]tag build publish" This would work if it is guaranteed that "make build" only succeeds if the build is really successful. I think we can assume that. I'd volunteer writing such a script. Comments? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Sep 6 09:28:18 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Sep 2007 11:28:18 +0200 Subject: Development SIG mailing list name suggestions? In-Reply-To: <20070905184754.GA16115@redhat.com> References: <20070905184754.GA16115@redhat.com> Message-ID: <1189070898.6847.63.camel@wombat.tiptoe.de> On Wed, 2007-09-05 at 14:47 -0400, Andrew Overholt wrote: > Hi, > > We'd like to have a mailing list to discuss issues pertaining to the > Development SIG and the "Fedora: Developer Edition" spin. > > What should the list be called? > > fedora-developer ? fedora-developer-spin? > fedora-develsig ? fedora-devel-sig? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jfontain at free.fr Thu Sep 6 09:42:54 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 06 Sep 2007 11:42:54 +0200 Subject: sqlite-tcl? Message-ID: <46DFCB9E.5070701@free.fr> Dear fellow developers, moodss needs a Tcl interface to SQLite and currently uses sqlite2-tcl. But sqlite2 is gone from development. Any plans to make a sqlite-tcl rpm (for SQLite version 3)? -- Jean-Luc Fontaine http://jfontain.free.fr/ From billcrawford1970 at gmail.com Thu Sep 6 10:59:29 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 6 Sep 2007 11:59:29 +0100 Subject: Goal: Increased Modularity? In-Reply-To: <46DF26CB.30903@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <46DED81A.9030004@gmail.com> <20070905191726.GE13750@nostromo.devel.redhat.com> <46DF0C41.8050705@gmail.com> <20070905202458.GC29272@nostromo.devel.redhat.com> <46DF26CB.30903@gmail.com> Message-ID: <544eb990709060359s64ca420ek5fc89d70870defce@mail.gmail.com> On 05/09/07, Les Mikesell wrote: > Back to the beginning with this argument: if you are only planning to > dlopen() libvorbis in the presence of ogg files there's no particular > reason to expect it to be necessary at all, let alone a particular > version of it. You have a plugin module for the application that is dlopen()'d by the application itself. The plugin is linked, normally, against libvorbis (or whatever). Then the build of the plugin will fail if the interface changes. The interface of the plugin is under the control of the application developer, and you can avoid breaking that at runtime by e.g. versioning the directory path the plugins are stored in, or something ... From lemenkov at gmail.com Thu Sep 6 11:25:35 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Thu, 6 Sep 2007 15:25:35 +0400 Subject: How to satisfy BuildRequires automatically while rebuilding from SRPM? Message-ID: Hello All! Subj. -- With best regards! From jkeating at redhat.com Thu Sep 6 11:24:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Sep 2007 07:24:02 -0400 Subject: How to satisfy BuildRequires automatically while rebuilding from SRPM? In-Reply-To: References: Message-ID: <20070906072402.639f8add@ender> On Thu, 6 Sep 2007 15:25:35 +0400 "Peter Lemenkov" wrote: > Hello All! > Subj. Use mock. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at miketc.com Thu Sep 6 12:29:43 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 06 Sep 2007 07:29:43 -0500 Subject: fedora background images and main menu icons gone In-Reply-To: <46DFBE47.8080904@gmail.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> <46DF53FC.8070500@gmail.com> <46DFBC4F.4010002@leemhuis.info> <46DFBE47.8080904@gmail.com> Message-ID: <1189081783.8187.2.camel@scrappy.miketc.com> On Thu, 2007-09-06 at 16:45 +0800, Ken YANG wrote: > Thorsten Leemhuis wrote: > > Did you file a bug report or found one? I noticed the same when I > > updated to rawhide some days ago, but didn't come around yet to ask > > bugzilla about it. > > i had not file a bug, i think this sort of problem is obvious, and > others will fix it in future, this kind of problem is common in > rawhide. I am using a rawhide install as of yesterday, and the menus and backgrounds are there. They may have changed or whatever somehow with the latest packages. Maybe you need to redo your appearances again, maybe try choosing a complete different one, then go back and choose the nokeda or whatever theme and see what happens. In other words, maybe it just needs a refresh to get it back again? -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From snecklifter at gmail.com Thu Sep 6 13:03:51 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 6 Sep 2007 14:03:51 +0100 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189061202.24848.662.camel@mccallum.corsepiu.local> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> Message-ID: <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> On 06/09/07, Ralf Corsepius wrote: > > On Wed, 2007-09-05 at 22:32 -0400, Jesse Keating wrote: > > On Wed, 05 Sep 2007 17:41:02 -0700 > > Peter Gordon wrote: > > > > > On Wed, 2007-09-05 at 19:49 -0400, Brian Pepple wrote: > > > > Probably, though I'm against killing it. I'll probably bring this > > > > up for discussion at the end of the meeting, since we have some > > > > other topics that are a lot more pressing. > > > > > > Yeah, I'm against killing it for the same reasons as have been stated. > > > Just was curious, that's all. :) > > > > How's this for odd. We asked to kill it on -maintainers and nobody > > objected. We blurb about it on -devel and now we get objections? > Because subscription to -maintainers isn't mandatory? > Although it is for maintainers of course. Essentially, maintainers (or those subscribed to the maintainers list) have asked for it to be closed. Now the discussion moves to -devel and developers want it left open. Those arguing in favour of leaving -maintainers open are not subscribed to it (or have missed the rather long thread on the subject - unlikely) so its difficult to understand how they can appreciate the issue of crosstalk that is happening. I'm also in favour of -maintainers closure FWIW or at least would be interested to hear how the line between the two lists (or a replacement) could be more definitive. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Thu Sep 6 13:05:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 15:05:17 +0200 Subject: fedora background images and main menu icons gone In-Reply-To: <1189081783.8187.2.camel@scrappy.miketc.com> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> <46DF53FC.8070500@gmail.com> <46DFBC4F.4010002@leemhuis.info> <46DFBE47.8080904@gmail.com> <1189081783.8187.2.camel@scrappy.miketc.com> Message-ID: <46DFFB0D.1030901@leemhuis.info> On 06.09.2007 14:29, Mike Chambers wrote: > On Thu, 2007-09-06 at 16:45 +0800, Ken YANG wrote: >> Thorsten Leemhuis wrote: > >>> Did you file a bug report or found one? I noticed the same when I >>> updated to rawhide some days ago, but didn't come around yet to ask >>> bugzilla about it. >> i had not file a bug, i think this sort of problem is obvious, and >> others will fix it in future, Well, you said you noticed it two weeks ago. So it seems it's not that obvious, as I'd say the developer would have fixed it already otherwise ;-) > [...] > I am using a rawhide install as of yesterday, and the menus and > backgrounds are there. For me it's only the MainMenu-Image for the "old-style" main-menu -- the one you have to manually add to the gnome-panel and not the default one with > In other words, maybe it just needs a refresh to get it back again? Worth a try -- I'll retest later and will file a bug if it's still happening to move this discussion where it belongs. CU knurd From lesmikesell at gmail.com Thu Sep 6 13:15:06 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 06 Sep 2007 08:15:06 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> Message-ID: <46DFFD5A.40609@gmail.com> Nicolas Mailhot wrote: > Le Jeu 6 septembre 2007 08:57, Les Mikesell a ?crit : >> How can that be >> if you don't keep track of the JVMs themselves? Or if the packages are >> supposed to be usable with unpackaged JVMs? > > They are *not* supposed to be usable with unpackaged JVMs. That seems philosophically very wrong. Somewhat like not being able to put an ogg file on your computer unless it is bundled with a known version of a known player packaged with the same packaging conventions. > Sorry. JPP > won't maintain a huge pile of workarounds just because vendors are too > lazy to follow common conventions and stick to them. Sometimes people > release an adaptation layer for a specific vendor jvm and yes this > layer is specific to this jvm but that's about it. That's not supposed to be the case. If you supply the right JAVA_HOME and start the right initial binary, it shouldn't matter where the actual location is or anything about how it was packaged. And in fact that is the case if you drop the sun binary under /usr/java and run things with it instead of the arbitrarily moved jpackage version that you have to have to do the app installs from the jpackage repo. >> I don't particularly care how the files are managed or where they >> live. > > Then you won't ever understand why something works or not and how to > fix your problems. By "don't care" I mean I consider it completely arbitrary and have no preference, not that I don't want to know. It's just annoying that the packaged location is different from what Sun uses in their RPM version and Sun should be somewhat of an authority on matters pertaining to java - and even more annoying that in this long chain of questions I still don't have the simple answer of where JAVA_HOME has been hidden for some small variety of JVMs. I _do_ want to know that, but don't have much interest in "understanding" arbitrary choices of paths that someone has already made. > The default is "just use the system jvm" if you > don't want to follow the defaults you have to understand the > conventions. That means reading the docs not deciding beforehand > what's relevant and what's not. Please, please - point me at the doc that says what JAVA_HOME is for some (any?) jvm that has been hidden in the alternatives scheme of symlinks. Preferable a document aimed at describing how to deal with an already made choice of location and execute it, not the philosophy of why the location and depth of symlinks that hide it was chosen. The only philosophical concept I'm interested in here is that more than one jvm can be run at once - and that should be expected if for nothing else but testing under the next JVM release while keeping the old version running in production. -- Les Mikesell lesmikesell at gmail.com From loupgaroublond at gmail.com Thu Sep 6 13:18:55 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 6 Sep 2007 09:18:55 -0400 Subject: Killing maintainers In-Reply-To: <686290.64972.qm@web60524.mail.yahoo.com> References: <645d17210709051440q1bd59f73q7cd0c2774311e781@mail.gmail.com> <686290.64972.qm@web60524.mail.yahoo.com> Message-ID: <7f692fec0709060618p7b1181c1uec4ed23db86209e0@mail.gmail.com> On 9/5/07, Timothy Spaulding wrote: > Seems to me that the "-maintainers must die" slogan is screaming to be > immortalized on a t-shirt soon. Kinda like "Vote for Pedro". :) Sorry for > the late gallows humor but it just struck me as funny. > Fedora 8 "-maintainers Edition" anyone? From buildsys at fedoraproject.org Thu Sep 6 13:32:13 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 6 Sep 2007 09:32:13 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-06 Message-ID: <20070906133214.03935152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 10 audio-convert-mod-3.45.2-1.fc6 ejabberd-1.1.3-11.fc6 em8300-kmod-0.16.3-1.2.6.22.4_45.fc6 GeoIP-1.4.3-1.fc6 hardinfo-0.4.2.2-7.fc6 NEW HippoDraw-1.21.1-2.fc6 : Interactive and Python scriptable data analysis application perl-ExtUtils-AutoInstall-0.63-6.fc6 NEW poster-20060221-4.fc6 : Scales PostScript images to span multiple pages xmlrpc-c-1.06.18-1.fc6 xtide-2.9.4-1.fc6 Changes in Fedora Extras 6: audio-convert-mod-3.45.2-1.fc6 ------------------------------ * Wed Sep 05 2007 Stewart Adam 3.45.2-1 - Update to 3.45.2 (see CHANGELOG file for details on version changes) - Fixes RH#277871 ejabberd-1.1.3-11.fc6 --------------------- * Tue Sep 04 2007 Jeffrey C. Ollie - 1.1.3-11 - Fix ejabberdctl wrapper script - #276071 * Wed Aug 22 2007 Jeffrey C. Ollie - 1.1.3-10 - Re-exclude ppc64 * Wed Aug 22 2007 Jeffrey C. Ollie - 1.1.3-9 - Fix license - Don't exclude ppc64 * Wed Aug 22 2007 Jeffrey C. Ollie - 1.1.3-8 - Bump & rebuild to build against latest erlang package. * Tue Jul 31 2007 Jeffrey C. Ollie - 1.1.3-7 - Bump release and rebuild due to Koji hiccups. em8300-kmod-0.16.3-1.2.6.22.4_45.fc6 ------------------------------------ * Wed Sep 05 2007 Ville Skytt? - Rebuild for kernel 2.6.22.4-45.fc6. GeoIP-1.4.3-1.fc6 ----------------- * Wed Sep 05 2007 Michael Fleming 1.4.3-1 - New upstream release - Small fixes to fetch scripts * Sun Apr 01 2007 Michael Fleming 1.4.2-1 - New upstream release. - Sync with devel - Fix dumb typo in fetch-geoipdata-city.pl hardinfo-0.4.2.2-7.fc6 ---------------------- * Wed Sep 05 2007 Adel Gadllah 0.4.2.2-6 - Fix libz location (/lib(64) vs /usr/lib(64)) HippoDraw-1.21.1-2.fc6 ---------------------- * Mon Jul 30 2007 Paul F. Kunz - 1.21-2 - Use exclude instead of ghost - declare file site_arch/hippo.pth only on 64 bit platforms perl-ExtUtils-AutoInstall-0.63-6.fc6 ------------------------------------ * Wed Sep 05 2007 Ralf Cors?pius - 0.63-6 - Update license tag. - BR: perl(ExtUtils::MakeMaker). - BR: perl(CPAN). poster-20060221-4.fc6 --------------------- * Mon Aug 27 2007 Lubomir Kundrak 20060221-4 - Multiple minor changes to clean up the SPEC to conform guidelines - Fix the License tag xmlrpc-c-1.06.18-1.fc6 ---------------------- * Tue Sep 04 2007 Enrico Scholz - 1.06.18-1 - updated to 1.06.18 xtide-2.9.4-1.fc6 ----------------- * Wed Sep 05 2007 Mamoru Tasaka - 2.9.4-1 - 2.9.4 (Relicensed: GPLv2+ -> GPLv3+) - Update user creation script * Wed Aug 22 2007 Mamoru Tasaka - 2.9.3-3.dist.2 - Mass rebuild (buildID or binutils issue) * Fri Aug 03 2007 Mamoru Tasaka - 2.9.3-3.dist.1 - License update From bpepple at fedoraproject.org Thu Sep 6 13:32:19 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 06 Sep 2007 09:32:19 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> Message-ID: <1189085539.24113.10.camel@kennedy> On Thu, 2007-09-06 at 14:03 +0100, Christopher Brown wrote: > > Those arguing in favour of leaving -maintainers open are not > subscribed to it (or have missed the rather long thread on the subject > - unlikely) so its difficult to understand how they can appreciate the > issue of crosstalk that is happening. Umm, no. As one of the three people moderating said list, doing a quick look at who has argued in favor of not closing the list, everyone of them is subscribed. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Thu Sep 6 12:54:21 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 6 Sep 2007 07:54:21 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <20070905222617.GA18296@psilocybe.teonanacatl.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> <20070905141957.GA17428@wolff.to> <20070905222617.GA18296@psilocybe.teonanacatl.org> Message-ID: <20070906125421.GA14723@wolff.to> On Wed, Sep 05, 2007 at 18:26:17 -0400, Todd Zullinger wrote: > > As of 1.5.15 the world turned inside out and upside down and mutt > grew support for SMTP: > > http://dev.mutt.org/trac/browser/ChangeLog#L1183 > > (The temperature in Hades may have even dropped by a few degrees, but > that's not confirmed. :) That news is a shocker. A long time ago, I used to follow the dev list and people seemed pretty adamant about it. (For what I think are good reasons.) > Are there a lot of mutt users who aren't capable of doing the needed > configuration to match their setup? It seems like one package that > could survive without a "hold the users hand" approach to the possible > things it might depend on. ;-) Where I work we have one or two. Professors who used command line from way back, but just knew enough about that to get their stuff done. Now they are reluctant to change. From billcrawford1970 at gmail.com Thu Sep 6 14:07:53 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 6 Sep 2007 15:07:53 +0100 Subject: Killing maintainers In-Reply-To: <686290.64972.qm@web60524.mail.yahoo.com> References: <645d17210709051440q1bd59f73q7cd0c2774311e781@mail.gmail.com> <686290.64972.qm@web60524.mail.yahoo.com> Message-ID: <544eb990709060707j263c70eo857b62285f20314c@mail.gmail.com> On 05/09/07, Timothy Spaulding wrote: > Seems to me that the "-maintainers must die" slogan is screaming to be > immortalized on a t-shirt soon. Kinda like "Vote for Pedro". :) Sorry for > the late gallows humor but it just struck me as funny. Only if we can have a "Credits" button in the installer ... and the credits made entirely from images of food :) Oh, and one of the maintainers of Anaconda should do a dance routine at the end. From snecklifter at gmail.com Thu Sep 6 14:09:24 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 6 Sep 2007 15:09:24 +0100 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189085539.24113.10.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> <1189085539.24113.10.camel@kennedy> Message-ID: <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> On 06/09/07, Brian Pepple wrote: > > On Thu, 2007-09-06 at 14:03 +0100, Christopher Brown wrote: > > > > Those arguing in favour of leaving -maintainers open are not > > subscribed to it (or have missed the rather long thread on the subject > > - unlikely) so its difficult to understand how they can appreciate the > > issue of crosstalk that is happening. > > Umm, no. As one of the three people moderating said list, doing a quick > look at who has argued in favor of not closing the list, everyone of > them is subscribed. Then whither ye voice in days of yore oh nay-sayers? -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpepple at fedoraproject.org Thu Sep 6 14:26:51 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 06 Sep 2007 10:26:51 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> <1189085539.24113.10.camel@kennedy> <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> Message-ID: <1189088811.24113.16.camel@kennedy> On Thu, 2007-09-06 at 15:09 +0100, Christopher Brown wrote: > On 06/09/07, Brian Pepple wrote: > Umm, no. As one of the three people moderating said list, > doing a quick > look at who has argued in favor of not closing the list, > everyone of > them is subscribed. > > Then whither ye voice in days of yore oh nay-sayers? Some of us actually have day jobs that don't involve Fedora, and haven't the time to comment on every thread. ;) Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From snecklifter at gmail.com Thu Sep 6 14:53:38 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 6 Sep 2007 15:53:38 +0100 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <1189088811.24113.16.camel@kennedy> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> <1189085539.24113.10.camel@kennedy> <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> <1189088811.24113.16.camel@kennedy> Message-ID: <364d303b0709060753g69f1ae8fqcbe64279966fa649@mail.gmail.com> On 06/09/07, Brian Pepple wrote: > > On Thu, 2007-09-06 at 15:09 +0100, Christopher Brown wrote: > > On 06/09/07, Brian Pepple wrote: > > Umm, no. As one of the three people moderating said list, > > doing a quick > > look at who has argued in favor of not closing the list, > > everyone of > > them is subscribed. > > > > Then whither ye voice in days of yore oh nay-sayers? > > Some of us actually have day jobs that don't involve Fedora, and haven't > the time to comment on every thread. ;) > Normally I would agree but: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00530.html was over two weeks ago and not one voice against until today. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From myfedora at richip.dhs.org Thu Sep 6 15:03:24 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 06 Sep 2007 09:03:24 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46DFA4C0.1000007@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> Message-ID: <1189091004.6909.6.camel@localhost6.localdomain6> On Thu, 2007-09-06 at 01:57 -0500, Les Mikesell wrote: > I could have sworn I ran into dependencies on specific JVM versions when > trying to install some packages from the jpackage repo. How can that be > if you don't keep track of the JVMs themselves? Or if the packages are > supposed to be usable with unpackaged JVMs? > > I don't particularly care how the files are managed or where they live. > I'm just trying to learn how to find what alternatives are available > and how to access them when certain apps require different JVMs and you > want to run them at the same time - and I haven't found much > documentation on the topic. As far as I know, there's the gcj version that comes with Fedora. Fedora 8 will / might have the IcedTea version but is already available for download from fedora-development (rawhide). If you scroll down to the "Non-Free" section of JPackage.org (http://www.jpackage.org/browser/browse.php?jppversion=1.7 or the older http://www.jpackage.org/browser/browse.php?jppversion=1.6), you'll find that there are JVMs available from Sun, IBM and BEA. Those JVMs aren't packaged with the binaries because of some licensing thing (I'm guessing). You'll have to download the packages from the source website and build the Fedora RPM packages using the nosrc.rpm's that JPackage provides. Those are the alternative JVMs that I'm aware of. I can see why they might put JVM-specific dependencies on some packages. I've had Eclipse break on me using IBM's JVM (ironically) but work on Sun's. JPackage just can't package the binaries. -- Richi Plana From ndbecker2 at gmail.com Thu Sep 6 15:17:41 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 06 Sep 2007 11:17:41 -0400 Subject: xorg-7.3 plans? Message-ID: xorg-7.3 is released, with support for hot-plugging. What is the roadmap for fedora? Will this be a post-f8 update? From mattdm at mattdm.org Thu Sep 6 15:49:21 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Sep 2007 11:49:21 -0400 Subject: calc ready for package review, for real Message-ID: <20070906154921.GA5448@jadzia.bu.edu> This has been hanging out in bugzilla for some time pending some upstream work. That's resolved, and I think the package is ready to go. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bruno at postle.net Thu Sep 6 16:42:57 2007 From: bruno at postle.net (Bruno Postle) Date: Thu, 6 Sep 2007 17:42:57 +0100 Subject: RFC: Naming guidelines for packages extending GIMP In-Reply-To: <1189067988.6847.22.camel@wombat.tiptoe.de> References: <1188984530.12274.55.camel@wombat.tiptoe.de> <20070905211518.GN4137@postle.net> <1189067988.6847.22.camel@wombat.tiptoe.de> Message-ID: <20070906164256.GU4137@postle.net> On Thu 06-Sep-2007 at 10:39 +0200, Nils Philippsen wrote: > > > > The fact that this is the first gimp plugin in fedora reminds me > > that fedora is very weak in this direction - Perhaps an 'imaging > > SIG' is needed? > > Good idea. What do we have to do for that? I guess come up with a goal and find some people who agree with it. -- Bruno From nicolas.mailhot at laposte.net Thu Sep 6 16:43:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Sep 2007 18:43:57 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <46DFFD5A.40609@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> Message-ID: <1189097037.3949.12.camel@rousalka.dyndns.org> Le jeudi 06 septembre 2007 ? 08:15 -0500, Les Mikesell a ?crit : > That seems philosophically very wrong. ... > That's not supposed to be the case. ... > It's just annoying that the > packaged location is different from what Sun uses ... > and Sun should be somewhat of an authority on matters pertaining to java 1. You're welcome to found a better designed Java packaging project. 2. SUN didn't care at all about the Java deployment problem space till it got sidelined by .Net and OSGi/Eclipse on the other. SUN's solution to the problem is JSR 277, which won't be deployed anywhere before Java 7 (mid-2008 at the earliest) and it remains to be seen if it will fly, crash or be rpm-compatible. > - and even more annoying that in this long chain of questions I still > don't have the simple answer You were given information but chose not to listen. I won't waste any more time on the subject. -- 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 krh at redhat.com Thu Sep 6 17:24:07 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Thu, 06 Sep 2007 13:24:07 -0400 Subject: xorg-7.3 plans? In-Reply-To: References: Message-ID: <1189099447.3423.2.camel@hinata.boston.redhat.com> On Thu, 2007-09-06 at 11:17 -0400, Neal Becker wrote: > xorg-7.3 is released, with support for hot-plugging. What is the roadmap > for fedora? Will this be a post-f8 update? Yes. cheers, Kristian From tmz at pobox.com Thu Sep 6 17:35:07 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 6 Sep 2007 13:35:07 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <20070906125421.GA14723@wolff.to> References: <1188923882.12969.36.camel@localhost6.localdomain6> <20070904165703.GB30334@nostromo.devel.redhat.com> <1188926548.12969.64.camel@localhost6.localdomain6> <20070905141957.GA17428@wolff.to> <20070905222617.GA18296@psilocybe.teonanacatl.org> <20070906125421.GA14723@wolff.to> Message-ID: <20070906173507.GA22506@psilocybe.teonanacatl.org> Bruno Wolff III wrote: > On Wed, Sep 05, 2007 at 18:26:17 -0400, Todd Zullinger > wrote: >> >> As of 1.5.15 the world turned inside out and upside down and mutt >> grew support for SMTP: [...] > That news is a shocker. A long time ago, I used to follow the dev > list and people seemed pretty adamant about it. (For what I think > are good reasons.) Yeah, I figured that the change would be a surprise to some long time mutt users. >> Are there a lot of mutt users who aren't capable of doing the >> needed configuration to match their setup? It seems like one >> package that could survive without a "hold the users hand" approach >> to the possible things it might depend on. ;-) > > Where I work we have one or two. Professors who used command line > from way back, but just knew enough about that to get their stuff > done. Now they are reluctant to change. FWIW, I think that the smtp support will make it easier for users like those professors to configure mutt. Most folks are acustomed to plugging in the info on where to send as well as where to receive mail in their MUA's. It seems scads simpler to set an smtp url than to setup sendmail. Anyway, now you've got a heads up on the change so if you're the guy that'll be helping out the professors you'll know what's coming. ;-) (Thanks to Miroslav Lichvar for updating the mutt rpm, BTW.) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. -- Edward Abbey -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tmz at pobox.com Thu Sep 6 17:38:49 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 6 Sep 2007 13:38:49 -0400 Subject: How to satisfy BuildRequires automatically while rebuilding from SRPM? In-Reply-To: <20070906072402.639f8add@ender> References: <20070906072402.639f8add@ender> Message-ID: <20070906173849.GB22506@psilocybe.teonanacatl.org> Jesse Keating wrote: > On Thu, 6 Sep 2007 15:25:35 +0400 > "Peter Lemenkov" wrote: > >> Hello All! >> Subj. > > Use mock. Mock is definitely the best answer. But for completeness, another option is yum-builddep from the yum-utils package. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When a stupid man is doing something he is ashamed of, he always declares that it is his duty. -- George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ajackson at redhat.com Thu Sep 6 17:33:11 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 06 Sep 2007 13:33:11 -0400 Subject: xorg-7.3 plans? In-Reply-To: References: Message-ID: <1189099991.24181.3745.camel@localhost.localdomain> On Thu, 2007-09-06 at 11:17 -0400, Neal Becker wrote: > xorg-7.3 is released, with support for hot-plugging. What is the roadmap > for fedora? Will this be a post-f8 update? Since we're well past feature freeze for F8, this will not land until F9's rawhide cycle. We've included many of the other components, but the X server itself will remain at 1.3 for F8. - ajax From smooge at gmail.com Thu Sep 6 17:46:01 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 6 Sep 2007 11:46:01 -0600 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <364d303b0709060753g69f1ae8fqcbe64279966fa649@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> <1189085539.24113.10.camel@kennedy> <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> <1189088811.24113.16.camel@kennedy> <364d303b0709060753g69f1ae8fqcbe64279966fa649@mail.gmail.com> Message-ID: <80d7e4090709061046q7f749805s1404aeb000920b43@mail.gmail.com> On 9/6/07, Christopher Brown wrote: > > > On 06/09/07, Brian Pepple wrote: > > On Thu, 2007-09-06 at 15:09 +0100, Christopher Brown wrote: > > > On 06/09/07, Brian Pepple wrote: > > > Umm, no. As one of the three people moderating said list, > > > doing a quick > > > look at who has argued in favor of not closing the list, > > > everyone of > > > them is subscribed. > > > > > > Then whither ye voice in days of yore oh nay-sayers? > > > > Some of us actually have day jobs that don't involve Fedora, and haven't > > the time to comment on every thread. ;) > > > > Normally I would agree but: > > https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00530.html > > was over two weeks ago and not one voice against until today. > Yes.. at 2 weeks I would say that even if you are subscribed to a list.. if you aren't reading it or replying to important threads.. you aren't really a part of the list. If you have to wait until the discussion is moved over to the one you do care about.. then that is further argument that the other list is not important. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Thu Sep 6 18:06:51 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 06 Sep 2007 14:06:51 -0400 Subject: How to satisfy BuildRequires automatically while rebuilding from SRPM? In-Reply-To: <20070906173849.GB22506@psilocybe.teonanacatl.org> References: <20070906072402.639f8add@ender> <20070906173849.GB22506@psilocybe.teonanacatl.org> Message-ID: <1189102011.16157.61.camel@cutter> On Thu, 2007-09-06 at 13:38 -0400, Todd Zullinger wrote: > Jesse Keating wrote: > > On Thu, 6 Sep 2007 15:25:35 +0400 > > "Peter Lemenkov" wrote: > > > >> Hello All! > >> Subj. > > > > Use mock. > > Mock is definitely the best answer. But for completeness, another > option is yum-builddep from the yum-utils package. > mock ensures you have a clean chroot with ONLY the builddeps. Much more precise than yum-builddep. -sv From fedora at leemhuis.info Thu Sep 6 18:28:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 20:28:22 +0200 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46DEE0D0.2070209@fedoraproject.org> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> Message-ID: <46E046C6.4050908@leemhuis.info> On 05.09.2007 19:01, Rahul Sundaram wrote: > Brian Pepple wrote: >> Hi, >> >> Please find below the list of topics that are likely to come up in the >> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC >> in #fedora-meeting on irc.freenode.org: >> >> /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: >> http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 > > Is the alternative proposal using DKMS at > http://fedoraproject.org/wiki/JefSpaleta/DKMSProposal being discussed too? Well, I think lots of the reasons against Kmod's are similar for dkms (or any other packaging standard for kernel modules); quoting some part from http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal below: > There is no justification for shipping kernel modules as separate packages within Fedora. If code is good enough to ship, it should be shipped in the kernel packageIf it's not, then it should not be shipped at all with the 'Fedora' name on it. Same for kernel modules packages of all kind. > Kernel module packages just cause gratuitous complexity for RPM/YUM and for users, without any real benefit. dynamically building modules on users is IMHO also "gratuitous complexity". One of the reasons: modules now and then simply won't compile anymore when the kernel-api changes; thus dkms tries to rebuild the modules on lots of systems and will fail on lots of systems. > Where there are certain drivers which are almost ready to be merged upstream and which Fedora would benefit from shipping, we have always managed to do that. [...] Same for dkms > Instead of shipping kmod packages, we should consider adding patches to the kernel RPM instead. [...] Same for dkms > The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. Same for dkms, as modules might break if the api changed. -- Further: the rules for including kmods in Fedora were and are quite strict. They were the main reason why we only had two kmod's (which was one of the reasons why we stopped developing kmod's further). So if those rules won't change (which I doubt) it's IMHO not worth investing work in another ruleset for kernel modules in Fedora. Just my 2 cent. CU knurd P.S.: No, I don't have anything against dkms in particular -- dkms or a dkms-like solution in combination with pre-compiled module packages (/like kmods or kmdls) are IMHO what we should aim for. But I agree with dwmw2 that Fedoras proper repos are not the place for it anymore. It was something different when we had Core and Extras separated. From jspaleta at gmail.com Thu Sep 6 18:43:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Sep 2007 10:43:59 -0800 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E046C6.4050908@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> Message-ID: <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> > > The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. > > Same for dkms, as modules might break if the api changed. slightly less complex for dkms, because with dkms you don't have to deal with synchronously building the modules on the central build system. You package dkms source payloads and you let dkms attempt to build the modules locally as soon as a new kernel is installed. (dkms can even build rpms locally too to populate the rpmdb for tracking purposes) I think dkms works as a piece of technology as far as it can. The question really is, would providing dkms source payloads in Fedora help drive mainlining of kernel modules or does it discourage the necessary upstream discussions. If providing dkms source payloads can help move things into upstream via feedback, then I'm all for it. But if its just going to be a way for people to get around the hard work of getting a module upstreamed, then I'm not for it. Which is why I'd be interested in setting an explicit expiration date for any dkms payload. I don't want to see this stuff linger as an external module indefinitely. I want to see progress towards adoption, and if there's no progress than we drop the dkms payload package. -jef From caillon at redhat.com Thu Sep 6 19:23:34 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 06 Sep 2007 15:23:34 -0400 Subject: XULRunner status In-Reply-To: References: Message-ID: <46E053B6.8080904@redhat.com> Michel Salim wrote: > Hello, > > Is XULRunner still intended to be included in Fedora 8? Yes, though it's getting bogged down with building churn. > openSUSE has > been using it since at least 10.2 (late last year) -- they don't build > Firefox off it, but applications like Liferea are built against > xulrunner, which makes it much easier to release Firefox security > updates without triggering rebuilds of dependent apps. Because they don't ship updates to their XULRunner 1.8.0.4(?) which would be equivalent to Firefox 1.5.0.4, security warts and all. There are something like 30+ critical unfixed security holes in their version last I looked which in turn affect apps such as liferea, though I'm guessing not all would affect all apps equally. From florin at andrei.myip.org Thu Sep 6 19:34:40 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 06 Sep 2007 12:34:40 -0700 Subject: memory leak, possibly xorg? In-Reply-To: <1188425774.5003.0.camel@localhost.localdomain> References: <46D5E7E1.7000807@andrei.myip.org> <1188425774.5003.0.camel@localhost.localdomain> Message-ID: <46E05650.60708@andrei.myip.org> Dave Airlie wrote: > > Please try using xrestop to see if one application is abusing X as > swap... I'm looking at firefox.. top: 30754 root 20 0 1302m 1.1g 7304 S 2 54.6 10:39.73 Xorg 2856 fandrei 20 0 578m 224m 15m S 0 11.1 2:56.83 thunderbird-bin 2877 fandrei 20 0 283m 136m 21m S 1 6.7 10:29.76 firefox-bin xrestop: 3800000 269 57 1 3251 214 1263922K 13K 1263936K 2877 KernelTrap | Kernel news - Mozilla Firefox 3600000 229 59 1 84 100 3967K 10K 3977K 2856 fedora-devel for florin at XXXXXXXXXXXX - Thunderbird What's next? -- Florin Andrei http://florin.myip.org/ From bpepple at fedoraproject.org Thu Sep 6 19:45:15 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 06 Sep 2007 15:45:15 -0400 Subject: FESCo Meeting Summary for 2007-09-06 Message-ID: <1189107915.24113.36.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jeremy Katz (jeremy) * Jesse Keating (f13) * Christian Iseli (c4chris) * Christopher Aillon (caillon) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Josh Boyer (jwb) * Tom Callaway (spot) Members Absent * David Woodhouse (dwmw2) * Warren Togami (warren) == Summary == == Bluetooth Feature Proposal == * Bastien Nocera (hadess) attended the meeting to appeal the recent FESCo decision to remove Bluetooth from the new features list for F8. After being apprised of the the changes for Bluetooth support, FESCo agreed to reverse it's prior decision. For more information about the Bluetooth improvements please refer to: http://fedoraproject.org/wiki/Releases/FeatureBluetooth == Bodhi Enhancements == * Luke Macken (lmacken) discussed some enhancements to Bodhi that should be coming shortly: * A nag mail will be sent to maintainers if a package update is left in testing for certain length of time. * Auto pushing of packages after receiving 3 karma votes. == Buildroot Changes == * f13 is going to implement the changes to the buildroot that were discussed in the 2007-08-30 FESCo meeting. == Compat Policy == * jeremy is still working on this, and will try to have something for next week. == Closing Maintainers List == * After a long discussion, it was decided to close the fedora-maintainers-list. In the future maintainer discussions will be conducted on the fedora-devel-list. bpepple will send a notice out announcing this. == Features Update == * FESCo discussed the status of the NetworkManger, xulrunner, and generic-logos features. For more details, please refer to the IRC log. IRC log can be found at: http://bpepple.fedorapeople.org/FESCo-2007-09-06.html Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu Sep 6 20:15:44 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 06 Sep 2007 15:15:44 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189097037.3949.12.camel@rousalka.dyndns.org> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> <1189097037.3949.12.camel@rousalka.dyndns.org> Message-ID: <46E05FF0.5070904@gmail.com> Nicolas Mailhot wrote: > Le jeudi 06 septembre 2007 ? 08:15 -0500, Les Mikesell a ?crit : > >> That seems philosophically very wrong. > > ... Do you disagree with the idea that a JVM executing java bytecode should be very much like a media player playing a media file? That is, installing the data should not be dependent on having some particular player or JVM available that might or might not be used to manipulate it later. Why can't I have the app before the JVM or supply my own JVM? >> That's not supposed to be the case. > > ... > >> It's just annoying that the >> packaged location is different from what Sun uses > > ... > >> and Sun should be somewhat of an authority on matters pertaining to java > > 1. You're welcome to found a better designed Java packaging project. Do any of them understand that unix-like systems are multi-tasking and multi-user by nature, and that some of those multiple tasks and multiple user preferences are going to be different versions of the same thing on the same machine at the same time? Apparently you do really get this at the application level if you were involved in building the packaged tomcat4/tomcat55 versions that can co-exist and do provide an obvious way to let the user distinguish between them. > 2. SUN didn't care at all about the Java deployment problem space till > it got sidelined by .Net and OSGi/Eclipse on the other. SUN's solution > to the problem is JSR 277, which won't be deployed anywhere before Java > 7 (mid-2008 at the earliest) and it remains to be seen if it will fly, > crash or be rpm-compatible. What does that mean? Sun has had downloadable RPMs for a long time. Jpackage just doesn't work with them due to arbitrarily different locations. And I don't see why there is any more relationship between the apps and the jvm than there would be between a source package and any number of compilers that might be used with it later. >> - and even more annoying that in this long chain of questions I still >> don't have the simple answer > > You were given information but chose not to listen. I won't waste any > more time on the subject. No one has given a usable answer for even a single value of JAVA_HOME for a single packaged jvm version. Or the location of the document that provides this necessary information. I'm sorry if that was too much to ask. -- Les Mikesell lesmikesll at gmail.com From jon.nettleton at gmail.com Thu Sep 6 20:17:57 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 6 Sep 2007 16:17:57 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> Message-ID: On 9/6/07, Jeff Spaleta wrote: > > > The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. > > > > Same for dkms, as modules might break if the api changed. > > slightly less complex for dkms, because with dkms you don't have to > deal with synchronously building the modules on the central build > system. You package dkms source payloads and you let dkms attempt to > build the modules locally as soon as a new kernel is installed. (dkms > can even build rpms locally too to populate the rpmdb for tracking > purposes) > > I think dkms works as a piece of technology as far as it can. The > question really is, would providing dkms source payloads in Fedora > help drive mainlining of kernel modules or does it discourage the > necessary upstream discussions. If providing dkms source payloads can > help move things into upstream via feedback, then I'm all for it. But > if its just going to be a way for people to get around the hard work > of getting a module upstreamed, then I'm not for it. Which is why I'd > be interested in setting an explicit expiration date for any dkms > payload. I don't want to see this stuff linger as an external module > indefinitely. I want to see progress towards adoption, and if there's > no progress than we drop the dkms payload package. > The other piece that is needed for dkms is a yum plugin that can detect when kernel is updated and then run the dkms installer against it. This will allow three things to happen. The first is that if a module fails to compile then grubby can select the old kernel for booting. Secondly we can give some feedback to the user that the dkms update failed. Reboots after a kernel update won't take really long. Jon From opensource at till.name Thu Sep 6 20:20:18 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Sep 2007 22:20:18 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189107915.24113.36.camel@kennedy> References: <1189107915.24113.36.camel@kennedy> Message-ID: <200709062220.23518.opensource@till.name> On Do September 6 2007, Brian Pepple wrote: > == Summary == It would be useful if you also list the items that are deferred, e.g. a kmod decision, to make it obvious that it is not missing unintentionally in the summary. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jspaleta at gmail.com Thu Sep 6 20:41:12 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Sep 2007 12:41:12 -0800 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> Message-ID: <604aa7910709061341s1ee3b82ag7250ece8c6479730@mail.gmail.com> On 9/6/07, Jon Nettleton wrote: > The other piece that is needed for dkms is a yum plugin that can > detect when kernel is updated and then run the dkms installer against > it. Uhm no... not a yum plugin.. a change in the script that is used in a kernel packages postinstall scriptlet to be dkms aware. Doing this in yum makes absolutely no since. -jef From jon.nettleton at gmail.com Thu Sep 6 20:51:46 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 6 Sep 2007 16:51:46 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <604aa7910709061341s1ee3b82ag7250ece8c6479730@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <604aa7910709061341s1ee3b82ag7250ece8c6479730@mail.gmail.com> Message-ID: On 9/6/07, Jeff Spaleta wrote: > On 9/6/07, Jon Nettleton wrote: > > The other piece that is needed for dkms is a yum plugin that can > > detect when kernel is updated and then run the dkms installer against > > it. > > Uhm no... not a yum plugin.. a change in the script that is used in a > kernel packages postinstall scriptlet to be dkms aware. Doing this in > yum makes absolutely no since. > Wherever as long as there is a way to install a kernel and not run dkms afterwards. Jon From opensource at till.name Thu Sep 6 20:55:24 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Sep 2007 22:55:24 +0200 Subject: kernel modules/kmods/dkms In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <604aa7910709061341s1ee3b82ag7250ece8c6479730@mail.gmail.com> Message-ID: <200709062255.31701.opensource@till.name> On Do September 6 2007, Jon Nettleton wrote: > Wherever as long as there is a way to install a kernel and not run > dkms afterwards. There is already a bug filed including this: https://bugzilla.redhat.com/show_bug.cgi?id=250377 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jspaleta at gmail.com Thu Sep 6 20:58:43 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Sep 2007 12:58:43 -0800 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <604aa7910709061341s1ee3b82ag7250ece8c6479730@mail.gmail.com> Message-ID: <604aa7910709061358ga991ac7pfb5e02da69a1b873@mail.gmail.com> On 9/6/07, Jon Nettleton wrote: > Wherever as long as there is a way to install a kernel and not run > dkms afterwards. look at the /sbin/new-kernel-pkg script Whether or not we actually decide to package dkms source payloads. Dkms users would benefit from enhancing that script to be dkms aware and to kick off rebuilds. We already have dkms packaged if Fedora, so such an enhancement isn't out of line even if we do not provide the payloads from the main fedora repository aa matter of policy. -jef From michel.sylvan at gmail.com Thu Sep 6 21:19:30 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 6 Sep 2007 17:19:30 -0400 Subject: Fwd: Killing maintainers In-Reply-To: References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> <20070905173132.655bc3ae@mentok.boston.redhat.com> Message-ID: On 05/09/07, Jesse Keating wrote: > On Wed, 5 Sep 2007 22:26:24 +0100 > "Jonathan Underwood" wrote: > > > What is the quickest way of getting this done? Which of the myriad > > committees does this need to go through? > > I will be pushing this through FESCo tomorrow. > If the mailing list software allows the use of +FOO suffix, an alternative to mailing list proliferation is to have a main -devel-list (like now), with major subcategories suffixed at the end? People can then filter and prioritize their list messages accordingly. Cheers, -- Michel ps right now it does not support "implicit destinations" like this -- I just tested it From ajackson at redhat.com Thu Sep 6 21:19:40 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 06 Sep 2007 17:19:40 -0400 Subject: libXaw6 Message-ID: <1189113580.24181.3748.camel@localhost.localdomain> I've moved libXaw6 to a compat subpackage. This shouldn't break anyone, nothing in the distro uses it, and if you're using the autoprovides generator you'll still get the package you need by soname. But it's one less dead library installed by default, so, yay. - ajax From buildsys at redhat.com Thu Sep 6 22:16:22 2007 From: buildsys at redhat.com (Build System) Date: Thu, 6 Sep 2007 18:16:22 -0400 Subject: rawhide report: 20070906 changes Message-ID: <200709062216.l86MGMVB003039@porkchop.devel.redhat.com> New package cjkunifonts Chinese TrueType Fonts -- Simplified and Traditional Chinese Ming and Kai Face Updated Packages: anaconda-11.3.0.28-1 -------------------- * Wed Sep 05 2007 Jeremy Katz - 11.3.0.28-1 - Make sure we find out about all nics (dcantrell) - Hard drive install fixing (clumens, #287241) - Make sure iniparse is in the image (notting, #276941) - Add the short hostname to the localhost entry (dcantrell, #253979) * Tue Sep 04 2007 Chris Lumens 11.3.0.27-1 - Honor hostname= command line option (dcantrell, #186560). - Set the hostname if provided by the user or by DHCP (dcantrell, #180451). - Blacklist floppy and iscsi modules (notting). - Fix traceback on GUI network config screen (dcantrell). - Kickstart networking interface fixes (dcantrell, #260621). - Don't traceback when reading kickstart post scripts (#276851). - On kickstart installs, output the incoming packages section to anaconda-ks.cfg. audit-1.6.1-1.fc8 ----------------- * Sun Sep 02 2007 Steve Grubb 1.6.1-1 - External plugin support in place - Fix reference counting in auparse python bindings (#263961) - Moved default af_unix plugin socket to /var/run/audispd_events desktop-backgrounds-7.92-3 -------------------------- * Wed Sep 05 2007 Ray Strode - 7.92-3 - create links for default.png etc until more artwork shows up - start animated backgrounds at midnight fedora-logos-7.92.0-4.fc8 ------------------------- * Wed Sep 05 2007 Jeremy Katz - 7.92.0-4 - merge back changes that got lost fonts-chinese-3.03-10.fc8 ------------------------- * Fri Aug 31 2007 Jens Petersen - 3.03-10.fc8 - finish moving Uming and Ukai truetype fonts over to cjkunifonts (#266281): - update summary and description - drop scriptlets and their requires - require new cjkunifonts-uming and cjkunifonts-ukai - version ttfonts-zh_CN and ttfonts-zh_TW obsoletes - run mkfontdir at buildtime and don't ghost fonts.dir - don't generate fonts.scale * Thu Aug 30 2007 Caius Chance - Resolves: rhbz#266281 (Remove uming and ukai from fonts-chinese.) -- remove ttfontdir and cidmapdir -- update license to Public Domain for taipeifonts -- remove /usr/share/fonts/zh_*/TrueType/ compat dirs -- remove fc-cache from post and postun scriptlets gimp-2:2.4.0-0.rc2.1.fc8 ------------------------ * Tue Sep 04 2007 Nils Philippsen - 2:2.4.0-0.rc2.1 - version 2.4.0-rc2 pavucontrol-0.9.5-0.3.svn20070905.fc8 ------------------------------------- * Wed Sep 05 2007 Lennart Poettering 0.9.5-0.3.svn20070905 - Add versioned dependency on pulseaudio-libs * Wed Sep 05 2007 Lennart Poettering 0.9.5-0.2.svn20070905 - Update from SVN snapshot * Thu Aug 16 2007 Lennart Poettering 0.9.5-0.1.svn20070816 - Update from SVN snapshot pulseaudio-0.9.7-0.10.svn20070905.fc8 ------------------------------------- * Wed Sep 05 2007 Lennart Poettering 0.9.7-0.10.svn20070905 - Update SVN snapshot * Tue Sep 04 2007 Lennart Poettering 0.9.7-0.9.svn20070904 - Update SVN snapshot - ship libflashsupport in our package - drop pulseaudio-devel since libpulsecore is not linked statically pykickstart-1.12-1.fc8 ---------------------- * Tue Sep 04 2007 Chris Lumens 1.12-1 - Fix lots of problems in processing the bootloader, device, network, and raid commands. - Add %end when writing out scripts and packages. - Add a makefile target to run pychecker to cut down on errors in releases. system-config-firewall-1.0.5-4.fc8 ---------------------------------- * Wed Sep 05 2007 Thomas Woerner 1.0.5-4 - fixed problem if /etc/sysconfig/system-config-securtylevel and /etc/sysconfig/system-config-firewall are not readable Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From mschwendt.tmp0701.nospam at arcor.de Thu Sep 6 22:36:16 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 00:36:16 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <20070827192643.GB24132@free.fr> References: <20070827192643.GB24132@free.fr> Message-ID: <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> On Mon, 27 Aug 2007 21:26:43 +0200, Patrice Dumas wrote: > Hello, > > Sometime there are obsolete of older packages by compat packages. The > idea is that when coming from an old package a compatible package is > needed. This is what is done in automake16. It is a compat package, and > it has > > Obsoletes: automake = 1.6.3 > > It makes sense, however I am not sure that it is that right, since > somebody having automake-1.6.3-* would also want to have the latest > automake version. > > Another issue is that for this scheme to be really effective, one should > have in automake15 > Obsoletes: automake < 1.6.0 and automake >= 1.5.0 > > and in automake16 > Obsoletes: automake < 1.7.0 and automake >= 1.6.0 > > which, unless I am wrong, cannot be done in rpm. As in the range 1.5.0 <= x < 1.6.0 ? I don't think that is possible with "Obsoletes". With Requires it is different, since all Requires must be satisfied. > So, what do you think? Is that practice wrong, right, or should it be > left to the maintainer? > > I would personally think that it is wrong, it could be right if one could > express that when updating 1.6.x, this package should be installed in > addition to the latest package with same name. IMO it is right. "Obsoletes" in compat packages is used to rename a package, to move it from the old name to the new name. It doesn't matter whether there is a separate package that upgrades the old one: automake = 1.6.3 renamed to automake16 = 1.6.3 automake = 1.10 replaces automake = 1.6.3 Also consider that a manual "rpm -Uvh automake16*.rpm" should get rid of the obsolete automake = 1.6.3, too, when they cannot coexist. The version upgrade can be requested on demand. From nicolas.mailhot at laposte.net Thu Sep 6 22:45:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 07 Sep 2007 00:45:49 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> References: <20070827192643.GB24132@free.fr> <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1189118749.3949.17.camel@rousalka.dyndns.org> Le vendredi 07 septembre 2007 ? 00:36 +0200, Michael Schwendt a ?crit : > As in the range 1.5.0 <= x < 1.6.0 ? > I don't think that is possible with "Obsoletes". > With Requires it is different, since all Requires must be satisfied. No it's not, since rpm is lacking true version range support you only need package A providing foo = 1.4.0 and package B foo = 1.8.0 to fool Requires 1.5.0 <= foo < 1.6.0 -- 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 mschwendt.tmp0701.nospam at arcor.de Thu Sep 6 23:04:20 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 01:04:20 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <1189118749.3949.17.camel@rousalka.dyndns.org> References: <20070827192643.GB24132@free.fr> <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> <1189118749.3949.17.camel@rousalka.dyndns.org> Message-ID: <20070907010420.19a40ddc.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Sep 2007 00:45:49 +0200, Nicolas Mailhot wrote: > > Le vendredi 07 septembre 2007 ? 00:36 +0200, Michael Schwendt a ?crit : > > > As in the range 1.5.0 <= x < 1.6.0 ? > > I don't think that is possible with "Obsoletes". > > With Requires it is different, since all Requires must be satisfied. > > No it's not, since rpm is lacking true version range support you only > need package A providing foo = 1.4.0 and package B foo = 1.8.0 to fool > Requires 1.5.0 <= foo < 1.6.0 Not that notation. But Requires: foo >= 1.5.0 Requires: foo < 1.6.0 does not work? It must be Requires: foo >= 1.5.0 Conflicts: foo >= 1.6.0 ? From rc040203 at freenet.de Thu Sep 6 22:56:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 00:56:23 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189107915.24113.36.camel@kennedy> References: <1189107915.24113.36.camel@kennedy> Message-ID: <1189119383.24848.696.camel@mccallum.corsepiu.local> On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > == Closing Maintainers List == > * After a long discussion, it was decided to close the > fedora-maintainers-list. In the future maintainer discussions > will be conducted on the fedora-devel-list. bpepple will send a > notice out announcing this. Given this decision, I would like to propose to also close down * fedora-test-list@: Rationale: There can't be a clear separation between testing and development. testing is part of development and maintaining packages. * fedora-packaging@: Packaging and discussing details of packages are part of a distribution's development. It doesn't make sense to keep specialized lists for these topics. Ralf From myfedora at richip.dhs.org Thu Sep 6 23:17:35 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 06 Sep 2007 17:17:35 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46E05FF0.5070904@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> <1189097037.3949.12.camel@rousalka.dyndns.org> <46E05FF0.5070904@gmail.com> Message-ID: <1189120655.6909.23.camel@localhost6.localdomain6> On Thu, 2007-09-06 at 15:15 -0500, Les Mikesell wrote: > Nicolas Mailhot wrote: > > Le jeudi 06 septembre 2007 ? 08:15 -0500, Les Mikesell a ?crit : > > > >> That seems philosophically very wrong. > > > > ... > > Do you disagree with the idea that a JVM executing java bytecode should > be very much like a media player playing a media file? That is, > installing the data should not be dependent on having some particular > player or JVM available that might or might not be used to manipulate it > later. Why can't I have the app before the JVM or supply my own JVM? Probably not the best example. A piece of data (a media file in your example) has so many different kinds of applications associated with it, some might even be on different systems and the data is exported via a number of means (http, nfs, etc.) Java bytecode, unless they're applets, are much easier to predict requirements for. There is a huge probability that they will need a JVM, and unlike media players, from outside, they're designed to function in the same way. As examples go, it's closer to say that JVMs are to Java applications or even just bytecode what glibc is to native applications. In Fedora, openoffice.org-core-2.2.0 Requires the virtual package java. You CAN have the app before the JVM, I suppose, the same way you can "rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be bytes taking up space in your filesystem. > No one has given a usable answer for even a single value of JAVA_HOME > for a single packaged jvm version. Or the location of the document that > provides this necessary information. I'm sorry if that was too much to > ask. Honestly, I tried to answer here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00396.html), here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00414.html) and here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00490.html), but I guess I'm misunderstanding the question. -- Richi Plana From jwboyer at jdub.homelinux.org Thu Sep 6 23:21:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 6 Sep 2007 18:21:49 -0500 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189119383.24848.696.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> Message-ID: <20070906182149.40029fc5@vader.jdub.homelinux.org> On Fri, 07 Sep 2007 00:56:23 +0200 Ralf Corsepius wrote: > On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > > > == Closing Maintainers List == > > * After a long discussion, it was decided to close the > > fedora-maintainers-list. In the future maintainer discussions > > will be conducted on the fedora-devel-list. bpepple will send a > > notice out announcing this. > Given this decision, I would like to propose to also close down > * fedora-test-list@: > Rationale: There can't be a clear separation between testing and > development. testing is part of development and maintaining packages. > > * fedora-packaging@: Packaging and discussing details of packages are > part of a distribution's development. It doesn't make sense to keep > specialized lists for these topics. We can discuss this at next week's FESCo meeting if you would like. josh From rc040203 at freenet.de Thu Sep 6 23:30:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 01:30:58 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <20070906182149.40029fc5@vader.jdub.homelinux.org> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> Message-ID: <1189121458.24848.703.camel@mccallum.corsepiu.local> On Thu, 2007-09-06 at 18:21 -0500, Josh Boyer wrote: > On Fri, 07 Sep 2007 00:56:23 +0200 > Ralf Corsepius wrote: > > > On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > > > > > == Closing Maintainers List == > > > * After a long discussion, it was decided to close the > > > fedora-maintainers-list. In the future maintainer discussions > > > will be conducted on the fedora-devel-list. bpepple will send a > > > notice out announcing this. > > Given this decision, I would like to propose to also close down > > * fedora-test-list@: > > Rationale: There can't be a clear separation between testing and > > development. testing is part of development and maintaining packages. > > > > * fedora-packaging@: Packaging and discussing details of packages are > > part of a distribution's development. It doesn't make sense to keep > > specialized lists for these topics. > > We can discuss this at next week's FESCo meeting if you would like. Yes, please do so - Put it on your schedule. This meant to be a serious proposal and is not a knee-jerk reaction[1]. You've decided to kill maintainers@, now you should be consequent and kill these lists, too. Ralf [1] IMO, this FESCO decision is a fault and mistake, we all will regret. It molests maintainers with long term development babbling and molests "application developers" with "bureaucracy of Fedora package maintenance" - It's not helpful to both parties. From kevin.kofler at chello.at Thu Sep 6 23:50:59 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 6 Sep 2007 23:50:59 +0000 (UTC) Subject: FESCo Meeting Summary for 2007-09-06 References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > It molests maintainers with long term development babbling and molests > "application developers" with "bureaucracy of Fedora package > maintenance" - It's not helpful to both parties. Well, the biggest problem with -maintainers was that it was only postable through on subscription (which also kept people from using tools like the GMane NNTP and web interfaces) and that subscription was essentially limited to existing maintainers (which kept not only the random users out, but even people with legitimate content to post). Kevin Kofler From jwboyer at jdub.homelinux.org Thu Sep 6 23:55:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 6 Sep 2007 18:55:10 -0500 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189121458.24848.703.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> Message-ID: <20070906185510.54e572b3@vader.jdub.homelinux.org> On Fri, 07 Sep 2007 01:30:58 +0200 Ralf Corsepius wrote: > On Thu, 2007-09-06 at 18:21 -0500, Josh Boyer wrote: > > On Fri, 07 Sep 2007 00:56:23 +0200 > > Ralf Corsepius wrote: > > > > > On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > > > > > > > == Closing Maintainers List == > > > > * After a long discussion, it was decided to close the > > > > fedora-maintainers-list. In the future maintainer discussions > > > > will be conducted on the fedora-devel-list. bpepple will send a > > > > notice out announcing this. > > > Given this decision, I would like to propose to also close down > > > * fedora-test-list@: > > > Rationale: There can't be a clear separation between testing and > > > development. testing is part of development and maintaining packages. > > > > > > * fedora-packaging@: Packaging and discussing details of packages are > > > part of a distribution's development. It doesn't make sense to keep > > > specialized lists for these topics. > > > > We can discuss this at next week's FESCo meeting if you would like. > Yes, please do so - Put it on your schedule. > > This meant to be a serious proposal and is not a knee-jerk reaction[1]. > You've decided to kill maintainers@, now you should be consequent and > kill these lists, too. I'll be sure it's discussed. > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > It molests maintainers with long term development babbling and molests > "application developers" with "bureaucracy of Fedora package > maintenance" - It's not helpful to both parties. I think that remains to be seen. Personally, I think -maintainers and -devel had overlapping purposes and there was not a way to enforce the distinction. -devel-announce should cover the "low traffic" part that -maintainers was intended for. It will handle the "these things have changed" type of announcements. As for actual discussions, I really do feel those belong on -devel. josh From rc040203 at freenet.de Fri Sep 7 00:06:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 02:06:19 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> Message-ID: <1189123579.24848.734.camel@mccallum.corsepiu.local> On Thu, 2007-09-06 at 23:50 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > > It molests maintainers with long term development babbling and molests > > "application developers" with "bureaucracy of Fedora package > > maintenance" - It's not helpful to both parties. > > Well, the biggest problem with -maintainers was that it was only postable > through on subscription (which also kept people from using tools like the GMane > NNTP and web interfaces) and that subscription was essentially limited to > existing maintainers (which kept not only the random users out, but even people > with legitimate content to post). Yes, it had been a closed list and maintainers did get automatically subscribed to it - The FESCO of the time this was decided, this approach wise - I never did - But THEM decided otherwise. Now, at least I will very likely miss essential postings, because they get swapped away in all the "*-ng, x11.R8, kernel-*, ubuntu has "a bigger one" babbling ... THEM have decided. Fortunately, THEM are a democratically elected - Now, I have a list of people have made top rankings on my list of folks I will NOT vote in next FESCO elections. Ralf From bpepple at fedoraproject.org Fri Sep 7 00:17:52 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 06 Sep 2007 20:17:52 -0400 Subject: Maintainers list discussion (Re: FESCo Meeting Summary for 2007-09-06) In-Reply-To: <1189121458.24848.703.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> Message-ID: <1189124272.31478.2.camel@kennedy> On Fri, 2007-09-07 at 01:30 +0200, Ralf Corsepius wrote: > On Thu, 2007-09-06 at 18:21 -0500, Josh Boyer wrote: > > On Fri, 07 Sep 2007 00:56:23 +0200 > > Ralf Corsepius wrote: > > > Given this decision, I would like to propose to also close down > > > * fedora-test-list@: > > > Rationale: There can't be a clear separation between testing and > > > development. testing is part of development and maintaining packages. > > > > > > * fedora-packaging@: Packaging and discussing details of packages are > > > part of a distribution's development. It doesn't make sense to keep > > > specialized lists for these topics. > > > > We can discuss this at next week's FESCo meeting if you would like. > Yes, please do so - Put it on your schedule. > > This meant to be a serious proposal and is not a knee-jerk reaction[1]. > You've decided to kill maintainers@, now you should be consequent and > kill these lists, too. I've added these to next weeks schedule. > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > It molests maintainers with long term development babbling and molests > "application developers" with "bureaucracy of Fedora package > maintenance" - It's not helpful to both parties. Yeah, I would have preferred to keep the maintainer's list as well, but sadly I was in the minority. :( /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri Sep 7 00:32:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 02:32:31 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189123579.24848.734.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> Message-ID: <1189125151.24848.739.camel@mccallum.corsepiu.local> On Fri, 2007-09-07 at 02:06 +0200, Ralf Corsepius wrote: > On Thu, 2007-09-06 at 23:50 +0000, Kevin Kofler wrote: > > Ralf Corsepius freenet.de> writes: > > > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > > > It molests maintainers with long term development babbling and molests > > > "application developers" with "bureaucracy of Fedora package > > > maintenance" - It's not helpful to both parties. > > > > Well, the biggest problem with -maintainers was that it was only postable > > through on subscription (which also kept people from using tools like the GMane > > NNTP and web interfaces) and that subscription was essentially limited to > > existing maintainers (which kept not only the random users out, but even people > > with legitimate content to post). > Yes, it had been a closed list and maintainers did get automatically s/did/did not/ > subscribed to it - The FESCO of the time this was decided, this approach s/, this approach/, thought this approach to be/ > wise - I never did - But THEM decided otherwise. Sorry, Ralf From lkundrak at redhat.com Fri Sep 7 00:39:22 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 07 Sep 2007 02:39:22 +0200 Subject: Approvals for Security updates Message-ID: <1189125562.28110.48.camel@dhcp-lab-117.englab.brq.redhat.com> A week ago, there remained no time to discuss this on FESCo meeting, so I was advised to post it here for comments: [1] [1] http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft -- Lubomir Kundrak (Red Hat Security Response Team) From jkeating at redhat.com Fri Sep 7 02:22:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Sep 2007 22:22:36 -0400 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189123579.24848.734.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> Message-ID: <20070906222236.7e6fce74@ender> On Fri, 07 Sep 2007 02:06:19 +0200 Ralf Corsepius wrote: > Now, at least I will very likely miss essential postings, because they > get swapped away in all the "*-ng, x11.R8, kernel-*, ubuntu has "a > bigger one" babbling ... THEM have decided. *yawn* fedora-devel-announce. Importing postings go there. Everything else is just follow up/discussion that you can read if you wish or ignore if you wish. Just do whatever you need to do so that fedora-devel-announce mails get your attention. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Sep 7 03:19:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 7 Sep 2007 03:19:07 +0000 (UTC) Subject: Approvals for Security updates References: <1189125562.28110.48.camel@dhcp-lab-117.englab.brq.redhat.com> Message-ID: Lubomir Kundrak redhat.com> writes: > A week ago, there remained no time to discuss this on FESCo meeting, so > I was advised to post it here for comments: [1] > > [1] http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft IMHO, you have to be careful that the approval process doesn't introduce excess delays because otherwise you'd encourage even more security updates not to be marked as such (and if you implement the automarking when a security bug is referenced, also missing Bugzilla references to avoid the security marking), which would be counterproductive. Kevin Kofler From michel.sylvan at gmail.com Fri Sep 7 03:41:23 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 6 Sep 2007 23:41:23 -0400 Subject: Approvals for Security updates In-Reply-To: References: <1189125562.28110.48.camel@dhcp-lab-117.englab.brq.redhat.com> Message-ID: On 06/09/07, Kevin Kofler wrote: > Lubomir Kundrak redhat.com> writes: > > A week ago, there remained no time to discuss this on FESCo meeting, so > > I was advised to post it here for comments: [1] > > > > [1] http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft > > IMHO, you have to be careful that the approval process doesn't introduce excess > delays because otherwise you'd encourage even more security updates not to be > marked as such (and if you implement the automarking when a security bug is > referenced, also missing Bugzilla references to avoid the security marking), > which would be counterproductive. How about retroactively reclassifying an update as a security update? This would work, the only problem being that the Changelog of a package initially unmarked would have no reference to CVE, unless the reclassifying triggers a rebuild of the update. -- Michel From loganjerry at gmail.com Fri Sep 7 03:45:37 2007 From: loganjerry at gmail.com (Jerry James) Date: Thu, 6 Sep 2007 21:45:37 -0600 Subject: aot-compile-rpm suggestion Message-ID: <870180fe0709062045k75ccea6evd952ef061c0346cd@mail.gmail.com> Due to operator error, I managed to create an empty jar file (containing only META-INF/MANIFEST.MF). Then aot-compile-rpm crashed: + /usr/bin/aot-compile-rpm Traceback (most recent call last): File "/usr/bin/aot-compile-rpm", line 66, in compiler.compile() File "/usr/lib/python2.5/site-packages/aotcompile.py", line 98, in compile self.writeMakefile(MAKEFILE, jobs) File "/usr/lib/python2.5/site-packages/aotcompile.py", line 124, in writeMakefile (job.dsoName(), job.dbName()) for job in jobs]))} TypeError: reduce() of empty sequence with no initial value error: Bad exit status from /var/tmp/rpm-tmp.78936 (%install) It took me a little digging through the code to figure out what that crash meant. In case others manage to trigger the same situation, it would be good to catch this exception and issue a "You dummy, there's nothing in your JAR file!" message instead. -- Jerry James http://loganjerry.googlepages.com/ From lesmikesell at gmail.com Fri Sep 7 04:05:42 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 06 Sep 2007 23:05:42 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189120655.6909.23.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> <1189097037.3949.12.camel@rousalka.dyndns.org> <46E05FF0.5070904@gmail.com> <1189120655.6909.23.camel@localhost6.localdomain6> Message-ID: <46E0CE16.1090702@gmail.com> Richi Plana wrote: >> Do you disagree with the idea that a JVM executing java bytecode should >> be very much like a media player playing a media file? That is, >> installing the data should not be dependent on having some particular >> player or JVM available that might or might not be used to manipulate it >> later. Why can't I have the app before the JVM or supply my own JVM? > > Probably not the best example. A piece of data (a media file in your > example) has so many different kinds of applications associated with it, > some might even be on different systems and the data is exported via a > number of means (http, nfs, etc.) Java bytecode, unless they're applets, > are much easier to predict requirements for. Is there some problem running an application where the bytecode is on a different machine than the jvm, using nfs? > There is a huge probability > that they will need a JVM, and unlike media players, from outside, > they're designed to function in the same way. I'm not sure I understand. Shouldn't you be able to use any version of a jvm, packaged or not, without specific dependencies, just like you could use different media players to play the same file? Or even run more than one of them at once? > As examples go, it's closer to say that JVMs are to Java applications or > even just bytecode what glibc is to native applications. Things may be that close-coupled in practice but only because of lack of conformance to the specification. It should be more like claiming that C source code is dependent on one gcc version or some other specific compiler. In some cases that may be true, but it doesn't seem right to encourage such bugginess with permanent workarounds. > In Fedora, openoffice.org-core-2.2.0 Requires the virtual package java. > > You CAN have the app before the JVM, I suppose, the same way you can > "rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be > bytes taking up space in your filesystem. Will it work later then if I provide a different JVM than the packaged versions? >> No one has given a usable answer for even a single value of JAVA_HOME >> for a single packaged jvm version. Or the location of the document that >> provides this necessary information. I'm sorry if that was too much to >> ask. > > Honestly, I tried to answer here > (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00396.html), here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00414.html) and here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00490.html), but I guess I'm misunderstanding the question. Yes, thanks, and sorry - I missed the one actual answer in the first link, but I was confused by the comment somewhere about parts going to private and export directories that didn't seem to be under the same top level. Is everything expected to be under JAVA_HOME actually still in one place? -- Les Mikesell lesmikesell at gmail.com From fedora at leemhuis.info Fri Sep 7 04:55:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 06:55:22 +0200 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> Message-ID: <46E0D9BA.7090406@leemhuis.info> On 06.09.2007 20:43, Jeff Spaleta wrote: >>> The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. >> Same for dkms, as modules might break if the api changed. > > slightly less complex for dkms, because with dkms you don't have to > deal with synchronously building the modules on the central build > system. Yeah -- so we offload the trouble to the user. And that's not the right thing to do IMHO. We should provide pre-compiled kernel-modules if we want to ship kernel-modules. dkms optional for that that want it: sure. But the signals from FESCo are afaics: no kernel-modules at all. And I think that's the right thing to do in the merged Fedora world. > [...] > I think dkms works as a piece of technology as far as it can. The > question really is, would providing dkms source payloads in Fedora > help drive mainlining of kernel modules or does it discourage the > necessary upstream discussions. It would, just as kmods do -- that's why we put a high entry-burden for kernel modules in Extras, and that's the reason why there are only two, and that's the reasons why we didn't work further on getting kmods automatically build when a new kernel gets shipped. > If providing dkms source payloads can > help move things into upstream via feedback, then I'm all for it. But > if its just going to be a way for people to get around the hard work > of getting a module upstreamed, then I'm not for it. >From http://lwn.net/Articles/248195/ (subscriber only ATM) [...]a really bad driver can create obscure problems all over the kernel. But the fact of the matter is that an ugly driver is more likely to be fixed in-tree than out. Linus asserted that anytime a distributor ships an out-of-tree driver, the process has failed. [...] Further: to avoid that driver authors "get around the hard work of getting a module upstreamed" was exactly the reasons why we put such a high entry burden for kmods into Fedora . The policy is still there at http://fedoraproject.org/wiki/Extras/GetKernelModulesUpstream and that shouldn't be altered just because we use a different packaging standard for modules now; if we want to alter it we can continue with an improved version of kmods or kmdls (that afaics both Axel and I are working on); we should just ban kernel modules completely, as dwmw2 proposed. > Which is why I'd > be interested in setting an explicit expiration date for any dkms > payload. Been there, discussed that multiple times already and chose to not go that route every time because that creates even more trouble for users "Hey, foo was supported in F7 and F8, why isn't it anymore in F10 and F11? Fedora is so stupid, I switch to foo instead!". CU knurd From fedora at leemhuis.info Fri Sep 7 05:02:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 07:02:23 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189119383.24848.696.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> Message-ID: <46E0DB5F.8000205@leemhuis.info> On 07.09.2007 00:56, Ralf Corsepius wrote: > On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > >> == Closing Maintainers List == >> * After a long discussion, it was decided to close the >> fedora-maintainers-list. In the future maintainer discussions >> will be conducted on the fedora-devel-list. bpepple will send a >> notice out announcing this. > Given this decision, I would like to propose to also close down > * fedora-test-list@: > Rationale: There can't be a clear separation between testing and > development. testing is part of development and maintaining packages. +1 > * fedora-packaging@: Packaging and discussing details of packages are > part of a distribution's development. It doesn't make sense to keep > specialized lists for these topics. +1 -- it's IMHO even hindering work and informations flow if something important to all gets discussed on a dedicated list. But warning, last time I proposed closing fedora-packaging I got ninjas send after me ;-) CU knurd From Fedora at FamilleCollet.com Fri Sep 7 05:09:22 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 07 Sep 2007 07:09:22 +0200 Subject: rpms/php-pear-Mail-Mime/devel .cvsignore, 1.3, 1.4 php-pear-Mail-Mime.spec, 1.2, 1.3 sources, 1.3, 1.4 In-Reply-To: <200709060548.l865mvTG020300@cvs-int.fedora.redhat.com> References: <200709060548.l865mvTG020300@cvs-int.fedora.redhat.com> Message-ID: <46E0DD02.7040505@FamilleCollet.com> Brandon Holbrook (static) a ?crit : > -BuildRequires: php-pear >= 1:1.4.9-1.2 > +BuildRequires: php-pear >= 1.6.0 > Requires: php-pear(PEAR) > You should probably keep "epoch" in this BR BuildRequires: php-pear >= 1:1.6.0 or BuildRequires: php-pear(PEAR) >= 1.6.0 (to avoid build on EL4, with php-pear 0:4.3.9) But, is it really a BuildRequires or a Requires ? Regards. From sundaram at fedoraproject.org Fri Sep 7 05:19:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Sep 2007 10:49:28 +0530 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <46E0DB5F.8000205@leemhuis.info> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <46E0DB5F.8000205@leemhuis.info> Message-ID: <46E0DF60.7060801@fedoraproject.org> Thorsten Leemhuis wrote: > +1 -- it's IMHO even hindering work and informations flow if something > important to all gets discussed on a dedicated list. > Weren't you suggesting closing fedora-qa and fedora-test-list and creating a new fedora-devel-users mailing list earlier? Is that still the proposal and having all the discussions in this list instead? If fedora-devel and fedora-test lists are being merged, the update notifications for test updates should probably be send to fedora-package-announce list under a new mailman topic and replies redirected to this list or the newly created fedora-devel-users list. Rahul From fedora at leemhuis.info Fri Sep 7 05:46:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 07:46:42 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <46E0DF60.7060801@fedoraproject.org> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <46E0DB5F.8000205@leemhuis.info> <46E0DF60.7060801@fedoraproject.org> Message-ID: <46E0E5C2.4070609@leemhuis.info> On 07.09.2007 07:19, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > >> +1 -- it's IMHO even hindering work and informations flow if something >> important to all gets discussed on a dedicated list. > Weren't you suggesting closing fedora-qa and fedora-test-list and > creating a new fedora-devel-users mailing list earlier? Yes. > Is that still the proposal If someone drives it I'm all for it. Albeit I think it won't work if we just create that list, as people will continue to post on fedora-devel-list. So if we want to disjoin "devel-users" and "developers" (which IMHO is a good differentiation and worth different lists) more work would be needed (e.g. create two new lists and point people currently on fedora{-qa,-devel,-test,-maintainers} in the right direction. > and having all the discussions in this list instead? During the last discussions I got the impression the Board / those on FAB feared to touch fedora-devel-list. But I think we need to touch it, as users sometimes post to this list and feed unheard or ignored. Developers on the other hand seem to be annoyed by users that post their problems and feature requests here, but are not doing anything else for Fedora. > If fedora-devel and fedora-test lists are being merged, the update > notifications for test updates should probably be send to > fedora-package-announce list under a new mailman topic and replies > redirected to this list or the newly created fedora-devel-users list. +1 CU knurd From andy at smile.org.ua Fri Sep 7 05:47:13 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 7 Sep 2007 08:47:13 +0300 Subject: Daemons as user "nobody" In-Reply-To: References: Message-ID: <20070907054713.GB10704@serv.smile.org.ua> Hi Konstantin Ryabitsev! On Wed, Sep 05, 2007 at 12:37:16PM -0400, Konstantin Ryabitsev wrote next: > I recall there being something about running daemons as user "nobody." > Is that still a policy? Cursory search in the wiki revealed nothing, > but searching for "user nobody" is near-futile. :) > Don't we normally create daemon-specific users? If you create only one user to many services you pick up big security hole. For example, you have installed httpd and mysql under nobody account. If the cracker crashed httpd he also got access to mysql. That's why we need to create separate user per unique service. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From nicolas.mailhot at laposte.net Fri Sep 7 06:07:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 07 Sep 2007 08:07:21 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <20070907010420.19a40ddc.mschwendt.tmp0701.nospam@arcor.de> References: <20070827192643.GB24132@free.fr> <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> <1189118749.3949.17.camel@rousalka.dyndns.org> <20070907010420.19a40ddc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1189145241.15304.2.camel@rousalka.dyndns.org> Le vendredi 07 septembre 2007 ? 01:04 +0200, Michael Schwendt a ?crit : > On Fri, 07 Sep 2007 00:45:49 +0200, Nicolas Mailhot wrote: > > > > > Le vendredi 07 septembre 2007 ? 00:36 +0200, Michael Schwendt a ?crit : > > > > > As in the range 1.5.0 <= x < 1.6.0 ? > > > I don't think that is possible with "Obsoletes". > > > With Requires it is different, since all Requires must be satisfied. > > > > No it's not, since rpm is lacking true version range support you only > > need package A providing foo = 1.4.0 and package B foo = 1.8.0 to fool > > Requires 1.5.0 <= foo < 1.6.0 > > Not that notation. But > > Requires: foo >= 1.5.0 > Requires: foo < 1.6.0 > > does not work? > It must be > > Requires: foo >= 1.5.0 > Conflicts: foo >= 1.6.0 This blacklists newer foo-providing packages from the system, when what you really want is ensure there is a foo in the right range (and do not care if there are also older or newer foo provides) -- 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 rc040203 at freenet.de Fri Sep 7 06:22:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 08:22:13 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <20070906222236.7e6fce74@ender> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> <20070906222236.7e6fce74@ender> Message-ID: <1189146133.24848.745.camel@mccallum.corsepiu.local> On Thu, 2007-09-06 at 22:22 -0400, wrote: > On Fri, 07 Sep 2007 02:06:19 +0200 > Ralf Corsepius wrote: > > > Now, at least I will very likely miss essential postings, because they > > get swapped away in all the "*-ng, x11.R8, kernel-*, ubuntu has "a > > bigger one" babbling ... THEM have decided. > > *yawn* fedora-devel-announce. Importing postings go there. No. Important "proclamations" go there - Important "discussions" will get lost in the flood, i.e. not take place. Ralf From jspaleta at gmail.com Fri Sep 7 06:54:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Sep 2007 22:54:35 -0800 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E0D9BA.7090406@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> Message-ID: <604aa7910709062354l802c815sa02b0c207d528040@mail.gmail.com> On 9/6/07, Thorsten Leemhuis wrote: > >From http://lwn.net/Articles/248195/ (subscriber only ATM) I was pointed to that article earlier today as well. I'm really keen on see what upstream is going to do with regard to making it easier to upstream modules. Whatever upstream decides to do to shake up the status-quo I'd like to find some way to have Fedora's community help. -jef From fedora at leemhuis.info Fri Sep 7 07:15:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 09:15:34 +0200 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <604aa7910709062354l802c815sa02b0c207d528040@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <604aa7910709062354l802c815sa02b0c207d528040@mail.gmail.com> Message-ID: <46E0FA96.40304@leemhuis.info> On 07.09.2007 08:54, Jeff Spaleta wrote: > On 9/6/07, Thorsten Leemhuis wrote: >> >From http://lwn.net/Articles/248195/ (subscriber only ATM) > > I was pointed to that article earlier today as well. I'm really keen > on see what upstream is going to do with regard to making it easier to > upstream modules. Whatever upstream decides to do to shake up the > status-quo I'd like to find some way to have Fedora's community help. Agreed. But as dwmw2 said in his proposal: "There is no justification for shipping kernel modules as separate packages within Fedora. If code is good enough to ship, it should be shipped in the kernel package." CU knurd From lemenkov at gmail.com Fri Sep 7 07:34:32 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 7 Sep 2007 11:34:32 +0400 Subject: Peter Lemenkov will be out of the office for the next 2 weeks. Message-ID: Hello All! I will be out of the office for the next two weeks (starting from 09.09). I'll be in Greece, Halkidiki if it does matter :). Although all my minds will be about Fedora Community I can't provide any feedback (no phone, no email and even no ssh or telnet! At least I hope so... :) ) If anyone has very urgent message for me, feel free to contact me via email of jabber. BTW I remember that there is a wiki-page for such things - can someone point me to that page? -- With best regards! From sundaram at fedoraproject.org Fri Sep 7 07:41:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Sep 2007 13:11:46 +0530 Subject: Peter Lemenkov will be out of the office for the next 2 weeks. In-Reply-To: References: Message-ID: <46E100BA.4020509@fedoraproject.org> Peter Lemenkov wrote: > Hello All! > I will be out of the office for the next two weeks (starting from > 09.09). I'll be in Greece, Halkidiki if it does matter :). > > Although all my minds will be about Fedora Community I can't provide > any feedback (no phone, no email and even no ssh or telnet! At least I > hope so... :) ) > > If anyone has very urgent message for me, feel free to contact me via > email of jabber. > > BTW I remember that there is a wiki-page for such things - can > someone point me to that page? Vacation notice page linked from http://fedoraproject.org/wiki/PackageMaintainers Rahul From lemenkov at gmail.com Fri Sep 7 07:49:35 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 7 Sep 2007 11:49:35 +0400 Subject: Peter Lemenkov will be out of the office for the next 2 weeks. In-Reply-To: <46E100BA.4020509@fedoraproject.org> References: <46E100BA.4020509@fedoraproject.org> Message-ID: > > BTW I remember that there is a wiki-page for such things - can > > someone point me to that page? > Vacation notice page linked from > http://fedoraproject.org/wiki/PackageMaintainers OK, thanks. -- With best regards! From eric.tanguy at univ-nantes.fr Fri Sep 7 07:49:59 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 07 Sep 2007 09:49:59 +0200 Subject: Building problem with mock devel Message-ID: <1189151399.2869.2.camel@bureau.maison> /etc/profile: line 38: /bin/hostname: No such file or directory Installing /builddir/build/SRPMS/libupnp-1.6.0-2.fc8.src.rpm Building target platforms: i386 Building for target i386 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.13507 + umask 022 + cd /builddir/build/BUILD + LANG=C + export LANG + unset DISPLAY + cd /builddir/build/BUILD + rm -rf libupnp-1.6.0 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2 + tar -xf - tar: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory bzip2: I/O or other error, bailing out. Possible reason follows. bzip2: Broken pipe Input file = /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2, output file = (stdout) Someone could help to solve this ? Eric From panemade at gmail.com Fri Sep 7 09:04:50 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 7 Sep 2007 14:34:50 +0530 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E0D9BA.7090406@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> Message-ID: Hi, On 9/7/07, Thorsten Leemhuis wrote: > On 06.09.2007 20:43, Jeff Spaleta wrote: > >>> The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. > >> Same for dkms, as modules might break if the api changed. > > > > slightly less complex for dkms, because with dkms you don't have to > > deal with synchronously building the modules on the central build > > system. > > Yeah -- so we offload the trouble to the user. And that's not the right > thing to do IMHO. We should provide pre-compiled kernel-modules if we > want to ship kernel-modules. dkms optional for that that want it: sure. > > But the signals from FESCo are afaics: no kernel-modules at all. And I > think that's the right thing to do in the merged Fedora world. Ok. So why we are discussing this again and again creating many threads on fedora-devel mailing list? Why not to close this topic with "No Kmod Packages Allowed in Fedora Repository"? I think still something is going on that is preventing FESCO to directly come to conclusion of disallowing kernel module packages in fedora". Regards, Parag. From mschwendt.tmp0701.nospam at arcor.de Fri Sep 7 09:33:23 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 11:33:23 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <1189145241.15304.2.camel@rousalka.dyndns.org> References: <20070827192643.GB24132@free.fr> <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> <1189118749.3949.17.camel@rousalka.dyndns.org> <20070907010420.19a40ddc.mschwendt.tmp0701.nospam@arcor.de> <1189145241.15304.2.camel@rousalka.dyndns.org> Message-ID: <20070907113323.1aa690cf.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Sep 2007 08:07:21 +0200, Nicolas Mailhot wrote: > > Le vendredi 07 septembre 2007 ? 01:04 +0200, Michael Schwendt a ?crit : > > On Fri, 07 Sep 2007 00:45:49 +0200, Nicolas Mailhot wrote: > > > > > > > > Le vendredi 07 septembre 2007 ? 00:36 +0200, Michael Schwendt a ?crit : > > > > > > > As in the range 1.5.0 <= x < 1.6.0 ? > > > > I don't think that is possible with "Obsoletes". > > > > With Requires it is different, since all Requires must be satisfied. > > > > > > No it's not, since rpm is lacking true version range support you only > > > need package A providing foo = 1.4.0 and package B foo = 1.8.0 to fool > > > Requires 1.5.0 <= foo < 1.6.0 > > > > Not that notation. But > > > > Requires: foo >= 1.5.0 > > Requires: foo < 1.6.0 > > > > does not work? > > It must be > > > > Requires: foo >= 1.5.0 > > Conflicts: foo >= 1.6.0 > > This blacklists newer foo-providing packages from the system, when what > you really want is ensure there is a foo in the right range (and do not > care if there are also older or newer foo provides) That's sufficient. To have an old foo and new foo in the same namespace is a corner-case anyway. For a long time, the new foo would have upgraded the old foo (even wrt virtual provides), breaking dependencies on older foo. From fedora at leemhuis.info Fri Sep 7 09:24:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 11:24:34 +0200 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> Message-ID: <46E118D2.7050807@leemhuis.info> On 07.09.2007 11:04, Parag N(????) wrote: > On 9/7/07, Thorsten Leemhuis wrote: >> On 06.09.2007 20:43, Jeff Spaleta wrote: >>>>> The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. >>>> Same for dkms, as modules might break if the api changed. >>> slightly less complex for dkms, because with dkms you don't have to >>> deal with synchronously building the modules on the central build >>> system. >> Yeah -- so we offload the trouble to the user. And that's not the right >> thing to do IMHO. We should provide pre-compiled kernel-modules if we >> want to ship kernel-modules. dkms optional for that that want it: sure. >> But the signals from FESCo are afaics: no kernel-modules at all. And I >> think that's the right thing to do in the merged Fedora world. > Ok. So why we are discussing this again and again creating many > threads on fedora-devel mailing list? I'm unsure myself. dwmw2's proposal afaics mainly reads as "no separately packaged *kernel-modules* (in source or binary form) in Fedora at all"; but he uses the term "kmods" here and there (and kmod specific examples), so some people afaics got the idea that something else (like dkms) would be acceptable. I doubt that's the intention behind dwmw2's proposal. David, can you clarify? Or Jesse (who's listed as owner for the proposal as well)? > Why not to close this topic > with "No Kmod Packages Allowed in Fedora Repository"? Same here ;-) Make that a "No separately packaged kernel-modules in Fedora at all" and it gets a +1 from me. > I think still something is going on that is preventing FESCO to > directly come to conclusion of disallowing kernel module packages in > fedora". >From looking at the FESCo meeting logs it were just real life issues: dwmw2 was not around yesterday and people were unsure what the dkms stuff was about afaics. Last week FESCo iirc didn't decide because it wanted to see the proposal reviewed in public. CU knurd From opensource at till.name Fri Sep 7 09:31:17 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 11:31:17 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189146133.24848.745.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <20070906222236.7e6fce74@ender> <1189146133.24848.745.camel@mccallum.corsepiu.local> Message-ID: <200709071131.22660.opensource@till.name> On Fr September 7 2007, Ralf Corsepius wrote: > No. Important "proclamations" go there - Important "discussions" will > get lost in the flood, i.e. not take place. This risk was there with -maintainers, too, because not many people agree on which topics are better for which list. When its break is over, the Fedora Weekly Newsletter may also help you to identify interesting discussions: http://fedoraproject.org/wiki/FWN Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mschwendt.tmp0701.nospam at arcor.de Fri Sep 7 09:44:36 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 11:44:36 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189119383.24848.696.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> Message-ID: <20070907114436.9a211f75.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Sep 2007 00:56:23 +0200, Ralf Corsepius wrote: > On Thu, 2007-09-06 at 15:45 -0400, Brian Pepple wrote: > > > == Closing Maintainers List == > > * After a long discussion, it was decided to close the > > fedora-maintainers-list. In the future maintainer discussions > > will be conducted on the fedora-devel-list. bpepple will send a > > notice out announcing this. > Given this decision, I would like to propose to also close down > * fedora-test-list@: > Rationale: There can't be a clear separation between testing and > development. testing is part of development and maintaining packages. +1 I wholeheartedly agree here. Find somebody who can explain in clear words which list to use when and for what and get that into the heads of the subscribers. Especially during the periods when there are official Test releases of the distribution, there is no clear separation between fedora-test* and fedora-devel*, and between development in rawhide and the test releases. But there are either cross-posts or exclusive posts to either list, which require everybody with interest to subscribe to both lists in order to stay informed. And then the Test Update announcements, which are much more relevant to the users of the stable dists, are mixed in there, too. From fedora at leemhuis.info Fri Sep 7 09:44:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 11:44:18 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <20070907114436.9a211f75.mschwendt.tmp0701.nospam@arcor.de> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070907114436.9a211f75.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46E11D72.1070704@leemhuis.info> On 07.09.2007 11:44, Michael Schwendt wrote: > > I wholeheartedly agree here. Find somebody who can explain in clear > words which list to use when we tried that in the past already... > and for what and get that into the heads of the subscribers. which IMHO is next-to-impossible at this point as lots of people got used to ask questions like "is foo broken in rawhide" on this list way to much already. > [...] CU knurd From mschwendt.tmp0701.nospam at arcor.de Fri Sep 7 09:59:56 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 11:59:56 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189123579.24848.734.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> Message-ID: <20070907115956.4b388482.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Sep 2007 02:06:19 +0200, Ralf Corsepius wrote: > On Thu, 2007-09-06 at 23:50 +0000, Kevin Kofler wrote: > > Ralf Corsepius freenet.de> writes: > > > [1] IMO, this FESCO decision is a fault and mistake, we all will regret. > > > It molests maintainers with long term development babbling and molests > > > "application developers" with "bureaucracy of Fedora package > > > maintenance" - It's not helpful to both parties. > > > > Well, the biggest problem with -maintainers was that it was only postable > > through on subscription (which also kept people from using tools like the GMane > > NNTP and web interfaces) and that subscription was essentially limited to > > existing maintainers (which kept not only the random users out, but even people > > with legitimate content to post). > Yes, it had been a closed list and maintainers did get automatically > subscribed to it - The FESCO of the time this was decided, this approach > wise - I never did - But THEM decided otherwise. The idea and rationale behind fedora-maintainers was good and wise. But it was based on the assumption of starting with low traffic and messages relevant to package maintainers. Instead, fedora-maintainers list has been "abused" as some sort of new fedora-devel list with lots of lengthy general discussions not specifically relevant to package maintainers. IMO the justification for keeping that content on a separate list was gone. > Now, at least I will very likely miss essential postings, because they > get swapped away in all the "*-ng, x11.R8, kernel-*, ubuntu has "a > bigger one" babbling ... THEM have decided. They should learn to copy essential posts to the moderated announce lists or directly to the contributors via private mail. Mandatory subscription of a list with lengthy threads and controversies (e.g. the completely inappropriate codenames discussion) simply does not work, as the package maintainers feel the need to escape from such madness. But to make them not miss announcements and important posts, somebody needs to decide on what's "essential" and what is not. From rc040203 at freenet.de Fri Sep 7 10:16:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Sep 2007 12:16:32 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <200709071131.22660.opensource@till.name> References: <1189107915.24113.36.camel@kennedy> <20070906222236.7e6fce74@ender> <1189146133.24848.745.camel@mccallum.corsepiu.local> <200709071131.22660.opensource@till.name> Message-ID: <1189160192.24848.795.camel@mccallum.corsepiu.local> On Fri, 2007-09-07 at 11:31 +0200, Till Maas wrote: > On Fr September 7 2007, Ralf Corsepius wrote: > > > No. Important "proclamations" go there - Important "discussions" will > > get lost in the flood, i.e. not take place. > > This risk was there with -maintainers, too, because not many people agree on > which topics are better for which list. When its break is over, the Fedora > Weekly Newsletter may also help you to identify interesting discussions: > http://fedoraproject.org/wiki/FWN lists are "push" media, wiki's (and web-pages in general) normally are being used as "pull-media", therefore can not replace lists. Ralf From spng.yang at gmail.com Fri Sep 7 10:24:35 2007 From: spng.yang at gmail.com (Ken YANG) Date: Fri, 07 Sep 2007 18:24:35 +0800 Subject: fedora background images and main menu icons gone In-Reply-To: <46DFFB0D.1030901@leemhuis.info> References: <47324ed80709041720j318dfa2dpcb2d7e7eae8017a9@mail.gmail.com> <604aa7910709051001o620fbb97k26d95dab6b79c553@mail.gmail.com> <46DF53FC.8070500@gmail.com> <46DFBC4F.4010002@leemhuis.info> <46DFBE47.8080904@gmail.com> <1189081783.8187.2.camel@scrappy.miketc.com> <46DFFB0D.1030901@leemhuis.info> Message-ID: <46E126E3.1060406@gmail.com> Thorsten Leemhuis wrote: > On 06.09.2007 14:29, Mike Chambers wrote: >> On Thu, 2007-09-06 at 16:45 +0800, Ken YANG wrote: >>> Thorsten Leemhuis wrote: >>>> Did you file a bug report or found one? I noticed the same when I >>>> updated to rawhide some days ago, but didn't come around yet to ask >>>> bugzilla about it. >>> i had not file a bug, i think this sort of problem is obvious, and >>> others will fix it in future, > > Well, you said you noticed it two weeks ago. So it seems it's not that > obvious, as I'd say the developer would have fixed it already otherwise ;-) today rawhide has fixed this bug: fedora-logos-7.92.0-4.fc8.noarch > >> [...] >> I am using a rawhide install as of yesterday, and the menus and >> backgrounds are there. > > For me it's only the MainMenu-Image for the "old-style" main-menu -- the > one you have to manually add to the gnome-panel and not the default one > with > >> In other words, maybe it just needs a refresh to get it back again? > > Worth a try -- I'll retest later and will file a bug if it's still > happening to move this discussion where it belongs. > > CU > knurd > From kevin.kofler at chello.at Fri Sep 7 10:28:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 7 Sep 2007 10:28:16 +0000 (UTC) Subject: FESCo Meeting Summary for 2007-09-06 References: <1189107915.24113.36.camel@kennedy> <20070906222236.7e6fce74@ender> <1189146133.24848.745.camel@mccallum.corsepiu.local> <200709071131.22660.opensource@till.name> <1189160192.24848.795.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > lists are "push" media, wiki's (and web-pages in general) normally are > being used as "pull-media", therefore can not replace lists. May I suggest list archives? That way you can "pull" and pick what you read and when (no flooded mailbox), and with the GMane web interface you can "push" if you need to (which is how this message is being sent). It's the way I keep up to date with high-volume mailing lists. Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Fri Sep 7 10:38:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 7 Sep 2007 12:38:24 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189160192.24848.795.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <20070906222236.7e6fce74@ender> <1189146133.24848.745.camel@mccallum.corsepiu.local> <200709071131.22660.opensource@till.name> <1189160192.24848.795.camel@mccallum.corsepiu.local> Message-ID: <20070907123824.4d42882e.mschwendt.tmp0701.nospam@arcor.de> On Fri, 07 Sep 2007 12:16:32 +0200, Ralf Corsepius wrote: > On Fri, 2007-09-07 at 11:31 +0200, Till Maas wrote: > > On Fr September 7 2007, Ralf Corsepius wrote: > > > > > No. Important "proclamations" go there - Important "discussions" will > > > get lost in the flood, i.e. not take place. > > > > This risk was there with -maintainers, too, because not many people agree on > > which topics are better for which list. When its break is over, the Fedora > > Weekly Newsletter may also help you to identify interesting discussions: > > http://fedoraproject.org/wiki/FWN > lists are "push" media, wiki's (and web-pages in general) normally are > being used as "pull-media", therefore can not replace lists. FWN is also delivered via mail: https://www.redhat.com/archives/fedora-announce-list/2007-August/msg00006.html https://www.redhat.com/mailman/listinfo/fedora-announce-list From opensource at till.name Fri Sep 7 10:29:30 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 12:29:30 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189160192.24848.795.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <200709071131.22660.opensource@till.name> <1189160192.24848.795.camel@mccallum.corsepiu.local> Message-ID: <200709071229.41297.opensource@till.name> On Fr September 7 2007, Ralf Corsepius wrote: > lists are "push" media, wiki's (and web-pages in general) normally are > being used as "pull-media", therefore can not replace lists. The FWN is pushed in full text to fedora-announce-list. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lkundrak at redhat.com Fri Sep 7 10:38:41 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 07 Sep 2007 12:38:41 +0200 Subject: Approvals for Security updates In-Reply-To: References: <1189125562.28110.48.camel@dhcp-lab-117.englab.brq.redhat.com> Message-ID: <1189161521.2971.3.camel@localhost.localdomain> Hi Kevin, On Fri, 2007-09-07 at 03:19 +0000, Kevin Kofler wrote: > Lubomir Kundrak redhat.com> writes: > > A week ago, there remained no time to discuss this on FESCo meeting, so > > I was advised to post it here for comments: [1] > > > > [1] http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft > > IMHO, you have to be careful that the approval process doesn't introduce excess > delays because otherwise you'd encourage even more security updates not to be > marked as such (and if you implement the automarking when a security bug is > referenced, also missing Bugzilla references to avoid the security marking), > which would be counterproductive. The members of Fedora Security Response team do receive mail notifications about security updates. In vast majority cases we are able to review the update within on (business) day. That is far less than what it takes to do a QA or for the package to be in -testing repository. > > Kevin Kofler > Regards, -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Fri Sep 7 10:39:40 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 07 Sep 2007 12:39:40 +0200 Subject: Approvals for Security updates In-Reply-To: References: <1189125562.28110.48.camel@dhcp-lab-117.englab.brq.redhat.com> Message-ID: <1189161580.2971.5.camel@localhost.localdomain> Hi Michael On Thu, 2007-09-06 at 23:41 -0400, Michel Salim wrote: > On 06/09/07, Kevin Kofler wrote: > > Lubomir Kundrak redhat.com> writes: > > > A week ago, there remained no time to discuss this on FESCo meeting, so > > > I was advised to post it here for comments: [1] > > > > > > [1] http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft > > > > IMHO, you have to be careful that the approval process doesn't introduce excess > > delays because otherwise you'd encourage even more security updates not to be > > marked as such (and if you implement the automarking when a security bug is > > referenced, also missing Bugzilla references to avoid the security marking), > > which would be counterproductive. > > How about retroactively reclassifying an update as a security update? > This would work, the only problem being that the Changelog of a > package initially unmarked would have no reference to CVE, unless the > reclassifying triggers a rebuild of the update. Pointless. The update mails would also not be marked [SECURITY]. > > -- > Michel > Regards, -- Lubomir Kundrak (Red Hat Security Response Team) From mike at miketc.com Fri Sep 7 10:48:23 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 07 Sep 2007 05:48:23 -0500 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <46E0DF60.7060801@fedoraproject.org> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <46E0DB5F.8000205@leemhuis.info> <46E0DF60.7060801@fedoraproject.org> Message-ID: <1189162103.8787.14.camel@scrappy.miketc.com> On Fri, 2007-09-07 at 10:49 +0530, Rahul Sundaram wrote: > If fedora-devel and fedora-test lists are being merged, the update > notifications for test updates should probably be send to > fedora-package-announce list under a new mailman topic and replies > redirected to this list or the newly created fedora-devel-users list. I think that users are going to confuse these lists no matter what, unless either everyone is all on one list, or you have two totally distinct lists, that people can surely distinguish between the two. Such as fedora-devel-users@ (beta/rawhide users, maintainers, etc.) and fedora-project-discuss@ (How fedora as a whole - docs, web, product - are discussed to guide it into the promise land). And the lists descriptions need be worded as dummied down as possible so they are totally known they are not the same. The names obviously could be something else if needed, but you get the idea. Just trying to help one way or the other :) -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From fedora at leemhuis.info Fri Sep 7 11:03:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 13:03:33 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189162103.8787.14.camel@scrappy.miketc.com> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <46E0DB5F.8000205@leemhuis.info> <46E0DF60.7060801@fedoraproject.org> <1189162103.8787.14.camel@scrappy.miketc.com> Message-ID: <46E13005.7010400@leemhuis.info> On 07.09.2007 12:48, Mike Chambers wrote: > On Fri, 2007-09-07 at 10:49 +0530, Rahul Sundaram wrote: > >> If fedora-devel and fedora-test lists are being merged, the update >> notifications for test updates should probably be send to >> fedora-package-announce list under a new mailman topic and replies >> redirected to this list or the newly created fedora-devel-users list. > I think that users are going to confuse these lists no matter what, > unless either everyone is all on one list, or you have two totally > distinct lists, that people can surely distinguish between the two. +1 > Such as fedora-devel-users@ (beta/rawhide users, maintainers, etc.) and > fedora-project-discuss@ (How fedora as a whole - docs, web, product - > are discussed to guide it into the promise land). I suggested something like fedora-project-discuss in the past, but it fedora-advisory-board seems to mostly serve the purpose of a list-for-all-fedora-projects currently afaics. But it's sees FAB is more used by contributors of Fedora projects and not by normal users. If we want to have a list for those as well then a fedora-project-discuss in addition might make sense. > And the lists > descriptions need be worded as dummied down as possible so they are > totally known they are not the same. +1 > [...] CU knurd From buildsys at redhat.com Fri Sep 7 11:18:12 2007 From: buildsys at redhat.com (Build System) Date: Fri, 7 Sep 2007 07:18:12 -0400 Subject: rawhide report: 20070907 changes Message-ID: <200709071118.l87BICW0018153@porkchop.devel.redhat.com> Updated Packages: curl-7.16.4-4.fc8 ----------------- * Mon Sep 03 2007 Jindrich Novy 7.16.4-4 - revert back to use OpenSSL (#266021) docbook-style-xsl-1.73.2-1.fc8 ------------------------------ * Wed Sep 05 2007 Ondrej Vasik 1.73.2-1 - new upstream version * Thu Aug 30 2007 Ondrej Vasik 1.73.1-2 - removed patch for #249294(included in new version other way) * Wed Aug 29 2007 Ondrej Vasik 1.73.1-1 - new upstream version(fixing some bugs) - small new-methods patch change firefox-2.0.0.6-6.fc8 --------------------- * Thu Sep 06 2007 Christopher Aillon - 2.0.0.6-6 - Fix default page for all locales geda-docs-20070902-1.fc8 ------------------------ * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-examples-20070902-1.fc8 ---------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Thu Aug 23 2007 Chitlesh Goorah - 20070708-2 - mass rebuild for fedora 8 - ppc32 geda-gattrib-20070902-1.fc8 --------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-gnetlist-20070902-1.fc8 ---------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-gschem-20070902-1.fc8 -------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-gsymcheck-20070902-1.fc8 ----------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-symbols-20070902-1.fc8 --------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release geda-utils-20070902-1.fc8 ------------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release kernel-xen-2.6-2.6.21-2936.fc8 ------------------------------ * Thu Sep 06 2007 Eduardo Habkost - Include modules.block and modules.networking on the package (bug #280731) * Thu Aug 30 2007 Eduardo Habkost - Provides: xen-hypervisor-abi = 3.1 (bug #269581) libgeda-20070902-1.fc8 ---------------------- * Mon Sep 03 2007 Chitlesh Goorah - 20070902-1 - New upstream release mash-0.2.3-1.fc8 ---------------- * Thu Sep 06 2007 Bill Nottingham 0.2.3-1 - blacklist java-1.7.0-icedtea-devel (#271761) pulseaudio-0.9.7-0.11.svn20070907.fc8 ------------------------------------- * Fri Sep 07 2007 Lennart Poettering 0.9.7-0.11.svn20070907 - Update SVN snapshot, don't link libpulsecore.so statically anymore selinux-policy-3.0.7-5.fc8 -------------------------- * Thu Sep 06 2007 Dan Walsh 3.0.7-5 - Fix java labeling * Thu Sep 06 2007 Dan Walsh 3.0.7-4 - Define user_home_type as home_type * Tue Aug 28 2007 Dan Walsh 3.0.7-3 - Allow sendmail to create etc_aliases_t Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.i386 requires libneon.so.25 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.i386 requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.x86_64 requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.x86_64 requires libneon.so.25()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl ocaml-calendar - 1.10-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-curl - 0.2.1-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-expat - 0.9.1-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-extlib - 1.5-5.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-findlib - 1.1.2pl1-10.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgl - 1.02-12.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-lablgtk-devel - 2.6.0-8.20060908cvs.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-libvirt - 0.3.2.4-1.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-pcre - 5.11.4-6.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ssl - 0.4.2-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 ocaml-ulex - 1.0-3.fc8.ppc requires ocaml = 0:3.10.0-1.fc8 octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc requires libneon.so.25 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rubygem-gem_plugin - 0.2.2-2.fc8.noarch requires rubygem(rake) >= 0:0.7 subcommander - 1.2.2-6.fc8.ppc64 requires libneon.so.25()(64bit) From buc at odusz.so-cdu.ru Fri Sep 7 11:33:11 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 07 Sep 2007 15:33:11 +0400 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189107915.24113.36.camel@kennedy> References: <1189107915.24113.36.camel@kennedy> Message-ID: <46E136F7.3000909@odu.neva.ru> Brian Pepple wrote: > == Bluetooth Feature Proposal == > * Bastien Nocera (hadess) attended the meeting to appeal the > recent FESCo decision to remove Bluetooth from the new features > list for F8. After being apprised of the the changes for > Bluetooth support, FESCo agreed to reverse it's prior decision. > For more information about the Bluetooth improvements please > refer to: > > http://fedoraproject.org/wiki/Releases/FeatureBluetooth > If it will be possible, please, do not forget about command line utilities for this. Besides Bluetooth, there are (there was :) ) irda and serial ports for the same purpose, hence when applicable, allow people to use those "ancient" transports too. ~buc From khc at pm.waw.pl Fri Sep 7 11:45:18 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Fri, 07 Sep 2007 13:45:18 +0200 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189014587.24933.14.camel@xo-3E-67-34.localdomain> (Dan Williams's message of "Wed, 05 Sep 2007 13:49:47 -0400") References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: Dan Williams writes: > Well, it's a really tricky problem. I'd personally do: > > try UTF-8 validation > try validation from the encoding in LANG > fall back to a lot of ? for unprintables Perhaps asking the user for encoding would make sense. -- Krzysztof Halasa From rjones at redhat.com Fri Sep 7 12:21:13 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 07 Sep 2007 13:21:13 +0100 Subject: rawhide report: 20070907 changes In-Reply-To: <200709071118.l87BICW0018153@porkchop.devel.redhat.com> References: <200709071118.l87BICW0018153@porkchop.devel.redhat.com> Message-ID: <46E14239.10108@redhat.com> The OCaml packages are all rebuilt now, so just waiting for the unfreeze of Fedora development. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From bpepple at fedoraproject.org Fri Sep 7 12:33:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 07 Sep 2007 08:33:18 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E118D2.7050807@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> Message-ID: <1189168398.3847.4.camel@kennedy> On Fri, 2007-09-07 at 11:24 +0200, Thorsten Leemhuis wrote: > On 07.09.2007 11:04, Parag N(????) wrote: > > > I think still something is going on that is preventing FESCO to > > directly come to conclusion of disallowing kernel module packages in > > fedora". > > >From looking at the FESCo meeting logs it were just real life issues: > dwmw2 was not around yesterday and people were unsure what the dkms > stuff was about afaics. Last week FESCo iirc didn't decide because it > wanted to see the proposal reviewed in public. Yeah, since dwmw2 hasn't been able to attend the last couple meetings, we wanted him to weight-in on dkms before making a decision. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Fri Sep 7 12:42:18 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Sep 2007 08:42:18 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: <20070907124218.GA19428@jadzia.bu.edu> On Fri, Sep 07, 2007 at 01:45:18PM +0200, Krzysztof Halasa wrote: > Dan Williams writes: > > Well, it's a really tricky problem. I'd personally do: > > try UTF-8 validation > > try validation from the encoding in LANG > > fall back to a lot of ? for unprintables > Perhaps asking the user for encoding would make sense. Where would one ask? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From walters at redhat.com Fri Sep 7 12:51:30 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 7 Sep 2007 08:51:30 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070907124218.GA19428@jadzia.bu.edu> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> Message-ID: Guys, this thread is a lot more appropriate on a Bugzilla. Say, here: http://bugzilla.gnome.org/show_bug.cgi?id=474543 (spotted at least one bug from your backtrace that's probably causing the crash; the encoding issue is a whole other set to which Owen's reply is the best) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Fri Sep 7 13:30:20 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Sep 2007 09:30:20 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: References: <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> Message-ID: <20070907133020.GA25022@jadzia.bu.edu> On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote: > Guys, this thread is a lot more appropriate on a Bugzilla. Say, here: I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone. I wanted to narrow things down first. > http://bugzilla.gnome.org/show_bug.cgi?id=474543 > (spotted at least one bug from your backtrace that's probably causing the > crash; the encoding issue is a whole other set to which Owen's reply is the > best) The crash is, however, *very* related to the encoding issue, because the assumed ascii string encoding is used not only for display but as the internal representation passed around in the program. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Fri Sep 7 14:14:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Sep 2007 08:14:19 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46E0CE16.1090702@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> <1189097037.3949.12.camel@rousalka.dyndns.org> <46E05FF0.5070904@gmail.com> <1189120655.6909.23.camel@localhost6.localdomain6> <46E0CE16.1090702@gmail.com> Message-ID: <1189174459.6562.14.camel@localhost6.localdomain6> On Thu, 2007-09-06 at 23:05 -0500, Les Mikesell wrote: > Is there some problem running an application where the bytecode is on a > different machine than the jvm, using nfs? No, of course not. That's what applets are designed for. Same with NFS-exported applications, but I'm thinking as real-world usage go, it's much less likely. But then, that's why there are overrides like --nodeps on rpm, I guess, just not on yum. > > There is a huge probability > > that they will need a JVM, and unlike media players, from outside, > > they're designed to function in the same way. > > I'm not sure I understand. Shouldn't you be able to use any version of > a jvm, packaged or not, without specific dependencies, just like you > could use different media players to play the same file? Or even run > more than one of them at once? Sorry, that was a bit vague. I just meant that a piece of java bytecode is usually designed to be executed in one way (either as a java application, web application, applet, etc.) or 2 or 3 at the most. Media files can be used in so many ways, not just playing them (editing, converting, analysis, etc.) Anyway, the point is that it's just not the best example to illustrate your point, and not that it doesn't. > > In Fedora, openoffice.org-core-2.2.0 Requires the virtual package java. > > > > You CAN have the app before the JVM, I suppose, the same way you can > > "rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be > > bytes taking up space in your filesystem. > > Will it work later then if I provide a different JVM than the packaged > versions? If both openoffice.org-core's Java requirements match those that the JVM installed's featureset provides, then yes. (And better if it's because they fully comply with JSRs for that version of Java(TM)). That's the beauty of modularity. > Yes, thanks, and sorry - I missed the one actual answer in the first > link, but I was confused by the comment somewhere about parts going to > private and export directories that didn't seem to be under the same top > level. Is everything expected to be under JAVA_HOME actually still in > one place? I honestly don't know. 1) So far, it's worked for me, 2) looking at the contents of the JRE (java-1.5.0-(sun|ibm)), it seems that apart from a couple of JAR files located in jvm-exports/ and jvm-private/, all the files are in (quotes) "$JAVA_HOME". Anybody read the pertinent JSR on JAVA_HOME directory layouts care to comment? -- Richi Plana From myfedora at richip.dhs.org Fri Sep 7 14:28:32 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Sep 2007 08:28:32 -0600 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E0D9BA.7090406@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> Message-ID: <1189175312.6562.28.camel@localhost6.localdomain6> On Fri, 2007-09-07 at 06:55 +0200, Thorsten Leemhuis wrote: > On 06.09.2007 20:43, Jeff Spaleta wrote: > >>> The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible. > >> Same for dkms, as modules might break if the api changed. > > > > slightly less complex for dkms, because with dkms you don't have to > > deal with synchronously building the modules on the central build > > system. > > Yeah -- so we offload the trouble to the user. And that's not the right > thing to do IMHO. We should provide pre-compiled kernel-modules if we > want to ship kernel-modules. dkms optional for that that want it: sure. I thought the idea was to offload the process to the user's computer (because that's the best place to ascertain version) and not necessarily the user. It would rather be like NVIDIA's display driver installation file. The user doesn't even know he/she's compiling (well, they're made aware but they don't have to know how). > But the signals from FESCo are afaics: no kernel-modules at all. And I > think that's the right thing to do in the merged Fedora world. I just thought I'd point out that that in subsequent discussion, just be sure to mention that what this really boils down to is a conflict between what certain spinners and users want (the capability to slim down their distro to just the bare essentials ... they call it optimizing) and what maintainers and developers want (easier code maintenance, no need to write the smart applications that alleviate all the thinking from the users' part). But even if you do go on and scrap DKMS and kernel modules from being separate packages in Fedora, I hope that Fedora helps come up with a standard for packaging kernel modules in external repos. Fedora is the best body to regulate the chaos that's going on out there. My own personal opinion is that a look at ATRPMS' kmdl2 and blessing it as a standard is the correct thing, speaking of the technical side. Either that or completely stop relying on putting meta-info into blasted RPM filenames. :) -- Richi Plana From otaylor at redhat.com Fri Sep 7 14:32:15 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 7 Sep 2007 10:32:15 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070907133020.GA25022@jadzia.bu.edu> References: <20070905131329.GA6375@ee.oulu.fi> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> Message-ID: <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> On 9/7/07, Matthew Miller wrote: > On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote: > > Guys, this thread is a lot more appropriate on a Bugzilla. Say, here: > > I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone. > I wanted to narrow things down first. > > > http://bugzilla.gnome.org/show_bug.cgi?id=474543 > > > > > (spotted at least one bug from your backtrace that's probably causing the > > crash; the encoding issue is a whole other set to which Owen's reply is the > > best) > > The crash is, however, *very* related to the encoding issue, because the > assumed ascii string encoding is used not only for display but as the > internal representation passed around in the program. I'd consider the two things actually quite distinct: * D-BUS object path: you want a *unique* *consistent* representation of the bytes of the ESSID. So you might, say, treat them as bytes and do URI-style %XY escaping of bytes that aren't legal ascii characters in the context * Display to the user: you want to make a best guess at the encoding and try to display the exact same thing that someone typed into the router configuration, rather some unique-but-looks-like-garbage escaped version. - Owen From myfedora at richip.dhs.org Fri Sep 7 14:46:37 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Sep 2007 08:46:37 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> References: <20070905131329.GA6375@ee.oulu.fi> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> Message-ID: <1189176397.6562.39.camel@localhost6.localdomain6> On Fri, 2007-09-07 at 10:32 -0400, Owen Taylor wrote: > I'd consider the two things actually quite distinct: > > * D-BUS object path: you want a *unique* *consistent* representation of the > bytes of the ESSID. So you might, say, treat them as bytes and do URI-style > %XY escaping of bytes that aren't legal ascii characters in the context +1. It's so easy with computers. Just set a standard (URI specification) and it starts to make sense everywhere. If we assume that no human will look at the D-BUS object path except likely the developers, then you can just adopt whatever's convenient for the devs. ASCII characters seem to be common for them. > * Display to the user: you want to make a best guess at the encoding and try > to display the exact same thing that someone typed into the router > configuration, > rather some unique-but-looks-like-garbage escaped version. At least with documents, there's a lot of heuristic to work on to make sense (encoding) of the the data. With ESSIDs, you're limited to 32-bytes and aren't even quite sure that they were meant to be treated as text. I don't envy the team tasked to design the algorithm for this, but I'm guessing first, they've to determine if it's supposed to be human-readable (0x00 bytes interspersed between non nulls is one indication). Otherwise, re-use some existing code to determine encoding. P.S. As much as I love reading about this issue, it probably does belong to a NetworkManager / nm-applet bugzilla or forum. -- Richi Plana From dcbw at redhat.com Fri Sep 7 15:06:28 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 07 Sep 2007 11:06:28 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> References: <20070905131329.GA6375@ee.oulu.fi> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> Message-ID: <1189177588.2612.7.camel@xo-3E-67-34.localdomain> On Fri, 2007-09-07 at 10:32 -0400, Owen Taylor wrote: > On 9/7/07, Matthew Miller wrote: > > On Fri, Sep 07, 2007 at 08:51:30AM -0400, Colin Walters wrote: > > > Guys, this thread is a lot more appropriate on a Bugzilla. Say, here: > > > > I hate to clutter up bugzilla with vague bugs. It's not helpful for anyone. > > I wanted to narrow things down first. > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=474543 > > > > > > > > > (spotted at least one bug from your backtrace that's probably causing the > > > crash; the encoding issue is a whole other set to which Owen's reply is the > > > best) > > > > The crash is, however, *very* related to the encoding issue, because the > > assumed ascii string encoding is used not only for display but as the > > internal representation passed around in the program. > > I'd consider the two things actually quite distinct: > > * D-BUS object path: you want a *unique* *consistent* representation of the > bytes of the ESSID. So you might, say, treat them as bytes and do URI-style > %XY escaping of bytes that aren't legal ascii characters in the context The decision to use the SSID as part of the D-Bus object path was insanely wrong, which is of course clear now 3 years later :) Rectified with 0.7, we may be able to fix it in 0.6.5 too since object paths are essentially just pointers and are opaque. Dan > * Display to the user: you want to make a best guess at the encoding and try > to display the exact same thing that someone typed into the router > configuration, > rather some unique-but-looks-like-garbage escaped version. > > - Owen > From overholt at redhat.com Fri Sep 7 15:46:52 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 7 Sep 2007 11:46:52 -0400 Subject: aot-compile-rpm suggestion In-Reply-To: <870180fe0709062045k75ccea6evd952ef061c0346cd@mail.gmail.com> References: <870180fe0709062045k75ccea6evd952ef061c0346cd@mail.gmail.com> Message-ID: <20070907154652.GA11580@redhat.com> * Jerry James [2007-09-06 23:45]: > It took me a little digging through the code to figure out what that > crash meant. In case others manage to trigger the same situation, it > would be good to catch this exception and issue a "You dummy, there's > nothing in your JAR file!" message instead. Please file this as a bug so it can be tracked. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Fri Sep 7 16:41:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 07 Sep 2007 12:41:57 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: <46E17F55.4000904@redhat.com> Krzysztof Halasa wrote: > Dan Williams writes: > >> Well, it's a really tricky problem. I'd personally do: >> >> try UTF-8 validation >> try validation from the encoding in LANG >> fall back to a lot of ? for unprintables > > Perhaps asking the user for encoding would make sense. The whole point of NetworkManager is to just work. Asking the user for anything is not something that should be done unless it is absolutely necessary, and the user can be expected to know it. Asking for encryption keys is a valid thing to ask. Asking the user to be able to know encodings is just insane. Even I don't know what encoding most things fall into. From caillon at redhat.com Fri Sep 7 16:52:46 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 07 Sep 2007 12:52:46 -0400 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <1189123579.24848.734.camel@mccallum.corsepiu.local> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> Message-ID: <46E181DE.8030507@redhat.com> Ralf Corsepius wrote: > Yes, it had been a closed list and maintainers did get automatically > subscribed to it - The FESCO of the time this was decided, this approach > wise - I never did - But THEM decided otherwise. So essentially you're agreeing that the way -maintainers was handled/set up by the old FESCo was wrong. Which is basically what the current FESCo decided. We can go on for days discussing various ways to fix it, but we decided that since it was broken, removing the broken bit was the best course of action for now since it provided a disservice to many people as evidenced by the complaints on the various lists about it by the very people who IMO we were trying to target. If you have a better solution for lists to actually serve the needs of the community, please propose it to FESCo. From mattdm at mattdm.org Fri Sep 7 17:23:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Sep 2007 13:23:40 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> References: <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> Message-ID: <20070907172340.GA20551@jadzia.bu.edu> On Fri, Sep 07, 2007 at 10:32:15AM -0400, Owen Taylor wrote: > > The crash is, however, *very* related to the encoding issue, because the > > assumed ascii string encoding is used not only for display but as the > > internal representation passed around in the program. > I'd consider the two things actually quite distinct: Right; but right now they're not treated that way at all. So in a way, that's the bug. > * D-BUS object path: you want a *unique* *consistent* representation of the > bytes of the ESSID. So you might, say, treat them as bytes and do URI-style > %XY escaping of bytes that aren't legal ascii characters in the context Which it *almost* does -- the ":" in my example is escaped somewhere along the line. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Fri Sep 7 17:25:17 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Sep 2007 11:25:17 -0600 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189177588.2612.7.camel@xo-3E-67-34.localdomain> References: <20070905131329.GA6375@ee.oulu.fi> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> <1189177588.2612.7.camel@xo-3E-67-34.localdomain> Message-ID: <1189185917.6562.46.camel@localhost6.localdomain6> On Fri, 2007-09-07 at 11:06 -0400, Dan Williams wrote: > The decision to use the SSID as part of the D-Bus object path was > insanely wrong, which is of course clear now 3 years later :) Rectified > with 0.7, we may be able to fix it in 0.6.5 too since object paths are > essentially just pointers and are opaque. Agree. Was wondering about why the SSID was made a part of the D-BUS object path to begin with. What was used in 0.7 to uniquely identify? -- Richi Plana From eric.tanguy at univ-nantes.fr Fri Sep 7 17:57:53 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 07 Sep 2007 19:57:53 +0200 Subject: Building problem with mock devel In-Reply-To: <1189151399.2869.2.camel@bureau.maison> References: <1189151399.2869.2.camel@bureau.maison> Message-ID: <1189187873.2852.2.camel@bureau.maison> Le vendredi 07 septembre 2007 ? 09:49 +0200, Tanguy Eric a ?crit : > /etc/profile: line 38: /bin/hostname: No such file or directory > Installing /builddir/build/SRPMS/libupnp-1.6.0-2.fc8.src.rpm > Building target platforms: i386 > Building for target i386 > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.13507 > + umask 022 > + cd /builddir/build/BUILD > + LANG=C > + export LANG > + unset DISPLAY > + cd /builddir/build/BUILD > + rm -rf libupnp-1.6.0 > + /usr/bin/bzip2 -dc /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2 > + tar -xf - > tar: error while loading shared libraries: libacl.so.1: cannot open > shared object file: No such file or directory > > bzip2: I/O or other error, bailing out. Possible reason follows. > bzip2: Broken pipe > Input file = /builddir/build/SOURCES/libupnp-1.6.0.tar.bz2, > output file = (stdout) > > Someone could help to solve this ? > > Eric > I can't achieve to solve this error. No one could help me ? Eric From jkeating at redhat.com Fri Sep 7 18:16:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 14:16:43 -0400 Subject: Building problem with mock devel In-Reply-To: <1189187873.2852.2.camel@bureau.maison> References: <1189151399.2869.2.camel@bureau.maison> <1189187873.2852.2.camel@bureau.maison> Message-ID: <20070907141643.6d36a2b1@mentok.boston.redhat.com> On Fri, 07 Sep 2007 19:57:53 +0200 Tanguy Eric wrote: > > tar: error while loading shared libraries: libacl.so.1: cannot open > > shared object file: No such file or directory When I got this it was because the libacl.so.1 symlink was pointing to the wrong location. I don't know how I got into that state, but a removal and re-install the acl packages fixed the issue. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alcapcom at gmail.com Fri Sep 7 18:10:12 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Fri, 07 Sep 2007 20:10:12 +0200 Subject: Building problem with mock devel In-Reply-To: <1189187873.2852.2.camel@bureau.maison> References: <1189151399.2869.2.camel@bureau.maison> <1189187873.2852.2.camel@bureau.maison> Message-ID: <46E19404.2020503@gmail.com> Tanguy Eric a ?crit : >> tar: error while loading shared libraries: libacl.so.1: cannot open >> shared object file: No such file or directory At first view, you add libacl package as BuildRequires. Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Fri Sep 7 18:23:19 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Sep 2007 14:23:19 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189177588.2612.7.camel@xo-3E-67-34.localdomain> References: <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> <1189177588.2612.7.camel@xo-3E-67-34.localdomain> Message-ID: <20070907182319.GA27871@jadzia.bu.edu> On Fri, Sep 07, 2007 at 11:06:28AM -0400, Dan Williams wrote: > The decision to use the SSID as part of the D-Bus object path was > insanely wrong, which is of course clear now 3 years later :) Rectified > with 0.7, we may be able to fix it in 0.6.5 too since object paths are > essentially just pointers and are opaque. So, theoretically if I install 0.7.0-0.1.svn2736.fc8 outta koji everything will be solved? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ssorce at redhat.com Fri Sep 7 18:57:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 07 Sep 2007 14:57:43 -0400 Subject: Building problem with mock devel In-Reply-To: <46E19404.2020503@gmail.com> References: <1189151399.2869.2.camel@bureau.maison> <1189187873.2852.2.camel@bureau.maison> <46E19404.2020503@gmail.com> Message-ID: <1189191463.19300.44.camel@localhost.localdomain> On Fri, 2007-09-07 at 20:10 +0200, Alphonse Van Assche wrote: > Tanguy Eric a ?crit : > >> tar: error while loading shared libraries: libacl.so.1: cannot open > >> shared object file: No such file or directory > At first view, you add libacl package as BuildRequires. I'd say: libacl-devel ? Simo. From alcapcom at gmail.com Fri Sep 7 19:02:42 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Fri, 07 Sep 2007 21:02:42 +0200 Subject: Building problem with mock devel In-Reply-To: <1189191463.19300.44.camel@localhost.localdomain> References: <1189151399.2869.2.camel@bureau.maison> <1189187873.2852.2.camel@bureau.maison> <46E19404.2020503@gmail.com> <1189191463.19300.44.camel@localhost.localdomain> Message-ID: <46E1A052.70102@gmail.com> Simo Sorce a ?crit : > On Fri, 2007-09-07 at 20:10 +0200, Alphonse Van Assche wrote: >> Tanguy Eric a ?crit : >>>> tar: error while loading shared libraries: libacl.so.1: cannot open >>>> shared object file: No such file or directory >> At first view, you add libacl package as BuildRequires. > > I'd say: libacl-devel ? > > Simo. > From what you say no. (yum provides \*libacl.so.1) Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Fri Sep 7 19:44:17 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 07 Sep 2007 14:44:17 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <1189174459.6562.14.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> <1189097037.3949.12.camel@rousalka.dyndns.org> <46E05FF0.5070904@gmail.com> <1189120655.6909.23.camel@localhost6.localdomain6> <46E0CE16.1090702@gmail.com> <1189174459.6562.14.camel@localhost6.localdomain6> Message-ID: <46E1AA11.4000605@gmail.com> Richi Plana wrote: >> I'm not sure I understand. Shouldn't you be able to use any version of >> a jvm, packaged or not, without specific dependencies, just like you >> could use different media players to play the same file? Or even run >> more than one of them at once? > > Sorry, that was a bit vague. I just meant that a piece of java bytecode > is usually designed to be executed in one way (either as a java > application, web application, applet, etc.) or 2 or 3 at the most. Media > files can be used in so many ways, not just playing them (editing, > converting, analysis, etc.) Anyway, the point is that it's just not the > best example to illustrate your point, and not that it doesn't. OK, the likely scenarios are that you have different apps that only work with one JVM each, and even with one app you always want to be able to test it under different JVM verions (including the next update) before thinking about changing the system default. >> Yes, thanks, and sorry - I missed the one actual answer in the first >> link, but I was confused by the comment somewhere about parts going to >> private and export directories that didn't seem to be under the same top >> level. Is everything expected to be under JAVA_HOME actually still in >> one place? > > I honestly don't know. 1) So far, it's worked for me, 2) looking at the > contents of the JRE (java-1.5.0-(sun|ibm)), it seems that apart from a > couple of JAR files located in jvm-exports/ and jvm-private/, all the > files are in (quotes) "$JAVA_HOME". Anybody read the pertinent JSR on > JAVA_HOME directory layouts care to comment? The answer I have really been looking for is that the concept of JAVA_HOME reliably still exists, and how to use it in spite of the efforts to hide where it lives in the alternatives universe. -- Les Mikesell lesmikesell at gmail.com From fitzsim at redhat.com Fri Sep 7 20:46:21 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 07 Sep 2007 16:46:21 -0400 Subject: Goal: Increased Modularity? In-Reply-To: <1189024443.1641.143.camel@localhost6.localdomain6> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <1189024443.1641.143.camel@localhost6.localdomain6> Message-ID: <46E1B89D.1030709@redhat.com> Richi Plana wrote: > On Wed, 2007-09-05 at 21:29 +0200, Nicolas Mailhot wrote: >> Le mercredi 05 septembre 2007 ? 12:33 -0500, Les Mikesell a ?crit : >>> Nicolas Mailhot wrote: >>> >>>>>> I want to know the correct JAVA_HOME and PATH settings for all the >>>>>> possible JVMs when they are installed as alternatives-conforming RPM >>>>>> packages but are not the system default. Is this documented somewhere? >>> So, where do I find the answer to the question above regarding the >>> correct JAVA_HOME and PATH to use a JVM that is not the system default? >> If the question is "what is the list of the roots of all the possible >> VMs that may be released for Linux and packaged using jpp conventions" > > Well, one method (and this isn't official AFAIK) is to run "alternatives > --config java" or "alternatives --config javac" and that should give you > a starting point for figuring out the list of JAVA_HOME paths for > packages installed that are blessed by JPackage (or was it Fedora? since > I'm not sure where alternatives support was introduced). Another method of querying and selecting blessed JPackage alternatives is system-switch-java. It simplifies selection because it switches all relevant master links (java, javac, plugin) to the selected vendor/version implementations. Try: yum install system-switch-java Tom From myfedora at richip.dhs.org Fri Sep 7 21:00:09 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 07 Sep 2007 15:00:09 -0600 Subject: Goal: Increased Modularity? In-Reply-To: <46E1B89D.1030709@redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <1189024443.1641.143.camel@localhost6.localdomain6> <46E1B89D.1030709@redhat.com> Message-ID: <1189198809.13800.2.camel@localhost6.localdomain6> On Fri, 2007-09-07 at 16:46 -0400, Thomas Fitzsimmons wrote: > Richi Plana wrote: > > Well, one method (and this isn't official AFAIK) is to run "alternatives > > --config java" or "alternatives --config javac" and that should give you > > a starting point for figuring out the list of JAVA_HOME paths for > > packages installed that are blessed by JPackage (or was it Fedora? since > > I'm not sure where alternatives support was introduced). > > Another method of querying and selecting blessed JPackage alternatives is > system-switch-java. It simplifies selection because it switches all relevant > master links (java, javac, plugin) to the selected vendor/version > implementations. Try: > > yum install system-switch-java The original poster was looking for a per-user solution to JVM switching. I'm guessing from the name (system-switch-java) that it switches the whole system's choice of java (javac, plugin, etc.) as opposed to just the user's. And that it probably requires some kind of elevated access permissions. Is it a frontend to the alternatives system? -- Richi Plana From lesmikesell at gmail.com Fri Sep 7 21:01:13 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 07 Sep 2007 16:01:13 -0500 Subject: Goal: Increased Modularity? In-Reply-To: <46E1B89D.1030709@redhat.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <1189024443.1641.143.camel@localhost6.localdomain6> <46E1B89D.1030709@redhat.com> Message-ID: <46E1BC19.3050002@gmail.com> Thomas Fitzsimmons wrote: > Another method of querying and selecting blessed JPackage alternatives > is system-switch-java. It simplifies selection because it switches all > relevant master links (java, javac, plugin) to the selected > vendor/version implementations. Try: > > yum install system-switch-java > Is that only in fedora 7? Also, what I'm looking for is not to switch the system default but to find how to invoke a non-default version. If this makes it obvious what JAVA_HOME should be it would be useful. -- Les Mikesell lesmikesell at gmail.com From eric.tanguy at univ-nantes.fr Fri Sep 7 21:30:35 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 07 Sep 2007 23:30:35 +0200 Subject: Building problem with mock devel In-Reply-To: <20070907141643.6d36a2b1@mentok.boston.redhat.com> References: <1189151399.2869.2.camel@bureau.maison> <1189187873.2852.2.camel@bureau.maison> <20070907141643.6d36a2b1@mentok.boston.redhat.com> Message-ID: <1189200635.2852.4.camel@bureau.maison> Le vendredi 07 septembre 2007 ? 14:16 -0400, Jesse Keating a ?crit : > On Fri, 07 Sep 2007 19:57:53 +0200 > Tanguy Eric wrote: > > > > tar: error while loading shared libraries: libacl.so.1: cannot open > > > shared object file: No such file or directory > > When I got this it was because the libacl.so.1 symlink was pointing to > the wrong location. I don't know how I got into that state, but a > removal and re-install the acl packages fixed the issue. > Rebuilding the mock buildroot cache solve the problem! Very strange ... Thanks Eric From jkeating at redhat.com Fri Sep 7 21:36:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 17:36:32 -0400 Subject: Fedora 8 Test 2 has gone gold, no more tag requests will be accepted. Freeze is over Message-ID: <20070907173632.0dd7293b@mentok.boston.redhat.com> We have satisfied ourselves that Test2 is as good as it's reasonably going to get without more delays. As such we're handing our release candidate tree off to the mirrors and unfreezing rawhide. This means that a pile of packages will land tomorrow and all kinds of new breakage may occur. The release day for Test2 is Thursday, as this gives the mirrors sufficient time to sync up and prepare for the release. Happy Hacking! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From alan at redhat.com Fri Sep 7 21:50:13 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Sep 2007 17:50:13 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <1189014587.24933.14.camel@xo-3E-67-34.localdomain> References: <20070905114802.GA17653@jadzia.bu.edu> <20070905131329.GA6375@ee.oulu.fi> <1189006016.1641.17.camel@localhost6.localdomain6> <190e0dab0709050944k7094ed8br46c268aa98c275bf@mail.gmail.com> <1189011320.1641.52.camel@localhost6.localdomain6> <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> Message-ID: <20070907215013.GJ30655@devserv.devel.redhat.com> On Wed, Sep 05, 2007 at 01:49:47PM -0400, Dan Williams wrote: > some native character like ???. However, if I live in Central Europoe > and for some reason I use ISO 8859-15 (or whatever it is) I'd probably Depends where, but ISO-8859-* are essentially obsolete for europe in favour of Unicode. From martin.sourada at seznam.cz Fri Sep 7 22:07:24 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 08 Sep 2007 00:07:24 +0200 Subject: rpms/xulrunner/devel xulrunner.spec,1.12,1.13 In-Reply-To: <200709060407.l8647b3M012976@cvs-int.fedora.redhat.com> References: <200709060407.l8647b3M012976@cvs-int.fedora.redhat.com> Message-ID: <1189202844.3143.8.camel@pc-notebook> On Thu, 2007-09-06 at 06:07 +0200, Christopher Aillon wrote: > Author: caillon > > Update of /cvs/extras/rpms/xulrunner/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv12949 > > Modified Files: > xulrunner.spec > Log Message: > fix file not found error > > > > Index: xulrunner.spec > =================================================================== > RCS file: /cvs/extras/rpms/xulrunner/devel/xulrunner.spec,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -r1.12 -r1.13 > --- xulrunner.spec 5 Sep 2007 19:55:01 -0000 1.12 > +++ xulrunner.spec 6 Sep 2007 04:07:04 -0000 1.13 > @@ -225,7 +225,7 @@ > > # set up our default preferences > %{__cat} %{SOURCE12} | %{__sed} -e 's,RPM_VERREL,%{version}-%{release},g' > rh-default-prefs > -%{__cp} rh-default-prefs $RPM_BUILD_ROOT/${MOZ_APP_DIR}/defaults/pref/all-redhat.js > +%{__install} -p -D -m 644 rh-default-prefs $RPM_BUILD_ROOT/${MOZ_APP_DIR}/defaults/pref/all-redhat.js > %{__rm} rh-default-prefs > > # set up our default bookmarks > Hi, I am trying to build a xulrunner from your spec in order to test it with my packages that can make use of it, but it seems that there is completely missing make install in the %%install section. Is that by oversight, or do you intend to do the install by hand in the spec file (or some fedora-specific script)? Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Sat Sep 8 00:39:56 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 07 Sep 2007 20:39:56 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <46DF85D6.2090901@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> <46DF85D6.2090901@leemhuis.info> Message-ID: <200709080040.l880du65005203@laptop13.inf.utfsm.cl> Thorsten Leemhuis wrote: [...] > The real solution IMHO is to make two lists: > > * a "developers" list, where only developers (be it Fedora developers, > developers of other distributions or developers of Linux Software we > ship) discuss. Make it moderated for a months or two to enforce the > target audience -- I suppose afterwards it will work without moderation > if we are a bit careful and point people to the right list. Doesn't work. A list needs a (somewhat fascist) owner to keep posters in line. -- 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 dwmw2 at infradead.org Sat Sep 8 02:01:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Sep 2007 03:01:38 +0100 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <46E118D2.7050807@leemhuis.info> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> Message-ID: <1189216898.3488.150.camel@pmac.infradead.org> On Fri, 2007-09-07 at 11:24 +0200, Thorsten Leemhuis wrote: > dwmw2's proposal afaics mainly reads as "no > separately packaged *kernel-modules* (in source or binary form) in > Fedora at all"; but he uses the term "kmods" here and there (and kmod > specific examples), so some people afaics got the idea that something > else (like dkms) would be acceptable. I doubt that's the intention > behind dwmw2's proposal. David, can you clarify? Or Jesse (who's listed > as owner for the proposal as well)? Indeed it was not the intention -- I used the term 'kmod' to refer to a generic evil. I have clarified the wording now. Not only do I think we shouldn't ship modules in binary form, I think we shouldn't be shipping them in source form as dkms payload either. I've no particular objection to shipping dkms itself, just as I have no objection to shipping the kernel-devel package -- I just don't think there's any justification for shipping 'dkms payload' packages as part of Fedora. > > Why not to close this topic > > with "No Kmod Packages Allowed in Fedora Repository"? > > Same here ;-) Make that a "No separately packaged kernel-modules in > Fedora at all" and it gets a +1 from me. > > > I think still something is going on that is preventing FESCO to > > directly come to conclusion of disallowing kernel module packages in > > fedora". > > From looking at the FESCo meeting logs it were just real life issues: > dwmw2 was not around yesterday... Yeah, I need to apologise for my poor attendance at meetings in the last few weeks. Being in Shanghai babysitting OLPC builds makes the meeting about 1am local time -- which when I'm working 14-hour days means that if I _did_ wake up for it I wouldn't be massively coherent anyway. This week it was the Kernel Summit... but I really will try to be present next week, even though I'll be away from home again at another meeting. I do appreciate the faith that people placed in me when they voted for me (assuming they did, and it wasn't just a conspiracy that I got in), and I know that I need to repay that trust. I won't keep skipping meetings -- I promise. -- dwmw2 From jkeating at redhat.com Sat Sep 8 01:48:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 21:48:12 -0400 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <20070830205314.7e66bdff@ender> References: <20070830205314.7e66bdff@ender> Message-ID: <20070907214812.05d204e1@ender> On Thu, 30 Aug 2007 20:53:14 -0400 Jesse Keating wrote: > The proposed new explicit list would look like: > > bzip2 > unzip > fedora-release > redhat-rpm-config > diffutils > make > cpio > gcc > coreutils > sed > which > rpm-build > gzip > patch > gcc-c++ > tar > bash > util-linux-ng > gawk > info > grep > findutils These are now the minimal build group. Reasonable requests to add more of what is currently implicit into the explicit list will gladly be discussed, but for now the important thing was to get util-linux-ng back in the set, and to remove perl(-devel) from the set. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From wart at kobold.org Sat Sep 8 02:06:56 2007 From: wart at kobold.org (Wart) Date: Fri, 07 Sep 2007 19:06:56 -0700 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <20070907214812.05d204e1@ender> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> Message-ID: <46E203C0.90506@kobold.org> Jesse Keating wrote: > On Thu, 30 Aug 2007 20:53:14 -0400 > Jesse Keating wrote: > >> The proposed new explicit list would look like: >> [...] > > These are now the minimal build group. Reasonable requests to add more > of what is currently implicit into the explicit list will gladly be > discussed, but for now the important thing was to get util-linux-ng > back in the set, and to remove perl(-devel) from the set. Can I assume that it is not necessary to rebuild packages for the sole purpose of updating BuildRequires due to the buildroot changes? --Wart From jkeating at redhat.com Sat Sep 8 02:02:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 22:02:22 -0400 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <46E203C0.90506@kobold.org> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> <46E203C0.90506@kobold.org> Message-ID: <20070907220222.29c5681c@ender> On Fri, 07 Sep 2007 19:06:56 -0700 Wart wrote: > Can I assume that it is not necessary to rebuild packages for the > sole purpose of updating BuildRequires due to the buildroot changes? Yes, that is a safe assumption. You can update cvs now if you wish, but save the build until you have a reason to build. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jon.nettleton at gmail.com Sat Sep 8 02:41:44 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 7 Sep 2007 22:41:44 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <1189216898.3488.150.camel@pmac.infradead.org> References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> Message-ID: On 9/7/07, David Woodhouse wrote: > On Fri, 2007-09-07 at 11:24 +0200, Thorsten Leemhuis wrote: > > dwmw2's proposal afaics mainly reads as "no > > separately packaged *kernel-modules* (in source or binary form) in > > Fedora at all"; but he uses the term "kmods" here and there (and kmod > > specific examples), so some people afaics got the idea that something > > else (like dkms) would be acceptable. I doubt that's the intention > > behind dwmw2's proposal. David, can you clarify? Or Jesse (who's listed > > as owner for the proposal as well)? > > Indeed it was not the intention -- I used the term 'kmod' to refer to a > generic evil. I have clarified the wording now. > > Not only do I think we shouldn't ship modules in binary form, I think we > shouldn't be shipping them in source form as dkms payload either. > > I've no particular objection to shipping dkms itself, just as I have no > objection to shipping the kernel-devel package -- I just don't think > there's any justification for shipping 'dkms payload' packages as part > of Fedora. > But do you have an objection to including dkms hooks in kernel rpms or existing scripts called from pre/post install scripts? There are lots of examples but my specific one is the gspca driver that I built the first dkms package for and is exists at freshrpms. This driver supports a lot of modern webcams, but the driver developer has no intention of even trying to have this code merged into the kernel. What are we to do in this circumstance? I think we need something better than the "safe" ostrich syndrome; if it is out of the kernel it scares us and we run away from it. There is plenty of legitimate driver development being done outside of the kernel. It just seems a bad decision to completely bury our heads in the sand to this code-base. Of course this is coming from someone that has 5 critical modules ( to me ) running and upgraded through dkms. -Jon From dwmw2 at infradead.org Sat Sep 8 03:06:52 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Sep 2007 04:06:52 +0100 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> Message-ID: <1189220812.3488.186.camel@pmac.infradead.org> On Fri, 2007-09-07 at 22:41 -0400, Jon Nettleton wrote: > On 9/7/07, David Woodhouse wrote: > > I've no particular objection to shipping dkms itself, just as I have no > > objection to shipping the kernel-devel package -- I just don't think > > there's any justification for shipping 'dkms payload' packages as part > > of Fedora. > > > > But do you have an objection to including dkms hooks in kernel rpms or > existing scripts called from pre/post install scripts? I have no particular objection to that either, in principle. > There are lots of examples but my specific one is the gspca driver > that I built the first dkms package for and is exists at freshrpms. > This driver supports a lot of modern webcams, but the driver developer > has no intention of even trying to have this code merged into the > kernel. What are we to do in this circumstance? Take driver developer out back and quietly shoot him. Start work on sending driver upstream. Merge driver into Fedora kernel RPM, if it's good enough and someone competent wants to maintain it there while it's being pushed upstream. > I think we need something better than the "safe" ostrich syndrome; if > it is out of the kernel it scares us and we run away from it. There > is plenty of legitimate driver development being done outside of the > kernel. It just seems a bad decision to completely bury our heads in > the sand to this code-base. I've spent much of the last decade maintaining precisely such a code base, and building it outside the kernel tree. It was me who pushed the whole "make -C /usr/src/wherever SUBDIRS=`pwd` modules" thing until it became the standard way of building out-of-tree kernel modules, instead of having people cobble together their own makefiles and consistently getting it wrong. I'm not _scared_ of out-of-tree code; I just feel very strongly that if it's good enough for us to be shipping as part of "Fedora", then we should be putting it into the proper kernel package. -- dwmw2 From fedora at leemhuis.info Sat Sep 8 05:37:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 08 Sep 2007 07:37:04 +0200 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <200709080040.l880du65005203@laptop13.inf.utfsm.cl> References: <1189008703.2702.2.camel@kennedy> <1189035274.3189.18.camel@tuxhugs> <1189036171.20671.1.camel@kennedy> <1189036642.24848.631.camel@mccallum.corsepiu.local> <645d17210709051703v6a176256r49860328a61cae24@mail.gmail.com> <46DF85D6.2090901@leemhuis.info> <200709080040.l880du65005203@laptop13.inf.utfsm.cl> Message-ID: <46E23500.9080404@leemhuis.info> On 08.09.2007 02:39, Horst H. von Brand wrote: > Thorsten Leemhuis wrote: > > [...] >> The real solution IMHO is to make two lists: >> >> * a "developers" list, where only developers (be it Fedora developers, >> developers of other distributions or developers of Linux Software we >> ship) discuss. Make it moderated for a months or two to enforce the >> target audience -- I suppose afterwards it will work without moderation >> if we are a bit careful and point people to the right list. > > Doesn't work. I agree that there is a risk that it doesn't work perfectly, but I suppose it will work better then now. There was also the idea to make it moderated fo ever (which IIRC ubuntu did for their major devel-list) for non-developers (witch should includes upstream developers or people developing somewhere in the Linux-space), but some people didn't like that due to the work that will be needed for it. > A list needs a (somewhat fascist) owner to keep posters in > line. Well, I'd say "support from those on the list" is the better approach. Just like in #fedora-devel on freenode you even for easy questions should not get more detailed answers on lists than "your question is off-topic here; go to list foo instead". CU knurd From opensource at till.name Sat Sep 8 05:46:51 2007 From: opensource at till.name (Till Maas) Date: Sat, 08 Sep 2007 07:46:51 +0200 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <20070907214812.05d204e1@ender> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> Message-ID: <200709080746.56772.opensource@till.name> On Sa September 8 2007, Jesse Keating wrote: > These are now the minimal build group. Reasonable requests to add more > of what is currently implicit into the explicit list will gladly be > discussed, but for now the important thing was to get util-linux-ng > back in the set, and to remove perl(-devel) from the set. Please make everything that is implicit now, also explicit with "secondary priority" and only remove packages from the Exceptions list once every development cycle. When it is time to clean up the list, you can check whether every "secondary priority" package is a dependency of a "primary priority" package and if one is not, remove it. If would be also nice, if there where was a way to scratch build packages in koji against the implicit list, so one can test whethe BR need to be adjusted in the future. But with the "secondary priority" packages always being installed, it prevents breaking builds for missing BRs without a warning, that this may happen. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Sat Sep 8 06:57:28 2007 From: opensource at till.name (Till Maas) Date: Sat, 08 Sep 2007 08:57:28 +0200 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <1189216898.3488.150.camel@pmac.infradead.org> References: <1189008703.2702.2.camel@kennedy> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> Message-ID: <200709080857.35899.opensource@till.name> On Sa September 8 2007, David Woodhouse wrote: > On Fri, 2007-09-07 at 11:24 +0200, Thorsten Leemhuis wrote: > > dwmw2's proposal afaics mainly reads as "no > > separately packaged *kernel-modules* (in source or binary form) in > > Fedora at all"; but he uses the term "kmods" here and there (and kmod > Indeed it was not the intention -- I used the term 'kmod' to refer to a > generic evil. I have clarified the wording now. > > Not only do I think we shouldn't ship modules in binary form, I think we > shouldn't be shipping them in source form as dkms payload either. There are some open questions to how to get a new kernel module into Fedora, once this proposal is accepted. Who will decide whether a new kernel module will be accepted as a patch for the kernel rpm? Will there be a guideline on how to add a kernel module as a patch to the kernel rpm? How will proposed kernel modules be reviewed / decided, whether or not it is good enough to be included in the kernel rpm? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From frank-buettner at gmx.net Sat Sep 8 07:36:21 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 08 Sep 2007 09:36:21 +0200 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. Message-ID: <46E250F5.2000103@gmx.net> Hello, something with the build system is wrong. The build self will work, but the system says failed. Have anyone see this also? Build ID: 36210 and 36211. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From mschwendt.tmp0701.nospam at arcor.de Sat Sep 8 08:36:57 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 8 Sep 2007 10:36:57 +0200 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <46E250F5.2000103@gmx.net> References: <46E250F5.2000103@gmx.net> Message-ID: <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> On Sat, 08 Sep 2007 09:36:21 +0200, Frank B?ttner wrote: > Hello, > something with the build system is wrong. > The build self will work, but the system says failed. > Have anyone see this also? > > Build ID: 36210 and 36211. It has been a topic on fedora-maintainer multiple times. Here's the corresponding ticket: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 From frank-buettner at gmx.net Sat Sep 8 09:01:24 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 08 Sep 2007 11:01:24 +0200 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> References: <46E250F5.2000103@gmx.net> <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46E264E4.6070501@gmx.net> Michael Schwendt schrieb: > On Sat, 08 Sep 2007 09:36:21 +0200, Frank B?ttner wrote: > >> Hello, >> something with the build system is wrong. >> The build self will work, but the system says failed. >> Have anyone see this also? >> >> Build ID: 36210 and 36211. > > It has been a topic on fedora-maintainer multiple times. Here's the > corresponding ticket: > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 > Yes, it's my problem too. I hope it will be fixed soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Sat Sep 8 09:12:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 8 Sep 2007 12:12:46 +0300 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <20070907214812.05d204e1@ender> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> Message-ID: <200709081212.47162.ville.skytta@iki.fi> On Saturday 08 September 2007, Jesse Keating wrote: > On Thu, 30 Aug 2007 20:53:14 -0400 > > Jesse Keating wrote: > > The proposed new explicit list would look like: [...] > > These are now the minimal build group. Reasonable requests to add more > of what is currently implicit into the explicit list will gladly be > discussed, but for now the important thing was to get util-linux-ng > back in the set, and to remove perl(-devel) from the set. Which distro branches does this change affect? EPEL too? util-linux-ng is only in Fedora devel, will util-linux be included in the list for earlier distro versions? If yes, I think it'd be good to clarify that in Wiki. Things at http://buildsys.fedoraproject.org/buildgroups/ don't seem to have been updated yet. From sdl.web at gmail.com Sat Sep 8 09:17:35 2007 From: sdl.web at gmail.com (Leo) Date: Sat, 08 Sep 2007 10:17:35 +0100 Subject: xorg-7.3 plans? References: <1189099991.24181.3745.camel@localhost.localdomain> Message-ID: On 2007-09-06 18:33 +0100, Adam Jackson wrote: > On Thu, 2007-09-06 at 11:17 -0400, Neal Becker wrote: >> xorg-7.3 is released, with support for hot-plugging. What is the roadmap >> for fedora? Will this be a post-f8 update? > > Since we're well past feature freeze for F8, this will not land until > F9's rawhide cycle. We've included many of the other components, but > the X server itself will remain at 1.3 for F8. > > - ajax How about an update for F7? -- Leo (GPG Key: 9283AA3F) "(require 'cl) considered harmful" considered harmful http://dto.freeshell.org/blog/blog-2007-09-07-2323.html From alan at redhat.com Sat Sep 8 09:42:05 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Sep 2007 05:42:05 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> Message-ID: <20070908094205.GB31856@devserv.devel.redhat.com> On Fri, Sep 07, 2007 at 10:41:44PM -0400, Jon Nettleton wrote: > This driver supports a lot of modern webcams, but the driver developer > has no intention of even trying to have this code merged into the > kernel. What are we to do in this circumstance? Talk to Greg KH and maybe als put a copy in the base tree anyway as the GPL permits is the view I took away from the kernel summit. Greg is working with people to get stuff in tree and failing that if the issue about being in/out of tree is 'can't be bothered' 'don't like the politics' or similar then we can find someone willing to act as the kernel tree side merge/review/keeper. From opensource at till.name Sat Sep 8 10:29:39 2007 From: opensource at till.name (Till Maas) Date: Sat, 08 Sep 2007 12:29:39 +0200 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <200709081212.47162.ville.skytta@iki.fi> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> <200709081212.47162.ville.skytta@iki.fi> Message-ID: <200709081229.44025.opensource@till.name> On Sa September 8 2007, Ville Skytt? wrote: > Things at http://buildsys.fedoraproject.org/buildgroups/ don't seem to have > been updated yet. Afaik, the packages there are not needed for devel anymore. \o/ Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ville.skytta at iki.fi Sat Sep 8 10:56:15 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 8 Sep 2007 13:56:15 +0300 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <200709081229.44025.opensource@till.name> References: <20070830205314.7e66bdff@ender> <200709081212.47162.ville.skytta@iki.fi> <200709081229.44025.opensource@till.name> Message-ID: <200709081356.17241.ville.skytta@iki.fi> On Saturday 08 September 2007, Till Maas wrote: > On Sa September 8 2007, Ville Skytt? wrote: > > Things at http://buildsys.fedoraproject.org/buildgroups/ don't seem to > > have been updated yet. > > Afaik, the packages there are not needed for devel anymore. \o/ But I think they are needed at least by EPEL and FE-6 build systems, and configurations shipped in the current FE-6 and F-7 mock packages. From dwmw2 at infradead.org Sat Sep 8 11:18:22 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Sep 2007 12:18:22 +0100 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: <200709080857.35899.opensource@till.name> References: <1189008703.2702.2.camel@kennedy> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> <200709080857.35899.opensource@till.name> Message-ID: <1189250302.3488.267.camel@pmac.infradead.org> On Sat, 2007-09-08 at 08:57 +0200, Till Maas wrote: > There are some open questions to how to get a new kernel module into Fedora, > once this proposal is accepted. The best answer to this will _always_ be: Mail it to torvalds at linux-foundation.org. However, we've often added new stuff to the kernel package, when it's _almost_ ready to go upstream or we have a particular need for it in the distribution. > Who will decide whether a new kernel module will be accepted as a patch for > the kernel rpm? I thought that was made explicitly clear in the proposal on the wiki. > Will there be a guideline on how to add a kernel module as a > patch to the kernel rpm? Prepare the patch as you would send it to Linus. Do so. If there's a _damn_ good reason for wanting it in Fedora sooner, then ask. The precise mechanism for asking isn't clear -- personally I usually just mail davej or hassle him on IRC. Perhaps bugzilla would be more appropriate? I haven't written that down, because it's mostly down to the preference of the kernel RPM maintainers. > How will proposed kernel modules be reviewed / > decided, whether or not it is good enough to be included in the kernel rpm? Dave looks into the magic 8-ball, which tells him whether to accept it or not. More seriously: In general, if it's good enough then Linus will accept it. If not, he won't. Exceptions to that rule can be handled on a case-by-case basis, and the final arbiter will be... well, I've said that already. -- dwmw2 From buildsys at fedoraproject.org Sat Sep 8 12:10:16 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 8 Sep 2007 08:10:16 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-08 Message-ID: <20070908121016.982C3152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 14 NEW armacycles-ad-0.2.8.2.1-5.fc6 : A lightcycle game in 3D NEW aspell-sk-0.52-3.fc6 : Slovak dictionaries for Aspell balsa-2.3.20-1.fc6 NEW flashrom-0-0.1.20070830svn2753.fc6 : Simple program for reading/writing BIOS chips content kbackup-0.5.2-1.fc6 NEW micq-0.5.4.2-4.fc6 : Text/line based ICQ client with many features mksh-31-1.fc6 mod_geoip-1.2.0-1.fc6 netpanzer-0.8.2-1.fc6 perl-Class-ReturnValue-0.55-1.fc6 NEW perl-IPC-Run3-0.037-2.fc6 : Run a subprocess in batch mode (a la system) on Unix, Win32, etc phpMyAdmin-2.11.0-1.fc6 qtparted-0.4.5-15.fc6 sipp-2.0.1-4.fc6 Changes in Fedora Extras 6: armacycles-ad-0.2.8.2.1-5.fc6 ----------------------------- * Fri Aug 31 2007 Jon Ciesla - 0.2.8.2.1-5 - Dropped extraneous script. - Removed .desktop version, Application category. * Thu Aug 16 2007 Hans de Goede - 0.2.8.2.1-4 - Use %configure instead of calling Configure ourselves, this fixes the configuration files being put in /usr/etc (now in /etc) - Wrap all lines > 80 chars - Use URL for Source0 - Install all size icons - Fix dedicated package Summary (CycleWeasel > Armacycles Ad) - Don't use strange x.final.y release field, for final versions normal release fields should be used - Add --disable-uninstall to %configure flags, people should use yum / pirut to uninstall packages, not some upstream provided script - Remove unused /usr/share/armacyclesad-dedicated/desktop dir - Replace SDL_mixer, SDL_image, libpng BuildRequires by their -devel parts * Tue Aug 14 2007 Jon Ciesla - 0.2.8.2.1-1.final.3 - Multiple review fixes. * Thu Aug 09 2007 Jon Ciesla - 0.2.8.2.1-1.final.2 - Added desktop file and icon, fixed summary. aspell-sk-0.52-3.fc6 -------------------- * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.52-3 - changed requirement to aspell >= 12:0.60 because of there worldlist incompatibility - debug_package set to nil to prevent empty debuginfo package - configure is called with sh interpreter to prevent rpmlint errors * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.52-2 - added macros to Source tag - cleanups * Sun Aug 26 2007 Jan ONDREJ (SAL) - 0.52-1 - initial release - configure rename to reconfigure to skip rpmlint errors balsa-2.3.20-1.fc6 ------------------ * Fri Sep 07 2007 Pawel Salek - 2.3.20-1 - update to upstream 2.3.20, fix #474366. flashrom-0-0.1.20070830svn2753.fc6 ---------------------------------- * Thu Sep 06 2007 Peter Lemenkov 0-0.1.20070830svn2753 - svn ver. 2753 (support for W29C040P and W29EE011 chips added) - New naming scheme * Wed Aug 22 2007 Peter Lemenkov 0.0-1.2744svn - svnver. 2744 kbackup-0.5.2-1.fc6 ------------------- * Thu Sep 06 2007 Alain Portal 0.5.2-1 - New upstream version - Update patch 1 - Remove patch 2 that is no more needed - Licence tag clarification micq-0.5.4.2-4.fc6 ------------------ * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.5.4.2-4 - using iconv instead of convmv * Wed Sep 05 2007 Jan ONDREJ (SAL) - 0.5.4.2-3 - added forgotten enca to BuildRequires - updated description (removed author) - install keeps file tempstamps * Wed Sep 05 2007 Jan ONDREJ (SAL) - 0.5.4.2-2 - changelog section moved to end of spec file - compilation condition removed - paralel compilation support added - libotr-devel added to BuildRequires to build package on f8 too - compilation flags updated (-O4 removed) - man files converted to UTF-8 - added lang macros for man pages - EVR added to changelog entries * Sun Aug 26 2007 Jan ONDREJ (SAL) - 0.5.4.2-1 - rpmlint cleanups mksh-31-1.fc6 ------------- * Sat Sep 08 2007 Robert Scheck 31-1 - Upgrade to 31 * Tue Aug 28 2007 Robert Scheck 30-2 - Updated the license tag according to the guidelines mod_geoip-1.2.0-1.fc6 --------------------- * Wed Sep 05 2007 Michael Fleming 1.2.0-1 - New upstream release - Employ some macro sanity.. netpanzer-0.8.2-1.fc6 --------------------- * Wed Aug 29 2007 Jon Ciesla 0.8.2-1 - Bumped to 0.8.2. - Merged in and obsoleted/provided netpanzer-data to follow upstream. - Patch to correct upstream .desktop file. * Thu Aug 16 2007 Jon Ciesla 0.8.1-2 - License tag correction. perl-Class-ReturnValue-0.55-1.fc6 --------------------------------- * Thu Sep 06 2007 Ralf Cors?pius - 0.55-1 - Upstream update. - Spec cleanup. perl-IPC-Run3-0.037-2.fc6 ------------------------- * Fri Sep 07 2007 Ralf Cors?pius 0.037-2 - Initial import. - Update license tag. phpMyAdmin-2.11.0-1.fc6 ----------------------- * Thu Sep 06 2007 Mike McGrath 2.11.0-1 - Upstream released new version - Altered sources file as required - Added proper license qtparted-0.4.5-15.fc6 --------------------- * Thu Sep 06 2007 Steven Pritchard 0.4.5-15 - Fix qtparted.pam (#237075). * Thu Mar 29 2007 Steven Pritchard - 0.4.5-14 - Rebuild again. * Tue Mar 20 2007 Steven Pritchard - 0.4.5-13 - Rebuild. sipp-2.0.1-4.fc6 ---------------- * Fri Sep 07 2007 Peter Lemenkov 2.0.1-4 - Removed .svn entries (close BZ #282431) - Added macro for builds for EL-4 * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.2 - finally added correct BR for EL-4 * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.1 - rebuild * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3 - Added tcpdump instead of libpcap as BR for EL-4 From jonathan.underwood at gmail.com Sat Sep 8 12:17:29 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 8 Sep 2007 13:17:29 +0100 Subject: Is PKG_CONFIG_PATH set on the buildsystem? Message-ID: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> Hi, I was just trying to update package of mine, and the main change is adding the following macros to the spec file: %define emacs_version %(pkg-config emacs --modversion) %define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) %define emacs_startdir %(pkg-coonfig emacs --variable sitestartdir) in order to determine those things at package build time (as discussed previously on fedora-packaging). However, on attempting to check the changes in, I get this: cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel Package emacs was not found in the pkg-config search path. Perhaps you should add the directory containing `emacs.pc' to the PKG_CONFIG_PATH environment variable No package 'emacs' found error: line 31: Version required: Requires: emacs >= error: query of specfile emacs-vm.spec failed, can't parse Package emacs was not found in the pkg-config search path. Perhaps you should add the directory containing `emacs.pc' to the PKG_CONFIG_PATH environment variable No package 'emacs' found error: line 31: Version required: Requires: emacs >= error: query of specfile emacs-vm.spec failed, can't parse cvs tag -c emacs-vm-- ? .build-8.0.3.495-1.fc8.log ? .build-8.0.3.495-3.fc8.log ? .emacs.desktop ? clog ? emacs-vm-8.0.3.495-1.fc8.src.rpm ? emacs-vm-8.0.3.495-3.fc8.src.rpm ? vm-8.0.2-devo-482.tgz ? vm-8.0.3-495 ? x86_64 ERROR: Tag emacs-vm-- is not in name-version-release format cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 Is it therefore not possible to call pkg-config from within a spec file? Could this be fixed? Cheers, Jonathan From snecklifter at gmail.com Sat Sep 8 12:21:25 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 8 Sep 2007 13:21:25 +0100 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> Message-ID: <364d303b0709080521w56f7ac49q8442a886fddcb7ae@mail.gmail.com> On 08/09/07, Jonathan Underwood wrote: > > Hi, > > I was just trying to update package of mine, and the main change is > adding the following macros to the spec file: > > %define emacs_version %(pkg-config emacs --modversion) > %define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) > %define emacs_startdir %(pkg-coonfig emacs --variable sitestartdir) > > in order to determine those things at package build time (as discussed > previously on fedora-packaging). However, on attempting to check the > changes in, I get this: > > cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel > Package emacs was not found in the pkg-config search path. > Perhaps you should add the directory containing `emacs.pc' > to the PKG_CONFIG_PATH environment variable > No package 'emacs' found > error: line 31: Version required: Requires: emacs >= > error: query of specfile emacs-vm.spec failed, can't parse > Package emacs was not found in the pkg-config search path. > Perhaps you should add the directory containing `emacs.pc' > to the PKG_CONFIG_PATH environment variable > No package 'emacs' found > error: line 31: Version required: Requires: emacs >= > error: query of specfile emacs-vm.spec failed, can't parse > cvs tag -c emacs-vm-- > ? .build-8.0.3.495-1.fc8.log > ? .build-8.0.3.495-3.fc8.log > ? .emacs.desktop > ? clog > ? emacs-vm-8.0.3.495-1.fc8.src.rpm > ? emacs-vm-8.0.3.495-3.fc8.src.rpm > ? vm-8.0.2-devo-482.tgz > ? vm-8.0.3-495 > ? x86_64 > ERROR: Tag emacs-vm-- is not in name-version-release format > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > > > Is it therefore not possible to call pkg-config from within a spec > file? Could this be fixed? > I think buildsys is having a bad hair day. My builds are failing because util-linux-ng is missing as a dependency. http://koji.fedoraproject.org/koji/getfile?taskID=152224&name=srpm.log http://koji.fedoraproject.org/koji/getfile?taskID=152224&name=root.log Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Sep 8 12:24:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 8 Sep 2007 08:24:14 -0400 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <364d303b0709080521w56f7ac49q8442a886fddcb7ae@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <364d303b0709080521w56f7ac49q8442a886fddcb7ae@mail.gmail.com> Message-ID: <20070908082414.5fcc8ea5@ender> On Sat, 8 Sep 2007 13:21:25 +0100 "Christopher Brown" wrote: > I think buildsys is having a bad hair day. My builds are failing > because util-linux-ng is missing as a dependency. > > http://koji.fedoraproject.org/koji/getfile?taskID=152224&name=srpm.log > http://koji.fedoraproject.org/koji/getfile?taskID=152224&name=root.log This was my fault. I've fixed it and the buildsystem shouldn't fail on this in roughly 20 minutes. (or once http://koji.fedoraproject.org/koji/taskinfo?taskID=152254 completes.) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Sat Sep 8 12:49:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 8 Sep 2007 14:49:30 +0200 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> Message-ID: <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> On Sat, 8 Sep 2007 13:17:29 +0100, Jonathan Underwood wrote: > Hi, > > I was just trying to update package of mine, and the main change is > adding the following macros to the spec file: > > %define emacs_version %(pkg-config emacs --modversion) > %define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) > %define emacs_startdir %(pkg-coonfig emacs --variable sitestartdir) > > in order to determine those things at package build time (as discussed > previously on fedora-packaging). However, on attempting to check the > changes in, I get this: > > cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel > Package emacs was not found in the pkg-config search path. > Perhaps you should add the directory containing `emacs.pc' > to the PKG_CONFIG_PATH environment variable > No package 'emacs' found > error: line 31: Version required: Requires: emacs >= > error: query of specfile emacs-vm.spec failed, can't parse (!) > Package emacs was not found in the pkg-config search path. > Perhaps you should add the directory containing `emacs.pc' > to the PKG_CONFIG_PATH environment variable > No package 'emacs' found > error: line 31: Version required: Requires: emacs >= > error: query of specfile emacs-vm.spec failed, can't parse > cvs tag -c emacs-vm-- > ? .build-8.0.3.495-1.fc8.log > ? .build-8.0.3.495-3.fc8.log > ? .emacs.desktop > ? clog > ? emacs-vm-8.0.3.495-1.fc8.src.rpm > ? emacs-vm-8.0.3.495-3.fc8.src.rpm > ? vm-8.0.2-devo-482.tgz > ? vm-8.0.3-495 > ? x86_64 > ERROR: Tag emacs-vm-- is not in name-version-release format > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > > > Is it therefore not possible to call pkg-config from within a spec > file? Could this be fixed? You can fix it by not creating invalid tags in your spec file. See (!) above. Just make sure that when pkg-config returns false and your macros are empty, you either override the macros with defaults or you create valid "Requires" tags via %if/%else/... From j.w.r.degoede at hhs.nl Sat Sep 8 13:12:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 08 Sep 2007 15:12:38 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) Message-ID: <46E29FC6.4090103@hhs.nl> Hi All, A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora. Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471 But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package? As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello. Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL. Notice that umbrello and kdesdk are just an example, this goes for other Aggregation upstreams too. Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello. If an upstream disolves into something bigger thats a whole different story, I'm talking about the aggregated project still having a clearly alive and active upstream. Actually this is much like having apps with bundled other upstream libs, where we always say these must not be used, and we even delay reviews, waiting for a package and review of the lib as a seperate package if necessary. I say we should extend this rule to bundled clearly seperate upstream apps. p.s. From j.w.r.degoede at hhs.nl Sat Sep 8 13:13:22 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 08 Sep 2007 15:13:22 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <46E29FF2.2060402@hhs.nl> Hans de Goede wrote: > > p.s. > Thats p.s. should have been: Regards, Hans (copy paste mess up) From opensource at till.name Sat Sep 8 13:24:32 2007 From: opensource at till.name (Till Maas) Date: Sat, 08 Sep 2007 15:24:32 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <200709081524.38289.opensource@till.name> On Sa September 8 2007, Hans de Goede wrote: > As it currently stands umbrello is just plain unfindable to end users, as > you know I'm not some noob. I even searched for in progress reviews of > umbrello. > > Also I think it is a very bad idea to ship packages with a clearly seperate > upstream in some kinda bundle form. Sticking with the umbrello example, in > order for the latest version to be included into Fedora, we must wait for a > new upstream kdesdk release, which likely won't happen before there is a > kdesdk4 in some far away future, as kde3 is as good as EOL. > > Notice that umbrello and kdesdk are just an example, this goes for other > Aggregation upstreams too. > > Since on of Fedora's strenghts is being always up to date with the latest > upstream versions, I think using these kind of upstream aggregation > projects is a BAD idea as it creates interlocks with regards to versions > between clearly seperate projects like kdesdk and umbrello. I agree completely. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lemenkov at gmail.com Sat Sep 8 13:29:50 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 8 Sep 2007 17:29:50 +0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: 2007/9/8, Hans de Goede : > As it currently stands umbrello is just plain unfindable to end users, as you > know I'm not some noob. I even searched for in progress reviews of umbrello. Heh :) Have you ever tried to install, say mp3-decoding plugins into GStreamer? There are a 4 subpackages with nothing-said-about-content names as gstreamer-plugins-bad, gstreamer-plugins-good etc. If I grep through "yum list" results I see nothing in this case but I never heard that anybody wants to change this situation. -- With best regards! From jonathan.underwood at gmail.com Sat Sep 8 13:46:31 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 8 Sep 2007 14:46:31 +0100 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <645d17210709080646q3a797e0asfa408fbe17f08192@mail.gmail.com> On 08/09/2007, Michael Schwendt wrote: > On Sat, 8 Sep 2007 13:17:29 +0100, Jonathan Underwood wrote: > > > Hi, > > > > I was just trying to update package of mine, and the main change is > > adding the following macros to the spec file: > > > > %define emacs_version %(pkg-config emacs --modversion) > > %define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) > > %define emacs_startdir %(pkg-coonfig emacs --variable sitestartdir) > > > > in order to determine those things at package build time (as discussed > > previously on fedora-packaging). However, on attempting to check the > > changes in, I get this: > > > > cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel > > Package emacs was not found in the pkg-config search path. > > Perhaps you should add the directory containing `emacs.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'emacs' found > > error: line 31: Version required: Requires: emacs >= > > error: query of specfile emacs-vm.spec failed, can't parse > > (!) > > > Package emacs was not found in the pkg-config search path. > > Perhaps you should add the directory containing `emacs.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'emacs' found > > error: line 31: Version required: Requires: emacs >= > > error: query of specfile emacs-vm.spec failed, can't parse > > cvs tag -c emacs-vm-- > > ? .build-8.0.3.495-1.fc8.log > > ? .build-8.0.3.495-3.fc8.log > > ? .emacs.desktop > > ? clog > > ? emacs-vm-8.0.3.495-1.fc8.src.rpm > > ? emacs-vm-8.0.3.495-3.fc8.src.rpm > > ? vm-8.0.2-devo-482.tgz > > ? vm-8.0.3-495 > > ? x86_64 > > ERROR: Tag emacs-vm-- is not in name-version-release format > > cvs tag: Pre-tag check failed > > cvs [tag aborted]: correct the above errors first! > > make: *** [tag] Error 1 > > > > > > Is it therefore not possible to call pkg-config from within a spec > > file? Could this be fixed? > > You can fix it by not creating invalid tags in your spec file. > See (!) above. Just make sure that when pkg-config returns false > and your macros are empty, you either override the macros with > defaults or you create valid "Requires" tags via %if/%else/... Yes - I realize - but I think the issue is the tag is invalid because pkg-config isn't seeing the .pc file for emacs on the build system, which is what I would like to fix.. Or am I missing something? [haven't had any coffee yet today]. J. From skvidal at fedoraproject.org Sat Sep 8 13:49:10 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 08 Sep 2007 09:49:10 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <1189259350.26570.3.camel@cutter> On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: > Hi All, > > A college of mine wanted to use umbrello in our Universities labs, since the > Linux install there are Fedora he asked me about umbrello for Fedora. > > Since I could NOT find it, I packaged it, see: > https://bugzilla.redhat.com/show_bug.cgi?id=283471 > > But then I got a comment to the review it was already in Fedora in kdesdk. But > then why on earth doesn't kdesdk have a Provides umbrello so that yum install > umbrello works? Or even better an umbrello sub-package? > File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes. Do it for all of the items you think is important. I think that's a fair thing to do. -sv From skvidal at fedoraproject.org Sat Sep 8 13:49:36 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 08 Sep 2007 09:49:36 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> Message-ID: <1189259376.26570.5.camel@cutter> On Sat, 2007-09-08 at 17:29 +0400, Peter Lemenkov wrote: > 2007/9/8, Hans de Goede : > > > As it currently stands umbrello is just plain unfindable to end users, as you > > know I'm not some noob. I even searched for in progress reviews of umbrello. > > Heh :) > Have you ever tried to install, say mp3-decoding plugins into > GStreamer? There are a 4 subpackages with nothing-said-about-content > names as gstreamer-plugins-bad, gstreamer-plugins-good etc. > > If I grep through "yum list" results I see nothing in this case but I > never heard that anybody wants to change this situation. > Well, the above is really a bug to file for livna - but again - ask them to add provides. -sv From j.w.r.degoede at hhs.nl Sat Sep 8 13:54:05 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 08 Sep 2007 15:54:05 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189259350.26570.3.camel@cutter> References: <46E29FC6.4090103@hhs.nl> <1189259350.26570.3.camel@cutter> Message-ID: <46E2A97D.50104@hhs.nl> seth vidal wrote: > On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: >> Hi All, >> >> A college of mine wanted to use umbrello in our Universities labs, since the >> Linux install there are Fedora he asked me about umbrello for Fedora. >> >> Since I could NOT find it, I packaged it, see: >> https://bugzilla.redhat.com/show_bug.cgi?id=283471 >> >> But then I got a comment to the review it was already in Fedora in kdesdk. But >> then why on earth doesn't kdesdk have a Provides umbrello so that yum install >> umbrello works? Or even better an umbrello sub-package? >> > > File a bug with the maintainer of kdesdk and ask them add provides for > each of the programs that it includes. > > Do it for all of the items you think is important. I think that's a fair > thing to do. > I forgot to say in my mail I already did that, see: https://bugzilla.redhat.com/show_bug.cgi?id=283521 But that still doesn't solve the version interlocking of completely unrelated packages. Regards, Hans From skvidal at fedoraproject.org Sat Sep 8 13:57:41 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 08 Sep 2007 09:57:41 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E2A97D.50104@hhs.nl> References: <46E29FC6.4090103@hhs.nl> <1189259350.26570.3.camel@cutter> <46E2A97D.50104@hhs.nl> Message-ID: <1189259861.26570.7.camel@cutter> On Sat, 2007-09-08 at 15:54 +0200, Hans de Goede wrote: > seth vidal wrote: > > On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: > >> Hi All, > >> > >> A college of mine wanted to use umbrello in our Universities labs, since the > >> Linux install there are Fedora he asked me about umbrello for Fedora. > >> > >> Since I could NOT find it, I packaged it, see: > >> https://bugzilla.redhat.com/show_bug.cgi?id=283471 > >> > >> But then I got a comment to the review it was already in Fedora in kdesdk. But > >> then why on earth doesn't kdesdk have a Provides umbrello so that yum install > >> umbrello works? Or even better an umbrello sub-package? > >> > > > > File a bug with the maintainer of kdesdk and ask them add provides for > > each of the programs that it includes. > > > > Do it for all of the items you think is important. I think that's a fair > > thing to do. > > > > I forgot to say in my mail I already did that, see: > https://bugzilla.redhat.com/show_bug.cgi?id=283521 > > But that still doesn't solve the version interlocking of completely unrelated > packages. No, it doesn't. But since we're past freeze - adding a provide is much easier than breaking the entire package out. -sv From limb at jcomserv.net Sat Sep 8 13:35:27 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Sat, 8 Sep 2007 08:35:27 -0500 (CDT) Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E2A97D.50104@hhs.nl> References: <46E29FC6.4090103@hhs.nl> <1189259350.26570.3.camel@cutter> <46E2A97D.50104@hhs.nl> Message-ID: <4285.192.168.0.1.1189258527.squirrel@mail.jcomserv.net> > seth vidal wrote: >> On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: >>> Hi All, >>> >>> A college of mine wanted to use umbrello in our Universities labs, >>> since the >>> Linux install there are Fedora he asked me about umbrello for Fedora. >>> >>> Since I could NOT find it, I packaged it, see: >>> https://bugzilla.redhat.com/show_bug.cgi?id=283471 >>> >>> But then I got a comment to the review it was already in Fedora in >>> kdesdk. But >>> then why on earth doesn't kdesdk have a Provides umbrello so that yum >>> install >>> umbrello works? Or even better an umbrello sub-package? >>> >> >> File a bug with the maintainer of kdesdk and ask them add provides for >> each of the programs that it includes. >> >> Do it for all of the items you think is important. I think that's a fair >> thing to do. >> > > I forgot to say in my mail I already did that, see: > https://bugzilla.redhat.com/show_bug.cgi?id=283521 > > But that still doesn't solve the version interlocking of completely > unrelated > packages. I agree (though I will start the umbrello review, examining all issues but the kdesdk one, which appear to be slogging out here :) ), but if kdesdk inclused umbrello, even if it does so along with 45 grintwillion other applications etc, until they either split out umbrello or include Provides, would not the umbrello package Conflict, and isn't that a No-No? I'm all for having it sepearate, don't misunderstand, but don't our efforts depend somewhat on the actions of the kdesdk maintainer? -Jon > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lemenkov at gmail.com Sat Sep 8 14:12:20 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 8 Sep 2007 18:12:20 +0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189259376.26570.5.camel@cutter> References: <46E29FC6.4090103@hhs.nl> <1189259376.26570.5.camel@cutter> Message-ID: > > Heh :) > > Have you ever tried to install, say mp3-decoding plugins into > > GStreamer? There are a 4 subpackages with nothing-said-about-content > > names as gstreamer-plugins-bad, gstreamer-plugins-good etc. > > If I grep through "yum list" results I see nothing in this case but I > > never heard that anybody wants to change this situation. > Well, the above is really a bug to file for livna - but again - ask them > to add provides. In case of mp3 - yes. But what about flac, ogg, wavpack etc? [petro at Sulaco ~]$ sudo yum install gstreamer-plugins-ogg fedora 100% |=========================| 2.1 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 Setting up Install Process Parsing package install arguments Nothing to do [petro at Sulaco ~]$ Lets look a little closer: ==================================== [petro at Sulaco ~]$ yum info gstreamer-plugins-good gstreamer-plugins-base Available Packages Name : gstreamer-plugins-base Arch : ppc Version: 0.10.13 Release: 1.fc7 Size : 831 k Repo : updates Summary: GStreamer streaming media framework base plug-ins Description: GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plug-ins. This package contains a set of well-maintained base plug-ins. Name : gstreamer-plugins-good Arch : ppc Version: 0.10.5 Release: 6.fc7 Size : 746 k Repo : fedora Summary: GStreamer plug-ins with good code and licensing Description: GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plug-ins. GStreamer Good Plug-ins is a collection of well-supported plug-ins of good quality and under the LGPL license. [petro at Sulaco ~]$ ==================================== So many words about licensing and other evil stuff but nothing about what's inside... -- With best regards! From jonathan.underwood at gmail.com Sat Sep 8 14:25:13 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 8 Sep 2007 15:25:13 +0100 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <645d17210709080725n1abcf1c6o32528fa8001637cd@mail.gmail.com> On 08/09/2007, Michael Schwendt wrote: > You can fix it by not creating invalid tags in your spec file. > See (!) above. Just make sure that when pkg-config returns false > and your macros are empty, you either override the macros with > defaults or you create valid "Requires" tags via %if/%else/... OK, had a coffeee, and now I understand what you're saying. Thanks. From johan at x-tnd.be Sat Sep 8 14:28:20 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Sat, 08 Sep 2007 16:28:20 +0200 Subject: kickoff - alternative KDE Menu Message-ID: <46E2B184.8070106@x-tnd.be> Hi all, I've tried to package kickoof, a KDE's menu remplacement (listed on the KDE SIG wiki page). The problem is kickoff is not really a new KDE menu, but a patched kdebase/kicker. So the package will not install new files and give user possibility to switch from base menu to kickoff, but it will replace numerous kdebase existing files. Suse Linux (who develops kickoff) have it integrated directly in kdebase (so the old KDE menu is not available I guess). My question is what must I do for this package ? - I don't think direct integration into kdebase is a such good idea (since there is no stable release for kickoff), and i'm not able to patch kdebase package. - Is there a way to backup existing files, so that base menu will reappear if kickoff is uninstalled ? - Or maybe this kind of package could not be build in respect of our standards... Regards, Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From mschwendt.tmp0701.nospam at arcor.de Sat Sep 8 14:44:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 8 Sep 2007 16:44:38 +0200 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <645d17210709080646q3a797e0asfa408fbe17f08192@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> <645d17210709080646q3a797e0asfa408fbe17f08192@mail.gmail.com> Message-ID: <20070908164438.acc83e56.mschwendt.tmp0701.nospam@arcor.de> On Sat, 8 Sep 2007 14:46:31 +0100, Jonathan Underwood wrote: > > > cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel > > You can fix it by not creating invalid tags in your spec file. > Yes - I realize - but I think the issue is the tag is invalid because > pkg-config isn't seeing the .pc file for emacs on the build system, > which is what I would like to fix.. Or am I missing something? > [haven't had any coffee yet today]. Well, then you need to 1) replace your "BuildRequires: emacs" with "BuildRequires: emacs-el", since the main package does not contain a pkg-config file anymore and 2) open a ticket against "emacs" to report that /usr/share/pkg-config/emacs.pc is a wrong location, which ought to be /usr/share/pkgconfig/emacs.pc The tool is called pkg-config, the directories pkgconfig From j.w.r.degoede at hhs.nl Sat Sep 8 14:34:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 08 Sep 2007 16:34:07 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> <1189259376.26570.5.camel@cutter> Message-ID: <46E2B2DF.6010009@hhs.nl> Peter Lemenkov wrote: >>> Heh :) >>> Have you ever tried to install, say mp3-decoding plugins into >>> GStreamer? There are a 4 subpackages with nothing-said-about-content >>> names as gstreamer-plugins-bad, gstreamer-plugins-good etc. >>> If I grep through "yum list" results I see nothing in this case but I >>> never heard that anybody wants to change this situation. > >> Well, the above is really a bug to file for livna - but again - ask them >> to add provides. > > In case of mp3 - yes. But what about flac, ogg, wavpack etc? > > [petro at Sulaco ~]$ sudo yum install gstreamer-plugins-ogg > fedora 100% |=========================| 2.1 kB 00:00 > livna 100% |=========================| 2.1 kB 00:00 > updates 100% |=========================| 1.9 kB 00:00 > Setting up Install Process > Parsing package install arguments > Nothing to do > [petro at Sulaco ~]$ > > Well in case off gstreamer-plugins-ugly from that other repo it has: Provides: gstreamer-mad = %{version}-%{release} I agree, not very usefull to a casual user, but I think we all agree the current codec situation is a pain. With that said I'm all for virtual provides for gstreamer plugins to make things easier on the end user, the only problem is what do we put in those virtual provides? Regards, Hans From j.w.r.degoede at hhs.nl Sat Sep 8 14:35:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 08 Sep 2007 16:35:34 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <4285.192.168.0.1.1189258527.squirrel@mail.jcomserv.net> References: <46E29FC6.4090103@hhs.nl> <1189259350.26570.3.camel@cutter> <46E2A97D.50104@hhs.nl> <4285.192.168.0.1.1189258527.squirrel@mail.jcomserv.net> Message-ID: <46E2B336.3060503@hhs.nl> Jon Ciesla wrote: >> seth vidal wrote: >>> On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: >>>> Hi All, >>>> >>>> A college of mine wanted to use umbrello in our Universities labs, >>>> since the >>>> Linux install there are Fedora he asked me about umbrello for Fedora. >>>> >>>> Since I could NOT find it, I packaged it, see: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=283471 >>>> >>>> But then I got a comment to the review it was already in Fedora in >>>> kdesdk. But >>>> then why on earth doesn't kdesdk have a Provides umbrello so that yum >>>> install >>>> umbrello works? Or even better an umbrello sub-package? >>>> >>> File a bug with the maintainer of kdesdk and ask them add provides for >>> each of the programs that it includes. >>> >>> Do it for all of the items you think is important. I think that's a fair >>> thing to do. >>> >> I forgot to say in my mail I already did that, see: >> https://bugzilla.redhat.com/show_bug.cgi?id=283521 >> >> But that still doesn't solve the version interlocking of completely >> unrelated >> packages. > > I agree (though I will start the umbrello review, examining all issues but > the kdesdk one, which appear to be slogging out here :) ), but if kdesdk > inclused umbrello, even if it does so along with 45 grintwillion other > applications etc, until they either split out umbrello or include > Provides, would not the umbrello package Conflict, and isn't that a No-No? > > I'm all for having it sepearate, don't misunderstand, but don't our > efforts depend somewhat on the actions of the kdesdk maintainer? > Yes they do (depend on the kdesdk maintainer), if I had known in advance that umbrello was already packaged, I wouldn't have started it. So if you could please review one of my packages from the games SIG instead, it will take a while before this gets resolved. Regards, Hans From buildsys at fedoraproject.org Sat Sep 8 14:42:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 8 Sep 2007 10:42:06 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-09-08 Message-ID: <20070908144206.8338F152131@buildsys.fedoraproject.org> Axel Thimm AT ATrpms net: smart FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) ahabig AT umn edu: yum-cron FE6 > F8 (0:0.4-1.fc6 > 0:0.3-3.fc8) F7-updates-testing > F8 (0:0.4-1.fc7 > 0:0.3-3.fc8) devrim AT commandprompt com: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) enrico scholz AT informatik tu-chemnitz de: clamav F7-updates > F8 (0:0.91.2-2.fc7 > 0:0.91.2-1.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libextractor FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-1.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) gauret AT free fr: glest-data F7-updates > F8 (0:2.0.1-1.fc7 > 0:2.0.0-5.fc8) gilboad AT gmail com: icewm FE6 > F8 (0:1.2.32-3.fc6 > 0:1.2.30-13.fc7) F7-updates-testing > F8 (0:1.2.32-3.fc7 > 0:1.2.30-13.fc7) jdennis AT redhat com: setroubleshoot F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) lemenkov AT gmail com: sipp FE6 > F7-updates (0:2.0.1-4.fc6 > 0:2.0.1-2.fc7) stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mdehaan AT redhat com: koan FE6 > F8 (0:0.6.1-2.fc6 > 0:0.6.1-1.fc8) F7-updates > F8 (0:0.6.1-2.fc7 > 0:0.6.1-1.fc8) mfleming+rpm AT enlartenment com: mod_geoip FE6 > F7 (0:1.2.0-1.fc6 > 0:1.1.8-2.fc6) michel sylvan AT gmail com: vala F7-updates-testing > F8 (0:0.1.3-3.fc7 > 0:0.1.3-2.fc8) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) pawsa AT theochem kth se: balsa FE6 > F7-updates (0:2.3.20-1.fc6 > 0:2.3.17-2.fc7) peter AT thecodergeek com: tango-icon-theme F7-updates-testing > F8 (0:0.8.1-1.fc7 > 0:0.8.0-1.fc7) rc040203 AT freenet de: perl-ExtUtils-AutoInstall FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) rdieter AT math unl edu: gnupg2 F7-updates-testing > F8 (0:2.0.6-2.fc7 > 0:2.0.6-1.fc8) kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) redhat AT linuxnetz de: mksh FE6 > F7-updates (0:31-1.fc6 > 0:30-2.fc7) roland AT redhat com: monotone FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) steve AT silug org: qtparted FE6 > F7 (0:0.4.5-15.fc6 > 0:0.4.5-14.fc7) varekova AT redhat com: gd F7-updates > F8 (0:2.0.35-1.fc7 > 0:2.0.34-3.fc8) wolfy AT nobugconsulting ro: ssmtp FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem kth se FE6 > F7-updates (0:2.3.20-1.fc6 > 0:2.3.17-2.fc7) clamav: enrico scholz AT informatik tu-chemnitz de F7-updates > F8 (0:0.91.2-2.fc7 > 0:0.91.2-1.fc8) fedora-usermgmt: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gd: varekova AT redhat com F7-updates > F8 (0:2.0.35-1.fc7 > 0:2.0.34-3.fc8) glest-data: gauret AT free fr F7-updates > F8 (0:2.0.1-1.fc7 > 0:2.0.0-5.fc8) gnupg2: rdieter AT math unl edu F7-updates-testing > F8 (0:2.0.6-2.fc7 > 0:2.0.6-1.fc8) gtranslator: foolish AT guezz net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) icewm: gilboad AT gmail com FE6 > F8 (0:1.2.32-3.fc6 > 0:1.2.30-13.fc7) F7-updates-testing > F8 (0:1.2.32-3.fc7 > 0:1.2.30-13.fc7) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter AT math unl edu FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) koan: mdehaan AT redhat com FE6 > F8 (0:0.6.1-2.fc6 > 0:0.6.1-1.fc8) F7-updates > F8 (0:0.6.1-2.fc7 > 0:0.6.1-1.fc8) libextractor: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) mksh: redhat AT linuxnetz de FE6 > F7-updates (0:31-1.fc6 > 0:30-2.fc7) mod_geoip: mfleming+rpm AT enlartenment com FE6 > F7 (0:1.2.0-1.fc6 > 0:1.1.8-2.fc6) monotone: roland AT redhat com FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-ExtUtils-AutoInstall: rc040203 AT freenet de FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) perl-Net-Libdnet: foolish AT guezz net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) postgresql-pgpool-II: devrim AT commandprompt com FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) qtparted: steve AT silug org FE6 > F7 (0:0.4.5-15.fc6 > 0:0.4.5-14.fc7) setroubleshoot: jdennis AT redhat com F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) sipp: lemenkov AT gmail com FE6 > F7-updates (0:2.0.1-4.fc6 > 0:2.0.1-2.fc7) smart: Axel Thimm AT ATrpms net FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) ssmtp: wolfy AT nobugconsulting ro FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) stratagus: lemenkov AT gmail com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tango-icon-theme: peter AT thecodergeek com F7-updates-testing > F8 (0:0.8.1-1.fc7 > 0:0.8.0-1.fc7) tcptraceroute: foolish AT guezz net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-1.fc6 > 0:0.30.212-3.fc7) vala: michel sylvan AT gmail com F7-updates-testing > F8 (0:0.1.3-3.fc7 > 0:0.1.3-2.fc8) xmlrpc-c: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7) yum-cron: ahabig AT umn edu FE6 > F8 (0:0.4-1.fc6 > 0:0.3-3.fc8) F7-updates-testing > F8 (0:0.4-1.fc7 > 0:0.3-3.fc8) From jonathan.underwood at gmail.com Sat Sep 8 14:46:09 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 8 Sep 2007 15:46:09 +0100 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <20070908164438.acc83e56.mschwendt.tmp0701.nospam@arcor.de> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> <645d17210709080646q3a797e0asfa408fbe17f08192@mail.gmail.com> <20070908164438.acc83e56.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <645d17210709080746g4c496b87k44255e7b230bc4fa@mail.gmail.com> On 08/09/2007, Michael Schwendt wrote: > On Sat, 8 Sep 2007 14:46:31 +0100, Jonathan Underwood wrote: > > > > > cvs diff: [12:11:28] obtained lock in /cvs/extras/rpms/emacs-vm/devel > > > > You can fix it by not creating invalid tags in your spec file. > > > Yes - I realize - but I think the issue is the tag is invalid because > > pkg-config isn't seeing the .pc file for emacs on the build system, > > which is what I would like to fix.. Or am I missing something? > > [haven't had any coffee yet today]. > > Well, then you need to > > 1) replace your "BuildRequires: emacs" with "BuildRequires: > emacs-el", since the main package does not contain a pkg-config > file anymore > > and > > 2) open a ticket against "emacs" to report that > /usr/share/pkg-config/emacs.pc > is a wrong location, which ought to be > /usr/share/pkgconfig/emacs.pc > > The tool is called pkg-config, the directories pkgconfig Aha. Yes - that's my fault too, as I provided Chip with the patch to build the pkg-config file. I suck. Will get it fixed. Thanks for noticing that Michael. J. From mschwendt.tmp0701.nospam at arcor.de Sat Sep 8 15:08:00 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 8 Sep 2007 17:08:00 +0200 Subject: Package EVR problems in Fedora 2007-09-08 In-Reply-To: <20070908144206.8338F152131@buildsys.fedoraproject.org> References: <20070908144206.8338F152131@buildsys.fedoraproject.org> Message-ID: <20070908170800.7f536e31.mschwendt.tmp0701.nospam@arcor.de> On Sat, 8 Sep 2007 10:42:06 -0400 (EDT), buildsys wrote: > rdieter AT math unl edu: > kdeartwork-extras > FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) > > kdegraphics-extras > FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) > > kdemultimedia-extras > FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) These look like false positives, because as I understand it, the script checks SRPMS, and the old -extras src.rpms are obsolete and the -extras binary packages are built from different SRPMS. From walters at redhat.com Sat Sep 8 16:09:14 2007 From: walters at redhat.com (Colin Walters) Date: Sat, 8 Sep 2007 12:09:14 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: On 9/8/07, Hans de Goede wrote: > > > But then I got a comment to the review it was already in Fedora in kdesdk. > But > then why on earth doesn't kdesdk have a Provides umbrello so that yum > install > umbrello works? Or even better an umbrello sub-package? Better search would solve this problem, too: http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html (I'm not sure there's a hard line for when you basically have to give up on categorization/naming standards and just rely on search, but I think the Fedora package collection is past it) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafalzaq at gmail.com Sat Sep 8 16:11:47 2007 From: rafalzaq at gmail.com (=?UTF-8?Q?Rafa=C5=82_Psota?=) Date: Sat, 8 Sep 2007 18:11:47 +0200 Subject: glob2 license change Message-ID: <5610e0590709080911u4f4b7b82hcb301f5a4ff5d158@mail.gmail.com> >From version 0.9.1 glob2 has changed its license from GPLv2+ to GPLv3+. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sylvan at gmail.com Sat Sep 8 16:18:58 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 8 Sep 2007 12:18:58 -0400 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <20070811201919.GA1205@hurricane.linuxnetz.de> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> <1186664323.5583.28.camel@localhost.localdomain> <20070811201919.GA1205@hurricane.linuxnetz.de> Message-ID: On 11/08/2007, Robert Scheck wrote: > Evening folks, > > On Thu, 09 Aug 2007, Tom spot Callaway wrote: > > On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > > > I want to announce a change I made in the new db4, that may affect > > > > you from the packaging POV if your package is dependent on db4. It is > > > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > > > to reduce dependency bloat (#220484). > > > > > > I can understand the splitting of the runtime bits, but why split the > > > *-devel package? > > > > +1. Splitting the -devel package is a rather significant alteration, for > > little benefit (and shouldn't increase dependency bloat). > > thousands of -devel packages is in my not so humble opinion what the > reporter of bug #220484 would like to see. And I don't believe, there's any > real benefit of doing so, so please avoid it. We're living in the 3rd year- > thousand and I don't want to calculate what 5 MB of disk space could cost. Thirded. Consider that good ol' Slackware does not even split development files out of their main packages! -- Michel From limb at jcomserv.net Sat Sep 8 16:03:20 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Sat, 8 Sep 2007 11:03:20 -0500 (CDT) Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> Message-ID: <4533.192.168.0.1.1189267400.squirrel@mail.jcomserv.net> > On 9/8/07, Hans de Goede wrote: >> >> >> But then I got a comment to the review it was already in Fedora in >> kdesdk. >> But >> then why on earth doesn't kdesdk have a Provides umbrello so that yum >> install >> umbrello works? Or even better an umbrello sub-package? > > > Better search would solve this problem, too: > > http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html > > (I'm not sure there's a hard line for when you basically have to give up > on > categorization/naming standards and just rely on search, but I think the > Fedora package collection is past it) I must have missed it in May. +1 WouldBeAwesomeUnlessTheresAYumPluginThatWeAlreadyHaveThatWouldDoThis In which case we build a web front end and Bob's your uncle. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From ville.skytta at iki.fi Sat Sep 8 17:20:01 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 8 Sep 2007 20:20:01 +0300 Subject: Package EVR problems in Fedora 2007-09-08 In-Reply-To: <20070908170800.7f536e31.mschwendt.tmp0701.nospam@arcor.de> References: <20070908144206.8338F152131@buildsys.fedoraproject.org> <20070908170800.7f536e31.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200709082020.02438.ville.skytta@iki.fi> On Saturday 08 September 2007, Michael Schwendt wrote: > On Sat, 8 Sep 2007 10:42:06 -0400 (EDT), buildsys wrote: > > rdieter AT math unl edu: > > > > kdeartwork-extras > > FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) > > > > kdegraphics-extras > > FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) > > > > kdemultimedia-extras > > FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) > > These look like false positives, because as I understand it, the script > checks SRPMS, and the old -extras src.rpms are obsolete and the -extras > binary packages are built from different SRPMS. You're right, the script operates on SRPMs. But these are not strictly speaking false positives - there *is* a newer SRPM by those names in FE6 than in F7. OTOH, there's probably nothing that the maintainer can do about this as the F7 SRPMs are in the release (not updates) tree, so I'll whitelist them in the scripts. From smooge at gmail.com Sat Sep 8 17:36:17 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 8 Sep 2007 11:36:17 -0600 Subject: xorg-7.3 plans? In-Reply-To: References: <1189099991.24181.3745.camel@localhost.localdomain> Message-ID: <80d7e4090709081036q6c053fc2ibba11e5a8fdf7f06@mail.gmail.com> On 9/8/07, Leo wrote: > On 2007-09-06 18:33 +0100, Adam Jackson wrote: > > On Thu, 2007-09-06 at 11:17 -0400, Neal Becker wrote: > >> xorg-7.3 is released, with support for hot-plugging. What is the roadmap > >> for fedora? Will this be a post-f8 update? > > > > Since we're well past feature freeze for F8, this will not land until > > F9's rawhide cycle. We've included many of the other components, but > > the X server itself will remain at 1.3 for F8. > > > > - ajax > > How about an update for F7? > I think that if F8 is not going to get updated.. then F7 is out of the question to. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From ville.skytta at iki.fi Sat Sep 8 17:55:03 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 8 Sep 2007 20:55:03 +0300 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070811201919.GA1205@hurricane.linuxnetz.de> Message-ID: <200709082055.04151.ville.skytta@iki.fi> On Saturday 08 September 2007, Michel Salim wrote: > On 11/08/2007, Robert Scheck wrote: > > > thousands of -devel packages is in my not so humble opinion what the > > reporter of bug #220484 would like to see. And I don't believe, there's > > any real benefit of doing so, so please avoid it. We're living in the 3rd > > year- thousand and I don't want to calculate what 5 MB of disk space > > could cost. > > Thirded. Consider that good ol' Slackware does not even split > development files out of their main packages! 5MB is actually pretty much if you consider setups on space constrained media such as live CDs, small flash disks etc. There have been other related lengthy discussions about things such as trimming package changelogs which would result in the same order of magnitude space savings when installed, so there are people who do care about numbers like that. From debarshi.ray at gmail.com Sat Sep 8 18:20:29 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 8 Sep 2007 23:50:29 +0530 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <3170f42f0709081120q5ce24ccco7c7d83fe22cd21c2@mail.gmail.com> > A college of mine wanted to use umbrello in our Universities labs, since the > Linux install there are Fedora he asked me about umbrello for Fedora. Just in case you are looking for a Qt based UML tool, you can also try out BOUML ('bouml' in Fedora). Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From laurent.rineau__fedora at normalesup.org Sat Sep 8 18:35:02 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Sat, 8 Sep 2007 20:35:02 +0200 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <645d17210709080725n1abcf1c6o32528fa8001637cd@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> <20070908144930.f6972be4.mschwendt.tmp0701.nospam@arcor.de> <645d17210709080725n1abcf1c6o32528fa8001637cd@mail.gmail.com> Message-ID: <200709082035.02182@rineau.tsetse> On Saturday 08 September 2007 16:25:13 Jonathan Underwood wrote: > On 08/09/2007, Michael Schwendt wrote: > > You can fix it by not creating invalid tags in your spec file. > > See (!) above. Just make sure that when pkg-config returns false > > and your macros are empty, you either override the macros with > > defaults or you create valid "Requires" tags via %if/%else/... > > OK, had a coffeee, and now I understand what you're saying. Thanks. Maybe a failed build task is better than a successfull build task that produces packages with wrong requirements. If something goes wrong, IMO the better is to let the build task fail. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From lightsolphoenix at gmail.com Sat Sep 8 20:45:53 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 8 Sep 2007 16:45:53 -0400 Subject: kickoff - alternative KDE Menu In-Reply-To: <46E2B184.8070106@x-tnd.be> References: <46E2B184.8070106@x-tnd.be> Message-ID: <200709081645.54541.lightsolphoenix@gmail.com> On Saturday, September 8, 2007 10:28:20 am Johan Cwiklinski wrote: > Hi all, > > I've tried to package kickoof, a KDE's menu remplacement (listed on the > KDE SIG wiki page). > > The problem is kickoff is not really a new KDE menu, but a patched > kdebase/kicker. > So the package will not install new files and give user possibility to > switch from base menu to kickoff, but it will replace numerous kdebase > existing files. > > Suse Linux (who develops kickoff) have it integrated directly in kdebase > (so the old KDE menu is not available I guess). > > My question is what must I do for this package ? > > - I don't think direct integration into kdebase is a such good idea > (since there is no stable release for kickoff), and i'm not able to > patch kdebase package. > - Is there a way to backup existing files, so that base menu will > reappear if kickoff is uninstalled ? > - Or maybe this kind of package could not be build in respect of our > standards... > > Regards, > Johan You won't be able to get Kickoff to work properly in Fedora; it's been tried, and tried, and tried. Kickoff has dependencies on other packages that are in openSUSE but not Fedora... But if you still want to try, then I believe the right answer is to put Provides: kdebase in the package. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From myfedora at richip.dhs.org Sat Sep 8 21:01:57 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Sep 2007 15:01:57 -0600 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <1189285317.8036.9.camel@localhost6.localdomain6> On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote: > Also I think it is a very bad idea to ship packages with a clearly seperate > upstream in some kinda bundle form. Sticking with the umbrello example, in > order for the latest version to be included into Fedora, we must wait for a new > upstream kdesdk release, which likely won't happen before there is a kdesdk4 in > some far away future, as kde3 is as good as EOL. Read the thread I started entitled "Goal: Increased Modularity". People are saying that Fedora is aimed at distro-makers who want to create spins of their own from Fedora. This is only possible if it actually CAN be broken down into the pieces that you want. Currently, there are no policies which even mention modularity, but most of the developers have come to the same conclusion. There's a faction which believe that it's easier to maintain something when they're all lumped together. Then there are those who believe it's easier for individual volunteers to maintain packages if they're cut down to smaller pieces. It's clear where my opinions lie. -- Richi Plana From myfedora at richip.dhs.org Sat Sep 8 21:04:56 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Sep 2007 15:04:56 -0600 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <3170f42f0709081120q5ce24ccco7c7d83fe22cd21c2@mail.gmail.com> References: <46E29FC6.4090103@hhs.nl> <3170f42f0709081120q5ce24ccco7c7d83fe22cd21c2@mail.gmail.com> Message-ID: <1189285496.8036.12.camel@localhost6.localdomain6> On Sat, 2007-09-08 at 23:50 +0530, Debarshi 'Rishi' Ray wrote: > > A college of mine wanted to use umbrello in our Universities labs, since the > > Linux install there are Fedora he asked me about umbrello for Fedora. > > Just in case you are looking for a Qt based UML tool, you can also try > out BOUML ('bouml' in Fedora). Know a good Gnome- or even just Gtk2-based UML tool (that's actually useful for programming)? -- Richi Plana From jeff at ocjtech.us Sat Sep 8 21:10:35 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 08 Sep 2007 16:10:35 -0500 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E2B2DF.6010009@hhs.nl> References: <46E29FC6.4090103@hhs.nl> <1189259376.26570.5.camel@cutter> <46E2B2DF.6010009@hhs.nl> Message-ID: <1189285835.3315.12.camel@lt21223.campus.dmacc.edu> On Sat, 2007-09-08 at 16:34 +0200, Hans de Goede wrote: > > Well in case off gstreamer-plugins-ugly from that other repo it has: > Provides: gstreamer-mad = %{version}-%{release} > > I agree, not very usefull to a casual user, but I think we all agree the > current codec situation is a pain. With that said I'm all for virtual provides > for gstreamer plugins to make things easier on the end user, the only problem > is what do we put in those virtual provides? For gstreamer, what about "gstreamer-plugin() = -"? For example: gstreamer-plugin(oggmux) = 0.10.13-1.fc7 gstreamer-plugin(vorbisenc) = 0.10.13-1.fc7 gstreamer-pligin(vorbisdec) = 0.10.13-1.fc7 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 myfedora at richip.dhs.org Sat Sep 8 21:09:38 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Sep 2007 15:09:38 -0600 Subject: xorg-7.3 plans? In-Reply-To: References: <1189099991.24181.3745.camel@localhost.localdomain> Message-ID: <1189285778.8036.15.camel@localhost6.localdomain6> On Sat, 2007-09-08 at 10:17 +0100, Leo wrote: > On 2007-09-06 18:33 +0100, Adam Jackson wrote: > > On Thu, 2007-09-06 at 11:17 -0400, Neal Becker wrote: > >> xorg-7.3 is released, with support for hot-plugging. What is the roadmap > >> for fedora? Will this be a post-f8 update? > > > > Since we're well past feature freeze for F8, this will not land until > > F9's rawhide cycle. We've included many of the other components, but > > the X server itself will remain at 1.3 for F8. > > > > - ajax > > How about an update for F7? Unlikely, unless F8 gets it and it would then be easier to maintain just one version. That said, if anyone compiles and distributes packages of xorg-7.3 or F[78], please post where it can be downloaded from. -- Richi Plana From jspaleta at gmail.com Sat Sep 8 21:28:42 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 8 Sep 2007 13:28:42 -0800 Subject: FYI: License change for gpodder to GPLv3 Message-ID: <604aa7910709081428m1516a994t627eab34ff1ea0f8@mail.gmail.com> I'm pretty sure this is a non-event since nothing depends on gpodder. I've talked with the upstream concerning the change and we both taken a look at the packages that gpodder depends on in Fedora. There are no potential complications that we can see. The license change is live in the upstream codebase meaning the gpodder 0.9.5 release now in fedora development is the last release under the GPLv2 license. -jef From martin.sourada at seznam.cz Sat Sep 8 21:28:56 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 08 Sep 2007 23:28:56 +0200 Subject: Making the xine-lib-extras nondependent on xine-lib-arts? Message-ID: <1189286936.3143.20.camel@pc-notebook> Hi, I noticed one thing that cheered me up a bit - splitting of xine-lib-arts from xine-lib-extras. Well, but the problem is that xine-lib-extras, which has a set of useful plugins like support for pulseaudio, is dependent on xine-lib-arts. And xine-lib-arts pushes arts which in turn pushes qt. If I'd like to use xine-lib as an engine for various gtk based players (totem-xine or gxine to name a few), with the plugins in xine-lib-extras and don't want to push the qt dependency, it is currently a no-go. Is there a chance of separating the arts plugin completely? Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Sat Sep 8 21:50:54 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 08 Sep 2007 17:50:54 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> Message-ID: <1189288254.26570.12.camel@cutter> On Sat, 2007-09-08 at 12:09 -0400, Colin Walters wrote: > On 9/8/07, Hans de Goede wrote: > > But then I got a comment to the review it was already in > Fedora in kdesdk. But > then why on earth doesn't kdesdk have a Provides umbrello so > that yum install > umbrello works? Or even better an umbrello sub-package? > > Better search would solve this problem, too: > > http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html > > (I'm not sure there's a hard line for when you basically have to give > up on categorization/naming standards and just rely on search, but I > think the Fedora package collection is past it) You don't want 'yum search' to always search every file in the distribution. Searching every file will just take a long time. And, in fact, you will routinely find that what you're searching for in the package is never explicitly listed in any of the file lists. so that leaves us two options: - we include some sort of keyword tag in the pkg metadata - we include some sort of keyword metadata file in the repodata Doing either of those and having yum search them if they are available is do-able. We talked about this before, iirc. We just need to decide which one is more palatable and do it. -sv From ville.skytta at iki.fi Sat Sep 8 21:59:48 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 9 Sep 2007 00:59:48 +0300 Subject: Making the xine-lib-extras nondependent on xine-lib-arts? In-Reply-To: <1189286936.3143.20.camel@pc-notebook> References: <1189286936.3143.20.camel@pc-notebook> Message-ID: <200709090059.48883.ville.skytta@iki.fi> On Sunday 09 September 2007, Martin Sourada wrote: > Hi, > > I noticed one thing that cheered me up a bit - splitting of > xine-lib-arts from xine-lib-extras. Well, but the problem is that > xine-lib-extras, which has a set of useful plugins like support for > pulseaudio, is dependent on xine-lib-arts. And xine-lib-arts pushes arts > which in turn pushes qt. If I'd like to use xine-lib as an engine for > various gtk based players (totem-xine or gxine to name a few), with the > plugins in xine-lib-extras and don't want to push the qt dependency, it > is currently a no-go. Is there a chance of separating the arts plugin > completely? I happened to ask the same thing from Aurelien a few days ago - I found it surprising too. He said something about plans to possibly gradually split more stuff out of xine-lib-extras and to have -extras eventually as just a metapackage that pulls all these "extra" things in. I have no problem with that, but nor do I have any problem with removing the dependency either. Aurelien? From limb at jcomserv.net Sat Sep 8 22:58:24 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Sat, 8 Sep 2007 17:58:24 -0500 (CDT) Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189288254.26570.12.camel@cutter> References: <46E29FC6.4090103@hhs.nl> <1189288254.26570.12.camel@cutter> Message-ID: <1343.192.168.0.1.1189292304.squirrel@mail.jcomserv.net> > > On Sat, 2007-09-08 at 12:09 -0400, Colin Walters wrote: >> On 9/8/07, Hans de Goede wrote: >> >> But then I got a comment to the review it was already in >> Fedora in kdesdk. But >> then why on earth doesn't kdesdk have a Provides umbrello so >> that yum install >> umbrello works? Or even better an umbrello sub-package? >> >> Better search would solve this problem, too: >> >> http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html >> >> (I'm not sure there's a hard line for when you basically have to give >> up on categorization/naming standards and just rely on search, but I >> think the Fedora package collection is past it) > > > You don't want 'yum search' to always search every file in the > distribution. Searching every file will just take a long time. And, in > fact, you will routinely find that what you're searching for in the > package is never explicitly listed in any of the file lists. > > > so that leaves us two options: > - we include some sort of keyword tag in the pkg metadata > - we include some sort of keyword metadata file in the repodata > > Doing either of those and having yum search them if they are available > is do-able. We talked about this before, iirc. We just need to decide > which one is more palatable and do it. Or, utilize pkgdb for this task. Maybe capture the data at build time with some sort of hook in koji? A tiny delay in each build, while the equivalent of an rpm -qa foo is dumped into pkgdg. This could then make not only searching but finding conflicts a snap. You would even build in a form where you could paste the rpm -qa foo of a new package during the review step and it would check the pkgdb so you know with absolute certainty that the new package does not conflict with something existing, or if it does, you know where. > -sv > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From chris.stone at gmail.com Sun Sep 9 00:54:39 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 8 Sep 2007 17:54:39 -0700 Subject: Koji is not building Message-ID: http://koji.fedoraproject.org/koji/tasks I tried killing the job and starting a new one. Didn't help. From robert at fedoraproject.org Sun Sep 9 02:06:40 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Sun, 9 Sep 2007 04:06:40 +0200 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <200709082055.04151.ville.skytta@iki.fi> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070811201919.GA1205@hurricane.linuxnetz.de> <200709082055.04151.ville.skytta@iki.fi> Message-ID: <20070909020640.GA12305@hurricane.linuxnetz.de> On Sat, 08 Sep 2007, Ville Skytt? wrote: > On Saturday 08 September 2007, Michel Salim wrote: > > On 11/08/2007, Robert Scheck wrote: > > > > > thousands of -devel packages is in my not so humble opinion what the > > > reporter of bug #220484 would like to see. And I don't believe, there's > > > any real benefit of doing so, so please avoid it. We're living in the 3rd > > > year- thousand and I don't want to calculate what 5 MB of disk space > > > could cost. > > > > Thirded. Consider that good ol' Slackware does not even split > > development files out of their main packages! > > 5MB is actually pretty much if you consider setups on space constrained media > such as live CDs, small flash disks etc. There have been other related > lengthy discussions about things such as trimming package changelogs which > would result in the same order of magnitude space savings when installed, so > there are people who do care about numbers like that. Ehem. I talked about 5 MB for splitting the -devel package itself. Since when are db4-devel packages installed on live CDs, small flash disks etc.? And no, it's not the same. So please don't bring my argumentation out of context! Ville, I agree with you 5 MB are much for tiny mediums or embedded devices, but this is not related to -devel packages itself. Thanks, Robert From sandeen at redhat.com Sun Sep 9 03:01:15 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 08 Sep 2007 22:01:15 -0500 Subject: gnome-control-center not in gnome menus? Message-ID: <46E361FB.9050204@redhat.com> Was playing with a F8test2-ish install, looking to set up sound, network, etc - in my personal opinion, the various things scattered around different menu items seem confusing to me. Firing up gnome-control-center puts them all in one place that seems more intuitive to me, but that's not in any menu item I can find... is there a reason for this? Thanks, -Eric From mclasen at redhat.com Sun Sep 9 03:14:25 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 08 Sep 2007 23:14:25 -0400 Subject: gnome-control-center not in gnome menus? In-Reply-To: <46E361FB.9050204@redhat.com> References: <46E361FB.9050204@redhat.com> Message-ID: <1189307665.18042.9.camel@localhost.localdomain> On Sat, 2007-09-08 at 22:01 -0500, Eric Sandeen wrote: > Was playing with a F8test2-ish install, looking to set up sound, > network, etc - in my personal opinion, the various things scattered > around different menu items seem confusing to me. Firing up > gnome-control-center puts them all in one place that seems more > intuitive to me, but that's not in any menu item I can find... is there > a reason for this? The Gnome control center has been through more than one cycle going from shell to individual capplets and back... We looked at the latest incarnation of the shell when it was introduced during the Gnome 2.18 devel cycle, and found that it is not really ready for prime time. There are numerous small interface issues, e.g. the confusion between focus and prelight. After we hid it from the Fedora menus, the upstream Gnome agreed and went back to the individual capplets in the menu for 2.18. Unfortunately, the shell has not seen much (or any) attention during the 2.20 cycle. Anyway, we do install the shell, so can just put it in your menus if you like it. From loganjerry at gmail.com Sun Sep 9 03:30:02 2007 From: loganjerry at gmail.com (Jerry James) Date: Sat, 8 Sep 2007 21:30:02 -0600 Subject: aot-compile-rpm suggestion In-Reply-To: <20070907154652.GA11580@redhat.com> References: <870180fe0709062045k75ccea6evd952ef061c0346cd@mail.gmail.com> <20070907154652.GA11580@redhat.com> Message-ID: <870180fe0709082030y537084dey2273bd2c14b936e3@mail.gmail.com> On 9/7/07, Andrew Overholt wrote: > Please file this as a bug so it can be tracked. https://bugzilla.redhat.com/show_bug.cgi?id=283831 Thanks, -- Jerry James http://loganjerry.googlepages.com/ From mmcgrath at redhat.com Sun Sep 9 03:38:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 08 Sep 2007 22:38:34 -0500 Subject: Koji is not building In-Reply-To: References: Message-ID: <46E36ABA.2010807@redhat.com> Christopher Stone wrote: > http://koji.fedoraproject.org/koji/tasks > > I tried killing the job and starting a new one. Didn't help. > BTW all, we discussed this on IRC. The build is hanging on a flock in rawhide, it's reproducible in mock locally though we haven't determined why yet. I'm going to take a closer look tomorrow when I have some more time but here's a strace for the interested: http://mmcgrath.fedorapeople.org/php-pear-PHPUnit-3.1.8-1.fc8.strace.log -Mike From chris.stone at gmail.com Sun Sep 9 03:47:26 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 8 Sep 2007 20:47:26 -0700 Subject: Koji is not building In-Reply-To: <46E36ABA.2010807@redhat.com> References: <46E36ABA.2010807@redhat.com> Message-ID: On 9/8/07, Mike McGrath wrote: > Christopher Stone wrote: > > http://koji.fedoraproject.org/koji/tasks > > > > I tried killing the job and starting a new one. Didn't help. > > > > BTW all, we discussed this on IRC. The build is hanging on a flock in > rawhide, it's reproducible in mock locally though we haven't determined > why yet. I'm going to take a closer look tomorrow when I have some more > time but here's a strace for the interested: > > http://mmcgrath.fedorapeople.org/php-pear-PHPUnit-3.1.8-1.fc8.strace.log Thanks for looking into this Mike. FYI, I am out of town tomorrow, will be back Monday. From myfedora at richip.dhs.org Sun Sep 9 04:57:40 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Sep 2007 22:57:40 -0600 Subject: gnome-control-center not in gnome menus? In-Reply-To: <1189307665.18042.9.camel@localhost.localdomain> References: <46E361FB.9050204@redhat.com> <1189307665.18042.9.camel@localhost.localdomain> Message-ID: <1189313860.1067.1.camel@localhost6.localdomain6> On Sat, 2007-09-08 at 23:14 -0400, Matthias Clasen wrote: > We looked at the latest incarnation of the shell when it was introduced > during the Gnome 2.18 devel cycle, and found that it is not really ready > for prime time. There are numerous small interface issues, e.g. the > confusion between focus and prelight. Do you have the list of gnome bugzilla numbers that are tracking shell-related issues? -- Richi Plana From myfedora at richip.dhs.org Sun Sep 9 05:01:59 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 08 Sep 2007 23:01:59 -0600 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189285835.3315.12.camel@lt21223.campus.dmacc.edu> References: <46E29FC6.4090103@hhs.nl> <1189259376.26570.5.camel@cutter> <46E2B2DF.6010009@hhs.nl> <1189285835.3315.12.camel@lt21223.campus.dmacc.edu> Message-ID: <1189314119.1067.4.camel@localhost6.localdomain6> On Sat, 2007-09-08 at 16:10 -0500, Jeffrey C. Ollie wrote: > For gstreamer, what about "gstreamer-plugin() = > -"? For example: > > gstreamer-plugin(oggmux) = 0.10.13-1.fc7 > gstreamer-plugin(vorbisenc) = 0.10.13-1.fc7 > gstreamer-pligin(vorbisdec) = 0.10.13-1.fc7 Better yet, scrap filenames altogether (use numbers or whatever) and grab all the meta-info from the file itself. The age of overloading of filenames is really starting to show. Maybe the start of the next-gen filesystem (no filenames) can start here, ;). -- Richi Plana From vonbrand at inf.utfsm.cl Sun Sep 9 05:14:07 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 09 Sep 2007 01:14:07 -0400 Subject: Plan for tomorrows (20070906) FESCO meeting In-Reply-To: <80d7e4090709061046q7f749805s1404aeb000920b43@mail.gmail.com> References: <1189008703.2702.2.camel@kennedy> <1189036171.20671.1.camel@kennedy> <1189039262.3189.20.camel@tuxhugs> <20070905223210.356fef1a@ender> <1189061202.24848.662.camel@mccallum.corsepiu.local> <364d303b0709060603m5e1ec1acjf57ae6683c5e79d4@mail.gmail.com> <1189085539.24113.10.camel@kennedy> <364d303b0709060709h3210ecd9i9a5d7cb56f23b73f@mail.gmail.com> <1189088811.24113.16.camel@kennedy> <364d303b0709060753g69f1ae8fqcbe64279966fa649@mail.gmail.com> <80d7e4090709061046q7f749805s1404aeb000920b43@mail.gmail.com> Message-ID: <200709090514.l895E7ld014410@laptop13.inf.utfsm.cl> Stephen John Smoogen wrote: [...] > Yes.. at 2 weeks I would say that even if you are subscribed to a > list.. if you aren't reading it or replying to important threads.. you > aren't really a part of the list. If you have to wait until the > discussion is moved over to the one you do care about.. then that is > further argument that the other list is not important. Historically, something like a 2% of people subscribed to various newsgroups or lists posted there in any longish (1 month or so) period... if it was much different here, the list would be unbearable. -- 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 vonbrand at inf.utfsm.cl Sun Sep 9 05:31:07 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 09 Sep 2007 01:31:07 -0400 Subject: kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting) In-Reply-To: References: <1189008703.2702.2.camel@kennedy> <46DEE0D0.2070209@fedoraproject.org> <46E046C6.4050908@leemhuis.info> <604aa7910709061143x51b4ae92kfd2f0c7418804351@mail.gmail.com> <46E0D9BA.7090406@leemhuis.info> <46E118D2.7050807@leemhuis.info> <1189216898.3488.150.camel@pmac.infradead.org> Message-ID: <200709090531.l895VA05015025@laptop13.inf.utfsm.cl> Jon Nettleton wrote: [...] > There are lots of examples but my specific one is the gspca driver > that I built the first dkms package for and is exists at freshrpms. > This driver supports a lot of modern webcams, but the driver developer > has no intention of even trying to have this code merged into the > kernel. What are we to do in this circumstance? Get somebody else to push the code upstream? > I think we need something better than the "safe" ostrich syndrome; if > it is out of the kernel it scares us and we run away from it. There > is plenty of legitimate driver development being done outside of the > kernel. It just seems a bad decision to completely bury our heads in > the sand to this code-base. I /do/ agree that the "got into the vanilla kernel" is an important cuality sign... -- 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 ville.skytta at iki.fi Sun Sep 9 07:46:43 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 9 Sep 2007 10:46:43 +0300 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <20070909020640.GA12305@hurricane.linuxnetz.de> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <200709082055.04151.ville.skytta@iki.fi> <20070909020640.GA12305@hurricane.linuxnetz.de> Message-ID: <200709091046.43665.ville.skytta@iki.fi> On Sunday 09 September 2007, Robert Scheck wrote: > On Sat, 08 Sep 2007, Ville Skytt? wrote: > > On Saturday 08 September 2007, Michel Salim wrote: > > > On 11/08/2007, Robert Scheck wrote: > > > > thousands of -devel packages is in my not so humble opinion what the > > > > reporter of bug #220484 would like to see. And I don't believe, > > > > there's any real benefit of doing so, so please avoid it. We're > > > > living in the 3rd year- thousand and I don't want to calculate what 5 > > > > MB of disk space could cost. > > > > > > Thirded. Consider that good ol' Slackware does not even split > > > development files out of their main packages! > > > > 5MB is actually pretty much if you consider setups on space constrained > > media such as live CDs, small flash disks etc. There have been other > > related lengthy discussions about things such as trimming package > > changelogs which would result in the same order of magnitude space > > savings when installed, so there are people who do care about numbers > > like that. > > Ehem. I talked about 5 MB for splitting the -devel package itself. Since > when are db4-devel packages installed on live CDs, small flash disks etc.? > And no, it's not the same. So please don't bring my argumentation out of > context! That wasn't my intention, sorry if I offended you. Your later (than your mailing list post) comment in #220484 seems very much opposed to the whole split and doesn't mention devel packages at all. Michel's reply above (which as the quote indicators show, is primarily what I replied to) seems to me to be using Slackware as a proof-of-concept argument that not caring about size overhead of development files in packages in general works just fine. And I don't actually see a db4-cxx-devel in the packages tree nor in the db4.spec CVS history. > Ville, I agree with you 5 MB are much for tiny mediums or embedded > devices, but this is not related to -devel packages itself. And I agree that splitting foo-devel into foo-bar-devel and foo-quux-devel is not usually that interesting if space considerations are the only thing driving it. From buildsys at redhat.com Sun Sep 9 09:02:21 2007 From: buildsys at redhat.com (Build System) Date: Sun, 9 Sep 2007 05:02:21 -0400 Subject: rawhide report: 20070909 changes Message-ID: <200709090902.l8992L1c007907@porkchop.devel.redhat.com> Updated Packages: VLGothic-fonts-20070901-1.fc8 ----------------------------- * Sun Sep 09 2007 Ryo Dairiki - 20070901-1 - Update to 20070901 anjuta-1:2.2.0-3.fc8 -------------------- * Wed Aug 29 2007 Fedora Release Engineering - 1:2.2.0-3 - Rebuild for selinux ppc32 issue. audio-convert-mod-3.45.2-2.fc8 ------------------------------ * Sat Sep 08 2007 Stewart Adam 3.45.2-2 - Fix traceback upon calling --help blam-1.8.3-8.fc8 ---------------- * Sat Sep 08 2007 Peter Gordon - 1.8.3-8 - Add mono-web runtime dependency; fixes bugs 282331 (Blam does not open links with commas correctly) and 277561 (Blam does nothing useful). cacti-0.8.6j-6.fc8 ------------------ * Sat Sep 08 2007 Mike McGrath - 0.8.6j-6 - rebuild cksfv-1.3.12-1.fc8 ------------------ * Sat Sep 08 2007 Christopher Stone 1.3.12-1 - Upstream sync glest-data-2.0.1-1.fc8 ---------------------- * Sun Sep 02 2007 Aurelien Bompard 2.0.1-1 - version 2.0.1 icewm-1.2.32-4.fc8 ------------------ * Sun Sep 02 2007 - 1.2.32-4 - Fix mangled if/else. (Again...) * Sat Sep 01 2007 - 1.2.32-3 - Fix missing BR: libXinerama-devel. - Fix broken source file. * Mon Aug 27 2007 - 1.2.32-2 - Fix bad %{_fedora} if/else. libbonoboui-2.19.6-4.fc8 ------------------------ * Sat Sep 08 2007 Matthias Clasen - 2.19.6-4 - Display a dialog if help cannot be found liferea-1.2.23-1.fc8 -------------------- * Sat Sep 08 2007 Brian Pepple - 1.2.23-1 - Update to 1.2.23. mach-0.9.2-2.fc8 ---------------- * Sun Sep 09 2007 Ville Skytt?? - 0.9.2-2 - Drop no longer needed (and failing) old ppc config bug workarounds. - Sync group creation scriptlet with current Fedora packaging guidelines. - Set default config to the "updates" flavour. perl-MP3-Info-1.22-3.fc8 ------------------------ * Sat Sep 08 2007 Christopher Stone 1.22-3 - Add BuildRequires perl(Test::More) * Sat Sep 08 2007 Christopher Stone 1.22-2 - Add BuildRequires perl(ExtUtils::MakeMaker) * Sat Sep 08 2007 Christopher Stone 1.22-1 - Upstream sync - spec file cleanups php-pear-DB-DataObject-1.8.7-1.fc8 ---------------------------------- * Sat Sep 08 2007 Christopher Stone 1.8.7-1 - Upstream sync - Update license file * Sun Jan 14 2007 Christopher Stone 1.8.5-2 - Use correct version of license * Sat Dec 16 2006 Christopher Stone 1.8.5-1 - Upstream sync - Add LICENSE to %doc php-pear-File-1.3.0-1.fc8 ------------------------- php-pear-Pager-2.4.4-1.fc8 -------------------------- php-pecl-radius-1.2.5-1.fc8 --------------------------- php-pecl-xdebug-2.0.0-1.fc8 --------------------------- * Sat Sep 08 2007 Christopher Stone 2.0.0-1 - Upstream sync - Remove %{?beta} tags qgit-1.5.7-1.fc8 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 sepostgresql-8.2.4-1.0.fc8 -------------------------- * Sat Sep 01 2007 - 8.2.4-1.0 - mark as SE-PostgreSQL 8.2.4-1.0 setroubleshoot-1.10.4-1.fc8 --------------------------- * Sat Sep 08 2007 John Dennis - 1.10.4-1 - fix init script * Sat Sep 08 2007 John Dennis - 1.10.3-1 - modify avc_audit.py to use new audit_data.py implementation - can listen for audit events on either /var/run/audit_events in bindary protocol mode or /var/run/audisp_events in text protocol mode * Thu Sep 06 2007 John Dennis - 1.10.2-1 - remove all copied code from test_setroubleshootd, now we import from setroubleshoot - export ClientConnectionHandler from rpc.py as a base class. Derive SetroubleshootdClientConnectionHandler and AuditClientConnectionHandler from ClientConnectionHandler. - add audisp_listen as test program - create setroubleshoot sym link in top devel directory pointing to src so import setroubleshoot.foo if PYTHONPATH=topdir - add get_option, convert_cfg_type to config.py.in so that one can pass optional dict to override config file settings - rewrite log_init() so it's easier for other programs to use it, fix the import logic concering log & config - remove log code from test_setroubleshoot, now just does import from setroubleshoot. - test_setroubleshootd can now handle audit records in both text and binary formats, can be selected by command line arg. It can now either output to clients connecting on a socket or to stdout. Can now optionally exit after N socket client connections. - remove non audit record lines from test data - remove config_init() and log_init() from package __init__.py It was the wrong place to call them, now call them when the process initializes before the first setroubleshoot imports - add parse_config_setting() and set_config() to config module - setroubleshootd now accepts -c --config command line arg - test_sectroubleshoot: add err defines & program_error exception add is_valid() tests to assure we read a valid audit record log the unrecognized line if not valid, clean up socket close() - Relates Bug #247056, update initscript to LSB standards Note: LSB initscripts in Fedora is not yet a resolved issue, the changes implemented were to add an LSB block and support the new LSB try-restart and force-reload commands. However the new /lib/lsb/init-functions are NOT currently used as this is the unstable part. smart-0.50-48.fc8 ----------------- * Sat Sep 08 2007 Ville Skytt?? - 0.50-48 - KSmartTray desktop entry fixes. - License: GPLv2+ * Thu Aug 02 2007 Axel Thimm - 0.50-47 - Add kernel-tuxonice series support. vala-0.1.3-4.fc8 ---------------- * Sat Sep 08 2007 Michel Salim - 0.1.3-4 - Split -vapigen subpackage. It is functionally self-contained and the license is more restricted - Updated license declarations * Wed Sep 05 2007 Michel Salim - 0.1.3-3 - Licensing and URL updates yum-cron-0.4-1.fc8 ------------------ * Mon Sep 03 2007 Alec Habig - 0.4-1 - Fix bug in cron.daily which was preventing updates from running - Integrate Frank's checkonly patches into the source zeroinstall-injector-0.30-2.fc8 ------------------------------- * Sat Sep 08 2007 Michel Salim 0.30-2 - Update scriptlet that creates zeroinst user Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.i386 requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-changelog eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-subclipse eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-rpm-editor kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From opensource at till.name Sun Sep 9 12:23:18 2007 From: opensource at till.name (Till Maas) Date: Sun, 09 Sep 2007 14:23:18 +0200 Subject: How require one out of many packages? Message-ID: <200709091423.29580.opensource@till.name> Hiyas, gt5 (https://bugzilla.redhat.com/show_bug.cgi?id=276201) requires one console browser to be installed (of out of links links2 elinks lynx w3m), can this be specified in an spec file? If not, what is the best workaround here? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Sun Sep 9 12:25:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 9 Sep 2007 08:25:53 -0400 Subject: How require one out of many packages? In-Reply-To: <200709091423.29580.opensource@till.name> References: <200709091423.29580.opensource@till.name> Message-ID: <20070909082553.0203a8e8@ender> On Sun, 09 Sep 2007 14:23:18 +0200 Till Maas wrote: > Hiyas, > > gt5 (https://bugzilla.redhat.com/show_bug.cgi?id=276201) requires one > console browser to be installed (of out of links links2 elinks lynx > w3m), can this be specified in an spec file? If not, what is the best > workaround here? Probably best to get them to all provide console-browser or some such as a generic provides, that way your package could just require console-browser and yum will sort it out at install time (either something already installed, already in the transaction set, or shortest name wins). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.sylvan at gmail.com Sun Sep 9 12:39:05 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 08:39:05 -0400 Subject: kickoff - alternative KDE Menu In-Reply-To: <200709081645.54541.lightsolphoenix@gmail.com> References: <46E2B184.8070106@x-tnd.be> <200709081645.54541.lightsolphoenix@gmail.com> Message-ID: On 08/09/2007, Kelly wrote: > On Saturday, September 8, 2007 10:28:20 am Johan Cwiklinski wrote: > > Hi all, > > > > I've tried to package kickoof, a KDE's menu remplacement (listed on the > > KDE SIG wiki page). > > > > The problem is kickoff is not really a new KDE menu, but a patched > > kdebase/kicker. > > So the package will not install new files and give user possibility to > > switch from base menu to kickoff, but it will replace numerous kdebase > > existing files. > > > > Suse Linux (who develops kickoff) have it integrated directly in kdebase > > (so the old KDE menu is not available I guess). > > > > My question is what must I do for this package ? > > > > - I don't think direct integration into kdebase is a such good idea > > (since there is no stable release for kickoff), and i'm not able to > > patch kdebase package. > > - Is there a way to backup existing files, so that base menu will > > reappear if kickoff is uninstalled ? > > - Or maybe this kind of package could not be build in respect of our > > standards... > > > > Regards, > > Johan > > You won't be able to get Kickoff to work properly in Fedora; it's been tried, > and tried, and tried. Kickoff has dependencies on other packages that are in > openSUSE but not Fedora... > > But if you still want to try, then I believe the right answer is to put > Provides: kdebase in the package. > Won't that cause a race condition? If kicker's Provides: is versioned, if it's newer it will upgrade kdebase, and if it's older, the next yum update will reinstall kdebase. If it's not versioned, I'm not sure -- the first might not happen, but kdebase will probably be reinstalled if a KDE package depends on a versioned kdebase? -- Michel From opensource at till.name Sun Sep 9 12:47:15 2007 From: opensource at till.name (Till Maas) Date: Sun, 09 Sep 2007 14:47:15 +0200 Subject: How require one out of many packages? In-Reply-To: <20070909082553.0203a8e8@ender> References: <200709091423.29580.opensource@till.name> <20070909082553.0203a8e8@ender> Message-ID: <200709091447.20778.opensource@till.name> On So September 9 2007, Jesse Keating wrote: > Probably best to get them to all provide console-browser or some such > as a generic provides, that way your package could just require > console-browser and yum will sort it out at install time (either > something already installed, already in the transaction set, or > shortest name wins). Ville has started to collect these kind of provides in a list[1], maybe this can be included in the Guidelines to make sure, that this is uniform, e.g. wget provides webclient, but curl does not. But webclient is not good enough, because also firefox provides webclient. Regards, Till [1] http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From michel.sylvan at gmail.com Sun Sep 9 13:18:13 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 09:18:13 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <200709081524.38289.opensource@till.name> References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: On 08/09/2007, Till Maas wrote: > On Sa September 8 2007, Hans de Goede wrote: > > > As it currently stands umbrello is just plain unfindable to end users, as > > you know I'm not some noob. I even searched for in progress reviews of > > umbrello. > > > > Also I think it is a very bad idea to ship packages with a clearly seperate > > upstream in some kinda bundle form. Sticking with the umbrello example, in > > order for the latest version to be included into Fedora, we must wait for a > > new upstream kdesdk release, which likely won't happen before there is a > > kdesdk4 in some far away future, as kde3 is as good as EOL. > > > > Notice that umbrello and kdesdk are just an example, this goes for other > > Aggregation upstreams too. > > > > Since on of Fedora's strenghts is being always up to date with the latest > > upstream versions, I think using these kind of upstream aggregation > > projects is a BAD idea as it creates interlocks with regards to versions > > between clearly seperate projects like kdesdk and umbrello. > > I agree completely. > Ditto, though in this case, umbrello happens to *also* be part of kdesdk: http://uml.sourceforge.net/download.php The source tarballs are taken straight out of kdesdk CVS, so the Fedora packaging, while needing to be fixed, is understandable. By the way, 'yum search umbrello' won't work with just a Provides:, and so yum install probably would not either: https://bugzilla.redhat.com/show_bug.cgi?id=283611 So a stopgap fix might not work, until the package is properly split. Regards, -- Michel From loupgaroublond at gmail.com Sun Sep 9 13:31:10 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 9 Sep 2007 09:31:10 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189259861.26570.7.camel@cutter> References: <46E29FC6.4090103@hhs.nl> <1189259350.26570.3.camel@cutter> <46E2A97D.50104@hhs.nl> <1189259861.26570.7.camel@cutter> Message-ID: <7f692fec0709090631v458231fcwd60b88f2db171fbc@mail.gmail.com> Hi On 9/8/07, seth vidal wrote: > > But that still doesn't solve the version interlocking of completely unrelated > > packages. > > No, it doesn't. But since we're past freeze - adding a provide is much > easier than breaking the entire package out. > Would this make a good Fedora 9 feature though? That is to say making it easier to remix parts of Fedora, or any other similar application? -Yaakov From nicolas.mailhot at laposte.net Sun Sep 9 14:04:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Sep 2007 16:04:49 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: <1189346690.3293.0.camel@rousalka.dyndns.org> Le dimanche 09 septembre 2007 ? 09:18 -0400, Michel Salim a ?crit : > By the way, 'yum search umbrello' won't work with just a Provides:, > and so yum install probably would not either: Nope, yum install will work. yum logic is funny -- 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 myfedora at richip.dhs.org Sun Sep 9 14:46:38 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 09 Sep 2007 08:46:38 -0600 Subject: Push Updates Message-ID: <1189349198.4783.8.camel@localhost6.localdomain6> Is there a system to make a build system push updates to computers in a scheduled manner? I'd like to set up a local Koji build system for building private packages and signal slave computers to start downloading the packages from their fastest mirror (throughput). I'd like to do it in a scheduled manner, though, so even though the repos are distributed, I still don't bring any down with an avalanche. Ideally, I would have the mirrors signal the update since it knows best if it's being overloaded or not. -- Richi Plana From fedora at camperquake.de Sun Sep 9 15:51:44 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 9 Sep 2007 17:51:44 +0200 Subject: rawhide report: 20070905 changes In-Reply-To: <200709051012.l85ACVN2020606@porkchop.devel.redhat.com> References: <200709051012.l85ACVN2020606@porkchop.devel.redhat.com> Message-ID: <20070909175144.0ec8f552@lain.camperquake.de> Hi. On Wed, 5 Sep 2007 06:12:31 -0400, Build System wrote > kernel-2.6.23-0.164.rc5.fc8 > --------------------------- Does not boot, at least on my system. More interesting, at least from my POV, is the last thing it prints before the machine resets itself: Booting: ABCDEFGHIJKLMNOPQ Is that from Grub or from the kernel already? And what does it mean? From bloch at verdurin.com Sun Sep 9 15:57:33 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Sun, 9 Sep 2007 16:57:33 +0100 (BST) Subject: Kernel problem and HAL broken with latest rawhide? Message-ID: <54743.87.194.100.54.1189353453.squirrel@webmail.cream.org> This afternoon I applied the latest post-test2 rawhide updates to my laptop. The latest kernel (2.6.23-0.169.rc5.git1.fc8 doesn't get past the first few lines of kernel output before rebooting. When I boot with the previous installed kernel (2.6.32-0.164.rc5.fc8) it boots but HAL doesn't start properly, meaning NetworkManager fails etc. I can put the full set of logs in bugzilla but I'm not sure which component to choose. Here's the relevant part of dmesg: Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ip_tables: (C) 2000-2006 Netfilter Core Team hal-setup-keyma[2743]: segfault at 0000000000000000 rip 00002aaaab189fb3 rsp 00007fff61db63a8 error 4 ADDRCONF(NETDEV_UP): wlan0: link is not ready sky2 eth0: enabling interface sky2 eth0: ram buffer 4K ADDRCONF(NETDEV_UP): eth0: link is not ready console-kit-dae[2573]: segfault at 0000000000000008 rip 000000357d822efc rsp 00000000400100b0 error 4 [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 sky2 eth0: disabling interface NetworkManager[3592] trap int3 rip:421b5f rsp:7fff0bb6e6d0 error:0 and of /var/log/messages: Sep 9 15:45:42 vaio setroubleshoot: [rpc.ERROR] exception DBusException: org.freedesktop.DBus.Error.AccessDe nied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied#012Traceback (most recen t call last):#012 File "/usr/lib/python2.5/site-packages/setroubleshoot/server.py", line 434, in RunFaultSer ver#012 setroubleshootd_dbus = SetroubleshootdDBus()#012 File "/usr/lib/python2.5/site-packages/setrouble shoot/server.py", line 345, in __init__#012 self.bus = dbus.SystemBus()#012 File "/usr/lib/python2.5/site -packages/dbus/_dbus.py", line 201, in __new__#012 private=private)#012 File "/usr/lib/python2.5/site-pac kages/dbus/_dbus.py", line 107, in __new__#012 bus = BusConnection.__new__(subclass, bus_type, mainloop=ma inloop)#012 File "/usr/lib/python2.5/site-packages/dbus/bus.py", line 121, in __new__#012 bus = cls._new_ for_bus(address_or_type, mainloop=mainloop)#012DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied#000 Sep 9 15:45:59 vaio dbus: Can't send to audit system: USER_AVC avc: denied { 0x2 } for msgtype=signal inte rface=org.freedesktop.NetworkManager member=StateChange dest=org.freedesktop.DBus spid=2804 tpid=2698 scontex t=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:rpm_t:s0 tclass=(null)#012: exe="/bin/dbus -daemon" (sauid=81, hostname=?, addr=?, terminal=?) Sep 9 15:45:59 vaio NetworkManager: nm_hal_deinit(): libhal shutdown failed - Connection is closed Sep 9 15:45:59 vaio NetworkManager: nm_dbus_init(): nm_dbus_init() could not get the system bus. Ma ke sure the message bus daemon is running! Sep 9 15:46:28 vaio setroubleshoot: [rpc.ERROR] attempt to open server connection failed: Connection refused #000 Sep 9 15:46:28 vaio setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused#000 From mschwendt.tmp0701.nospam at arcor.de Sun Sep 9 16:36:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 9 Sep 2007 18:36:38 +0200 Subject: rawhide report: 20070905 changes In-Reply-To: <20070909175144.0ec8f552@lain.camperquake.de> References: <200709051012.l85ACVN2020606@porkchop.devel.redhat.com> <20070909175144.0ec8f552@lain.camperquake.de> Message-ID: <20070909183638.0b9e47f1.mschwendt.tmp0701.nospam@arcor.de> On Sun, 9 Sep 2007 17:51:44 +0200, Ralf Ertzinger wrote: > Hi. > > On Wed, 5 Sep 2007 06:12:31 -0400, Build System wrote > > > kernel-2.6.23-0.164.rc5.fc8 > > --------------------------- > > Does not boot, at least on my system. > > More interesting, at least from my POV, is the last thing it prints > before the machine resets itself: > > Booting: ABCDEFGHIJKLMNOPQ > > Is that from Grub or from the kernel already? And what does it mean? https://www.redhat.com/archives/fedora-extras-commits/2007-September/msg01376.html From lsof at nodata.co.uk Sun Sep 9 17:02:07 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 09 Sep 2007 19:02:07 +0200 Subject: Push Updates In-Reply-To: <1189349198.4783.8.camel@localhost6.localdomain6> References: <1189349198.4783.8.camel@localhost6.localdomain6> Message-ID: <1189357327.3180.4.camel@sb-home> Am Sonntag, den 09.09.2007, 08:46 -0600 schrieb Richi Plana: > Is there a system to make a build system push updates to computers in a > scheduled manner? I'd like to set up a local Koji build system for > building private packages and signal slave computers to start > downloading the packages from their fastest mirror (throughput). I'd > like to do it in a scheduled manner, though, so even though the repos > are distributed, I still don't bring any down with an avalanche. > Ideally, I would have the mirrors signal the update since it knows best > if it's being overloaded or not. > -- > > Richi Plana > Sounds like Satellite server.. Anyway. You can do what you want very easily with fastestmirror and a yum upgrade or rsync (for the mirrors) randomised over a few hours. I think dag also had a solution for this. From rc040203 at freenet.de Sun Sep 9 17:22:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 09 Sep 2007 19:22:54 +0200 Subject: FESCo Meeting Summary for 2007-09-06 In-Reply-To: <46E181DE.8030507@redhat.com> References: <1189107915.24113.36.camel@kennedy> <1189119383.24848.696.camel@mccallum.corsepiu.local> <20070906182149.40029fc5@vader.jdub.homelinux.org> <1189121458.24848.703.camel@mccallum.corsepiu.local> <1189123579.24848.734.camel@mccallum.corsepiu.local> <46E181DE.8030507@redhat.com> Message-ID: <1189358575.3157.6.camel@mccallum.corsepiu.local> On Fri, 2007-09-07 at 12:52 -0400, wrote: > Ralf Corsepius wrote: > > Yes, it had been a closed list and maintainers did get automatically > > subscribed to it - The FESCO of the time this was decided, this approach > > wise - I never did - But THEM decided otherwise. > > So essentially you're agreeing that the way -maintainers was handled/set > up by the old FESCo was wrong. Correct. > Which is basically what the current > FESCo decided. We can go on for days discussing various ways to fix it, > but we decided that since it was broken, removing the broken bit was the > best course of action for now since it provided a disservice to many > people as evidenced by the complaints on the various lists about it by > the very people who IMO we were trying to target. IMO, the current FESCO's decision to kill "maintainers@" is as wrong as their predecessor's decision to not make subscription to "maintainers@" mandatory to all "package maintainers". > If you have a better > solution for lists to actually serve the needs of the community, please > propose it to FESCo. I would keep maintainers, but make subscription mandatory to all maintainers and "kill all *announce lists". Alternative would be to kill all "devel/testing lists" in favor of one single list all maintainers and devs can not avoid being subscribed too. Ralf From fedora at camperquake.de Sun Sep 9 17:36:23 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 9 Sep 2007 19:36:23 +0200 Subject: rawhide report: 20070905 changes In-Reply-To: <20070909183638.0b9e47f1.mschwendt.tmp0701.nospam@arcor.de> References: <200709051012.l85ACVN2020606@porkchop.devel.redhat.com> <20070909175144.0ec8f552@lain.camperquake.de> <20070909183638.0b9e47f1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070909193623.0f0641eb@lain.camperquake.de> Hi. On Sun, 9 Sep 2007 18:36:38 +0200, Michael Schwendt wrote > > More interesting, at least from my POV, is the last thing it prints > > before the machine resets itself: > > > > Booting: ABCDEFGHIJKLMNOPQ > > > > Is that from Grub or from the kernel already? And what does it mean? > > https://www.redhat.com/archives/fedora-extras-commits/2007-September/msg01376.html Nice. Thanks. From myfedora at richip.dhs.org Sun Sep 9 17:38:07 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sun, 09 Sep 2007 11:38:07 -0600 Subject: Push Updates In-Reply-To: <1189357327.3180.4.camel@sb-home> References: <1189349198.4783.8.camel@localhost6.localdomain6> <1189357327.3180.4.camel@sb-home> Message-ID: <1189359487.4783.23.camel@localhost6.localdomain6> On Sun, 2007-09-09 at 19:02 +0200, nodata wrote: > Am Sonntag, den 09.09.2007, 08:46 -0600 schrieb Richi Plana: > > Is there a system to make a build system push updates to computers in a > > scheduled manner? I'd like to set up a local Koji build system for > > building private packages and signal slave computers to start > > downloading the packages from their fastest mirror (throughput). I'd > > like to do it in a scheduled manner, though, so even though the repos > > are distributed, I still don't bring any down with an avalanche. > > Ideally, I would have the mirrors signal the update since it knows best > > if it's being overloaded or not. > > -- > > > > Richi Plana > > > > Sounds like Satellite server.. The only reference I could find for "Satellite server" is for the RHN Satellite Server (http://www.redhat.com/docs/manuals/RHNetwork/satellite/4.1.0/index.html). After going through a couple chapters of the manual, I still don't have an idea what it actually does, :-p. It just says it's the solution to package management. At any rate, it's RHN and I don't know if the code for that is actually being released. I'm looking for a solution I can actually use. If one exists, then nice. If not, then I'm wondering if anyone is interested in such a project. > Anyway. You can do what you want very easily with fastestmirror and a > yum upgrade or rsync (for the mirrors) randomised over a few hours. I've no problem with pushing files to a mirror. I'm not sure how fastestmirror works. What principle does it use to determine which is the fastest mirror? Random is one way of ensuring things (I think Smolt uses something like that), but it isn't very scientific, is it? I doubt it's the most optimized, but it is the most expedient. -- Richi Plana From pemboa at gmail.com Sun Sep 9 18:09:23 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 9 Sep 2007 13:09:23 -0500 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: <16de708d0709091109s5bc7e2fcy5083b62ca3286c17@mail.gmail.com> On 9/9/07, Michel Salim wrote: > On 08/09/2007, Till Maas wrote: > > On Sa September 8 2007, Hans de Goede wrote: > > > > > As it currently stands umbrello is just plain unfindable to end users, as > > > you know I'm not some noob. I even searched for in progress reviews of > > > umbrello. > > > > > > Also I think it is a very bad idea to ship packages with a clearly seperate > > > upstream in some kinda bundle form. Sticking with the umbrello example, in > > > order for the latest version to be included into Fedora, we must wait for a > > > new upstream kdesdk release, which likely won't happen before there is a > > > kdesdk4 in some far away future, as kde3 is as good as EOL. > > > > > > Notice that umbrello and kdesdk are just an example, this goes for other > > > Aggregation upstreams too. > > > > > > Since on of Fedora's strenghts is being always up to date with the latest > > > upstream versions, I think using these kind of upstream aggregation > > > projects is a BAD idea as it creates interlocks with regards to versions > > > between clearly seperate projects like kdesdk and umbrello. > > > > I agree completely. > > > Ditto, though in this case, umbrello happens to *also* be part of kdesdk: > > http://uml.sourceforge.net/download.php > > The source tarballs are taken straight out of kdesdk CVS, so the > Fedora packaging, while needing to be fixed, is understandable. > > By the way, 'yum search umbrello' won't work with just a Provides:, > and so yum install probably would not either: How about listing the apps in the description? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From michel.sylvan at gmail.com Sun Sep 9 18:41:26 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 14:41:26 -0400 Subject: rawhide report: 20070909 changes In-Reply-To: <200709090902.l8992L1c007907@porkchop.devel.redhat.com> References: <200709090902.l8992L1c007907@porkchop.devel.redhat.com> Message-ID: Hi Brian, On 09/09/2007, Build System wrote: > liferea-1.2.23-1.fc8 > -------------------- > * Sat Sep 08 2007 Brian Pepple - 1.2.23-1 > - Update to 1.2.23. > Is liferea going to stay at the 1.2 series until F8 final comes out, and then move to the 1.4 series? Thanks, -- Michel From bpepple at fedoraproject.org Sun Sep 9 19:06:05 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 09 Sep 2007 15:06:05 -0400 Subject: rawhide report: 20070909 changes In-Reply-To: References: <200709090902.l8992L1c007907@porkchop.devel.redhat.com> Message-ID: <1189364765.10624.13.camel@kennedy> On Sun, 2007-09-09 at 14:41 -0400, Michel Salim wrote: > On 09/09/2007, Build System wrote: > > liferea-1.2.23-1.fc8 > > -------------------- > > * Sat Sep 08 2007 Brian Pepple - 1.2.23-1 > > - Update to 1.2.23. > > > Is liferea going to stay at the 1.2 series until F8 final comes out, > and then move to the 1.4 series? Yeah, it's going to definitely stay at the 1.2 series for F8 for now. The 1.4 branch is a fairly major rewrite, and based on my experience with it so far, extremely unstable. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eric.tanguy at univ-nantes.fr Sun Sep 9 20:11:42 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 09 Sep 2007 22:11:42 +0200 Subject: GtkTooltips and rawhide Message-ID: <1189368702.2902.3.camel@bureau.maison> I try to compile gperiodic for rawhide and it uses GtkTooltips type but it give an error : make gperiodic make[1]: Entering directory `/builddir/build/BUILD/gperiodic-2.0.10' gcc -c `pkg-config --cflags gtk+-2.0` -I. -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED gperiodic.c In file included from gperiodic.c:37: gperiodic.h:73: error: expected specifier-qualifier-list before 'GtkTooltips' gperiodic.c: In function 'main_prog': gperiodic.c:389: error: 'struct table_entry' has no member named 'tooltip' gperiodic.c:390: error: 'struct table_entry' has no member named 'tooltip' gperiodic.c:391: error: 'struct table_entry' has no member named 'tooltip' make[1]: *** [gperiodic.o] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/gperiodic-2.0.10' it seems that GtkTooltips type is no longer known. I have to BR a new package ? Thanks Eric From mclasen at redhat.com Sun Sep 9 20:22:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 09 Sep 2007 16:22:37 -0400 Subject: GtkTooltips and rawhide In-Reply-To: <1189368702.2902.3.camel@bureau.maison> References: <1189368702.2902.3.camel@bureau.maison> Message-ID: <1189369357.3988.1.camel@localhost.localdomain> On Sun, 2007-09-09 at 22:11 +0200, Tanguy Eric wrote: > I try to compile gperiodic for rawhide and it uses GtkTooltips type but > it give an error : > > make gperiodic > make[1]: Entering directory `/builddir/build/BUILD/gperiodic-2.0.10' > gcc -c `pkg-config --cflags gtk+-2.0` -I. -DG_DISABLE_DEPRECATED > -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED > -DGTK_DISABLE_DEPRECATED gperiodic.c > In file included from gperiodic.c:37: > gperiodic.h:73: error: expected specifier-qualifier-list before > 'GtkTooltips' > gperiodic.c: In function 'main_prog': > gperiodic.c:389: error: 'struct table_entry' has no member named > 'tooltip' > gperiodic.c:390: error: 'struct table_entry' has no member named > 'tooltip' > gperiodic.c:391: error: 'struct table_entry' has no member named > 'tooltip' > make[1]: *** [gperiodic.o] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/gperiodic-2.0.10' > > it seems that GtkTooltips type is no longer known. I have to BR a new > package ? > GtkTooltips have been deprecated in favor of a new tooltips implementation. You need to remove -DGTK_DISABLE_DEPRECATED. Matthias From michel.sylvan at gmail.com Sun Sep 9 20:23:53 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 16:23:53 -0400 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <200709091046.43665.ville.skytta@iki.fi> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <200709082055.04151.ville.skytta@iki.fi> <20070909020640.GA12305@hurricane.linuxnetz.de> <200709091046.43665.ville.skytta@iki.fi> Message-ID: On 09/09/2007, Ville Skytt? wrote: > On Sunday 09 September 2007, Robert Scheck wrote: > > On Sat, 08 Sep 2007, Ville Skytt? wrote: > > > On Saturday 08 September 2007, Michel Salim wrote: > > > > On 11/08/2007, Robert Scheck wrote: > > > > > thousands of -devel packages is in my not so humble opinion what the > > > > > reporter of bug #220484 would like to see. And I don't believe, > > > > > there's any real benefit of doing so, so please avoid it. We're > > > > > living in the 3rd year- thousand and I don't want to calculate what 5 > > > > > MB of disk space could cost. > > > > > > > > Thirded. Consider that good ol' Slackware does not even split > > > > development files out of their main packages! > > > > > > 5MB is actually pretty much if you consider setups on space constrained > > > media such as live CDs, small flash disks etc. There have been other > > > related lengthy discussions about things such as trimming package > > > changelogs which would result in the same order of magnitude space > > > savings when installed, so there are people who do care about numbers > > > like that. > > > > Ehem. I talked about 5 MB for splitting the -devel package itself. Since > > when are db4-devel packages installed on live CDs, small flash disks etc.? > > And no, it's not the same. So please don't bring my argumentation out of > > context! > > That wasn't my intention, sorry if I offended you. Your later (than your > mailing list post) comment in #220484 seems very much opposed to the whole > split and doesn't mention devel packages at all. Michel's reply above (which > as the quote indicators show, is primarily what I replied to) seems to me to > be using Slackware as a proof-of-concept argument that not caring about size > overhead of development files in packages in general works just fine. And I > don't actually see a db4-cxx-devel in the packages tree nor in the db4.spec > CVS history. > My mistake. I meant to actually state that on a developer's workstation, the size of -devel does not matter that much (when I brought up the Slackware example, I meant it as a quintessential developer's distribution). Of course, on space-constrained environments every megabyte counts. -- Michel From michel.sylvan at gmail.com Sun Sep 9 20:29:15 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 16:29:15 -0400 Subject: DKMS and old kernel modules Message-ID: Hi, I'm wondering how the version of DKMS in rawhide deals with old modules, when the kernel for which they were built is removed. On F-7, with FreshRPMS' madwifi RPM (which uses DKMS), the old modules are left behind, which means /lib/modules accumulates junk files over time. Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot? (will Bugzilla this if people think it's a good idea) Regards, -- Michel From opensource at till.name Sun Sep 9 20:40:10 2007 From: opensource at till.name (Till Maas) Date: Sun, 09 Sep 2007 22:40:10 +0200 Subject: DKMS and old kernel modules In-Reply-To: References: Message-ID: <200709092240.23077.opensource@till.name> On So September 9 2007, Michel Salim wrote: > Not sure what the best solution is. Trigger a cleanup process in the > DKMS initscript, which would operate if the kernel booted is not the > same as at the previous boot? Proposed is a trigger when an old kernel is removed. > (will Bugzilla this if people think it's a good idea) It's alread there: https://bugzilla.redhat.com/show_bug.cgi?id=250377 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From denis at poolshark.org Sun Sep 9 20:38:57 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 09 Sep 2007 22:38:57 +0200 Subject: GtkTooltips and rawhide In-Reply-To: <1189369357.3988.1.camel@localhost.localdomain> References: <1189368702.2902.3.camel@bureau.maison> <1189369357.3988.1.camel@localhost.localdomain> Message-ID: <46E459E1.1030505@poolshark.org> Matthias Clasen wrote: > On Sun, 2007-09-09 at 22:11 +0200, Tanguy Eric wrote: >> I try to compile gperiodic for rawhide and it uses GtkTooltips type but >> it give an error : >> >> make gperiodic >> make[1]: Entering directory `/builddir/build/BUILD/gperiodic-2.0.10' >> gcc -c `pkg-config --cflags gtk+-2.0` -I. -DG_DISABLE_DEPRECATED >> -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED >> -DGTK_DISABLE_DEPRECATED gperiodic.c >> In file included from gperiodic.c:37: >> gperiodic.h:73: error: expected specifier-qualifier-list before >> 'GtkTooltips' >> gperiodic.c: In function 'main_prog': >> gperiodic.c:389: error: 'struct table_entry' has no member named >> 'tooltip' >> gperiodic.c:390: error: 'struct table_entry' has no member named >> 'tooltip' >> gperiodic.c:391: error: 'struct table_entry' has no member named >> 'tooltip' >> make[1]: *** [gperiodic.o] Error 1 >> make[1]: Leaving directory `/builddir/build/BUILD/gperiodic-2.0.10' >> >> it seems that GtkTooltips type is no longer known. I have to BR a new >> package ? >> > > GtkTooltips have been deprecated in favor of a new tooltips > implementation. You need to remove -DGTK_DISABLE_DEPRECATED. Or even better, write a patch to port to the newer tooltip interface (it's straightforward). See http://library.gnome.org/devel/gtk/unstable/gtk-migrating-tooltips.html If you need help with that, let me know. -denis From jonathan.underwood at gmail.com Sun Sep 9 21:19:20 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 9 Sep 2007 22:19:20 +0100 Subject: DKMS and old kernel modules In-Reply-To: <200709092240.23077.opensource@till.name> References: <200709092240.23077.opensource@till.name> Message-ID: <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> On 09/09/2007, Till Maas wrote: > On So September 9 2007, Michel Salim wrote: > > > Not sure what the best solution is. Trigger a cleanup process in the > > DKMS initscript, which would operate if the kernel booted is not the > > same as at the previous boot? > > Proposed is a trigger when an old kernel is removed. > > > (will Bugzilla this if people think it's a good idea) > > It's alread there: > https://bugzilla.redhat.com/show_bug.cgi?id=250377 > I thought that dkms had the ability to build an rpm and then install that. That would be the ideal solution. From michel.sylvan at gmail.com Sun Sep 9 21:51:28 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 17:51:28 -0400 Subject: DKMS and old kernel modules In-Reply-To: <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> References: <200709092240.23077.opensource@till.name> <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> Message-ID: On 09/09/2007, Jonathan Underwood wrote: > On 09/09/2007, Till Maas wrote: > > On So September 9 2007, Michel Salim wrote: > > > > > Not sure what the best solution is. Trigger a cleanup process in the > > > DKMS initscript, which would operate if the kernel booted is not the > > > same as at the previous boot? > > > > Proposed is a trigger when an old kernel is removed. > > > > > (will Bugzilla this if people think it's a good idea) > > > > It's alread there: > > https://bugzilla.redhat.com/show_bug.cgi?id=250377 > > > > I thought that dkms had the ability to build an rpm and then install > that. That would be the ideal solution. > Matt Domsch, who is (AFAIK) in charge of DKMS development, did not mention that at all. No kernel developer has weighed in on that discussion, it seems. Ping? -- Michel From buildsys at fedoraproject.org Sun Sep 9 22:11:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 9 Sep 2007 18:11:43 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-09 Message-ID: <20070909221143.AC72B152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 14 audio-convert-mod-3.45.2-2.fc6 cksfv-1.3.12-1.fc6 gcstar-1.2.0-1.fc6 libeXosip2-3.0.3-1.fc6 libosip2-3.0.3-2.fc6 perl-MP3-Info-1.22-3.fc6 php-pear-DB-DataObject-1.8.7-1.fc6 php-pear-Pager-2.4.4-1.fc6 php-pecl-radius-1.2.5-1.fc6 php-pecl-xdebug-2.0.0-1.fc6 qgit-1.5.7-1.fc6 qucs-0.0.12-3.fc6 shorewall-3.4.6-1.fc6 VLGothic-fonts-20070901-1.fc6 Changes in Fedora Extras 6: audio-convert-mod-3.45.2-2.fc6 ------------------------------ * Sat Sep 08 2007 Stewart Adam 3.45.2-2 - Fix traceback upon calling --help cksfv-1.3.12-1.fc6 ------------------ * Sat Sep 08 2007 Christopher Stone 1.3.12-1 - Upstream sync * Tue Aug 28 2007 Fedora Release Engineering - 1.3.11-2 - Rebuild for selinux ppc32 issue. gcstar-1.2.0-1.fc6 ------------------ * Sun Sep 09 2007 Tian - 1.2.0-1 - New upstream version * Thu Aug 16 2007 Tian - 1.1.1-4 - Updated license tag * Sun May 27 2007 Tian - 1.1.1-3 - Added Obsoletes tag libeXosip2-3.0.3-1.fc6 ---------------------- * Tue Aug 28 2007 Jeffrey C. Ollie - 3.0.3-1 - Update to 3.0.3 libosip2-3.0.3-2.fc6 -------------------- * Tue Aug 28 2007 Jeffrey C. Ollie - 3.0.3-2 - Bump release. * Tue Aug 28 2007 Jeffrey C. Ollie - 3.0.3-1 - Update to 3.0.3 - Update license tag. * Wed Nov 22 2006 Jeffrey C. Ollie - 3.0.1-2 - Bump release and rebuild perl-MP3-Info-1.22-3.fc6 ------------------------ * Sat Sep 08 2007 Christopher Stone 1.22-3 - Add BuildRequires perl(Test::More) * Sat Sep 08 2007 Christopher Stone 1.22-2 - Add BuildRequires perl(ExtUtils::MakeMaker) * Sat Sep 08 2007 Christopher Stone 1.22-1 - Upstream sync - spec file cleanups php-pear-DB-DataObject-1.8.7-1.fc6 ---------------------------------- * Sat Sep 08 2007 Christopher Stone 1.8.7-1 - Upstream sync - Update license file php-pear-Pager-2.4.4-1.fc6 -------------------------- * Sat Sep 08 2007 Christopher Stone 2.4.4-1 - Upstream sync php-pecl-radius-1.2.5-1.fc6 --------------------------- * Sat Sep 08 2007 Christopher Stone 1.2.5-1 - Upstream sync php-pecl-xdebug-2.0.0-1.fc6 --------------------------- * Sat Sep 08 2007 Christopher Stone 2.0.0-1 - Upstream sync - Remove %{?beta} tags qgit-1.5.7-1.fc6 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 - update license tag qucs-0.0.12-3.fc6 ----------------- * Sun Sep 09 2007 Eric Tanguy - 0.0.12-3 - Modifiy qucs.desktop BZ 283941 shorewall-3.4.6-1.fc6 --------------------- * Sun Sep 09 2007 Robert Marcano - 3.4.6-1 - Update to upstream 3.4.6 VLGothic-fonts-20070901-1.fc6 ----------------------------- * Sun Sep 09 2007 Ryo Dairiki - 20070901-1 - Update to 20070901 From adalbert.prokop at gmx.de Sun Sep 9 22:09:42 2007 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Mon, 10 Sep 2007 00:09:42 +0200 Subject: Enhancement proposal for Firefox Message-ID: <200709100009.42098.adalbert.prokop@gmx.de> Hello! I'd like to propose an enhancement for the Firefox's start script. It includes two changes: 1. Give the user the choice which version of Firefox is started, especially on 64-bit architectures. 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they use OSS now, which will fail in most cases, because /dev/dsp is almost constantly in use by arts/esd/whatever. Motivation ========== I lately installed F7 on an AMD64 machine and had some problems with firefox plugins, because most of them don't exist for 64 bit architectures. I decided to use the 32 bit version, but it's not easy to achieve it, because /usr/bin/firefox alwas uses the output of uname -m to choose the version. And alsa-oss simply because I was sorry either to have a soundless browser or to change scripts. How to do it ============ I have attached a patch, which will do what I suggested. It uses two environment variables: MOZ_ARCH and MOZ_AOSS. If MOZ_ARCH is set, it's value is used to determine the firefox version, if it's not set, uname -m is called like before. Simmilarly MOZ_AOSS could contain the path to the aoss application. If not set, it would default to /usr/bin/aoss. If set to "none", alsa-oss would be ommited completely. Both variables could be set in /etc/profile.d to provide system wide settings. What do you think about these enhancements? -- Bye, Adalbert It is said that the lonely eagle flies to the mountain peaks while the lowly ant crawls the ground, but cannot the soul of the ant soar as high as the eagle? -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox.diff Type: text/x-diff Size: 724 bytes Desc: not available URL: From michel.sylvan at gmail.com Sun Sep 9 22:37:19 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 9 Sep 2007 18:37:19 -0400 Subject: Enhancement proposal for Firefox In-Reply-To: <200709100009.42098.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: On 09/09/2007, Adalbert Prokop wrote: [snip] > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they > use OSS now, which will fail in most cases, because /dev/dsp is almost > constantly in use by arts/esd/whatever. > Last time I tried, on a 64-bit platform you can not use alsa-oss with 32-bit Firefox. Still nice if you happen to be running at the native wordsize, though. On recent dmix-capable soundcards, this should not be a problem, no? -- Michel From jonathan.underwood at gmail.com Sun Sep 9 22:37:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 9 Sep 2007 23:37:28 +0100 Subject: DKMS and old kernel modules In-Reply-To: References: <200709092240.23077.opensource@till.name> <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> Message-ID: <645d17210709091537u15477c3bi8c292769326b7d72@mail.gmail.com> On 09/09/2007, Michel Salim wrote: > On 09/09/2007, Jonathan Underwood wrote: > > On 09/09/2007, Till Maas wrote: > > > On So September 9 2007, Michel Salim wrote: > > > > > > > Not sure what the best solution is. Trigger a cleanup process in the > > > > DKMS initscript, which would operate if the kernel booted is not the > > > > same as at the previous boot? > > > > > > Proposed is a trigger when an old kernel is removed. > > > > > > > (will Bugzilla this if people think it's a good idea) > > > > > > It's alread there: > > > https://bugzilla.redhat.com/show_bug.cgi?id=250377 > > > > > > > I thought that dkms had the ability to build an rpm and then install > > that. That would be the ideal solution. > > > Matt Domsch, who is (AFAIK) in charge of DKMS development, did not > mention that at all. > Announcement of that capability goes back to 2004: http://lists.atrpms.net/pipermail/atrpms-devel/2004-June/000259.html From mattdm at mattdm.org Sun Sep 9 22:43:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 9 Sep 2007 18:43:48 -0400 Subject: NetworkManager and "illegal" SSID chars = crash? In-Reply-To: <20070907182319.GA27871@jadzia.bu.edu> References: <1189011580.24933.4.camel@xo-3E-67-34.localdomain> <1189012558.1641.69.camel@localhost6.localdomain6> <1189014587.24933.14.camel@xo-3E-67-34.localdomain> <20070907124218.GA19428@jadzia.bu.edu> <20070907133020.GA25022@jadzia.bu.edu> <190e0dab0709070732o5def911ewa507d5fa04d6a554@mail.gmail.com> <1189177588.2612.7.camel@xo-3E-67-34.localdomain> <20070907182319.GA27871@jadzia.bu.edu> Message-ID: <20070909224348.GA24933@jadzia.bu.edu> On Fri, Sep 07, 2007 at 02:23:19PM -0400, Matthew Miller wrote: > > The decision to use the SSID as part of the D-Bus object path was > > insanely wrong, which is of course clear now 3 years later :) Rectified > > with 0.7, we may be able to fix it in 0.6.5 too since object paths are > > essentially just pointers and are opaque. > So, theoretically if I install 0.7.0-0.1.svn2736.fc8 outta koji everything > will be solved? The answer is no: that one doesn't work at all. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ivazqueznet at gmail.com Sun Sep 9 23:32:53 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 09 Sep 2007 19:32:53 -0400 Subject: alsa-oss (was: Re: Enhancement proposal for Firefox) In-Reply-To: <200709100009.42098.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: <1189380773.9741.9.camel@ignacio.lan> On Mon, 2007-09-10 at 00:09 +0200, Adalbert Prokop wrote: > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. I'm curious. Why does everyone suggest using alsa-oss instead of just slaving pcm.!dsp to default? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon Sep 10 02:04:44 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 09 Sep 2007 21:04:44 -0500 Subject: alsa-oss (was: Re: Enhancement proposal for Firefox) In-Reply-To: <1189380773.9741.9.camel@ignacio.lan> References: <200709100009.42098.adalbert.prokop@gmx.de> <1189380773.9741.9.camel@ignacio.lan> Message-ID: <1189389884.4289.10.camel@localhost> On Sun, 2007-09-09 at 19:32 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2007-09-10 at 00:09 +0200, Adalbert Prokop wrote: > > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. > > I'm curious. Why does everyone suggest using alsa-oss instead of just > slaving pcm.!dsp to default? I've never heard of it? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Mon Sep 10 02:16:37 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Sep 2007 21:16:37 -0500 Subject: DKMS and old kernel modules In-Reply-To: References: <200709092240.23077.opensource@till.name> <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> Message-ID: <20070910021637.GC31880@auslistsprd01.us.dell.com> On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote: > On 09/09/2007, Jonathan Underwood wrote: > > I thought that dkms had the ability to build an rpm and then install > > that. That would be the ideal solution. > > > Matt Domsch, who is (AFAIK) in charge of DKMS development, did not > mention that at all. There are several problems DKMS is designed to solve, and while clearly biased, I think it does so quite well. Dell honestly would not have been able to ship a product like RHEL, SLES, or Ubuntu without having a tool like DKMS available - which is why we wrote and continue to maintain it. We rarely change our factory images from the "gold" kernels of those products - the complete retesting required to do so makes it time-consuming and therefore expensive. We use DKMS to change individual kernel modules, with clear targeted changes that are easy to verify by code inspection and through runtime testing. We do this in cooperation with the developers at the distros, so the changes that are backported into a DKMS packaged module are then included in future distro updated kernels, which then eliminate the need for the DKMS packaged module. Gary added 'mkrpm', at the request of people within Red Hat, several years ago. One can argue that the RPM spec file template that has evolved over time could be done differently or better, and you'd have no argument from me. The kmod work from SLES and RHEL, while each are different spec templates, both try to solve the same problem - make DKMS produce a source RPM containing source code, which is built in a build system to produce binary RPMs. There are other spec file proposals, like Jef and others propose. Great! I haven't looked at all of them in detail, but with the 'mkrpm' and 'mkkmp' commands in DKMS, any of those spec file proposals should be usable by DKMS. I would want any proposal made to include shipping the source code in the RPM, such that DKMS can rebuild modules on the fly (provided gcc etc. are available). I find this one of the "killer features" of DKMS - it lets modules which are not presently "in the tree" get rebuilt whenever "the tree" gets updated. It isn't perfect, but it's a whole lot better than having no such solution. With the module versioning code I helped get into the kernel, DKMS recognizes when a module is now "in the tree", and of same or equal version to what is provided by a DKMSified package. DKMS then defers to the in-kernel module rather than updating from its own - exactly the behavior we want to encourage (get your code into upstream and therefore into the distros; use DKMS as a backport mechansim for specific fixes older kernels, or in rarer cases, for currently out-of-tree modules which are working to get into the tree). > No kernel developer has weighed in on that discussion, it seems. Ping? The Fedora kernel developers, from the comments I've gathered, all seem to prefer a) modules be upstream first, and b) in rare necessary instances (say, squashfs) they can patch modules into the Fedora kernel tree themselves. This works well for open source modules where you can attract a Fedora kernel developer's attention (e.g. bugzilla with a really good technical case and use case, but the bar is pretty high given that the code isn't upstream yet). Especially with Linus's comments of this past week [1] about the need to work harder to get currently out-of-tree modules cleaned up and into the upstream tree, if that comes to pass there will be less need for out-of-tree modules. And Fedora doesn't have an audience that freezes on a kernel version like RHEL or SLES do, so there's less need for DKMSified modules in the Fedora branded repositories. I say "less need", because there's still the case of open source, out-of-tree modules that one can't convince the kernel maintainers to accept, maybe because it needs wider audience testing. I used DKMS to produce a ppp_mppe module package exactly to address this (not included in Fedora, but posted on the pptpclient.sf.net web site)a. It was a short-lived package, a few months, while testers actively ran and found bugs, and provided me feedback, such that when the driver was proposed for mainline inclusion, I had many people to point to saying "it works for them", and none reporting bugs. It made mainline inclusion much easier. And then the package went away, its need eliminated - my goal all along. I'm OK with keeping kmods out of the official Fedora repositories. But I really like seeing people use DKMS in this last way, as a testing environment for code being prepared for upstream inclusion. [1] http://lwn.net/Articles/248195/ Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From seg at haxxed.com Mon Sep 10 06:32:55 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 10 Sep 2007 01:32:55 -0500 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189285317.8036.9.camel@localhost6.localdomain6> References: <46E29FC6.4090103@hhs.nl> <1189285317.8036.9.camel@localhost6.localdomain6> Message-ID: <1189405975.4289.24.camel@localhost> On Sat, 2007-09-08 at 15:01 -0600, Richi Plana wrote: > Read the thread I started entitled "Goal: Increased Modularity". People > are saying that Fedora is aimed at distro-makers who want to create > spins of their own from Fedora. This is only possible if it actually CAN > be broken down into the pieces that you want. Currently, there are no > policies which even mention modularity, but most of the developers have > come to the same conclusion. There's a faction which believe that it's > easier to maintain something when they're all lumped together. Then > there are those who believe it's easier for individual volunteers to > maintain packages if they're cut down to smaller pieces. Lumping multiple separately versioned, separately released entities into the same SRPM is broken, period. If upstream is lumping a ton of stuff into one tarball, its an upstream bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Mon Sep 10 06:49:45 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 10 Sep 2007 08:49:45 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189405975.4289.24.camel@localhost> References: <46E29FC6.4090103@hhs.nl> <1189285317.8036.9.camel@localhost6.localdomain6> <1189405975.4289.24.camel@localhost> Message-ID: <46E4E909.2050509@hhs.nl> Callum Lerwick wrote: > On Sat, 2007-09-08 at 15:01 -0600, Richi Plana wrote: >> Read the thread I started entitled "Goal: Increased Modularity". People >> are saying that Fedora is aimed at distro-makers who want to create >> spins of their own from Fedora. This is only possible if it actually CAN >> be broken down into the pieces that you want. Currently, there are no >> policies which even mention modularity, but most of the developers have >> come to the same conclusion. There's a faction which believe that it's >> easier to maintain something when they're all lumped together. Then >> there are those who believe it's easier for individual volunteers to >> maintain packages if they're cut down to smaller pieces. > > Lumping multiple separately versioned, separately released entities into > the same SRPM is broken, period. > > If upstream is lumping a ton of stuff into one tarball, its an upstream > bug. > Thats a very short way of saying exactly what I was trying to say, thanks! Regards, Hans From buildsys at redhat.com Mon Sep 10 09:20:48 2007 From: buildsys at redhat.com (Build System) Date: Mon, 10 Sep 2007 05:20:48 -0400 Subject: rawhide report: 20070910 changes Message-ID: <200709100920.l8A9KmeS003983@porkchop.devel.redhat.com> New package flpsed WYSIWYG pseudo PostScript editor Updated Packages: crossvc-1.5.1-7.fc8 ------------------- * Sun Sep 09 2007 Jochen Schmitt 1.5.1-7 - Downgrade to last stable release - Add Req to qt-3.3.8-6 (#246024) eclipse-subclipse-1.2.2-6.fc8 ----------------------------- * Sun Sep 09 2007 Robert Marcano 1.2.2-6 - Change MANIFEST.MF patch to be applied on prep stage * Wed Aug 29 2007 Fedora Release Engineering - 1.2.2-4 - Rebuild for selinux ppc32 issue. emacs-vm-8.0.3.495-6.fc8 ------------------------ * Sun Sep 09 2007 Jonathan G. Underwood - 8.0.3.495-6 - Fix typo with start file creation * Sun Sep 09 2007 Jonathan G. Underwood - 8.0.3.495-5 - Add BuildRequires: emacs since emacs-el doesn't pull this in * Sat Sep 08 2007 Jonathan G. Underwood - 8.0.3.495-4 - Update for agreement with packaging guidelines - add versioned emacs requirement - If no pkg-config is found, revert to sensible defaults geany-0.11-2.fc8 ---------------- * Sun Sep 09 2007 Jonathan G. Underwood - 0.11-2 - Fix Version entry in .desktop file * Sun Sep 09 2007 Jonathan G. Underwood - 0.11-1 - Update to version 0.11 gnu-smalltalk-2.3.6-2.fc8 ------------------------- * Sun Sep 09 2007 Jochen Schmitt 2.3.6-2 - Remove build path from gst.im - Temporarly disable ppc64 * Thu Sep 06 2007 Jochen Schmitt 2.3.6-1 - New upstream release * Thu Aug 09 2007 Jochen Schmitt 2.3.5-3 - Try to fix smp_mflags issue gq-1.2.2-7.fc8 -------------- * Thu Sep 06 2007 Terje R??sten - 1.2.2-7 - Add default-codeset to configure (fix bz #281431) hotwire-0.595-1.fc8 ------------------- * Sun Sep 09 2007 Colin Walters - 0.595-1 - new upstream jd-1.9.6-0.4.svn1322.fc8 ------------------------ * Mon Sep 10 2007 Mamoru Tasaka - 1.9.6-0.4.svn1322 - svn 1322 * Sun Aug 05 2007 Mamoru Tasaka - 1.9.6-0.2.beta070804 - 1.9.6 beta 070804 release 2 * Sat Aug 04 2007 Mamoru Tasaka - 1.9.6-0.1.beta070804 - 1.9.6 beta 070804 kleansweep-0.2.9-5.fc8 ---------------------- * Sun Sep 09 2007 Chitlesh Goorah - 0.2.9-5 - fixed duplicate kmenu entries php-pear-1:1.6.2-1.fc8 ---------------------- * Sun Sep 09 2007 Remi Collet 1:1.6.2-1 - update to 1.6.2 - remove patches merged upstream - Fix : "pear install" hangs on non default channel (#283401) * Tue Aug 21 2007 Joe Orton 1:1.6.1-2 - fix License * Thu Jul 19 2007 Remi Collet 1:1.6.1-1 - update to PEAR-1.6.1 and Console_Getopt-1.2.3 qucs-0.0.12-4.fc8 ----------------- * Sun Sep 09 2007 Eric Tanguy - 0.0.12-4 - Modifiy qucs.desktop BZ 283941 shorewall-3.4.6-1.fc8 --------------------- * Sun Sep 09 2007 Robert Marcano - 3.4.6-1 - Update to upstream 3.4.6 strigi-0.5.5-2.fc8 ------------------ * Sun Sep 09 2007 Deji Akingunola - 0.5.5-2 - Rebuild for BuildID changes * Sat Aug 11 2007 Deji Akingunola - 0.5.5-1 - Update to 0.5.5 release tango-icon-theme-0.8.1-1.fc8 ---------------------------- * Sat Feb 17 2007 Peter Gordon - 0.8.1-1 - Update to new upstream release (0.8.1) xine-lib-1.1.8-2.fc8 -------------------- * Sun Sep 09 2007 Aurelien Bompard 1.1.8-2 - remove the dependency from -extras to -arts, and use Obsoletes to provide an upgrade path Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.i386 requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-changelog eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-subclipse eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-rpm-editor kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From j.w.r.degoede at hhs.nl Mon Sep 10 11:08:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 10 Sep 2007 13:08:06 +0200 Subject: Koji builds hanging on ppc64 target? Message-ID: <46E52596.2030104@hhs.nl> Hi, This morning I started 2 simple builds, but they still haven't completed yet, they are both waiting for the ppc64 arch build to complete? http://koji.fedoraproject.org/koji/taskinfo?taskID=153582 http://koji.fedoraproject.org/koji/taskinfo?taskID=153598 Regards, Hans From adalbert.prokop at gmx.de Mon Sep 10 11:54:16 2007 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Mon, 10 Sep 2007 13:54:16 +0200 Subject: Enhancement proposal for Firefox In-Reply-To: References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: <200709101354.16723.adalbert.prokop@gmx.de> Am Montag, 10. September 2007 schrieb Michel Salim: Hi! >> 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK >> they use OSS now, which will fail in most cases, because /dev/dsp is >> almost constantly in use by arts/esd/whatever. > Last time I tried, on a 64-bit platform you can not use alsa-oss with > 32-bit Firefox. Still nice if you happen to be running at the native > wordsize, though. Hmmm, the only thing I can say for sure is: it works in F7. ;-) I did not thing about it and just tried it. After I've patched the Firefox start script and let it point to /usr/lib/mozilla (not lib64) I simply did aoss firefox and it was good enough. I would investigate it deeper, but the problem is: I have no access to this machine any more. It was my friend's laptop. -- bye, Adalbert F u cn rd ths u cnt spl wrth a dm! From adalbert.prokop at gmx.de Mon Sep 10 12:01:43 2007 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Mon, 10 Sep 2007 14:01:43 +0200 Subject: alsa-oss In-Reply-To: <1189380773.9741.9.camel@ignacio.lan> References: <200709100009.42098.adalbert.prokop@gmx.de> <1189380773.9741.9.camel@ignacio.lan> Message-ID: <200709101401.46686.adalbert.prokop@gmx.de> Am Montag, 10. September 2007 schrieb Ignacio Vazquez-Abrams: Hi Ignacio! > > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. > I'm curious. Why does everyone suggest using alsa-oss instead of just > slaving pcm.!dsp to default? I'm curious. What do you mean by slaving pcm.!dsp to default? For example the flash plugins tries to write to /dev/dsp0 directly. If I don't use aoss, there is little chance I it succeeds, is there? -- Bye, Adalbert Things are not always what they seem. -- Phaedrus From ivazqueznet at gmail.com Mon Sep 10 12:53:28 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 10 Sep 2007 08:53:28 -0400 Subject: alsa-oss In-Reply-To: <200709101401.46686.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> <1189380773.9741.9.camel@ignacio.lan> <200709101401.46686.adalbert.prokop@gmx.de> Message-ID: <1189428808.9741.12.camel@ignacio.lan> On Mon, 2007-09-10 at 14:01 +0200, Adalbert Prokop wrote: > Am Montag, 10. September 2007 schrieb Ignacio Vazquez-Abrams: > > Hi Ignacio! > > > > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. > > > I'm curious. Why does everyone suggest using alsa-oss instead of just > > slaving pcm.!dsp to default? > > I'm curious. What do you mean by slaving pcm.!dsp to default? My ~/.asoundrc is attached. I'm thinking that you could just slave the channels to default instead of hw:0,0. Feel free to experiment with it. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- pcm.!default { type plug slave.pcm "hw:0,0" } pcm.dsp0 { type plug slave.pcm "hw:0,0" } pcm.!dsp { type plug slave.pcm "hw:0,0" } ctl.mixer0 { type hw card 0 } -------------- 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 jonathan.underwood at gmail.com Mon Sep 10 14:16:23 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 10 Sep 2007 15:16:23 +0100 Subject: DKMS and old kernel modules In-Reply-To: <20070910021637.GC31880@auslistsprd01.us.dell.com> References: <200709092240.23077.opensource@till.name> <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> <20070910021637.GC31880@auslistsprd01.us.dell.com> Message-ID: <645d17210709100716q29873c01k717ea77cc10a070f@mail.gmail.com> On 10/09/2007, Matt Domsch wrote: > On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote: > > On 09/09/2007, Jonathan Underwood wrote: > > > I thought that dkms had the ability to build an rpm and then install > > > that. That would be the ideal solution. > > > > > Matt Domsch, who is (AFAIK) in charge of DKMS development, did not > > mention that at all. > > There are several problems DKMS is designed to solve, and while > clearly biased, I think it does so quite well. Dell honestly would > not have been able to ship a product like RHEL, SLES, or Ubuntu > without having a tool like DKMS available - which is why we wrote and > continue to maintain it. We rarely change our factory images from the > "gold" kernels of those products - the complete retesting required to > do so makes it time-consuming and therefore expensive. We use DKMS to > change individual kernel modules, with clear targeted changes that are > easy to verify by code inspection and through runtime testing. We do > this in cooperation with the developers at the distros, so the changes > that are backported into a DKMS packaged module are then included in future > distro updated kernels, which then eliminate the need for the DKMS > packaged module. > > Gary added 'mkrpm', at the request of people within Red Hat, several > years ago. One can argue that the RPM spec file template that has > evolved over time could be done differently or better, and you'd have > no argument from me. The kmod work from SLES and RHEL, while each are > different spec templates, both try to solve the same problem - make > DKMS produce a source RPM containing source code, which is built in a > build system to produce binary RPMs. > > There are other spec file proposals, like Jef and others propose. > Great! I haven't looked at all of them in detail, but with the > 'mkrpm' and 'mkkmp' commands in DKMS, any of those spec file > proposals should be usable by DKMS. > > I would want any proposal made to include shipping the source code in > the RPM, such that DKMS can rebuild modules on the fly (provided gcc > etc. are available). I find this one of the "killer features" of DKMS > - it lets modules which are not presently "in the tree" get rebuilt > whenever "the tree" gets updated. It isn't perfect, but it's a whole > lot better than having no such solution. With the module versioning > code I helped get into the kernel, DKMS recognizes when a module is > now "in the tree", and of same or equal version to what is provided by > a DKMSified package. DKMS then defers to the in-kernel module rather > than updating from its own - exactly the behavior we want to > encourage (get your code into upstream and therefore into the distros; > use DKMS as a backport mechansim for specific fixes older kernels, or > in rarer cases, for currently out-of-tree modules which are working to > get into the tree). Ah, ok, I slightly misunderstood the use of mkrpm - I was under the impression that DKMS could build an rpm of the kernel module on the users machine (not in a repository buildsystem) and then install that. I.e. dkms, when it sees a new kernel on the users machine compiles the kernel module and packages at as an rpm and then installs it. Would that be implementable? From che666 at gmail.com Mon Sep 10 14:38:01 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 10 Sep 2007 16:38:01 +0200 Subject: Enhancement proposal for Firefox In-Reply-To: <200709100009.42098.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: 2007/9/10, Adalbert Prokop : > Hello! > > I'd like to propose an enhancement for the Firefox's start script. It > includes two changes: > > 1. Give the user the choice which version of Firefox is started, > especially on 64-bit architectures. > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they > use OSS now, which will fail in most cases, because /dev/dsp is almost > constantly in use by arts/esd/whatever. > > Motivation > ========== > I lately installed F7 on an AMD64 machine and had some problems with > firefox plugins, because most of them don't exist for 64 bit > architectures. I decided to use the 32 bit version, but it's not easy to > achieve it, because /usr/bin/firefox alwas uses the output of uname -m to > choose the version. so the fix is to get the plugins properly working with x86_64? workarounds will only slow down solutions because of the lack of motiviation to properly push fixes instead of working around with hacks. regards, Rudolf Kastl > > And alsa-oss simply because I was sorry either to have a soundless browser > or to change scripts. > > How to do it > ============ > I have attached a patch, which will do what I suggested. It uses two > environment variables: MOZ_ARCH and MOZ_AOSS. > > If MOZ_ARCH is set, it's value is used to determine the firefox version, > if it's not set, uname -m is called like before. > > Simmilarly MOZ_AOSS could contain the path to the aoss application. If not > set, it would default to /usr/bin/aoss. If set to "none", alsa-oss would > be ommited completely. > > Both variables could be set in /etc/profile.d to provide system wide > settings. > > > What do you think about these enhancements? > > -- > Bye, > Adalbert > > It is said that the lonely eagle flies to the mountain peaks while the > lowly ant crawls the ground, but cannot the soul of the ant soar as high > as the eagle? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From robert at marcanoonline.com Mon Sep 10 15:09:12 2007 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 10 Sep 2007 11:09:12 -0400 Subject: rpms/eclipse/devel eclipse.spec,1.484,1.485 In-Reply-To: <200709101337.l8ADb5ee001659@cvs-int.fedora.redhat.com> References: <200709101337.l8ADb5ee001659@cvs-int.fedora.redhat.com> Message-ID: <1189436952.3514.2.camel@localhost.localdomain> On Mon, 2007-09-10 at 09:37 -0400, Andrew Overholt wrote: > Author: overholt > > Update of /cvs/pkgs/rpms/eclipse/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv1606 > > Modified Files: > eclipse.spec > Log Message: > * Mon Sep 10 2007 Andrew Overholt 3.3.0-19 > - Don't require subclipse, cdt, or rpm-editor on ppc64. Andrew I am rebuilding subclipse and dependencies too on ppc64 now ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From caillon at redhat.com Mon Sep 10 15:59:39 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Sep 2007 11:59:39 -0400 Subject: Enhancement proposal for Firefox In-Reply-To: <200709100009.42098.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: <46E569EB.70405@redhat.com> Adalbert Prokop wrote: > Hello! > > I'd like to propose an enhancement for the Firefox's start script. It > includes two changes: > > 1. Give the user the choice which version of Firefox is started, > especially on 64-bit architectures. You should look into playing with nspluginwrapper. > 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they > use OSS now, which will fail in most cases, because /dev/dsp is almost > constantly in use by arts/esd/whatever. I'd rather see Firefox patched to drop it's ESD support in favor of moving to gstreamer/pulseaudio or something of the sort. From caillon at redhat.com Mon Sep 10 16:02:06 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Sep 2007 12:02:06 -0400 Subject: Is PKG_CONFIG_PATH set on the buildsystem? In-Reply-To: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> References: <645d17210709080517o6d65764ai246a3b10e8bf4d9@mail.gmail.com> Message-ID: <46E56A7E.5030100@redhat.com> Jonathan Underwood wrote: > Hi, > > I was just trying to update package of mine, and the main change is > adding the following macros to the spec file: > > %define emacs_version %(pkg-config emacs --modversion) > %define emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) > %define emacs_startdir %(pkg-coonfig emacs --variable sitestartdir) Trick question: how many letter 'o's does pkg-config have? From jima at beer.tclug.org Mon Sep 10 16:24:20 2007 From: jima at beer.tclug.org (Jima) Date: Mon, 10 Sep 2007 11:24:20 -0500 (CDT) Subject: Enhancement proposal for Firefox In-Reply-To: References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: On Sun, 9 Sep 2007, Michel Salim wrote: > On 09/09/2007, Adalbert Prokop wrote: > [snip] >> 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they >> use OSS now, which will fail in most cases, because /dev/dsp is almost >> constantly in use by arts/esd/whatever. >> > Last time I tried, on a 64-bit platform you can not use alsa-oss with > 32-bit Firefox. Still nice if you happen to be running at the native > wordsize, though. Last time you tried might have been before I fixed aoss to allow for that. :-) The aoss script first checks if you have the 64-bit library, and by default uses that. *Unless* you incant it with the first argument of "-32", in which case it'll check if you have the 32-bit library, and if so, use it instead (and error out if not, which may be a bit unhelpful if it's initiated by a GUI). If it doesn't detect a 64-bit alsa-oss-libs, it assumes you have the 32-bit ones (as the package containing the script depends on *one* of them). I committed these changes to alsa-oss on February 8th, FWIW, due to BZ#221711 and Jason Tibbitts' recommendations (via IRC). Apparently I may have broken the aoss man page. The script could probably use a -h flag, too. Not sure if it'd be in bad taste to fix those before F8 without an open bug. Jima From buildsys at fedoraproject.org Mon Sep 10 16:47:01 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 10 Sep 2007 12:47:01 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-10 Message-ID: <20070910164701.6FBE9152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 1 lighttpd-1.4.18-1.fc6 Changes in Fedora Extras 6: lighttpd-1.4.18-1.fc6 --------------------- * Mon Sep 10 2007 Matthias Saou 1.4.18-1 - Update to 1.4.18. - Include newly installed lighttpd-angel ("angel" process meant to always run as root and restart lighttpd when it crashes, spawn processes on SIGHUP), but it's in testing stage and must be run with -D for now. * Wed Sep 05 2007 Matthias Saou 1.4.17-1 - Update to 1.4.17. - Update defaultconf patch to match new example configuration. - Include patch to fix log file rotation with max-workers set (trac #902). - Add /var/run/lighttpd/ directory where to put fastcgi sockets. * Thu Aug 23 2007 Matthias Saou 1.4.16-3 - Add /usr/bin/awk build requirement, used to get LIGHTTPD_VERSION_ID. * Wed Aug 22 2007 Matthias Saou 1.4.16-2 - Rebuild to fix wrong execmem requirement on ppc32. From 440volt.tux at gmail.com Mon Sep 10 18:08:00 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Mon, 10 Sep 2007 23:38:00 +0530 Subject: koji build failed Message-ID: <539333cb0709101108l310af231m346c5e9d838a1b83@mail.gmail.com> hi ! While trying to build straw-0.27.src.rpm using the command $ koji build --scratch dist-fc7 /usr/src/redhat/SRPMS/straw-0.27-3.src.rpm I encountered a build failed with the following exit status running install running install_modules_check Error: PyGTK-2.8.0 or newer is required. error: Bad exit status from /var/tmp/rpm-tmp.78160 (%install) What to do now ? From dennis at ausil.us Mon Sep 10 18:30:01 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 10 Sep 2007 13:30:01 -0500 Subject: koji build failed In-Reply-To: <539333cb0709101108l310af231m346c5e9d838a1b83@mail.gmail.com> References: <539333cb0709101108l310af231m346c5e9d838a1b83@mail.gmail.com> Message-ID: <200709101330.02039.dennis@ausil.us> On Monday 10 September 2007 1:08:00 pm subhodip biswas wrote: > hi ! > > > While trying to build straw-0.27.src.rpm using the command > $ koji build --scratch dist-fc7 /usr/src/redhat/SRPMS/straw-0.27-3.src.rpm > > I encountered a build failed with the following exit status > > running install > running install_modules_check > Error: PyGTK-2.8.0 or newer is required. > error: Bad exit status from /var/tmp/rpm-tmp.78160 (%install) > > > What to do now ? it seems that pygtk2-2.10.6-1.fc7 is the latest in fedora 7 so you need to make sure your configure script is finding it and that you have the correct BuildRequire's Dennis From 440volt.tux at gmail.com Mon Sep 10 18:53:33 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Tue, 11 Sep 2007 00:23:33 +0530 Subject: koji build failed In-Reply-To: <200709101330.02039.dennis@ausil.us> References: <539333cb0709101108l310af231m346c5e9d838a1b83@mail.gmail.com> <200709101330.02039.dennis@ausil.us> Message-ID: <539333cb0709101153o2a8c032av5d42b9b40c6ce607@mail.gmail.com> Thanx for the information.. On 9/11/07, Dennis Gilmore wrote: > On Monday 10 September 2007 1:08:00 pm subhodip biswas wrote: > > hi ! > > > > > > While trying to build straw-0.27.src.rpm using the command > > $ koji build --scratch dist-fc7 /usr/src/redhat/SRPMS/straw-0.27-3.src.rpm > > > > I encountered a build failed with the following exit status > > > > running install > > running install_modules_check > > Error: PyGTK-2.8.0 or newer is required. > > error: Bad exit status from /var/tmp/rpm-tmp.78160 (%install) > > > > > > What to do now ? > > > it seems that pygtk2-2.10.6-1.fc7 is the latest in fedora 7 so you need to > make sure your configure script is finding it and that you have the correct > BuildRequire's > > Dennis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Regards Subhodip Biswas From michel.sylvan at gmail.com Mon Sep 10 19:25:33 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 10 Sep 2007 15:25:33 -0400 Subject: Enhancement proposal for Firefox In-Reply-To: References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: On 10/09/2007, Jima wrote: > On Sun, 9 Sep 2007, Michel Salim wrote: > > On 09/09/2007, Adalbert Prokop wrote: > > [snip] > >> 2. Use alsa-oss to allow Firefox (or its plugins) play sound. AFAIK they > >> use OSS now, which will fail in most cases, because /dev/dsp is almost > >> constantly in use by arts/esd/whatever. > >> > > Last time I tried, on a 64-bit platform you can not use alsa-oss with > > 32-bit Firefox. Still nice if you happen to be running at the native > > wordsize, though. > > Last time you tried might have been before I fixed aoss to allow for > that. :-) > The aoss script first checks if you have the 64-bit library, and by > default uses that. *Unless* you incant it with the first argument of > "-32", in which case it'll check if you have the 32-bit library, and if > so, use it instead (and error out if not, which may be a bit unhelpful if > it's initiated by a GUI). Ah! I currently do not have my Fedora laptop with me, so I could not check, and before that, I have been using a dmix-enabled sound device, so my observation was rather out-of-date. -- Michel From adalbert.prokop at gmx.de Mon Sep 10 19:28:51 2007 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Mon, 10 Sep 2007 21:28:51 +0200 Subject: Enhancement proposal for Firefox In-Reply-To: References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: <200709102128.52986.adalbert.prokop@gmx.de> Am Montag, 10. September 2007 schrieb Rudolf Kastl: Hi Rudolf! > > I lately installed F7 on an AMD64 machine and had some problems with > > firefox plugins, because most of them don't exist for 64 bit > > architectures. I decided to use the 32 bit version, but it's not easy > > to achieve it, because /usr/bin/firefox alwas uses the output of > > uname -m to choose the version. > so the fix is to get the plugins properly working with x86_64? > workarounds will only slow down solutions because of the lack of > motiviation to properly push fixes instead of working around with > hacks. Yes, the first part of my proposal is about getting plugins work properly with x86_64. It is also about increase usability and acceptance of Fedora by the man-in-the-street. I fully agree that it would the very good if we had native plugins for every achitecture and it would be almost perfect if all of them were open source. Unfortunatelly, this is not the case. My goal was to improve the linux experience for the ordinary user who is not interested in political decisions. NVidia's and ATI's closed source drivers also come as easy-to-install packages for Fedora. And Linux Torvalds also does not let the kernel be a weapon in closed/open source wars. His arguments fit quite well here (and I agree with them): open software should be usable for any purpose, as long as it does not violate the license. I believe Linux would already be dead for a long time I it was used "against" closed source. Coexistance is crucial. What my patch does is just giving the user another option, how he can use a piece of software. -- Bye, Adalbert we're waiting for [the phone company] to fix that line From rc040203 at freenet.de Mon Sep 10 20:08:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 22:08:32 +0200 Subject: bodhi is broken: Message-ID: <1189454913.3157.43.camel@mccallum.corsepiu.local> Invoking https://admin.fedoraproject.org/updates/mine returns: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Powered by CherryPy 2.2.1 From rc040203 at freenet.de Mon Sep 10 20:11:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 22:11:36 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] Message-ID: <1189455097.3157.47.camel@mccallum.corsepiu.local> Something is very broken with the buildsystem, rel-eng's procedures or bodhi. Both packages have been built either days ago or earlier today: --- Package: perl-ExtUtils-AutoInstall-0.63-6.fc8 Tag: dist-f8 Status: complete Built by: corsepiu ID: 17859 Started: Wed, 05 Sep 2007 07:03:10 MST Finished: Wed, 05 Sep 2007 07:11:31 MST ---Package: perl-Set-IntSpan-1.12-1.fc8 Tag: dist-f8 Status: complete Built by: corsepiu ID: 18195 Started: Sun, 09 Sep 2007 22:00:37 MST Finished: Sun, 09 Sep 2007 22:04:27 MST Ralf -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Package EVR problems in Fedora 2007-09-10 Date: Mon, 10 Sep 2007 14:09:04 -0400 (EDT) Size: 1445 URL: From michel.sylvan at gmail.com Mon Sep 10 20:18:55 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 10 Sep 2007 16:18:55 -0400 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189455097.3157.47.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> Message-ID: On 10/09/2007, Ralf Corsepius wrote: > Something is very broken with the buildsystem, rel-eng's procedures or > bodhi. > > Both packages have been built either days ago or earlier today: > [snip] > perl-ExtUtils-AutoInstall > FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) > Note that this is even more broken: it's about a Fedora 7 package being out-of-date, but the EVR given has an FC6 tag! -- Michel From jeff at ocjtech.us Mon Sep 10 20:25:27 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 10 Sep 2007 15:25:27 -0500 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: References: <1189455097.3157.47.camel@mccallum.corsepiu.local> Message-ID: <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> On Mon, 2007-09-10 at 16:18 -0400, Michel Salim wrote: > On 10/09/2007, Ralf Corsepius wrote: > > Something is very broken with the buildsystem, rel-eng's procedures or > > bodhi. > > > > Both packages have been built either days ago or earlier today: > > > [snip] > > perl-ExtUtils-AutoInstall > > FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) > > > Note that this is even more broken: it's about a Fedora 7 package > being out-of-date, but the EVR given has an FC6 tag! Was the package ever rebuilt for F7? ISTR that not all of them were. That makes it possible for a package with a 'fc6' tag to show up in F7. It looks like 0.63-6 was built and pushed out on FC6 before the updated version on F7 got pushed into updates/updates-testing. 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 Sep 10 20:28:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 22:28:09 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> Message-ID: <1189456089.3157.52.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 15:25 -0500, Jeffrey C. Ollie wrote: > On Mon, 2007-09-10 at 16:18 -0400, Michel Salim wrote: > > On 10/09/2007, Ralf Corsepius wrote: > > > Something is very broken with the buildsystem, rel-eng's procedures or > > > bodhi. > > > > > > Both packages have been built either days ago or earlier today: > > > > > [snip] > > > perl-ExtUtils-AutoInstall > > > FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) > > > > > Note that this is even more broken: it's about a Fedora 7 package > > being out-of-date, but the EVR given has an FC6 tag! > > Was the package ever rebuilt for F7? Package: perl-ExtUtils-AutoInstall-0.63-6.fc7 Tag: dist-fc7-updates-candidate Status: complete Built by: corsepiu ID: 17860 Started: Wed, 05 Sep 2007 07:04:50 MST Finished: Wed, 05 Sep 2007 07:10:14 MST Ralf From rc040203 at freenet.de Mon Sep 10 20:29:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 22:29:28 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189456089.3157.52.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> Message-ID: <1189456168.3157.54.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 22:28 +0200, Ralf Corsepius wrote: > On Mon, 2007-09-10 at 15:25 -0500, Jeffrey C. Ollie wrote: > > On Mon, 2007-09-10 at 16:18 -0400, Michel Salim wrote: > > > On 10/09/2007, Ralf Corsepius wrote: > > > > Something is very broken with the buildsystem, rel-eng's procedures or > > > > bodhi. > > > > > > > > Both packages have been built either days ago or earlier today: > > > > > > > [snip] > > > > perl-ExtUtils-AutoInstall > > > > FE6 > F7 (0:0.63-6.fc6 > 0:0.63-5.fc6) > > > > > > > Note that this is even more broken: it's about a Fedora 7 package > > > being out-of-date, but the EVR given has an FC6 tag! > > > > Was the package ever rebuilt for F7? > > Package: perl-ExtUtils-AutoInstall-0.63-6.fc7 > Tag: dist-fc7-updates-candidate > Status: complete > Built by: corsepiu > ID: 17860 > Started: Wed, 05 Sep 2007 07:04:50 MST > Finished: Wed, 05 Sep 2007 07:10:14 MST And push request'ed: corsepiu has submitted a new update for Fedora 7 ================================================================================ perl-ExtUtils-AutoInstall-0.63-6.fc7 ================================================================================ Release: Fedora 7 Status: pending Type: bugfix Submitter: corsepiu Submitted: 2007-09-05 16:26:09 Ralf From jkeating at redhat.com Mon Sep 10 20:38:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Sep 2007 16:38:21 -0400 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189456168.3157.54.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> Message-ID: <20070910163821.278c794e@mentok.boston.redhat.com> On Mon, 10 Sep 2007 22:29:28 +0200 Ralf Corsepius wrote: > And push request'ed: > > corsepiu has submitted a new update for Fedora 7 > > ================================================================================ > perl-ExtUtils-AutoInstall-0.63-6.fc7 > ================================================================================ > Release: Fedora 7 > Status: pending > Type: bugfix > Submitter: corsepiu > Submitted: 2007-09-05 16:26:09 You neither pushed it to Testing nor stable. perl-ExtUtils-AutoInstall-0.63-6.fc7 [ Push to Testing | Push to Stable | Delete | Edit ] -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Sep 10 21:05:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 23:05:36 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <20070910163821.278c794e@mentok.boston.redhat.com> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> Message-ID: <1189458336.3157.62.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 16:38 -0400, Jesse Keating wrote: > On Mon, 10 Sep 2007 22:29:28 +0200 > Ralf Corsepius wrote: > > > And push request'ed: > > > > corsepiu has submitted a new update for Fedora 7 > > > > ================================================================================ > > perl-ExtUtils-AutoInstall-0.63-6.fc7 > > ================================================================================ > > Release: Fedora 7 > > Status: pending > > Type: bugfix > > Submitter: corsepiu > > Submitted: 2007-09-05 16:26:09 > > > You neither pushed it to Testing nor stable. I don't know if I pushed this package to stable or not, or if I lost in the bodhi's usability swamp. But then you also might be able to explain this: perl-Set-IntSpan F7-updates > F8 (0:1.12-1.fc7 > 0:1.11-1.fc7) Package: perl-Set-IntSpan-1.12-1.fc8 Tag: dist-f8 Status: complete Built by: corsepiu ID: 18195 Started: Sun, 09 Sep 2007 22:00:37 MST Finished: Sun, 09 Sep 2007 22:04:27 MST This is FC8 - my built predates your complaint by almost a day. Ralf -- Don't cage Fedora. Maintainers, just say no to acls. From jwboyer at jdub.homelinux.org Mon Sep 10 21:09:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 10 Sep 2007 16:09:56 -0500 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189458336.3157.62.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> Message-ID: <20070910160956.11a910de@weaponx.rchland.ibm.com> On Mon, 10 Sep 2007 23:05:36 +0200 Ralf Corsepius wrote: > On Mon, 2007-09-10 at 16:38 -0400, Jesse Keating wrote: > > On Mon, 10 Sep 2007 22:29:28 +0200 > > Ralf Corsepius wrote: > > > > > And push request'ed: > > > > > > corsepiu has submitted a new update for Fedora 7 > > > > > > ================================================================================ > > > perl-ExtUtils-AutoInstall-0.63-6.fc7 > > > ================================================================================ > > > Release: Fedora 7 > > > Status: pending > > > Type: bugfix > > > Submitter: corsepiu > > > Submitted: 2007-09-05 16:26:09 > > > > > > You neither pushed it to Testing nor stable. > I don't know if I pushed this package to stable or not, or if I lost in > the bodhi's usability swamp. > > > But then you also might be able to explain this: > > perl-Set-IntSpan > F7-updates > F8 (0:1.12-1.fc7 > 0:1.11-1.fc7) > > Package: perl-Set-IntSpan-1.12-1.fc8 > Tag: dist-f8 > Status: complete > Built by: corsepiu > ID: 18195 > Started: Sun, 09 Sep 2007 22:00:37 MST > Finished: Sun, 09 Sep 2007 22:04:27 MST > > This is FC8 - my built predates your complaint by almost a day. rawhide was composed from the dist-rawhide tag, not dist-f8. Basically, I think this was held up by the test2 freeze. josh From g at socallinuxexpo.org Mon Sep 10 21:23:11 2007 From: g at socallinuxexpo.org (Gareth J. Greenaway) Date: Mon, 10 Sep 2007 14:23:11 -0700 Subject: SCALE 6x Gears Up Message-ID: <200709101423.11236.g@socallinuxexpo.org> The Sixth Annual SoCal Linux Expo will be February 8th-10th, 2008. It will again be at the Westin LAX. SCALE has reserved more of the hotel resources for SCALE 6X which will help address some of the seminar crowding issues that arose during S5X (success is a nice problem to have). Over the last two SCALEs, the Expo has expanded to included specialized conferences on the Friday prior to SCALE. The Expo will ?expand upon the expansion? for SCALE 6x: the Women in Open Source conference will return for its second year; the health care conference, now knows as DOHCS ? Demonstrating Open Source Health Care Systems, returns for a second time. Last year DOHCS was a single track. For SCALE 6X, DOHCS splits into two tracks, a technical track and a business track. And newly added for SCALE 6X is a Friday conference on education: ?Open Source in Education? which focuses on opportunities for Open Source in the field of education . If you have any experience in any of the above-mentioned areas, please consider sharing it with the Open Source community at SCALE: the calls for papers for SCALE and for the Friday conferences can be found here: http://www.socallinuxexpo.org/scale6x/conference-info/calls-for-papers/ All of the calls are now open for submittals. For SCALE 4X and 5X the speaker slots filled rapidly; we anticipate the same for SCALE 6X. So if you're considering speaking, don't delay submitting your proposal. Submittal info for each conference can be found on their respective CFP pages. If your organization is considering a booth on the SCALE Expo floor, be advised that we no more booths than last year, and last year they went quickly. If you want to ensure that you have a booth reserved, apply for one NOW. If you're a non-profit group, complete the application form at http://www.socallinuxexpo.org/scale6x/documents/scale6x_dotORG_application.pdf and send it to gareth at socallinuxexpo.org The second SCALE IRC chat will be September 16th , at 7:00 pm PST. It will be held in the #scale-chat channel of OFTC (irc.oftc.net). If you have questions or comments about SCALE, feel free to join us. SCALE 6X looks to be even better than S5X; mark your calendar ? be in Los Angeles February 8th-10th , 2008! -- Gareth J. Greenaway | g at socallinuxexpo.org Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org From lmacken at redhat.com Mon Sep 10 21:17:49 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 10 Sep 2007 17:17:49 -0400 Subject: bodhi is broken: In-Reply-To: <1189454913.3157.43.camel@mccallum.corsepiu.local> References: <1189454913.3157.43.camel@mccallum.corsepiu.local> Message-ID: <20070910211748.GB15866@crow.redhat.com> On Mon, Sep 10, 2007 at 10:08:32PM +0200, Ralf Corsepius wrote: > Invoking https://admin.fedoraproject.org/updates/mine > returns: > > 500 Internal error > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > Powered by CherryPy 2.2.1 Interesting... looks like a character in your display name is causing some explosions. File "/srv/tg/bodhi/bodhi/util.py", line 105, in displayname return fixEncoding('%s <%s>' % (identity.current.user.display_name, File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1576, in fixEncoding return value.decode('utf8').encode('utf8') File "/usr/lib64/python2.4/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 9: ordinal not in range(128) I'm looking into it... luke From rc040203 at freenet.de Mon Sep 10 21:44:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Sep 2007 23:44:51 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <20070910160956.11a910de@weaponx.rchland.ibm.com> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> Message-ID: <1189460692.3157.71.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 16:09 -0500, Josh Boyer wrote: > On Mon, 10 Sep 2007 23:05:36 +0200 > Ralf Corsepius wrote: > > > On Mon, 2007-09-10 at 16:38 -0400, Jesse Keating wrote: > > > On Mon, 10 Sep 2007 22:29:28 +0200 > > > Ralf Corsepius wrote: > > > > > > > And push request'ed: > > > > > > > > corsepiu has submitted a new update for Fedora 7 > > > > > > > > ================================================================================ > > > > perl-ExtUtils-AutoInstall-0.63-6.fc7 > > > > ================================================================================ > > > > Release: Fedora 7 > > > > Status: pending > > > > Type: bugfix > > > > Submitter: corsepiu > > > > Submitted: 2007-09-05 16:26:09 > > > > > > > > > You neither pushed it to Testing nor stable. > > I don't know if I pushed this package to stable or not, or if I lost in > > the bodhi's usability swamp. > > > > > > But then you also might be able to explain this: > > > > perl-Set-IntSpan > > F7-updates > F8 (0:1.12-1.fc7 > 0:1.11-1.fc7) > > > > Package: perl-Set-IntSpan-1.12-1.fc8 > > Tag: dist-f8 > > Status: complete > > Built by: corsepiu > > ID: 18195 > > Started: Sun, 09 Sep 2007 22:00:37 MST > > Finished: Sun, 09 Sep 2007 22:04:27 MST > > > > This is FC8 - my built predates your complaint by almost a day. > > rawhide was composed from the dist-rawhide tag, not dist-f8. > Basically, I think this was held up by the test2 freeze. Great, ... :/ in other words, the freeze breaks rawhide? Ralf From jwboyer at jdub.homelinux.org Mon Sep 10 21:52:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 10 Sep 2007 16:52:21 -0500 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189460692.3157.71.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> Message-ID: <20070910165221.3bfec415@weaponx.rchland.ibm.com> On Mon, 10 Sep 2007 23:44:51 +0200 Ralf Corsepius wrote: > > > > > > This is FC8 - my built predates your complaint by almost a day. > > > > rawhide was composed from the dist-rawhide tag, not dist-f8. > > Basically, I think this was held up by the test2 freeze. > > Great, ... :/ > > in other words, the freeze breaks rawhide? Or it means you didn't follow the freeze process. Again. josh From rc040203 at freenet.de Mon Sep 10 22:05:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Sep 2007 00:05:52 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <20070910165221.3bfec415@weaponx.rchland.ibm.com> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> Message-ID: <1189461952.3157.84.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 16:52 -0500, Josh Boyer wrote: > On Mon, 10 Sep 2007 23:44:51 +0200 > Ralf Corsepius wrote: > > > > > > > > > This is FC8 - my built predates your complaint by almost a day. > > > > > > rawhide was composed from the dist-rawhide tag, not dist-f8. > > > Basically, I think this was held up by the test2 freeze. > > > > Great, ... :/ > > > > in other words, the freeze breaks rawhide? > > Or it means you didn't follow the freeze process. Again. C'mon, what you say is really ridiculous and embarrassing. Nothing (neither CVS, nor bodhi, nor koji) prevented me (nor anybody else amongst the dozens of other folks having done the same) from submitting, building nor pushing packages ... So I conclude, you actually mean bodhi's unusability and rel-eng's broken procedures start to show effect ... as usual during the final phases of release preps. You simply deny the brokenness of your procedures. Ralf -- Don't cage Fedora. Maintainers, just say no to acls. From mschwendt.tmp0701.nospam at arcor.de Mon Sep 10 22:14:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 00:14:32 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189461952.3157.84.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> <1189461952.3157.84.camel@mccallum.corsepiu.local> Message-ID: <20070911001432.02c2bfa5.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Sep 2007 00:05:52 +0200, Ralf Corsepius wrote: > On Mon, 2007-09-10 at 16:52 -0500, Josh Boyer wrote: > > On Mon, 10 Sep 2007 23:44:51 +0200 > > Ralf Corsepius wrote: > > > > > > > > > > > > This is FC8 - my built predates your complaint by almost a day. > > > > > > > > rawhide was composed from the dist-rawhide tag, not dist-f8. > > > > Basically, I think this was held up by the test2 freeze. > > > > > > Great, ... :/ > > > > > > in other words, the freeze breaks rawhide? > > > > Or it means you didn't follow the freeze process. Again. > C'mon, what you say is really ridiculous and embarrassing. > > Nothing (neither CVS, nor bodhi, nor koji) prevented me (nor anybody > else amongst the dozens of other folks having done the same) from > submitting, building nor pushing packages ... > > So I conclude, you actually mean bodhi's unusability and rel-eng's > broken procedures start to show effect ... as usual during the final > phases of release preps. You simply deny the brokenness of your > procedures. Ralf, http://katzj.livejournal.com/405215.html ;) From rc040203 at freenet.de Mon Sep 10 22:20:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Sep 2007 00:20:29 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <20070911001432.02c2bfa5.mschwendt.tmp0701.nospam@arcor.de> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> <1189461952.3157.84.camel@mccallum.corsepiu.local> <20070911001432.02c2bfa5.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1189462829.3157.96.camel@mccallum.corsepiu.local> On Tue, 2007-09-11 at 00:14 +0200, Michael Schwendt wrote: > On Tue, 11 Sep 2007 00:05:52 +0200, Ralf Corsepius wrote: > > > On Mon, 2007-09-10 at 16:52 -0500, Josh Boyer wrote: > > > On Mon, 10 Sep 2007 23:44:51 +0200 > > > Ralf Corsepius wrote: > > > > > > > > > > > > > > > This is FC8 - my built predates your complaint by almost a day. > > > > > > > > > > rawhide was composed from the dist-rawhide tag, not dist-f8. > > > > > Basically, I think this was held up by the test2 freeze. > > > > > > > > Great, ... :/ > > > > > > > > in other words, the freeze breaks rawhide? > > > > > > Or it means you didn't follow the freeze process. Again. > > C'mon, what you say is really ridiculous and embarrassing. > > > > Nothing (neither CVS, nor bodhi, nor koji) prevented me (nor anybody > > else amongst the dozens of other folks having done the same) from > > submitting, building nor pushing packages ... > > > > So I conclude, you actually mean bodhi's unusability and rel-eng's > > broken procedures start to show effect ... as usual during the final > > phases of release preps. You simply deny the brokenness of your > > procedures. > > Ralf, > > http://katzj.livejournal.com/405215.html Well, at least a glimpse of insight ... ... leaves the immaturity of the infrastructure which pees at volunteers by sending unjustified complaints, if you want to have it "bluntly". Ralf From adalbert.prokop at gmx.de Mon Sep 10 22:27:34 2007 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Tue, 11 Sep 2007 00:27:34 +0200 Subject: Enhancement proposal for Firefox In-Reply-To: <46E569EB.70405@redhat.com> References: <200709100009.42098.adalbert.prokop@gmx.de> <46E569EB.70405@redhat.com> Message-ID: <200709110027.34651.adalbert.prokop@gmx.de> Christopher Aillon schrieb am Montag, 10. September 2007: Hi Christopher! > > 1. Give the user the choice which version of Firefox is started, > > especially on 64-bit architectures. > You should look into playing with nspluginwrapper. I already stumbled over this project. :-) The flash and AcrobatReader can be wrapped. But then there is still a big piece missing: Java. GCC-Java has not matured far enough. Sun does not provide a 64 bit plugin. (I was very astonished about it...) And Blackdown has only Java 1.4.2 which crashed Firefox repeatable when surfing on www.map24.de. So which options does one have under such cicumstances? :-) -- bye, Adalbert There but for the grace of God, goes God. -- Winston Churchill, speaking of Sir Stafford Cripps. From lmacken at redhat.com Tue Sep 11 00:04:34 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 10 Sep 2007 20:04:34 -0400 Subject: bodhi is broken: In-Reply-To: <1189454913.3157.43.camel@mccallum.corsepiu.local> References: <1189454913.3157.43.camel@mccallum.corsepiu.local> Message-ID: <20070911000434.GA18809@crow.myhome.westell.com> On Mon, Sep 10, 2007 at 10:08:32PM +0200, Ralf Corsepius wrote: > Invoking https://admin.fedoraproject.org/updates/mine > returns: > > 500 Internal error > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > Powered by CherryPy 2.2.1 Hey Ralf, Please try again, this issue should hopefully be fixed. Sorry for the inconvenience. luke From myfedora at richip.dhs.org Tue Sep 11 00:18:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 10 Sep 2007 18:18:58 -0600 Subject: Enhancement proposal for Firefox In-Reply-To: <200709110027.34651.adalbert.prokop@gmx.de> References: <200709100009.42098.adalbert.prokop@gmx.de> <46E569EB.70405@redhat.com> <200709110027.34651.adalbert.prokop@gmx.de> Message-ID: <1189469938.13490.2.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 00:27 +0200, Adalbert Prokop wrote: > > You should look into playing with nspluginwrapper. > > I already stumbled over this project. :-) The flash and AcrobatReader can > be wrapped. But then there is still a big piece missing: Java. > > GCC-Java has not matured far enough. Sun does not provide a 64 bit plugin. > (I was very astonished about it...) And Blackdown has only Java 1.4.2 > which crashed Firefox repeatable when surfing on www.map24.de. > > So which options does one have under such cicumstances? :-) # yum --enablerepo=development install java-1.7.0-icedtea-plugin and report any bugs to http://icedtea.classpath.org/bugzilla/ ! -- Richi Plana From rc040203 at freenet.de Tue Sep 11 00:26:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Sep 2007 02:26:07 +0200 Subject: bodhi is broken: In-Reply-To: <20070911000434.GA18809@crow.myhome.westell.com> References: <1189454913.3157.43.camel@mccallum.corsepiu.local> <20070911000434.GA18809@crow.myhome.westell.com> Message-ID: <1189470367.3157.120.camel@mccallum.corsepiu.local> On Mon, 2007-09-10 at 20:04 -0400, Luke Macken wrote: > On Mon, Sep 10, 2007 at 10:08:32PM +0200, Ralf Corsepius wrote: > > Invoking https://admin.fedoraproject.org/updates/mine > > returns: > > > > 500 Internal error > > The server encountered an unexpected condition which prevented it from > > fulfilling the request. > > > > Powered by CherryPy 2.2.1 > > Hey Ralf, > > Please try again, this issue should hopefully be fixed. Sorry for the > inconvenience. Seems to be functional, now. Thanks for the promptly response. Ralf From mcepl at redhat.com Sun Sep 9 14:29:32 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 09 Sep 2007 16:29:32 +0200 Subject: Aggregation upstream projects are BAD (kdesdk for example) References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: On 2007-09-09, 13:18 GMT, Michel Salim wrote: >> > Since on of Fedora's strenghts is being always up to date >> > with the latest upstream versions, I think using these kind >> > of upstream aggregation projects is a BAD idea as it creates >> > interlocks with regards to versions between clearly seperate >> > projects like kdesdk and umbrello. > > Ditto, though in this case, umbrello happens to *also* be part of kdesdk: This is the situation for all KDE programs -- KDE team in Fedora is apparently so small that they managed to do anything else than just repackaging upstream tarballs (I don't know more about that being GNOMEr, but I have certainly nothing against KDE -- I would use it myself, if not being employed in RH desktop team). You had problem with umbrello, but exactly the same situation is with kmail, knode, and others. See this example: [root at viklef ~]# yum list kmail knode konqueror konsole kwrite \ kword koffice kspread kopete updates-testing 100% |=========================| 1.9 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 adobe-linux-i386 100% |=========================| 951 B 00:00 fedora-debuginfo 100% |=========================| 1.9 kB 00:00 updates-testing-debuginfo 100% |=========================| 1.9 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 texlive 100% |=========================| 951 B 00:00 Error: No matching Packages to list [root at viklef ~]# Of course, it would be nice to create kmail as a subpackage of kdepim (as it is done in Debian -- http://packages.debian.org/sarge/kmail is a subpackage of source package kdepim -- see "Source" label on the top of the page), but I am afraid it would be asking KDE team to do more work than they are able to do. Best, Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 From ndbecker2 at gmail.com Mon Sep 10 11:11:01 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 10 Sep 2007 07:11:01 -0400 Subject: dkms - should I use it? References: Message-ID: I see dkms is now in fedora. Does this mean fedora now blesses it's use? I'd like to submit a package to use it. From rdieter at math.unl.edu Mon Sep 10 11:22:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Sep 2007 06:22:37 -0500 Subject: Making the xine-lib-extras nondependent on xine-lib-arts? References: <1189286936.3143.20.camel@pc-notebook> Message-ID: Martin Sourada wrote: > I noticed one thing that cheered me up a bit - splitting of > xine-lib-arts from xine-lib-extras. Well, but the problem is that > xine-lib-extras, which has a set of useful plugins like support for > pulseaudio Since pulseaudio is planned to be the default setup, it should (imo) go in either the main xine-lib pkg or in it's own subpkg as well (and be installed by default). -- Rex From ndbecker2 at gmail.com Mon Sep 10 11:11:01 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 10 Sep 2007 07:11:01 -0400 Subject: dkms - should I use it? References: Message-ID: I see dkms is now in fedora. Does this mean fedora now blesses it's use? I'd like to submit a package to use it. From sundaram at fedoraproject.org Tue Sep 11 04:12:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 11 Sep 2007 09:42:08 +0530 Subject: dkms - should I use it? In-Reply-To: References: Message-ID: <46E61598.9060608@fedoraproject.org> Neal Becker wrote: > I see dkms is now in fedora. Does this mean fedora now blesses it's use? > I'd like to submit a package to use it. DKMS has been available in Fedora for a long time. The curent kernel modules guidelines doesn't use it and there is a proposal to get rid of separate kernel modules entirely and patch the kernel package directly if needed. What is the module you are thinking of packaging? Rahul From halfline at gmail.com Tue Sep 11 05:05:58 2007 From: halfline at gmail.com (Ray Strode) Date: Tue, 11 Sep 2007 01:05:58 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <46E29FC6.4090103@hhs.nl> References: <46E29FC6.4090103@hhs.nl> Message-ID: <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> Hi, > But then I got a comment to the review it was already in Fedora in kdesdk. But > then why on earth doesn't kdesdk have a Provides umbrello so that yum install > umbrello works? So one cool feature I learned about a while ago (that you may already know about) with yum is you can do yum install /usr/bin/umbrello or whatever the full path to the program is, and it will automatically grab the right package. Of course, that feature is only useful if you already know the name of the binary, and where it's getting installed to. > Also I think it is a very bad idea to ship packages with a clearly seperate > upstream in some kinda bundle form. Couldn't agree more. For a while we shipped gcalctool and zenity in gnome-utils. it was a maintainability nightmare. --Ray From ville.skytta at iki.fi Tue Sep 11 06:37:29 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 11 Sep 2007 09:37:29 +0300 Subject: Making the xine-lib-extras nondependent on xine-lib-arts? In-Reply-To: References: <1189286936.3143.20.camel@pc-notebook> Message-ID: <200709110937.29935.ville.skytta@iki.fi> On Monday 10 September 2007, Rex Dieter wrote: > Martin Sourada wrote: > > I noticed one thing that cheered me up a bit - splitting of > > xine-lib-arts from xine-lib-extras. Well, but the problem is that > > xine-lib-extras, which has a set of useful plugins like support for > > pulseaudio > > Since pulseaudio is planned to be the default setup, it should (imo) go in > either the main xine-lib pkg or in it's own subpkg as well (and be > installed by default). I asked about that a while ago, but Lennart didn't think it's a good idea at the moment so I left it in -extras. http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01411.html From j.w.r.degoede at hhs.nl Tue Sep 11 06:38:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Sep 2007 08:38:19 +0200 Subject: Announcing rpmfusion Message-ID: <46E637DB.6060102@hhs.nl> The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project. RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux. We don't have a repository ready for end users yet, but we are actively working on merging the following ones: * http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/ We will have two distinct repositories: free and non-free. Free will contain Open Source Software (as defined by the Fedora Packaging Guidelines) which can't be included in Fedora -- for example because it might be patent encumbered in the US. Non-free will contain everything else which is not free software (as defined by the Fedora Licensing Guidelines), like software with public available source-code that has "no commercial use" restrictions or the graphics drivers from AMD and Nvidia. Repositories and infrastructure will follow Fedora where possible. This means using Fedora's packaging guidelines (except for legal), Fedora's review process for new submissions, Fedora's VCS structure etc. It will contain add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/CentOS + EPEL or Fedora (Fedora 7+). It will contain kernel module packages in the main repo, even if Fedora will drop them (which looks likely as of August 2007). We aim to provide support for all 'current' versions of Fedora including devel, for i386, ppc, ppc64 and x86_64. We hope to attract new Fedora packagers and many other 3rd party repositories. Please join our mailing list at: http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion From sundaram at fedoraproject.org Tue Sep 11 07:05:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 11 Sep 2007 12:35:05 +0530 Subject: Announcing rpmfusion In-Reply-To: <46E637DB.6060102@hhs.nl> References: <46E637DB.6060102@hhs.nl> Message-ID: <46E63E21.8020305@fedoraproject.org> Hans de Goede wrote: > The Dribble, Freshrpms and Livna teams, already joined by some Fedora > contributors, are proud to announce the RPM Fusion project. > > RPM Fusion aims to bring together many packagers from various 3rd party > repos and build a single add-on repository for Fedora and Red Hat > Enterprise Linux. > > We don't have a repository ready for end users yet, but we are actively > working on merging the following ones: > > * http://dribble.org.uk/ > * http://freshrpms.net/ > * http://rpm.livna.org/ Though not within the Fedora official structure, merging these throws away one of the major points for end users in Fedora. Congrats on this effort. Noticeably missing is ATrpms however. > We will have two distinct repositories: free and non-free. Free will > contain Open Source Software (as defined by the Fedora Packaging > Guidelines) which can't be included in Fedora -- for example because it > might be patent encumbered in the US. Non-free will contain everything > else which is not free software (as defined by the Fedora Licensing > Guidelines), like software with public available source-code that has > "no commercial use" restrictions or the graphics drivers from AMD and > Nvidia. Thanks for this split. Hopefully we will able to link to the free part from within Fedora. Rahul From j.w.r.degoede at hhs.nl Tue Sep 11 07:16:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Sep 2007 09:16:07 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E63E21.8020305@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> Message-ID: <46E640B7.4030803@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> We don't have a repository ready for end users yet, but we are >> actively working on merging the following ones: >> >> * http://dribble.org.uk/ >> * http://freshrpms.net/ >> * http://rpm.livna.org/ > > Noticeably missing is ATrpms however. ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring. Regards, Hans From opensource at till.name Tue Sep 11 08:45:02 2007 From: opensource at till.name (Till Maas) Date: Tue, 11 Sep 2007 10:45:02 +0200 Subject: Exclude Requires for some archs Message-ID: <200709111045.03218.opensource@till.name> Hiyas, I want to use %ifnarch ppc ppc64 Requires: vbetool %endif in a package, which should work according to maximum rpm[1] and was suggested by Mamoru Tasaka. Nevertheless koji does not want to build[2] this for ppc(64) because of a missing vbetool. Does someone spot the error in the spec[3]? Regards, Till [1] http://www.rpm.org/max-rpm/s1-rpm-inside-conditionals.html [2] http://koji.fedoraproject.org/koji/getfile?taskID=155137&name=root.log [3] http://cvs.fedoraproject.org/viewcvs/rpms/pm-utils/devel/pm-utils.spec?rev=1.79&view=markup -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mschwendt.tmp0701.nospam at arcor.de Tue Sep 11 09:00:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 11:00:40 +0200 Subject: Exclude Requires for some archs In-Reply-To: <200709111045.03218.opensource@till.name> References: <200709111045.03218.opensource@till.name> Message-ID: <20070911110040.799f442b.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Sep 2007 10:45:02 +0200, Till Maas wrote: > Hiyas, > > I want to use > %ifnarch ppc ppc64 > Requires: vbetool > %endif > in a package, which should work according to maximum rpm[1] and was suggested > by Mamoru Tasaka. Nevertheless koji does not want to build[2] this for > ppc(64) because of a missing vbetool. Does someone spot the error in the > spec[3]? ifnarch does not work with a set of archs (like ifarch does). Don't read it like "if arch NOT in [ppc,ppc64]", but like "if arch NOT equal to ppc" (a single value only!). So, in your spec, when the targetarch is ppc, your %ifnarch holds true because ppc!=ppc64, and when the targetarch is ppc64, it holds true because ppc64!=ppc. From mschwendt.tmp0701.nospam at arcor.de Tue Sep 11 09:12:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 11:12:40 +0200 Subject: Exclude Requires for some archs In-Reply-To: <20070911110040.799f442b.mschwendt.tmp0701.nospam@arcor.de> References: <200709111045.03218.opensource@till.name> <20070911110040.799f442b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070911111240.0bbf0f1a.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Sep 2007 11:00:40 +0200, Michael Schwendt wrote: > On Tue, 11 Sep 2007 10:45:02 +0200, Till Maas wrote: > > > Hiyas, > > > > I want to use > > %ifnarch ppc ppc64 > > Requires: vbetool > > %endif > > in a package, which should work according to maximum rpm[1] and was suggested > > by Mamoru Tasaka. Nevertheless koji does not want to build[2] this for > > ppc(64) because of a missing vbetool. Does someone spot the error in the > > spec[3]? > > ifnarch does not work with a set of archs (like ifarch does). Don't > read it like "if arch NOT in [ppc,ppc64]", but like "if arch NOT equal > to ppc" (a single value only!). So, in your spec, when the targetarch > is ppc, your %ifnarch holds true because ppc!=ppc64, and when the > targetarch is ppc64, it holds true because ppc64!=ppc. Hmm, scratch that. I have the feeling I've mixed it up with something else. %ifnarch should really be "NOT %ifarch". From mschwendt.tmp0701.nospam at arcor.de Tue Sep 11 09:23:17 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 11:23:17 +0200 Subject: Circular dep - Re: Exclude Requires for some archs In-Reply-To: <200709111045.03218.opensource@till.name> References: <200709111045.03218.opensource@till.name> Message-ID: <20070911112317.303ee0fa.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Sep 2007 10:45:02 +0200, Till Maas wrote: > Hiyas, > > I want to use > %ifnarch ppc ppc64 > Requires: vbetool > %endif > in a package, which should work according to maximum rpm[1] and was suggested > by Mamoru Tasaka. Nevertheless koji does not want to build[2] this for > ppc(64) because of a missing vbetool. Does someone spot the error in the > spec[3]? > > Regards, > Till > > [1] http://www.rpm.org/max-rpm/s1-rpm-inside-conditionals.html > [2] http://koji.fedoraproject.org/koji/getfile?taskID=155137&name=root.log There's a circular dep on pm-utils when building pm-utils. See bottom of the previous build-job by Peter Jones for pm-utils-0.99.4-1.fc8.src.rpm http://koji.fedoraproject.org/koji/getfile?taskID=154848&name=root.log ... pciutils ppc64 2.2.6-3.fc8 core 89 k pm-utils ppc64 0.99.3-11.fc8 core 27 k procps ppc64 3.2.7-16.1.fc8 core 225 k ... The change with added Requires: vbetool was in post 0.99.3-12.fc8 cvs. So, the pm-utils in the buildroots requires vbetools for all archs, and build pm-utils requires pm-utils. > [3] > http://cvs.fedoraproject.org/viewcvs/rpms/pm-utils/devel/pm-utils.spec?rev=1.79&view=markup > From opensource at till.name Tue Sep 11 08:58:50 2007 From: opensource at till.name (Till Maas) Date: Tue, 11 Sep 2007 10:58:50 +0200 Subject: Exclude Requires for some archs In-Reply-To: <200709111045.03218.opensource@till.name> References: <200709111045.03218.opensource@till.name> Message-ID: <200709111058.51088.opensource@till.name> On Di September 11 2007, Till Maas wrote: > this for ppc(64) because of a missing vbetool. Does someone spot the error > in the spec[3]? The problem is that pm-utils BRs itself via hal-devel, Mamoru Tasaka is the genius who found this out. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 11 09:26:16 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 11 Sep 2007 18:26:16 +0900 Subject: Exclude Requires for some archs In-Reply-To: <20070911111240.0bbf0f1a.mschwendt.tmp0701.nospam@arcor.de> References: <200709111045.03218.opensource@till.name> <20070911110040.799f442b.mschwendt.tmp0701.nospam@arcor.de> <20070911111240.0bbf0f1a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46E65F38.7090600@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 09/11/2007 06:12 PM +9:00: > On Tue, 11 Sep 2007 11:00:40 +0200, Michael Schwendt wrote: > >> On Tue, 11 Sep 2007 10:45:02 +0200, Till Maas wrote: >> >>> Hiyas, >>> >>> I want to use >>> %ifnarch ppc ppc64 >>> Requires: vbetool >>> %endif >>> in a package, which should work according to maximum rpm[1] and was suggested >>> by Mamoru Tasaka. Nevertheless koji does not want to build[2] this for >>> ppc(64) because of a missing vbetool. Does someone spot the error in the >>> spec[3]? >> ifnarch does not work with a set of archs (like ifarch does). Don't >> read it like "if arch NOT in [ppc,ppc64]", but like "if arch NOT equal >> to ppc" (a single value only!). So, in your spec, when the targetarch >> is ppc, your %ifnarch holds true because ppc!=ppc64, and when the >> targetarch is ppc64, it holds true because ppc64!=ppc. > > Hmm, scratch that. I have the feeling I've mixed it up with something > else. %ifnarch should really be "NOT %ifarch". > Note: pm-utils dependency problem for vbetool commented here is actually not due to the usage of %ifnarch (bug 285361) Regards, Mamoru From buildsys at redhat.com Tue Sep 11 10:22:34 2007 From: buildsys at redhat.com (Build System) Date: Tue, 11 Sep 2007 06:22:34 -0400 Subject: rawhide report: 20070911 changes Message-ID: <200709111022.l8BAMYpg013872@porkchop.devel.redhat.com> New package filezilla FileZilla FTP, FTPS and SFTP client New package gnome-web-photo HTML pages thumbnailer New package hedgewars 2D tankbattle game with the tanks replaced by hedgehogs New package isync Tool to synchronize IMAP4 and Maildir mailboxes New package radeontool Backlight and video output configuration tool for radeon cards New package vbetool Run real-mode video BIOS code to alter hardware state Updated Packages: TeXmacs-1.0.6.11-1.fc8 ---------------------- * Mon Sep 10 2007 Gerard Milmeister - 1.0.6.11-1 - new release 1.0.6.11 * Fri Jun 29 2007 Gerard Milmeister - 1.0.6.10-3 - ps generation fix * Mon May 14 2007 Gerard Milmeister - 1.0.6.10-1 - new version 1.0.6.10 aspell-bn-0.01.1-2.fc8 ---------------------- aspell-gu-0.02-2.fc8 -------------------- aspell-hi-0.01-2.fc8 -------------------- aspell-mr-0.10-2.fc8 -------------------- aspell-or-0.03-2.fc8 -------------------- aspell-pa-0.01-2.fc8 -------------------- aspell-ta-20040424-2.fc8 ------------------------ aspell-te-0.01-2.fc8 -------------------- bzflag-2.0.8-6.fc8 ------------------ * Wed Sep 05 2007 Nils Philippsen 2.0.8-6 - change license tag from LGPL to LGPLv2 * Fri Jun 22 2007 Nils Philippsen - change license tag from GPL to LGPL * Mon Nov 06 2006 Jindrich Novy 2.0.8-4 - rebuild because of the new curl claws-mail-plugins-3.0.0-1.fc8 ------------------------------ * Wed Sep 05 2007 Andreas Bierfert - 3.0.0 - version upgrade curl-7.16.4-6.fc8 ----------------- * Mon Sep 10 2007 Jindrich Novy 7.16.4-6 - provide webclient (#225671) dhcp-12:3.0.6-5.fc8 ------------------- * Mon Sep 10 2007 David Cantrell - 12:3.0.6-5 - Fix typos in ldap.c and correct LDAP macros (#283391) * Tue Sep 04 2007 David Cantrell - 12:3.0.6-4 - Do not override manually configured NTP servers in /etc/ntp.conf (#274761) * Wed Aug 15 2007 David Cantrell - 12:3.0.6-3 - Remove the -x switch enabling extended new option info. If given to dhclient now, it's ignored. dhcpv6-0.10-50.fc8 ------------------ * Mon Sep 10 2007 David Cantrell - 0.10-50 - Fix more segfaults when dhcp6s starts with empty control files (#253968) * Mon Sep 10 2007 David Cantrell - 0.10-49 - Make dhcp6r and dhcp6s init scripts conform to Fedora guidelines (#246909) - Let dhcp6c ignore reply msgs that contain IA_NA with T1 > T2 (#254194) - In dhcp6c, do not remove leases no on the updated list (#265761) - Retransmit confirm message in expected duration in dhcp6c (#251192) - Store correct value to elapsed time option in solicit msg (#249451) - Reassign IPv6 global address after confirm/reply msg in dhcp6c (#249466) * Mon Sep 10 2007 David Cantrell - 0.10-48 - Recognize 802.1Q VLAN network device names (#245115) eclipse-1:3.3.0-19.fc8 ---------------------- * Mon Sep 10 2007 Andrew Overholt 3.3.0-19 - Don't require subclipse, cdt, or rpm-editor on ppc64. * Fri Sep 07 2007 Ben Konrath 3.3.0-18 - Build 1.6 plugins when building with IcedTea. * Fri Sep 07 2007 Ben Konrath 3.3.0-17 - Update Fedora Eclipse product plugin to fix Welcome page. firefox-2.0.0.6-7.fc8 --------------------- * Mon Sep 10 2007 Martin Stransky 2.0.0.6-7 - added fix for #246248 - firefox crashes when searching for word "do" flac-1.2.0-1.fc8 ---------------- * Mon Sep 10 2007 - Bastien Nocera - 1.2.0 - Update for 1.20 and drop obsolete patches (#285161) fvwm-2.5.23-2.fc8 ----------------- * Mon Sep 10 2007 Adam Goode - 2.5.23-2 - Don't add gnome-libs-devel to BR (not on ppc64?) * Mon Sep 10 2007 Adam Goode - 2.5.23-1 - New upstream release ganymed-ssh2-210-5.fc8 ---------------------- * Mon Sep 10 2007 Robert Marcano 210-5 - Build for all supported arquitectures gcstar-1.2.0-1.fc8 ------------------ * Sun Sep 09 2007 Tian - 1.2.0-1 - New upstream version gimp-help-2-0.2.0.13.fc8 ------------------------ * Wed Aug 08 2007 Nils Philippsen - 2-0.2.0.13 - change licensing tag to GFDL gnome-panel-2.19.92-3.fc8 ------------------------- * Mon Sep 10 2007 Ray Strode - 2.19.92-3 - create ~/.local/share/applications before writing out preferred app launchers im-chooser-0.5.1-1.fc8 ---------------------- * Mon Sep 10 2007 Akira TAGOH - 0.5.1-1 - New upstream release. kernel-2.6.23-0.171.rc5.git1.fc8 -------------------------------- * Mon Sep 10 2007 Chuck Ebbert - fix clock warping on x86_64 * Mon Sep 10 2007 Chuck Ebbert - x86: fix debug early boot * Thu Sep 06 2007 Chuck Ebbert - x86: debug early boot libflaim-4.9.989-15.fc8 ----------------------- * Mon Sep 10 2007 Christopher Brown - 4.9.989-15 - bump release for EVR issues lighttpd-1.4.18-1.fc8 --------------------- * Mon Sep 10 2007 Matthias Saou 1.4.18-1 - Update to 1.4.18. - Include newly installed lighttpd-angel ("angel" process meant to always run as root and restart lighttpd when it crashes, spawn processes on SIGHUP), but it's in testing stage and must be run with -D for now. linkchecker-4.7-10.fc8 ---------------------- * Mon Sep 10 2007 W. Michael Petullo - 4.7-10 - Bump version to retag with new sources. * Mon Sep 10 2007 W. Michael Petullo - 4.7-9 - Rebuild for F8. man-pages-fr-2.40.0-9.fc8 ------------------------- * Mon Sep 10 2007 Marcela Maslanova 2.40.0-9 - 273941 doesn't install linkchecker man page maven2-0:2.0.4-10jpp.6.fc8 -------------------------- * Fri Sep 07 2007 Deepak Bhole 0:2.0.4-10jpp.7 - Exclude ppc64 build - Add patch to build with ant 1.7 - Build with bootstrap (First build on F8/ppc) mugshot-1.1.52-1.fc8 -------------------- * Mon Sep 10 2007 Colin Walters - 1.1.52-1 - add devel pkg - 1.1.52 nspluginwrapper-0.9.91.5-2.fc8 ------------------------------ * Mon Sep 10 2007 Martin Stransky 0.9.91.5-2 - added upstream patches - RPC error handling and plugin restart online-desktop-0.2.12-1.fc8 --------------------------- * Mon Sep 10 2007 Colin Walters - 0.2.12-1 - new upstream opensc-0.11.4-1.fc8 ------------------- * Mon Sep 10 2007 Ville Skytt?? - 0.11.4-1 - 0.11.4. perl-Set-IntSpan-1.12-1.fc8 --------------------------- * Mon Sep 10 2007 Ralf Cors??pius - 1.12.1 - Upstream update. * Mon Aug 06 2007 Ville Skytt?? - 1.11-2 - License: GPL+ or Artistic pm-utils-0.99.4-1.fc8 --------------------- * Mon Sep 10 2007 Peter Jones - 0.99.4-1 - Merge new upstream - remove pm/power.d/laptop-tools - add --quirk-reset-brightness (needed for the Fujitsu Lifebook S7110) * Sat Sep 08 2007 Till Maas - 0.99.3-12 - Adjust %files to own /etc/pm/ and /usr/lib/pm-utils/ (#233906) - remove (C|CXX|F)FLAGS definitions, they are already in %configure - remove Core in Summary tag - add URL for pm-utils - add %{?arm} to ExclusiveArch (#245463) - remove vbetool and require it (it is a separate package now) - remove radeontool and require it (it is a separate package now) - Update License Tag - cleanup buildrequires - clear %setup policycoreutils-2.0.25-11.fc8 ----------------------------- * Mon Sep 10 2007 Dan Walsh 2.0.25-11 - Lots of fixes for polgengui * Thu Sep 06 2007 Dan Walsh 2.0.25-10 - Change Requires /bin/rpm to rpm * Wed Sep 05 2007 Dan Walsh 2.0.25-9 - Bump libsemanage version for disable dontaudit - New gui features for creating admin users postr-0.8-1.fc8 --------------- * Mon Sep 10 2007 Trond Danielsen - 0.8-1 - New upstream - Updated license tag. python-2.5.1-10.fc8 ------------------- * Mon Sep 10 2007 Jeremy Katz - 2.5.1-10 - work around problems with multi-line plural specification (#252136) * Tue Aug 28 2007 Jeremy Katz - 2.5.1-9 - rebuild against new expat * Tue Aug 14 2007 Jeremy Katz - 2.5.1-8 - build against db4.6 python-iniparse-0.2.1-3.fc8 --------------------------- * Mon Sep 10 2007 Tim Lauridsen - 0.2.1-3 - Added patch from upstream svn to fix problems with out commented lines. seamonkey-1.1.3-8.fc8 --------------------- * Mon Sep 10 2007 Martin Stransky 1.1.3-8 - added fix for #246248 - firefox crashes when searching for word "do" seaview-2.0-1.fc8 ----------------- * Mon Sep 10 2007 Christian Iseli 2.0-1 - New upstream version, with a true version number :) selinux-policy-3.0.7-8.fc8 -------------------------- * Mon Sep 10 2007 Dan Walsh 3.0.7-8 - Allow newalias/sendmail dac_override - Allow bind to bind to all udp ports svnkit-1.1.4-1.fc8 ------------------ * Mon Sep 10 2007 Robert Marcano - 1.1.4-1 - Update to upstream 1.1.4 - Build for all supported arquitectures system-config-language-1.2.9-1.fc8 ---------------------------------- * Mon Sep 10 2007 Lingning Zhang - 1.2.9 - fix bug275711 and bug284331. * Mon Aug 20 2007 Lingning Zhang - 1.2.8 - re-fix bug251478. * Mon Aug 13 2007 Lingning Zhang - 1.2.7 - fix bug251478. system-config-samba-1.2.51-1.fc8 -------------------------------- * Mon Sep 10 2007 Nils Philippsen - 1.2.51 - update Polish, Serbian translations - $RPM_BUILD_ROOT -> %{buildroot} - don't add distro specific desktop categories from Fedora 8 on (#277591) - attempt to put the tool into the System -> Administration menu (#249440) - require libuser-python from Fedora 8 on (#251354) - make use of force tagging (since mercurial 0.9.4) thunderbird-2.0.0.6-3.fc8 ------------------------- * Mon Sep 10 2007 Martin Stransky 2.0.0.6-3 - added fix for #246248 - firefox crashes when searching for word "do" uim-1.4.1-7.fc8 --------------- * Mon Sep 10 2007 Akira TAGOH - 1.4.1-7 - Update the xinput script to support the new im-chooser. - bring up uim-toolbar-gtk-systray as the auxiliary program - support the config button. widelands-0-0.6.build11.fc8 --------------------------- * Mon Sep 10 2007 Karol Trzcionka - 0-0.6.build11 - Upgrade to build-11 xfsdump-2.2.46-1.fc8 -------------------- * Mon Sep 10 2007 Eric Sandeen - 2.2.46-1 - Update to xfsdump version 2.2.46 - Dropped O_CREAT patch, now upstream xfsprogs-2.9.4-1.fc8 -------------------- * Mon Sep 10 2007 Eric Sandeen 2.9.4-1 - Update to xfsprogs 2.9.4 xsc-1.5-2.fc8 ------------- yum-3.2.5-1.fc8 --------------- * Mon Sep 10 2007 Seth Vidal 3.2.5-1 - 3.2.5 - pull out unused patches yum-utils-1.1.7-1.fc8 --------------------- * Mon Sep 10 2007 Tim Lauridsen - mark as 1.1.7 Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 pm-utils - 0.99.4-1.fc8.ppc requires vbetool polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) pm-utils - 0.99.4-1.fc8.ppc64 requires vbetool referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From pknirsch at redhat.com Tue Sep 11 10:32:37 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Tue, 11 Sep 2007 12:32:37 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E640B7.4030803@hhs.nl> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> Message-ID: <46E66EC5.8000307@redhat.com> Hans de Goede wrote: > Rahul Sundaram wrote: >> Hans de Goede wrote: >>> We don't have a repository ready for end users yet, but we are >>> actively working on merging the following ones: >>> >>> * http://dribble.org.uk/ >>> * http://freshrpms.net/ >>> * http://rpm.livna.org/ >> >> Noticeably missing is ATrpms however. > > ATrpms (Axel) has been involved in the merger talks from day one, > unfortunately we (rpmfusion and atrpms) couldn't come to terms and have > each gone our seperate ways (as good friends), but who knows what the > future will bring. > > Regards, > > Hans > Great work Hans, this is really a big step forward to making it easier for Fedora user to get those apps that we don't ship in Fedora itself. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From ndbecker2 at gmail.com Tue Sep 11 10:37:49 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 11 Sep 2007 06:37:49 -0400 Subject: dkms - should I use it? References: <46E61598.9060608@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Neal Becker wrote: >> I see dkms is now in fedora. Does this mean fedora now blesses it's use? >> I'd like to submit a package to use it. > > DKMS has been available in Fedora for a long time. The curent kernel > modules guidelines doesn't use it and there is a proposal to get rid of > separate kernel modules entirely and patch the kernel package directly > if needed. > > What is the module you are thinking of packaging? > > Rahul > I have sent a review request for blcr, Berkeley Linux Checkpoint Restart, which uses a kernel module. From buildsys at fedoraproject.org Tue Sep 11 10:41:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 11 Sep 2007 06:41:52 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-11 Message-ID: <20070911104152.6AB8F152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 13 NEW cbios-0.21-3.fc6 : A third party BIOS compatible with the MSX BIOS eclipse-subclipse-1.2.4-1.fc6 freenx-0.7.0-1.fc6 gperiodic-2.0.10-1.fc6 NEW isync-1.0.3-3.fc6 : Tool to synchronize IMAP4 and Maildir mailboxes NEW openmsx-0.6.2-4.fc6 : An emulator for the MSX home computer system perl-Graph-0.84-1.fc6 perl-Set-IntSpan-1.12-1.fc6 postr-0.8-1.fc6 svnkit-1.1.4-1.fc6 sysprof-kmod-1.0.8-1.2.6.22.4_45.fc6 xfsdump-2.2.45-1.fc6 zabbix-1.4.2-1.fc6 Changes in Fedora Extras 6: cbios-0.21-3.fc6 ---------------- * Tue Aug 28 2007 Ian Chapman 0.21-3 - Really convert some documentation to UTF8 this time. * Sun Aug 26 2007 Ian Chapman 0.21-2 - Migration to Fedora - Converted some documentation to UTF8 eclipse-subclipse-1.2.4-1.fc6 ----------------------------- * Mon Sep 10 2007 Robert Marcano 1.2.4-1 - Update to upstream 1.2.4 - Build for all supported arquitectures * Sun Sep 09 2007 Robert Marcano 1.2.2-6 - Change MANIFEST.MF patch to be applied on prep stage * Wed Aug 29 2007 Fedora Release Engineering - 1.2.2-4 - Rebuild for selinux ppc32 issue. freenx-0.7.0-1.fc6 ------------------ * Thu Sep 06 2007 Jon Ciesla - 0.7.0-1 - CM = Christian Mandery mail at chrismandery.de, BZ 252976 - Version bump to 0.7.0 upstream release (CM) - Fixed download URL (didn't work, Berlios changed layout). (CM) - Changed license field from GPL to GPLv2 in RPM. (CM) - Fixed release. gperiodic-2.0.10-1.fc6 ---------------------- * Sat Sep 08 2007 Eric Tanguy 2.0.10-1 - New upstream version * Sat May 05 2007 Eric Tanguy 2.0.8-8 - Rebuild isync-1.0.3-3.fc6 ----------------- * Sun Sep 09 2007 Lubomir Kundrak 1.0.3-3 - Fix code for the case where open() is a macro. (thanks to Marek Mahut) - Cosmetic fixes. (#282261) (thanks to Till Maas) * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-2 - Added dependency on OpenSSL for SSL/TLS support * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-1 - Initial package openmsx-0.6.2-4.fc6 ------------------- * Mon Aug 27 2007 Ian Chapman 0.6.2-4 - License field corrected * Sun Aug 26 2007 Ian Chapman 0.6.2-3 - Migration to Fedora - License field changed due to new guidelines perl-Graph-0.84-1.fc6 --------------------- * Wed Sep 05 2007 Alex Lancaster 0.84-1 - Update to latest upstream. perl-Set-IntSpan-1.12-1.fc6 --------------------------- * Mon Sep 10 2007 Ralf Cors?pius - 1.12.1 - Upstream update. * Mon Aug 06 2007 Ville Skytt? - 1.11-2 - License: GPL+ or Artistic postr-0.8-1.fc6 --------------- * Mon Sep 10 2007 Trond Danielsen - 0.8-1 - New upstream - Updated license tag. svnkit-1.1.4-1.fc6 ------------------ * Mon Sep 10 2007 Robert Marcano - 1.1.4-1 - Update to upstream 1.1.4 - Build for all supported arquitectures * Wed Aug 29 2007 Fedora Release Engineering - 1.1.2-4 - Rebuild for selinux ppc32 issue. sysprof-kmod-1.0.8-1.2.6.22.4_45.fc6 ------------------------------------ * Tue Aug 21 2007 Gianluca Sforna - Update License field xfsdump-2.2.45-1.fc6 -------------------- * Thu May 31 2007 Eric Sandeen - 2.2.45-1 - Update to xfsdump 2.2.45 * Thu Aug 31 2006 Russell Cattelan - 2.2.42-2 - Remove Distribution: tag zabbix-1.4.2-1.fc6 ------------------ * Tue Sep 11 2007 Dan Horak 1.4.2-1 - New upstream release From dhollis at davehollis.com Tue Sep 11 12:13:36 2007 From: dhollis at davehollis.com (David Hollis) Date: Tue, 11 Sep 2007 08:13:36 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E640B7.4030803@hhs.nl> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> Message-ID: <1189512816.4916.1.camel@dhollis-lnx.sunera.com> On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote: > ATrpms (Axel) has been involved in the merger talks from day one, > unfortunately > we (rpmfusion and atrpms) couldn't come to terms and have each gone > our > seperate ways (as good friends), but who knows what the future will > bring. Hopefully the two repos can at least coordinate enough that they don't step on each other. I'm sure everyone has had the frustration with apps such as mplayer that are in multiple repos, all packaged differently, and all updated at different times so you wind up with crazy dependency issues preventing regular updates and such. -- David Hollis From jonesc at hep.phy.cam.ac.uk Tue Sep 11 12:45:04 2007 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Tue, 11 Sep 2007 13:45:04 +0100 Subject: Announcing rpmfusion In-Reply-To: <46E66EC5.8000307@redhat.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <46E66EC5.8000307@redhat.com> Message-ID: <46E68DD0.2020400@hep.phy.cam.ac.uk> > Great work Hans, this is really a big step forward to making it easier > for Fedora user to get those apps that we don't ship in Fedora itself. Yes, +1 to that. Also, +1 to the fact its not as good a news as if ATrpms had also been incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say livna and ATrpms are now, then on a practical level the merger is no where near as useful as it could have been. Heres hoping you iron out your differences in the future sometime. Chris From mschwendt.tmp0701.nospam at arcor.de Tue Sep 11 13:11:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 15:11:01 +0200 Subject: Exclude Requires for some archs In-Reply-To: <46E65F38.7090600@ioa.s.u-tokyo.ac.jp> References: <200709111045.03218.opensource@till.name> <20070911110040.799f442b.mschwendt.tmp0701.nospam@arcor.de> <20070911111240.0bbf0f1a.mschwendt.tmp0701.nospam@arcor.de> <46E65F38.7090600@ioa.s.u-tokyo.ac.jp> Message-ID: <20070911151101.cf741c90.mschwendt.tmp0701.nospam@arcor.de> On Tue, 11 Sep 2007 18:26:16 +0900, Mamoru Tasaka wrote: > Note: pm-utils dependency problem for vbetool commented here is actually > not due to the usage of %ifnarch (bug 285361) Yeah, I've confused it with the several noarch scenarios [1] we've had. The first read of the message was like "despite the added %ifnarch, the Requires make it into the pkg". Not "with the added %ifnarch, the packages doesn't build in koji". After a few minutes, my memory made me realise the mistake, and then I looked up the build task in koji. -- [1] e.g. "BuildArch: noarch", %ifarch/%ifnarch conditional sub-packages and/or dependencies, some of the attempts at building noarch pkgs for only some archs From skvidal at fedoraproject.org Tue Sep 11 13:03:09 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Sep 2007 09:03:09 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> References: <46E29FC6.4090103@hhs.nl> <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> Message-ID: <1189515789.6704.19.camel@cutter> On Tue, 2007-09-11 at 01:05 -0400, Ray Strode wrote: > Hi, > > > But then I got a comment to the review it was already in Fedora in kdesdk. But > > then why on earth doesn't kdesdk have a Provides umbrello so that yum install > > umbrello works? > So one cool feature I learned about a while ago (that you may already > know about) with yum is you can do > > yum install /usr/bin/umbrello > > or whatever the full path to the program is, and it will automatically > grab the right package. Of course, that feature is only useful if you > already know the name of the binary, and where it's getting installed > to. Right- yum can install using provides as the key. This is why I suggested packages containing more than one program should provide the name of the other programs explicitly. Then: yum install umbrello would work. -sv From Christian.Iseli at licr.org Tue Sep 11 13:18:15 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 11 Sep 2007 15:18:15 +0200 Subject: Fedora Package Status of Sep 11, 2007 Message-ID: <20070911151815.6651f604@ludwig-alpha.unil.ch> Hi folks, The package status page has been updated. Congrats to tibbs for passing the 500 packages reviewed landmark. Cheers, Christian ==== Fedora Package Status of Sep 11, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners stats: - 4943 packages - 8181 binary rpms in devel - 98 orphans - 54 packages not available in devel or release andreas at bawue dot net perl-HTML-CalendarMonthSimple arozansk at redhat dot com wdaemon bdpepple at gmail dot com galago-filesystem bdpepple at gmail dot com gaim-galago bnocera at redhat dot com gnome-web-photo cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests debarshi dot ray at gmail dot com opyum devrim at commandprompt dot com postgresql-pgpool-ha foolish at guezz dot net perl-SQLite-Simple j dot w dot r dot degoede at hhs dot nl ksirk j dot w dot r dot degoede at hhs dot nl boswars jafo at tummy dot com python-mechanoid jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client kwizart at gmail dot com filezilla limb at jcomserv dot net xsc lkundrak at redhat dot com isync mastahnke at gmail dot com epel-release matthias at rpmforge dot net gnome-themes-extras mchristi at redhat dot com scsi-target-utils mmahut at redhat dot com mencal mpg at redhat dot com olpc-hardware-manager mpg at redhat dot com sugar mpg at redhat dot com sugar-presence-service mpg at redhat dot com xulrunner mpg at redhat dot com sugar-artwork mpg at redhat dot com sugar-datastore mpg at redhat dot com hulahop mpg at redhat dot com pyxapian navid at redhat dot com sos noah at coderanger dot net rainbow noah at coderanger dot net python-olpcgames odvorace at redhat dot com odvorace odvorace at redhat dot com jbrassow ondrejj at salstar dot sk micq opensource at till dot name vbetool opensource at till dot name radeontool orion at cora dot nwra dot com R-multcomp paul at all-the-johnsons dot co dot uk mysql-connector-net pertusus at free dot fr ivman rdieter at math dot unl dot edu pykdeextensions richard at hughsie dot com ohm rvokal at redhat dot com gaim-guifications splinux25 at gmail dot com drapes sundaram at redhat dot com olpc-utils than at redhat dot com kdepimlibs than at redhat dot com kdelibs3 trond dot danielsen at gmail dot com uisp trond dot danielsen at gmail dot com avarice vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp yufanyufan at gmail dot com audacious-plugins-docklet - 10 packages not available in devel but present in release andreas dot bierfert at lowlatency dot de syncekonnector caolanm at redhat dot com hunspell-he j dot w dot r dot degoede at hhs dot nl hedgewars jkeating at redhat dot com tux jorton at redhat dot com newt-perl overholt at redhat dot com eclipse-nlspackager overholt at redhat dot com eclipse-sdk-nls tmraz at redhat dot com openssl097a twaugh at redhat dot com desktop-printing wtogami at redhat dot com firefox-32 - 10 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861,250040,253941 eclipse bkonrath at redhat.com cyrus-imapd tjanouse at redhat.com new mike at flyn.org cgi-util mike at flyn.org https://bugzilla.redhat.com/buglist.cgi?bug_id=177841,221717,224458,252049,269441,280541 Tracker roozbeh at farsiweb.info agg caolanm at redhat.com libsilc wtogami at redhat.com asm2 vivekl at redhat.com dvgrab rpm at greysector.net setools cpebenito at tresys.com - 4 packages present in the development repo which have no owners entry audacious-docklet s390utils stardict-dic ufsparse - 1 orphaned packages, yet available in devel gkrellm-hddtemp FE-ACCEPT packages stats: - 3154 accepted, closed package reviews - 47 accepted, closed package reviews not in repo - 9 accepted, closed package reviews not in owners - 67 accepted, open package reviews older than 4 weeks; - 52 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 251 open tickets - 115 tickets with no activity in eight weeks - 38 tickets with no activity in four weeks - 25 closed tickets FE-NEW packages stats: - 920 open tickets - 645 tickets with no activity in eight weeks - 110 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 46 open tickets - 7 tickets with no activity in eight weeks - 7 tickets with no activity in four weeks FE-Legal packages stats: - 6 open tickets - 1 tickets with no activity in eight weeks - 2 tickets with no activity in four weeks OPEN-BUGS packages stats: - 8685 open tickets - 5824 tickets with no activity in eight weeks - 1037 tickets with no activity in four weeks CVS stats: - 4950 packages with a devel directory - 3 packages with no owners entry glibc32 glibc64 tdma - 239 packages were dropped from Fedora Maintainers stats: - 419 maintainers - 29 inactive maintainers with open bugs - 18 inactive maintainers Dropped Fedora packages: - 50 packages were dropped since Fedora 7 Comps.xml files stats: - 2509 packages in comps-f8 file - 1105 packages missing from comps-f8 file - 28 packages in comps-f8 but not in repo - 2407 packages in comps-f7 file - 1077 packages missing from comps-f7 file - 28 packages in comps-f7 but not in repo From sundaram at fedoraproject.org Tue Sep 11 13:27:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 11 Sep 2007 18:57:36 +0530 Subject: Fedora Package Status of Sep 11, 2007 In-Reply-To: <20070911151815.6651f604@ludwig-alpha.unil.ch> References: <20070911151815.6651f604@ludwig-alpha.unil.ch> Message-ID: <46E697C8.8000806@fedoraproject.org> Christian Iseli wrote: > Hi folks, > > The package status page has been updated. Please exclude all the following packages in the OLPC-2 branch. > johnp at redhat dot com GConf2-dbus > mpg at redhat dot com olpc-hardware-manager > mpg at redhat dot com sugar > mpg at redhat dot com sugar-presence-service > mpg at redhat dot com xulrunner > mpg at redhat dot com sugar-artwork > mpg at redhat dot com sugar-datastore > sundaram at redhat dot com olpc-utils This one is EPEL specific mastahnke at gmail dot com epel-release Rahul From Matt_Domsch at dell.com Tue Sep 11 13:33:41 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 11 Sep 2007 08:33:41 -0500 Subject: DKMS and old kernel modules In-Reply-To: <645d17210709100716q29873c01k717ea77cc10a070f@mail.gmail.com> References: <200709092240.23077.opensource@till.name> <645d17210709091419i695fec4bq348dbedecec82428@mail.gmail.com> <20070910021637.GC31880@auslistsprd01.us.dell.com> <645d17210709100716q29873c01k717ea77cc10a070f@mail.gmail.com> Message-ID: <20070911133341.GA21438@auslistsprd01.us.dell.com> On Mon, Sep 10, 2007 at 03:16:23PM +0100, Jonathan Underwood wrote: > Ah, ok, I slightly misunderstood the use of mkrpm - I was under the > impression that DKMS could build an rpm of the kernel module on the > users machine (not in a repository buildsystem) and then install that. > I.e. dkms, when it sees a new kernel on the users machine compiles the > kernel module and packages at as an rpm and then installs it. Would > that be implementable? sure, it's just a matter of code. There's also the secondary problem of rpm being non-recursive. e.g. you'd have to do this from outside of a running rpm transaction, such as in the dkms_autoinstaller. DKMS couldn't do it from the proposed kernel package postinst hook that's called by the kernel RPM's %post, which is where you'd really want it to be called from. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jima at beer.tclug.org Tue Sep 11 13:38:02 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 11 Sep 2007 08:38:02 -0500 (CDT) Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189461952.3157.84.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> <1189461952.3157.84.camel@mccallum.corsepiu.local> Message-ID: On Tue, 11 Sep 2007, Ralf Corsepius wrote: > On Mon, 2007-09-10 at 16:52 -0500, Josh Boyer wrote: >> Or it means you didn't follow the freeze process. Again. > > C'mon, what you say is really ridiculous and embarrassing. > > Nothing (neither CVS, nor bodhi, nor koji) prevented me (nor anybody > else amongst the dozens of other folks having done the same) from > submitting, building nor pushing packages ... > > So I conclude, you actually mean bodhi's unusability and rel-eng's > broken procedures start to show effect ... as usual during the final > phases of release preps. You simply deny the brokenness of your > procedures. If we're talking about freeze, we're talking about rawhide, and if we're talking about rawhide, we're NOT talking about bodhi. At all. Bodhi isn't involved in rawhide, so you can stop beating that old drum. Bodhi didn't eat the curtains, and its kitten consumption is pretty minimal for a Fedora product. Jima From harald at redhat.com Tue Sep 11 13:42:15 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 15:42:15 +0200 Subject: udev performance Message-ID: <46E69B37.3000604@redhat.com> For all of you who are bothered by the performance of udev: I did some profiling, where udev spents its time... so here are the numbers: Out of 3.63s of measured activity udev spent: 44.1% (1,6s) with /sbin/modprobe 13.3% (0,48s) with persistent-storage (mostly vol_id) 12% (0.44s) with 60-net.rules 10.5% (0.38s) with 90-alsa.rules 7% (0.25s) with pam_console (which will go away anyway) Your numbers may vary because of different hardware. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From Christian.Iseli at licr.org Tue Sep 11 13:50:38 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 11 Sep 2007 15:50:38 +0200 Subject: Fedora Package Status of Sep 11, 2007 In-Reply-To: <46E697C8.8000806@fedoraproject.org> References: <20070911151815.6651f604@ludwig-alpha.unil.ch> <46E697C8.8000806@fedoraproject.org> Message-ID: <20070911155038.73a4f138@ludwig-alpha.unil.ch> On Tue, 11 Sep 2007 18:57:36 +0530, Rahul Sundaram wrote: > Please exclude all the following packages in the OLPC-2 branch. Yup, it's on my TODO list... :) C From harald at redhat.com Tue Sep 11 13:55:25 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 15:55:25 +0200 Subject: udev performance In-Reply-To: <46E69B37.3000604@redhat.com> References: <46E69B37.3000604@redhat.com> Message-ID: <46E69E4D.2000805@redhat.com> Harald Hoyer schrieb: > 44.1% (1,6s) with /sbin/modprobe modprobe is parsing its configuration/dependency files every time it is called. > 12% (0.44s) with 60-net.rules I am sure 60-net.rules does not have to call /etc/sysconfig/network-scripts/net.hotplug for _every_ "net" event. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From rc040203 at freenet.de Tue Sep 11 13:57:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Sep 2007 15:57:33 +0200 Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> <1189461952.3157.84.camel@mccallum.corsepiu.local> Message-ID: <1189519053.3157.164.camel@mccallum.corsepiu.local> On Tue, 2007-09-11 at 08:38 -0500, Jima wrote: > At all. Bodhi > isn't involved in rawhide, so you can stop beating that old drum. Try "new packages" in bodhi and you will find fc8 packages. Ralf From Christian.Iseli at licr.org Tue Sep 11 13:58:32 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 11 Sep 2007 15:58:32 +0200 Subject: Review queue stats Message-ID: <20070911155832.3e515b77@ludwig-alpha.unil.ch> Hi folks, An image of the "Package Review" tickets queue over time... The close rate is wrong due to some mass ticket changes that occurred at some point, and my script is too dumb to actually capture the closed date: it just looks at the modified date. One thing I think worth noting: we are nowhere nearing a point where there is nothing left to package it seems. The scripts are in CVS if anyone feels like playing with them: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora grabBZstats : collect the data bzstat.gp : call gnuplot Cheers, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: bzstat.png Type: image/png Size: 14795 bytes Desc: not available URL: From fedora at camperquake.de Tue Sep 11 14:00:19 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 11 Sep 2007 16:00:19 +0200 Subject: udev performance In-Reply-To: <46E69E4D.2000805@redhat.com> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> Message-ID: <20070911160019.76b18651@banea.int.addix.net> Hi. On Tue, 11 Sep 2007 15:55:25 +0200, Harald Hoyer wrote: > modprobe is parsing its configuration/dependency files every time it > is called. What else should it do? From j.w.r.degoede at hhs.nl Tue Sep 11 14:02:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Sep 2007 16:02:14 +0200 Subject: udev performance In-Reply-To: <20070911160019.76b18651@banea.int.addix.net> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> Message-ID: <46E69FE6.403@hhs.nl> Ralf Ertzinger wrote: > Hi. > > On Tue, 11 Sep 2007 15:55:25 +0200, Harald Hoyer wrote: > >> modprobe is parsing its configuration/dependency files every time it >> is called. > > What else should it do? > Cache the result in a dump of the resulting binary structs in disk (ugly). Or much better: have a run as daemon mode where one can stuff new modules names to probe to it through a pipe, that would avoid a zillion forks and execs too, or maybe split most of the code into a lib and use that lib from udev? Regards, Hans From harald at redhat.com Tue Sep 11 14:05:03 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 16:05:03 +0200 Subject: udev performance In-Reply-To: <20070911160019.76b18651@banea.int.addix.net> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> Message-ID: <46E6A08F.1010403@redhat.com> Ralf Ertzinger schrieb: > Hi. > > On Tue, 11 Sep 2007 15:55:25 +0200, Harald Hoyer wrote: > >> modprobe is parsing its configuration/dependency files every time it >> is called. > > What else should it do? > Kay and Greg thought about putting modprobe code in udev, so the config/dep files have to be read only once. Another idea was some kind of modprobe-daemon. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From ibmalone at gmail.com Tue Sep 11 14:05:37 2007 From: ibmalone at gmail.com (Ian Malone) Date: Tue, 11 Sep 2007 15:05:37 +0100 Subject: vorbis-tools in 7.90 Message-ID: <124299980709110705j6b4e86b0pb2b8acd10b89e88d@mail.gmail.com> Hi, I notice that Fedora 7.90 still has vorbis-tools-1.1.1.svn20070412-2. A newer version of svn would fix bug 244757[1]. Given that an svn version rather than an official release is being used anyway wouldn't testing be a good time to try to bump to a slightly newer revision that doesn't contain this disabling bug for oggdec? [1] https://bugzilla.redhat.com/show_bug.cgi?id=244757 -- imalone From jima at beer.tclug.org Tue Sep 11 14:08:29 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 11 Sep 2007 09:08:29 -0500 (CDT) Subject: [Fwd: Package EVR problems in Fedora 2007-09-10] In-Reply-To: <1189519053.3157.164.camel@mccallum.corsepiu.local> References: <1189455097.3157.47.camel@mccallum.corsepiu.local> <1189455927.3447.24.camel@lt21223.campus.dmacc.edu> <1189456089.3157.52.camel@mccallum.corsepiu.local> <1189456168.3157.54.camel@mccallum.corsepiu.local> <20070910163821.278c794e@mentok.boston.redhat.com> <1189458336.3157.62.camel@mccallum.corsepiu.local> <20070910160956.11a910de@weaponx.rchland.ibm.com> <1189460692.3157.71.camel@mccallum.corsepiu.local> <20070910165221.3bfec415@weaponx.rchland.ibm.com> <1189461952.3157.84.camel@mccallum.corsepiu.local> <1189519053.3157.164.camel@mccallum.corsepiu.local> Message-ID: On Tue, 11 Sep 2007, Ralf Corsepius wrote: > On Tue, 2007-09-11 at 08:38 -0500, Jima wrote: >> At all. Bodhi >> isn't involved in rawhide, so you can stop beating that old drum. > Try "new packages" in bodhi and you will find fc8 packages. I'm aware of this; IIRC it's due to the way that bodhi looks up packages against koji. Alas, do you see "Rawhide" or "Fedora 8" anywhere in the "Release" drop-down on the "New update" page? I don't. Mainly because rawhide updates don't go through bodhi; they get pushed directly. Jima From notting at redhat.com Tue Sep 11 14:12:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Sep 2007 10:12:22 -0400 Subject: udev performance In-Reply-To: <46E69E4D.2000805@redhat.com> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> Message-ID: <20070911141222.GA20980@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: >> 12% (0.44s) with 60-net.rules > > I am sure 60-net.rules does not have to call > /etc/sysconfig/network-scripts/net.hotplug for _every_ "net" event. What events are there besides add and remove? In any case, please file a bug and we'll get that fixed. Bill From notting at redhat.com Tue Sep 11 14:17:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Sep 2007 10:17:38 -0400 Subject: udev performance In-Reply-To: <46E69B37.3000604@redhat.com> References: <46E69B37.3000604@redhat.com> Message-ID: <20070911141738.GA23797@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > For all of you who are bothered by the performance of udev: > > I did some profiling, where udev spents its time... so here are the > numbers: > > Out of 3.63s of measured activity udev spent: What rules were installed (out of all of the Fedora universe) - is this a base install? Bill From harald at redhat.com Tue Sep 11 14:22:42 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 16:22:42 +0200 Subject: udev performance In-Reply-To: <20070911141738.GA23797@nostromo.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> Message-ID: <46E6A4B2.1040507@redhat.com> Bill Nottingham schrieb: > Harald Hoyer (harald at redhat.com) said: >> For all of you who are bothered by the performance of udev: >> >> I did some profiling, where udev spents its time... so here are the >> numbers: >> >> Out of 3.63s of measured activity udev spent: > > What rules were installed (out of all of the Fedora universe) - is this > a base install? > > Bill > This was a F7 with latest udev-115. I will rerun this test with a rules-everything F8. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From poelstra at redhat.com Tue Sep 11 14:39:24 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 11 Sep 2007 07:39:24 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-SEP-10 Message-ID: <46E6A89C.40302@redhat.com> Apologies for sending to the wrong list -------- Original Message -------- Subject: Fedora Rel-Eng Meeting Recap 2007-SEP-10 To: fedora-announce-list at redhat.com Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-sep-10 Please make corrections and clarifications to the wiki page. == News Update From F13 == * Test2 is on the way to mirrors * rawhide is now back to being rawhide unfrozen * minimal buildroots have been adjusted (util-linux-ng is back, perl(-devel) not listed) * have a list of names for F8--need to followup with legal * we should really go after the broken deps and upgrade paths a week or two before the test3 freeze * when are we supposed to turn off new packages for FC6? * FC6 gets shut down one month after F8, do we turn off new packages beforehand? * I'm working on the signing server stuff, and making good progress. I updated the Spec page for it and moved it into ReleaseEngineering/Projects/ space. * hope to have something reasonable for a code drop in a git module or something by the end of this week. Right now things like gpg key and passphrase are hardcoded so I don't want to commit that anywhere right now (: == Miscellaneous == * http://fedoraproject.org/wiki/Extras/Policy/EOL * The EOL policy is clearly stale/out-out-date, something FESCo should probably clarify/update. * Should we do freezes and and snapshots differently for F9 and beyond? * http://katzj.livejournal.com/405215.html == IRC Transcript == -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From mike at miketc.com Tue Sep 11 14:48:38 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 11 Sep 2007 09:48:38 -0500 Subject: Evolution icons Message-ID: <1189522118.2793.1.camel@scrappy.miketc.com> Anyone notice that at least the attachement icon is missing or something in evolution? Seemed to happen after updates in rawhide from yesterday. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From j.w.r.degoede at hhs.nl Tue Sep 11 14:47:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Sep 2007 16:47:16 +0200 Subject: ode changes headsup Message-ID: <46E6AA74.80000@hhs.nl> Hi all, I've just build the new 0.8.1 ode from upstream this version is ABI and API compatible, except that it drops the odecpp_old.h backwards compatibility header (which contains an 100% inline code cpp wrapper). If you have a package which needs this to compile let me know, adding it back is trivial. Regards, Hans From wcohen at redhat.com Tue Sep 11 15:02:45 2007 From: wcohen at redhat.com (William Cohen) Date: Tue, 11 Sep 2007 11:02:45 -0400 Subject: udev performance In-Reply-To: <46E69E4D.2000805@redhat.com> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> Message-ID: <46E6AE15.4060406@redhat.com> Harald Hoyer wrote: > Harald Hoyer schrieb: >> 44.1% (1,6s) with /sbin/modprobe > > modprobe is parsing its configuration/dependency files every time it is > called. > >> 12% (0.44s) with 60-net.rules > > I am sure 60-net.rules does not have to call > /etc/sysconfig/network-scripts/net.hotplug for _every_ "net" event. > > A while back I did some experiments with systemtap and found that modprobe was doing a linear search through modules.deps: http://sourceware.org/ml/systemtap/2007-q1/msg00140.html I wrote a script that would prepend the modules that are actually used to the beginning of modules.dep to reduce the average length of search. This reduced the amount of data read (and time spent waiting for I/O) and slightly reduced the time to boot the machine. Bootchart samples process state periodically. Below is some of the data extracted from the bootchart samples: all states D state modprobe modprobe samples samples normal modules.dep 120 73 reordered modules.deps 63 27 Having to linearly through 250K of text in modules.dep each time a module is loaded doesn't seem very efficient. -Will From dhollis at davehollis.com Tue Sep 11 15:06:29 2007 From: dhollis at davehollis.com (David Hollis) Date: Tue, 11 Sep 2007 11:06:29 -0400 Subject: udev performance In-Reply-To: <46E69FE6.403@hhs.nl> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> <46E69FE6.403@hhs.nl> Message-ID: <1189523189.3003.11.camel@dhollis-lnx.sunera.com> On Tue, 2007-09-11 at 16:02 +0200, Hans de Goede wrote: > Ralf Ertzinger wrote: > > Hi. > > > > On Tue, 11 Sep 2007 15:55:25 +0200, Harald Hoyer wrote: > > > >> modprobe is parsing its configuration/dependency files every time it > >> is called. > > > > What else should it do? > > > > Cache the result in a dump of the resulting binary structs in disk (ugly). Or > much better: have a run as daemon mode where one can stuff new modules names to > probe to it through a pipe, that would avoid a zillion forks and execs too, > or > maybe split most of the code into a lib and use that lib from udev? I kind of like this last option myself. You don't really want to dupe the modprobe code in udev, and have two separate code bases to maintain. I don't really see a need for a daemon since 99% of modloads are done upon boot, plus now you have a pipe/socket/whatever to load mods and the security implications that has. Making libmodprobe.so that they all use, centralized code-base and all of that just seems to make some good sense. -- David Hollis From martin.sourada at seznam.cz Tue Sep 11 15:09:04 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 11 Sep 2007 17:09:04 +0200 Subject: Evolution icons In-Reply-To: <1189522118.2793.1.camel@scrappy.miketc.com> References: <1189522118.2793.1.camel@scrappy.miketc.com> Message-ID: <1189523344.11397.3.camel@pc-notebook> On Tue, 2007-09-11 at 16:48 +0200, Mike Chambers wrote: > Anyone notice that at least the attachement icon is missing or something > in evolution? Seemed to happen after updates in rawhide from yesterday. > > -- > Mike Chambers > Madisonville, KY > > "Best lil town on Earth!" > Yes, I noticed that also, though I didn't know which icon is missing, because I completely forgot what icon was there... Now that you mentioned it I remembered... Yes, attachment icon is missing, though I don't know if it is general problem or only in some icon themes (I use Echo). Martin -------------- 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 harald at redhat.com Tue Sep 11 15:40:27 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 17:40:27 +0200 Subject: udev performance In-Reply-To: <46E6AE15.4060406@redhat.com> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <46E6AE15.4060406@redhat.com> Message-ID: <46E6B6EB.8070502@redhat.com> William Cohen schrieb: > Harald Hoyer wrote: >> Harald Hoyer schrieb: >>> 44.1% (1,6s) with /sbin/modprobe >> >> modprobe is parsing its configuration/dependency files every time it >> is called. >> >>> 12% (0.44s) with 60-net.rules >> >> I am sure 60-net.rules does not have to call >> /etc/sysconfig/network-scripts/net.hotplug for _every_ "net" event. >> >> > > A while back I did some experiments with systemtap and found that > modprobe was doing a linear search through modules.deps: > > http://sourceware.org/ml/systemtap/2007-q1/msg00140.html > > I wrote a script that would prepend the modules that are actually used > to the beginning of modules.dep to reduce the average length of search. > This reduced the amount of data read (and time spent waiting for I/O) > and slightly reduced the time to boot the machine. Bootchart samples > process state periodically. Below is some of the data extracted from the > bootchart samples: > > all states D state > modprobe modprobe > samples samples > normal modules.dep 120 73 > reordered modules.deps 63 27 > > Having to linearly through 250K of text in modules.dep each time a > module is loaded doesn't seem very efficient. > > > -Will > Problem is, that most of the modprobes with a modalias are not existent and so every line is parsed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From harald at redhat.com Tue Sep 11 15:45:24 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 17:45:24 +0200 Subject: udev performance In-Reply-To: <46E6A4B2.1040507@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> Message-ID: <46E6B814.5000404@redhat.com> Harald Hoyer schrieb: > Bill Nottingham schrieb: >> Harald Hoyer (harald at redhat.com) said: >>> For all of you who are bothered by the performance of udev: >>> >>> I did some profiling, where udev spents its time... so here are the >>> numbers: >>> >>> Out of 3.63s of measured activity udev spent: >> >> What rules were installed (out of all of the Fedora universe) - is this >> a base install? >> >> Bill >> > > This was a F7 with latest udev-115. I will rerun this test with a > rules-everything F8. > Ok, did this with a rules-everything-rawhide on my laptop: 26 seconds 85% (22.3s) in modprobe 7.5% (2s) in 60-openct.rules:26 PROGRAM="/bin/sleep 0.1" rest is below 0.5 seconds... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From sandeen at redhat.com Tue Sep 11 15:49:34 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 11 Sep 2007 10:49:34 -0500 Subject: udev performance In-Reply-To: <46E6B814.5000404@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> Message-ID: <46E6B90E.7040309@redhat.com> Harald Hoyer wrote: > Ok, did this with a rules-everything-rawhide on my laptop: > > 26 seconds > > 85% (22.3s) in modprobe > 7.5% (2s) in 60-openct.rules:26 PROGRAM="/bin/sleep 0.1" > > rest is below 0.5 seconds... What exactly is the test you're running? Or did I miss that... Thanks, -Eric From jakub at redhat.com Tue Sep 11 15:58:27 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 11 Sep 2007 11:58:27 -0400 Subject: udev performance In-Reply-To: <46E6B6EB.8070502@redhat.com> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <46E6AE15.4060406@redhat.com> <46E6B6EB.8070502@redhat.com> Message-ID: <20070911155827.GO20571@devserv.devel.redhat.com> On Tue, Sep 11, 2007 at 05:40:27PM +0200, Harald Hoyer wrote: > >A while back I did some experiments with systemtap and found that > >modprobe was doing a linear search through modules.deps: > > > >http://sourceware.org/ml/systemtap/2007-q1/msg00140.html > > > >I wrote a script that would prepend the modules that are actually used > >to the beginning of modules.dep to reduce the average length of search. > >This reduced the amount of data read (and time spent waiting for I/O) > >and slightly reduced the time to boot the machine. Bootchart samples > >process state periodically. Below is some of the data extracted from the > >bootchart samples: > > > > all states D state > > modprobe modprobe > > samples samples > >normal modules.dep 120 73 > >reordered modules.deps 63 27 > > > >Having to linearly through 250K of text in modules.dep each time a > >module is loaded doesn't seem very efficient. > > > > > >-Will > > > > Problem is, that most of the modprobes with a modalias are not existent and > so every line is parsed. If modules.dep searching really takes significant time, then there is always an option to precompile it into a more efficient format, e.g. more compact, with a hash table or whatever best matches modprobe's use. Jakub From harald at redhat.com Tue Sep 11 16:08:53 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 18:08:53 +0200 Subject: udev performance In-Reply-To: <46E6B90E.7040309@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E6B90E.7040309@redhat.com> Message-ID: <46E6BD95.10800@redhat.com> Eric Sandeen schrieb: > Harald Hoyer wrote: > >> Ok, did this with a rules-everything-rawhide on my laptop: >> >> 26 seconds >> >> 85% (22.3s) in modprobe >> 7.5% (2s) in 60-openct.rules:26 PROGRAM="/bin/sleep 0.1" >> >> rest is below 0.5 seconds... > > What exactly is the test you're running? Or did I miss that... > > Thanks, > > -Eric > my own version of udev with some ugly profiling code :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From harald at redhat.com Tue Sep 11 16:17:54 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 11 Sep 2007 18:17:54 +0200 Subject: udev performance In-Reply-To: <46E6B814.5000404@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> Message-ID: <46E6BFB2.6050206@redhat.com> Harald Hoyer schrieb: > Ok, did this with a rules-everything-rawhide on my laptop: > > 26 seconds > > 85% (22.3s) in modprobe > 7.5% (2s) in 60-openct.rules:26 PROGRAM="/bin/sleep 0.1" > > rest is below 0.5 seconds... > Note: modprobe + kernel loading the modules is taking 22s Normally most of the modprobes are executed in parallel, so you normally don't have to wait 22s. Here for my test, I turned on sequential processing of the events. These are absolut times, including sleeps, e.g. for HW devices. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From dennis at ausil.us Tue Sep 11 16:14:30 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 11 Sep 2007 11:14:30 -0500 Subject: Exclude Requires for some archs In-Reply-To: <200709111045.03218.opensource@till.name> References: <200709111045.03218.opensource@till.name> Message-ID: <200709111114.30647.dennis@ausil.us> On Tuesday 11 September 2007 3:45:02 am Till Maas wrote: > Hiyas, > > I want to use > %ifnarch ppc ppc64 > Requires: vbetool > %endif > in a package, which should work according to maximum rpm[1] and was > suggested by Mamoru Tasaka. Nevertheless koji does not want to build[2] > this for ppc(64) because of a missing vbetool. Does someone spot the error > in the spec[3]? > > Regards, > Till > > [1] http://www.rpm.org/max-rpm/s1-rpm-inside-conditionals.html > [2] http://koji.fedoraproject.org/koji/getfile?taskID=155137&name=root.log > [3] > http://cvs.fedoraproject.org/viewcvs/rpms/pm-utils/devel/pm-utils.spec?rev= >1.79&view=markup When doing this please also consider Secondary Archs. what archs does it make sense to have vbetool on? Dennis From 440volt.tux at gmail.com Tue Sep 11 16:17:17 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Tue, 11 Sep 2007 21:47:17 +0530 Subject: koji build failed Message-ID: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> While building Straw-0.27 ,koji gave the following error Error: PyGTK's glade module is required to install Straw error: Bad exit status from /var/tmp/rpm-tmp.41264 (%install) [http://koji.fedoraproject.org/koji/getfile?taskID=155446&name=build.log] My spec file contains the following Requires: python >= 2.4 # fix for python >= 2.5 %if "%{?fedora}" > "6" BuildRequires: python-devel %endif Requires: gnome-python2 Requires: gnome-python2-gconf Requires: gnome-python2-gnomevfs Requires: gnome-python2-gtkhtml2 Requires: libxml2-python >= 1.99.13 Requires: pyorbit Requires: pygtk2-libglade Requires: python-mx-base Requires: python-gnome2-extras Requires: pygtk2-devel Requires: gtk2 >= 2.4 Requires: libglade2 Requires: dbus-python BuildRequires: pygtk2 >= 2.8.0 BuildRequires: desktop-file-utils BuildRequires: gnome-python2-gconf BuildRequires: intltool What i have missed?? Please help. From myfedora at richip.dhs.org Tue Sep 11 16:32:28 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 10:32:28 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E640B7.4030803@hhs.nl> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> Message-ID: <1189528348.7482.3.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote: > ATrpms (Axel) has been involved in the merger talks from day one, unfortunately > we (rpmfusion and atrpms) couldn't come to terms and have each gone our > seperate ways (as good friends), but who knows what the future will bring. Is the discussion of the issues related to integration available on some public archive somewhere? I've been following developments on ATRPMs for a while now and have to say that there are a lot of great and elegant stuff in their system. I would love to see a concerted effort. I would REALLY hate to give up one for another. Right now, I'm balancing livna and ATRMS with repo-specific "exclude"s MANUALLY. Not fun for me, and probably not within the capability of many a user. -- Richi Plana From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 11 16:39:24 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 12 Sep 2007 01:39:24 +0900 Subject: koji build failed In-Reply-To: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> Message-ID: <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> subhodip biswas wrote, at 09/12/2007 01:17 AM +9:00: > While building Straw-0.27 ,koji gave the following error > > Error: PyGTK's glade module is required to install Straw > error: Bad exit status from /var/tmp/rpm-tmp.41264 (%install) > > [http://koji.fedoraproject.org/koji/getfile?taskID=155446&name=build.log] pygtk2-libglade is missing from BuildRequires. Regards, Mamoru From myfedora at richip.dhs.org Tue Sep 11 16:41:47 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 10:41:47 -0600 Subject: udev performance In-Reply-To: <46E69FE6.403@hhs.nl> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> <46E69FE6.403@hhs.nl> Message-ID: <1189528907.7482.7.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 16:02 +0200, Hans de Goede wrote: > Or > much better: have a run as daemon mode where one can stuff new modules names to > probe to it through a pipe, that would avoid a zillion forks and execs too, or > maybe split most of the code into a lib and use that lib from udev? Came to the same conclusion, as well. Add three options: 1) start the daemon, 2) communicate with the daemon, and 3) kill daemon. Processes should really be as reusable as code. The daemon just has to be made sensitive to configuration changes, or document somewhere that the daemon cached information remains static for the entire session. -- Richi Plana From chris.stone at gmail.com Tue Sep 11 16:45:55 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 11 Sep 2007 09:45:55 -0700 Subject: Koji is not building In-Reply-To: References: <46E36ABA.2010807@redhat.com> Message-ID: On 9/8/07, Christopher Stone wrote: > On 9/8/07, Mike McGrath wrote: > > Christopher Stone wrote: > > > http://koji.fedoraproject.org/koji/tasks > > > > > > I tried killing the job and starting a new one. Didn't help. > > > > > > > BTW all, we discussed this on IRC. The build is hanging on a flock in > > rawhide, it's reproducible in mock locally though we haven't determined > > why yet. I'm going to take a closer look tomorrow when I have some more > > time but here's a strace for the interested: > > > > http://mmcgrath.fedorapeople.org/php-pear-PHPUnit-3.1.8-1.fc8.strace.log > > Thanks for looking into this Mike. FYI, I am out of town tomorrow, > will be back Monday. > Fixed with bug #283401 Thanks Remi. :) From myfedora at richip.dhs.org Tue Sep 11 16:51:42 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 10:51:42 -0600 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189515789.6704.19.camel@cutter> References: <46E29FC6.4090103@hhs.nl> <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> <1189515789.6704.19.camel@cutter> Message-ID: <1189529502.7482.16.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote: > Right- yum can install using provides as the key. > > This is why I suggested packages containing more than one program should > provide the name of the other programs explicitly. > > Then: > > yum install umbrello > > would work. Would there ever be a danger where overriding package names (via virtual packages) might result in ambiguities? So package names would now mean program names, as well? Would there be a problem if a real package were to be added to the repo (or some repo)? What would yum (or the resolver) base its decision on? I'm not too comfortable with overriding it using the full path ("/usr/bin/umbrello") but at least it disambiguates much better than the other. (And I figure it's too much to put in a language for specifying other parameters such as "yum install --program-name=umbrello" or "--lib=c"). Just posing questions. -- Richi Plana From chris.stone at gmail.com Tue Sep 11 16:53:59 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 11 Sep 2007 09:53:59 -0700 Subject: Announcing rpmfusion In-Reply-To: <46E640B7.4030803@hhs.nl> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> Message-ID: On 9/11/07, Hans de Goede wrote: > Rahul Sundaram wrote: > > Hans de Goede wrote: > >> We don't have a repository ready for end users yet, but we are > >> actively working on merging the following ones: > >> > >> * http://dribble.org.uk/ > >> * http://freshrpms.net/ > >> * http://rpm.livna.org/ > > > > Noticeably missing is ATrpms however. > > ATrpms (Axel) has been involved in the merger talks from day one, unfortunately > we (rpmfusion and atrpms) couldn't come to terms and have each gone our > seperate ways (as good friends), but who knows what the future will bring. didnt his leaving have something to do with no enterprise linux support? supporting enterprise linux is in the future plans for rpmfusion, correct? From skvidal at fedoraproject.org Tue Sep 11 16:55:45 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Sep 2007 12:55:45 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189529502.7482.16.camel@localhost6.localdomain6> References: <46E29FC6.4090103@hhs.nl> <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> <1189515789.6704.19.camel@cutter> <1189529502.7482.16.camel@localhost6.localdomain6> Message-ID: <1189529745.6704.31.camel@cutter> On Tue, 2007-09-11 at 10:51 -0600, Richi Plana wrote: > On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote: > > Right- yum can install using provides as the key. > > > > This is why I suggested packages containing more than one program should > > provide the name of the other programs explicitly. > > > > Then: > > > > yum install umbrello > > > > would work. > > Would there ever be a danger where overriding package names (via virtual > packages) might result in ambiguities? So package names would now mean > program names, as well? you mean if there were multiple things providing 'umbrello' that's just like any other multiple-provider situation. > Would there be a problem if a real package were > to be added to the repo (or some repo)? What would yum (or the resolver) > base its decision on? the decision works now as: - best arch for the system - shortest name - first in the list > I'm not too comfortable with overriding it using > the full path ("/usr/bin/umbrello") but at least it disambiguates much > better than the other. (And I figure it's too much to put in a language > for specifying other parameters such as "yum install > --program-name=umbrello" or "--lib=c"). yes - that's just not sane. -sv From chris.stone at gmail.com Tue Sep 11 16:59:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 11 Sep 2007 09:59:11 -0700 Subject: Announcing rpmfusion In-Reply-To: <1189528348.7482.3.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <1189528348.7482.3.camel@localhost6.localdomain6> Message-ID: On 9/11/07, Richi Plana wrote: > On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote: > > ATrpms (Axel) has been involved in the merger talks from day one, unfortunately > > we (rpmfusion and atrpms) couldn't come to terms and have each gone our > > seperate ways (as good friends), but who knows what the future will bring. > > Is the discussion of the issues related to integration available on some > public archive somewhere? I've been following developments on ATRPMs for > a while now and have to say that there are a lot of great and elegant > stuff in their system. I would love to see a concerted effort. I would > REALLY hate to give up one for another. Right now, I'm balancing livna > and ATRMS with repo-specific "exclude"s MANUALLY. Not fun for me, and > probably not within the capability of many a user. Ah I remember now, I wont comment on what Axel wrote, instead I'll just say come to your own conclusions: http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/000137.html From 440volt.tux at gmail.com Tue Sep 11 16:42:22 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Tue, 11 Sep 2007 22:12:22 +0530 Subject: koji build failed In-Reply-To: <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> Message-ID: <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> Thanx for help :) On 9/11/07, Mamoru Tasaka wrote: > subhodip biswas wrote, at 09/12/2007 01:17 AM +9:00: > > While building Straw-0.27 ,koji gave the following error > > > > Error: PyGTK's glade module is required to install Straw > > error: Bad exit status from /var/tmp/rpm-tmp.41264 (%install) > > > > [http://koji.fedoraproject.org/koji/getfile?taskID=155446&name=build.log] > > pygtk2-libglade is missing from BuildRequires. > > Regards, > Mamoru > > -- Regards Subhodip From hughsient at gmail.com Tue Sep 11 17:09:06 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 11 Sep 2007 18:09:06 +0100 Subject: rawhide report: 20070911 changes In-Reply-To: <200709111022.l8BAMYpg013872@porkchop.devel.redhat.com> References: <200709111022.l8BAMYpg013872@porkchop.devel.redhat.com> Message-ID: <15e53e180709111009p14e4e5c2ma9a592f738b558ce@mail.gmail.com> On 11/09/2007, Build System wrote: > New package radeontool > Backlight and video output configuration tool for radeon cards > > New package vbetool > Run real-mode video BIOS code to alter hardware state Quality, thanks for doing this. This was one on my main gripes with the pm-utils fedora package. Richard. From fedora at camperquake.de Tue Sep 11 17:37:15 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 11 Sep 2007 19:37:15 +0200 Subject: udev performance In-Reply-To: <46E69FE6.403@hhs.nl> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> <46E69FE6.403@hhs.nl> Message-ID: <20070911193715.3cb4dfc1@lain.camperquake.de> Hi. On Tue, 11 Sep 2007 16:02:14 +0200, Hans de Goede wrote > Cache the result in a dump of the resulting binary structs in disk > (ugly). Or let depmod create a more easily parseable format on the disk (as Jakub suggested). > Or much better: have a run as daemon mode where one can stuff > new modules names to probe to it through a pipe, that would avoid a > zillion forks and execs too Daemons create a bunch of new security problems we really do not want to have at that place. From SteveD at redhat.com Tue Sep 11 17:57:10 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 11 Sep 2007 13:57:10 -0400 Subject: Changing a Package's Name. Message-ID: <46E6D6F6.4090905@RedHat.com> Upstream has renamed a package. So I was wondering what would the best approach to handle this. Create an entirely new package or do some type of rename in CVS pool? The rename is libgssapi to libgssglue which will effect all the dependences for the nfs-utils* packages. steved. From jaroslav at aster.pl Tue Sep 11 18:03:51 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Tue, 11 Sep 2007 20:03:51 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E637DB.6060102@hhs.nl> References: <46E637DB.6060102@hhs.nl> Message-ID: <200709112003.58735.jaroslav@aster.pl> Hi, Tuesday 11 of September 2007 08:38:19 Hans de Goede napisa?(a): > RPM Fusion aims to bring together many packagers from various 3rd party > repos and build a single add-on repository for Fedora and Red Hat > Enterprise Linux. great, > It will contain add-on packages and not replacements in relation to the > base package set. Whereby the base package set is defined as: RHEL/CentOS + > EPEL or Fedora (Fedora 7+). hmmm.... I'm not sure I understand it correctly... let's have an example. Fedora doesn't have 'lame'. RPM Fusion will have 'lame', right? But You will _not_ rebuild k3b with lame support, because You don't want to replace "base" package set (k3b is in base). Right? Another example: inclusion of mp3 support libraries, but without rebuilding audio players. If this is the case, wouldn't such a repo be useless? regards, PS. Please clarify this if I misunderstood the point. -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Sep 11 18:06:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Sep 2007 14:06:16 -0400 Subject: Announcing rpmfusion In-Reply-To: <200709112003.58735.jaroslav@aster.pl> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> Message-ID: <20070911140616.61fc2799@localhost.localdomain> On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny wrote: > Another example: inclusion of mp3 support libraries, but without > rebuilding audio players. > > If this is the case, wouldn't such a repo be useless? With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Sep 11 18:09:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Sep 2007 10:09:16 -0800 Subject: Announcing rpmfusion In-Reply-To: <200709112003.58735.jaroslav@aster.pl> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> Message-ID: <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> On 9/11/07, Jaroslaw Gorny wrote: > Another example: inclusion of mp3 support libraries, but without rebuilding > audio players. > > If this is the case, wouldn't such a repo be useless? not for audio applications which are smart enough to know how to do detect availability of optional libraries at runtime or use a plugin architecture. And it seems..lame...to me to have a multimedia application can't detect new codecs on the system at runtime. -jef From Jochen at herr-schmitt.de Tue Sep 11 18:09:59 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 11 Sep 2007 20:09:59 +0200 Subject: Changing a Package's Name. In-Reply-To: <46E6D6F6.4090905@RedHat.com> References: <46E6D6F6.4090905@RedHat.com> Message-ID: <46E6D9F7.4010206@herr-schmitt.de> Steve Dickson schrieb: > Upstream has renamed a package. So I was wondering what > would the best approach to handle this. Create an entirely new > package or do some type of rename in CVS pool? > > The rename is libgssapi to libgssglue which will > effect all the dependences for the nfs-utils* packages. > I think, you should add a CVS-Admin request to create a new module with the new package name and start the retired package procedure described on http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife for the module with the old name. In the dead.package file you should write, that the package was renamed and where you can find the renamed package. Best Regards: Jochen Schmitt From skvidal at fedoraproject.org Tue Sep 11 18:10:53 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Sep 2007 14:10:53 -0400 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> Message-ID: <1189534253.6704.38.camel@cutter> On Tue, 2007-09-11 at 10:09 -0800, Jeff Spaleta wrote: > On 9/11/07, Jaroslaw Gorny wrote: > > Another example: inclusion of mp3 support libraries, but without rebuilding > > audio players. > > > > If this is the case, wouldn't such a repo be useless? > > not for audio applications which are smart enough to know how to do > detect availability of optional libraries at runtime or use a plugin > architecture. And it seems..lame...to me to have a multimedia > application can't detect new codecs on the system at runtime. -2 points from Jef for that pun. -sv From notting at redhat.com Tue Sep 11 18:15:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Sep 2007 14:15:52 -0400 Subject: udev performance In-Reply-To: <46E6B814.5000404@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> Message-ID: <20070911181552.GA5755@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > Ok, did this with a rules-everything-rawhide on my laptop: > > 26 seconds > > 85% (22.3s) in modprobe That doesn't make sense. Why does adding more rules make it call modprobe that much more? Bill From limb at jcomserv.net Tue Sep 11 17:50:28 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 11 Sep 2007 12:50:28 -0500 (CDT) Subject: Announcing rpmfusion In-Reply-To: <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> Message-ID: <29930.65.192.24.164.1189533028.squirrel@mail.jcomserv.net> > > architecture. And it seems..lame...to me to have a multimedia > application can't detect new codecs on the system at runtime. You owe me a new keyboard. :)P > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From SteveD at redhat.com Tue Sep 11 18:19:51 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 11 Sep 2007 14:19:51 -0400 Subject: Changing a Package's Name. In-Reply-To: <46E6D9F7.4010206@herr-schmitt.de> References: <46E6D6F6.4090905@RedHat.com> <46E6D9F7.4010206@herr-schmitt.de> Message-ID: <46E6DC47.2020807@RedHat.com> Jochen Schmitt wrote: > Steve Dickson schrieb: >> Upstream has renamed a package. So I was wondering what >> would the best approach to handle this. Create an entirely new >> package or do some type of rename in CVS pool? >> >> The rename is libgssapi to libgssglue which will >> effect all the dependences for the nfs-utils* packages. >> > > I think, you should add a CVS-Admin request to create a new module with > the new package name > and start the retired package procedure described on > > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife > > for the module with the old name. In the dead.package file you should > write, that the package > was renamed and where you can find the renamed package. OK, thanks for the pointer... steved. From sandeen at redhat.com Tue Sep 11 18:23:43 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 11 Sep 2007 13:23:43 -0500 Subject: udev performance In-Reply-To: <20070911193715.3cb4dfc1@lain.camperquake.de> References: <46E69B37.3000604@redhat.com> <46E69E4D.2000805@redhat.com> <20070911160019.76b18651@banea.int.addix.net> <46E69FE6.403@hhs.nl> <20070911193715.3cb4dfc1@lain.camperquake.de> Message-ID: <46E6DD2F.4090301@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Tue, 11 Sep 2007 16:02:14 +0200, Hans de Goede wrote > >> Cache the result in a dump of the resulting binary structs in disk >> (ugly). > > Or let depmod create a more easily parseable format on the disk (as > Jakub suggested). I don't think it's yet been proven that parsing the files is accounting for a significant portion of the time.... FWIW, I straced the parent udevd process during my F7 boot, and here's how it spent most of it's time: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 67.93 0.157414 142 1105 288 waitpid 9.98 0.023130 4626 5 1 init_module 5.45 0.012638 2 6662 15 read 5.01 0.011601 48 240 execve ... ------ ----------- ----------- --------- --------- ---------------- 100.00 0.231726 58010 6125 total -Eric From tcallawa at redhat.com Tue Sep 11 18:07:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 11 Sep 2007 14:07:44 -0400 Subject: [Guidelines Update] PHP Guidelines Changes Message-ID: <1189534064.3964.18.camel@localhost.localdomain> The following changes were committed to the PHP Guidelines (http://fedoraproject.org/wiki/Packaging/PHP). They were approved by the Fedora Packaging Committee and ratified by FESCo. In the Requires and Provides section, PEAR and PECL packages were redefined to the following: PEAR Packages ============== A PEAR package MUST have: BuildRequires: php-pear(PEAR) Requires: php-pear(PEAR) Requires(post): %{__pear} Requires(postun): %{__pear} Provides: php-pear(foo) = %{version} PECL Packages ============== A PECL package MUST have: BuildRequires: php-devel, php-pear Requires(post): %{__pecl} Requires(postun): %{__pecl} %if %{?php_zend_api}0 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else Requires: php-api = %{php_apiver} %endif Provides: php-pecl(foo) = %{version} In the Macros and Scriptlets section, PECL Modules was redefined to the following: PECL Modules ============= You may need to define a few additional macros to extract some information from PHP. It is recommended that you use the following: %global php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) %{!?__pecl: %{expand: %%global __pecl %{_bindir}/pecl}} %{!?php_extdir: %{expand: %%global php_extdir %(php-config --extension-dir)}} And here are some recommended scriptlets for properly registering and unregistering the module: %if 0%{?pecl_install:1} %post %{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || : %endif %if 0%{?pecl_uninstall:1} %postun if [ $1 -eq 0 ] ; then %{pecl_uninstall} %{pecl_name} >/dev/null || : fi %endif Thanks, ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tcallawa at redhat.com Tue Sep 11 18:15:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 11 Sep 2007 14:15:25 -0400 Subject: [Guidelines Change] New guidelines for R packages Message-ID: <1189534525.3964.21.camel@localhost.localdomain> New Guidelines are available for R module packaging: http://fedoraproject.org/wiki/Packaging/R These guidelines were approved by the Fedora Packaging Committee (FPC) and ratified by FESCo. Thanks, ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tcallawa at redhat.com Tue Sep 11 18:24:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 11 Sep 2007 14:24:25 -0400 Subject: [Guidelines Change] Emacs Guidelines Message-ID: <1189535065.3964.24.camel@localhost.localdomain> New guidelines describing how to package GNU Emacs and XEmacs addon packages can be found here: http://fedoraproject.org/wiki/Packaging/Emacs These guidelines were approved by the Fedora Packaging Committee (FPC) and ratified by FESCo. Thanks, ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From 440volt.tux at gmail.com Tue Sep 11 18:46:12 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Wed, 12 Sep 2007 00:16:12 +0530 Subject: koji build failed In-Reply-To: <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> Message-ID: <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> Hi ! While building straw 0.27 koji build for dist-fc7 works without error However dist-f8 fails with following error :- var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw/constants.py:libdir = os.path.normpath('/var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw') Found '/var/tmp/straw-0.27-4-F13608' in installed files; aborting error: Bad exit status from /var/tmp/rpm-tmp.65277 (%install) Tried to fix it with the following sed -i -e "s@${RPM_BUILD_ROOT}@@" constants.py.in But No avail What to do ? Attached setup.py and constants.py.in ( if required) Regards Subhodip -------------- next part -------------- A non-text attachment was scrubbed... Name: constants.py.in Type: application/octet-stream Size: 841 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py Type: text/x-python Size: 5932 bytes Desc: not available URL: From michel.sylvan at gmail.com Tue Sep 11 19:08:20 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 11 Sep 2007 15:08:20 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: <1189529502.7482.16.camel@localhost6.localdomain6> References: <46E29FC6.4090103@hhs.nl> <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> <1189515789.6704.19.camel@cutter> <1189529502.7482.16.camel@localhost6.localdomain6> Message-ID: On 11/09/2007, Richi Plana wrote: > On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote: > > Right- yum can install using provides as the key. > > > > This is why I suggested packages containing more than one program should > > provide the name of the other programs explicitly. > > > > Then: > > > > yum install umbrello > > > > would work. > > Would there ever be a danger where overriding package names (via virtual > packages) might result in ambiguities? So package names would now mean > program names, as well? Would there be a problem if a real package were > to be added to the repo (or some repo)? What would yum (or the resolver) If someone were to provide umbrello as a separate package while the kdesdk package from Fedora still contains it as well, you have a problem anyway, since it will also provide /usr/bin/umbrello. Unless the 3rd-party umbrello was packaged with this in mind, and install in some other prefix. Regards, -- Michel From mschwendt.tmp0701.nospam at arcor.de Tue Sep 11 19:33:58 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 11 Sep 2007 21:33:58 +0200 Subject: koji build failed In-Reply-To: <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> Message-ID: <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> On Wed, 12 Sep 2007 00:16:12 +0530, subhodip biswas wrote: > Hi ! > > > While building straw 0.27 koji build for dist-fc7 works without error > However dist-f8 fails with following error :- > var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw/constants.py:libdir > = > os.path.normpath('/var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw') > Found '/var/tmp/straw-0.27-4-F13608' in installed files; aborting > error: Bad exit status from /var/tmp/rpm-tmp.65277 (%install) > > > > Tried to fix it with the following > > sed -i -e "s@${RPM_BUILD_ROOT}@@" constants.py.in > > But No avail > > What to do ? > > Attached setup.py and constants.py.in ( if required) You need to find out why and when constants.py (not constants.py.in) is created with $RPM_BUILD_ROOT filled into it. Then replacing the buildroot string in the %install section would very likely work. Also note that the %build section should not do anything with $RPM_BUILD_ROOT unless it cannot be avoided. From kevin.kofler at chello.at Tue Sep 11 19:28:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 19:28:37 +0000 (UTC) Subject: Aggregation upstream projects are BAD (kdesdk for example) References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> <16de708d0709091109s5bc7e2fcy5083b62ca3286c17@mail.gmail.com> Message-ID: Arthur Pemberton gmail.com> writes: > How about listing the apps in the description? This is what's done for some of the other kde* packages, it could probably be done here. The main problem with this is that sometimes apps get dropped or replaced (in the upstream collection), or new apps get into the collection, and then the list tends to get out of sync with what's actually in the package. Kevin Kofler From jaroslav at aster.pl Tue Sep 11 19:37:08 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Tue, 11 Sep 2007 21:37:08 +0200 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> Message-ID: <200709112137.18121.jaroslav@aster.pl> Tuesday 11 of September 2007 20:09:16 Jeff Spaleta napisa?(a): > On 9/11/07, Jaroslaw Gorny wrote: > > Another example: inclusion of mp3 support libraries, but without > > rebuilding audio players. > > > > If this is the case, wouldn't such a repo be useless? > > not for audio applications which are smart enough to know how to do > detect availability of optional libraries at runtime or use a plugin > architecture. And it seems..lame...to me to have a multimedia > application can't detect new codecs on the system at runtime. Are they lame or not, it's not my point here. They are in distro, so maybe they're not so lame after all. Simple kde player included in kdemultimedia-extras (noatun) won't handle mp3 without rebuild. And this is the default player in KDE. If somebody just downloads mp3 file and clicks it - noatun starts and stops immediately. It can be frustrating for user to download all 'fusion' packages responsible for mp3 handling, and still not being able to play a file. K3b is in distro too. Although I have libmad installed (freshrpms), k3b complains that no support for mp3 decoding can be found. So I guess, k3b should be rebuilt with libmad-devel in order to use this feature. But these are only examples - maybe not the lucky ones. What I'm asking for is a general 'rule': We provide foo-lib. There's some package that can be rebuilt with foo-lib and gain some extra features, but we don't do this. Is it really the best solution? regards, -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Sep 11 19:39:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 19:39:09 +0000 (UTC) Subject: Aggregation upstream projects are BAD (kdesdk for example) References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: Michel Salim gmail.com> writes: > Ditto, though in this case, umbrello happens to *also* be part of kdesdk: > > http://uml.sourceforge.net/download.php > > The source tarballs are taken straight out of kdesdk CVS, so the > Fedora packaging, while needing to be fixed, is understandable. Well, as you're saying, kdesdk here is the canonical source, the separate tarballs are taken out of kdesdk SVN, and it is also included in kdesdk, so packaging Umbrello as part of kdesdk fully makes sense. As for Hans de Goede's worry: a KDE 3.5.8 bugfix release is planned. Given that the latest Umbrello comes straight out of the KDE 3.5 SVN branch, it will also end up in there. Both monolithic and modular packaging has advantages and disadvantages. The advantages of the monolithic way: * less packages => less packaging work * clearer versioning: You know that you're using KDE 3.5.7, whereas for e.g. GNOME, you have stuff versioned 2.18.0, 2.18.1, 2.18.2, ... and it's hard to figure out what GNOME version this actually corresponds to (and similarly for the new modular X.Org X11). But of course, the advantages of the modular way (independent updates, better granularity for end-users) have been beaten to death on this list already. The granularity could be obtained in other ways though (e.g. subpackages). Still, my current position (and as far as I was able to tell from the general feeling when this issue came up in the IRC meetings, also the one of the KDE SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is that unleashing even a subpackage for every single KDE app would lead to a gigantic mess which would cause more problems than it solves. Kevin Kofler From kevin.kofler at chello.at Tue Sep 11 19:42:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 19:42:31 +0000 (UTC) Subject: Aggregation upstream projects are BAD (kdesdk for example) References: <46E29FC6.4090103@hhs.nl> <45abe7d80709102205g6cabdfb7vf21d8fbb44c109a1@mail.gmail.com> Message-ID: Ray Strode gmail.com> writes: > > Also I think it is a very bad idea to ship packages with a clearly seperate > > upstream in some kinda bundle form. > Couldn't agree more. For a while we shipped gcalctool and zenity in > gnome-utils. it was a maintainability nightmare. That's a different situation: you added those extra tarballs to the package. The upstream kdesdk tarball actually _contains_ Umbrello and builds it with no extra magic. (That magic would be needed _not_ to build it there, e.g. the DO_NOT_COMPILE hack.) It is _also_ released separately. And it is maintained upstream as part of kdesvn, the separate releases are actually cut from the KDE 3.5 SVN branch as well. Kevin Kofler From michel.sylvan at gmail.com Tue Sep 11 19:46:16 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 11 Sep 2007 15:46:16 -0400 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: On 11/09/2007, Kevin Kofler wrote: > Michel Salim gmail.com> writes: > Both monolithic and modular packaging has advantages and disadvantages. The > advantages of the monolithic way: > * less packages => less packaging work > * clearer versioning: You know that you're using KDE 3.5.7, whereas for e.g. > GNOME, you have stuff versioned 2.18.0, 2.18.1, 2.18.2, ... and it's hard to > figure out what GNOME version this actually corresponds to (and similarly for > the new modular X.Org X11). > Oh yes. Figuring out which parts of X.org 7.3 is in F8 and which is not, is not exactly trivial. > But of course, the advantages of the modular way (independent updates, better > granularity for end-users) have been beaten to death on this list already. The > granularity could be obtained in other ways though (e.g. subpackages). > Subpackages give end-users better granularity, but still does not allow for independent updates (unless, taking Umbrello as an example, an urgent Umbrello release is handled by building a separate package that is versioned higher than the bundled kdesdk-umbrello). Gets unwieldy really fast! (Alternatively, kdesdk maintainer needs to pull the fix pertaining to Umbrello, apply it as a patch, release it and prepare for the grumbles from other kdesdk users who then have to upgrade) > Still, my current position (and as far as I was able to tell from the general > feeling when this issue came up in the IRC meetings, also the one of the KDE > SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is > that unleashing even a subpackage for every single KDE app would lead to a > gigantic mess which would cause more problems than it solves. > Seems reasonable. Regards, -- Michel From michel.sylvan at gmail.com Tue Sep 11 19:48:14 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 11 Sep 2007 15:48:14 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E637DB.6060102@hhs.nl> References: <46E637DB.6060102@hhs.nl> Message-ID: On 11/09/2007, Hans de Goede wrote: > The Dribble, Freshrpms and Livna teams, already joined by some Fedora > contributors, are proud to announce the RPM Fusion project. > > RPM Fusion aims to bring together many packagers from various 3rd party repos > and build a single add-on repository for Fedora and Red Hat Enterprise Linux. > Nice -- so this is like the old RPMforge, but with a unified packaging policy (rather than a confederation of repositories)? -- Michel From jon at fedoraunity.org Tue Sep 11 19:52:30 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Tue, 11 Sep 2007 13:52:30 -0600 Subject: Announcing rpmfusion In-Reply-To: <200709112137.18121.jaroslav@aster.pl> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> <200709112137.18121.jaroslav@aster.pl> Message-ID: <46E6F1FE.6000800@fedoraunity.org> Jaroslaw Gorny wrote: > Tuesday 11 of September 2007 20:09:16 Jeff Spaleta napisa?(a): >> On 9/11/07, Jaroslaw Gorny wrote: >>> Another example: inclusion of mp3 support libraries, but without >>> rebuilding audio players. >>> >>> If this is the case, wouldn't such a repo be useless? [...] > K3b is in distro too. Although I have libmad installed (freshrpms), k3b > complains that no support for mp3 decoding can be found. So I guess, k3b > should be rebuilt with libmad-devel in order to use this feature. > k3b-extras-nonfree is provided by livna. k3b seems to be a bad example. I do understand what you are saying but in this exact case ... ;-) Jonathan Steffan daMaestro From kevin.kofler at chello.at Tue Sep 11 19:54:40 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 19:54:40 +0000 (UTC) Subject: Announcing rpmfusion References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <604aa7910709111109k46dd0c71hde92d015f6270b96@mail.gmail.com> <200709112137.18121.jaroslav@aster.pl> Message-ID: Jaroslaw Gorny aster.pl> writes: > Simple kde player included in kdemultimedia-extras (noatun) won't handle mp3 > without rebuild. This is not true. Noatun from the default Fedora package can play MP3s here. I think akode-extras and/or kdemultimedia-extras-nonfree (both from Livna) is the magic package here. > K3b is in distro too. Although I have libmad installed (freshrpms), k3b > complains that no support for mp3 decoding can be found. So I guess, k3b > should be rebuilt with libmad-devel in order to use this feature. You need k3b-extras-nonfree from Livna. > We provide foo-lib. There's some package that can be rebuilt with foo-lib and > gain some extra features, but we don't do this. > Is it really the best solution? That's what plugins are for. In other cases, there may be other solutions, for example ld.so.conf library overrides. This is what freetype-freeworld (approved for Livna, waiting on account creation) is doing for libfreetype, the proprietary graphics card drivers for libGL etc. There's even a package within Fedora doing that, though of course not for legal reasons (ATLAS, which replaces the unoptimized reference implementations of BLAS and LAPACK that way). And then there's always the solution to have a new package like audacity-nonfree which Conflicts: audacity. But if a plugin package can be provided instead, that's much preferred. Kevin Kofler From cjdahlin at ncsu.edu Tue Sep 11 19:50:52 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 11 Sep 2007 15:50:52 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189512816.4916.1.camel@dhollis-lnx.sunera.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <1189512816.4916.1.camel@dhollis-lnx.sunera.com> Message-ID: <46E6F19C.4010002@ncsu.edu> ATrpms was one of the only repos that I always advised against installing for usability reasons. Because of the large amount of package replacements in AT, updating with ATrpms in yum.repos.d often causes very invasive changes, and when things go wrong finding the issue becomes a pain. I don't mean to diminish the service ATrpms provides, but it is in my opinion a fundamentally different animal from the other third party repos. More of a community-built "service pack" than a collection of applications. David Hollis wrote: > On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote: > >> ATrpms (Axel) has been involved in the merger talks from day one, >> unfortunately >> we (rpmfusion and atrpms) couldn't come to terms and have each gone >> our >> seperate ways (as good friends), but who knows what the future will >> bring. >> > > Hopefully the two repos can at least coordinate enough that they don't > step on each other. I'm sure everyone has had the frustration with apps > such as mplayer that are in multiple repos, all packaged differently, > and all updated at different times so you wind up with crazy dependency > issues preventing regular updates and such. > > From wtogami at redhat.com Tue Sep 11 20:00:09 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 11 Sep 2007 16:00:09 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E6F19C.4010002@ncsu.edu> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <1189512816.4916.1.camel@dhollis-lnx.sunera.com> <46E6F19C.4010002@ncsu.edu> Message-ID: <46E6F3C9.2030208@redhat.com> Casey Dahlin wrote: > ATrpms was one of the only repos that I always advised against > installing for usability reasons. Because of the large amount of package > replacements in AT, updating with ATrpms in yum.repos.d often causes > very invasive changes, and when things go wrong finding the issue > becomes a pain. > > I don't mean to diminish the service ATrpms provides, but it is in my > opinion a fundamentally different animal from the other third party > repos. More of a community-built "service pack" than a collection of > applications. > Or a fork of the distribution. Warren Togami wtogami at redhat.com From kevin.kofler at chello.at Tue Sep 11 20:02:40 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Subject: Announcing rpmfusion References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > Thanks for this split. Hopefully we will able to link to the free part > from within Fedora. Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US. You _might_ be able to refer to the non-free part for NVidia and stuff, but I guess there's probably also going to be stuff that's legally murky at least in the US in there. (For example, the proprietary drivers might be a violation of the Linux kernel's GPL (version 2) license.) Kevin Kofler From jkeating at redhat.com Tue Sep 11 20:05:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Sep 2007 16:05:37 -0400 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> Message-ID: <20070911160537.696c6a25@localhost.localdomain> On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler wrote: > Rahul Sundaram fedoraproject.org> writes: > > Thanks for this split. Hopefully we will able to link to the free > > part from within Fedora. > > Unfortunately I don't think you will be able to. The stuff in the > free part (or most of it, at least) is going to be exactly the stuff > which Legal is most uncomfortable with: Free Software, but > patent-encumbered in the US. And really, if we could reference it, then why the crap couldn't we just package it in our repo? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jaroslav at aster.pl Tue Sep 11 20:07:20 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Tue, 11 Sep 2007 22:07:20 +0200 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112137.18121.jaroslav@aster.pl> Message-ID: <200709112207.27643.jaroslav@aster.pl> Hallo, Tuesday 11 of September 2007 21:54:40 Kevin Kofler napisa?(a): > > In other cases, there may be other solutions, for example > (...) > > And then there's always the solution to have a new package like > audacity-nonfree which Conflicts: audacity. But if a plugin package can be > provided instead, that's much preferred. Thanks a lot for clarification, Kevin. Both general and my app-specific "issues" :) regards, -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Tue Sep 11 20:03:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 01:33:59 +0530 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> Message-ID: <46E6F4AF.2090902@fedoraproject.org> Kevin Kofler wrote: > Rahul Sundaram fedoraproject.org> writes: >> Thanks for this split. Hopefully we will able to link to the free part >> from within Fedora. > > Unfortunately I don't think you will be able to. The stuff in the free part (or > most of it, at least) is going to be exactly the stuff which Legal is most > uncomfortable with: Free Software, but patent-encumbered in the US. Trust me. I am aware of the legal details. See https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00032.html. It is just waiting on Max Spevack to get final advice from Legal. Rahul From kevin.kofler at chello.at Tue Sep 11 20:09:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Sep 2007 20:09:05 +0000 (UTC) Subject: Making the xine-lib-extras nondependent on xine-lib-arts? References: <1189286936.3143.20.camel@pc-notebook> <200709110937.29935.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > I asked about that a while ago, but Lennart didn't think it's a good idea at > the moment so I left it in -extras. > http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01411.html But he also said he needs to look into it because KDE will probably need it. ;-) Indeed, I think Xine should really not only ship the PulseAudio output plugin by default, but also default to it (*), if PulseAudio is to be a real default. For KDE 3, this will affect at least Amarok and Kaffeine. For KDE 4, it will also affect Phonon (phonon-xine is the default/best backend and the one included in kdebase-runtime) and thus the KDE 4 versions of essentially all the apps which currently use aRts. (Disclaimer: I have not tested the Xine PulseAudio plugin yet. IMHO, the important part there is not "Does the code look good?", but "Does it work well?".) Kevin Kofler (*) It is quite possible/likely we also need to tweak the defaults of the KDE apps using Xine there. But this doesn't mean xine-lib itself shouldn't also default to it. ;-) From sundaram at fedoraproject.org Tue Sep 11 20:07:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 01:37:55 +0530 Subject: Announcing rpmfusion In-Reply-To: <20070911160537.696c6a25@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> Message-ID: <46E6F59B.7010506@fedoraproject.org> Jesse Keating wrote: > On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) > Kevin Kofler wrote: > >> Rahul Sundaram fedoraproject.org> writes: >>> Thanks for this split. Hopefully we will able to link to the free >>> part from within Fedora. >> Unfortunately I don't think you will be able to. The stuff in the >> free part (or most of it, at least) is going to be exactly the stuff >> which Legal is most uncomfortable with: Free Software, but >> patent-encumbered in the US. > > And really, if we could reference it, then why the crap couldn't we > just package it in our repo? There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible. Rahul From sundaram at fedoraproject.org Tue Sep 11 20:08:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 01:38:02 +0530 Subject: Announcing rpmfusion In-Reply-To: <20070911160537.696c6a25@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> Message-ID: <46E6F5A2.1090808@fedoraproject.org> Jesse Keating wrote: > On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) > Kevin Kofler wrote: > >> Rahul Sundaram fedoraproject.org> writes: >>> Thanks for this split. Hopefully we will able to link to the free >>> part from within Fedora. >> Unfortunately I don't think you will be able to. The stuff in the >> free part (or most of it, at least) is going to be exactly the stuff >> which Legal is most uncomfortable with: Free Software, but >> patent-encumbered in the US. > > And really, if we could reference it, then why the crap couldn't we > just package it in our repo? There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the related threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible. Rahul From cjdahlin at ncsu.edu Tue Sep 11 20:05:38 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 11 Sep 2007 16:05:38 -0400 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> Message-ID: <46E6F512.1070403@ncsu.edu> Kevin Kofler wrote: > Rahul Sundaram fedoraproject.org> writes: > >> Thanks for this split. Hopefully we will able to link to the free part >> from within Fedora. >> > > Unfortunately I don't think you will be able to. The stuff in the free part (or > most of it, at least) is going to be exactly the stuff which Legal is most > uncomfortable with: Free Software, but patent-encumbered in the US. > > There's a wide spectrum between "right in Fedora" and "not acknowledging its existence." Whereas before Red Hat became subject to liability for merely saying the word "Livna" in public, we might be able to move to a tacit and well-disclaimed "suggestion" that users use the Free half of rpmfusion. So we could go from having to say "Never heard of it" to being able to say "Its over there, and I know about it, but I really can't recommend that you use it (by clicking this button right here)" > You _might_ be able to refer to the non-free part for NVidia and stuff, but I > guess there's probably also going to be stuff that's legally murky at least in > the US in there. (For example, the proprietary drivers might be a violation of > the Linux kernel's GPL (version 2) license.) > > Kevin Kofler > > From jspaleta at gmail.com Tue Sep 11 20:59:15 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Sep 2007 12:59:15 -0800 Subject: Aggregation upstream projects are BAD (kdesdk for example) In-Reply-To: References: <46E29FC6.4090103@hhs.nl> <200709081524.38289.opensource@till.name> Message-ID: <604aa7910709111359y2bd989f4u7961ec3d2f418757@mail.gmail.com> On 9/11/07, Kevin Kofler wrote: > Still, my current position (and as far as I was able to tell from the general > feeling when this issue came up in the IRC meetings, also the one of the KDE > SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is > that unleashing even a subpackage for every single KDE app would lead to a > gigantic mess which would cause more problems than it solves. I think as downstream bit maintainers, you've got to stick close to how upstream deals with thier source collection. If KDE as a project continues to prefer monolithic model then I think its best to follow their lead. and use subpackaging as is appropriate. -jef From peter at thecodergeek.com Tue Sep 11 21:02:02 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 11 Sep 2007 14:02:02 -0700 Subject: [OT] Re: Fedora Package Status of Sep 11, 2007 In-Reply-To: <20070911151815.6651f604@ludwig-alpha.unil.ch> References: <20070911151815.6651f604@ludwig-alpha.unil.ch> Message-ID: <1189544522.11101.0.camel@tuxhugs> On Tue, 2007-09-11 at 15:18 +0200, Christian Iseli wrote: > Congrats to tibbs for passing the 500 packages reviewed landmark. Damn. o_O Keep up the awesome work, tibbs! -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Tue Sep 11 21:06:44 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 11 Sep 2007 16:06:44 -0500 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> Message-ID: <46E70364.9060609@gmail.com> Michel Salim wrote: > On 11/09/2007, Hans de Goede wrote: >> The Dribble, Freshrpms and Livna teams, already joined by some Fedora >> contributors, are proud to announce the RPM Fusion project. >> >> RPM Fusion aims to bring together many packagers from various 3rd party repos >> and build a single add-on repository for Fedora and Red Hat Enterprise Linux. >> > Nice -- so this is like the old RPMforge, but with a unified packaging > policy (rather than a confederation of repositories)? But the reason you need additional 3rd party repositories in the first place is when the unified one has a policy that prohibits certain packages from being there. Will that still be the case? -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Mon Sep 10 21:05:19 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 10 Sep 2007 23:05:19 +0200 Subject: Enhancement proposal for Firefox References: <200709100009.42098.adalbert.prokop@gmx.de> Message-ID: On 2007-09-09, 22:09 GMT, Adalbert Prokop wrote: > 1. Give the user the choice which version of Firefox is > started, especially on 64-bit architectures. See https://bugzilla.redhat.com/show_bug.cgi?id=236521 -- if you have something to add to the discussion there (and I doubt it), then add comment to the bugzilla, please. Thanks, Matej From michel.sylvan at gmail.com Tue Sep 11 21:15:36 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 11 Sep 2007 17:15:36 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E70364.9060609@gmail.com> References: <46E637DB.6060102@hhs.nl> <46E70364.9060609@gmail.com> Message-ID: On 11/09/2007, Les Mikesell wrote: > Michel Salim wrote: > > On 11/09/2007, Hans de Goede wrote: > >> The Dribble, Freshrpms and Livna teams, already joined by some Fedora > >> contributors, are proud to announce the RPM Fusion project. > >> > >> RPM Fusion aims to bring together many packagers from various 3rd party repos > >> and build a single add-on repository for Fedora and Red Hat Enterprise Linux. > >> > > Nice -- so this is like the old RPMforge, but with a unified packaging > > policy (rather than a confederation of repositories)? > > But the reason you need additional 3rd party repositories in the first > place is when the unified one has a policy that prohibits certain > packages from being there. Will that still be the case? > I meant that RPMforge is a collection of third-party repos, while RPM Fusion will actually be a single repository. I do not mean 'unified' as in "merged with Fedora", I meant unified as in "one packaging policy for all the merged repos". Sorry if it's not clear from context. -- Michel From myfedora at richip.dhs.org Tue Sep 11 21:17:59 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 15:17:59 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E6F19C.4010002@ncsu.edu> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <1189512816.4916.1.camel@dhollis-lnx.sunera.com> <46E6F19C.4010002@ncsu.edu> Message-ID: <1189545479.13590.34.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 15:50 -0400, Casey Dahlin wrote: > ATrpms was one of the only repos that I always advised against > installing for usability reasons. Because of the large amount of package > replacements in AT, updating with ATrpms in yum.repos.d often causes > very invasive changes, and when things go wrong finding the issue > becomes a pain. I have to agree. At first, I would avoid ATRPMs simply because it would provide packages (using the same names) as the ones in Fedora. It took me a while before I realized that many of these "duplicate packages" were there because of some added feature which (I'm guessing) inherently couldn't be separated into parts (Modularity). One example is ATRPMS' spamassassin package. As I understand it, ATRPMS spamassassin package makes use of Vipul's Razor (http://razor.sourceforge.net/) thereby increasing spamassassin's value. Unfortunately, spamassassin razor functionality probably couldn't be separated into an optional package and Axel decided to name the combined integrated package spamassassin (as opposed to, say, spamassassin-razor ... which, by the by, it still a kludge IMO). Or his bugzilla seems to require ruby, ImageMagick, and perl-GD*. (again perhaps added functionality that couldn't be packaged separately and still calling it the same package). Axel has, however, made very good decisions technically (like changing library names to include major versions so that different versioned libraries could be installed in parallel, kmdl has the ability to pull in the correct kernel modules for any arbitrary kernel version if they existed in the repository). That and he has packages that aren't available in other repos (like asterisk and mythtv) made me decide to use his repository as well. As for some decisions that I'm half-and-half with, they would include using newer versions of packages (which didn't work for me because the newer version of mjpegtools wouldn't work) and the fact that there are times when there would be no compromising between his personal taste and that of others. I think it's always good to take the good things from various schemes and throw away the bad ones to form a cohesive whole. If people could get over personal pride and bigotry, that is. -- Richi Plana From myfedora at richip.dhs.org Tue Sep 11 21:26:43 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 15:26:43 -0600 Subject: Announcing rpmfusion In-Reply-To: <20070911140616.61fc2799@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> Message-ID: <1189546003.13590.38.camel@localhost6.localdomain6> On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote: > On Tue, 11 Sep 2007 20:03:51 +0200 > Jaroslaw Gorny wrote: > > > Another example: inclusion of mp3 support libraries, but without > > rebuilding audio players. > > > > If this is the case, wouldn't such a repo be useless? > > With things like gstreamer you don't have to rebuild audio apps. > gstreamer plugins will plug into the base gstreamer framework and audio > apps just make use of whatever plugins are available. Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*"). -- Richi Plana From jwilson at redhat.com Tue Sep 11 21:31:38 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 11 Sep 2007 17:31:38 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E68DD0.2020400@hep.phy.cam.ac.uk> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <46E66EC5.8000307@redhat.com> <46E68DD0.2020400@hep.phy.cam.ac.uk> Message-ID: <46E7093A.8050303@redhat.com> Chris Jones wrote: > Also, +1 to the fact its not as good a news as if ATrpms had also been > incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say > livna and ATrpms are now, then on a practical level the merger is no > where near as useful as it could have been. Yeah, +10 to it being nowhere as good as if ATrpms were included in the merger, since the bulk of the overlap/conflicts in the 3rd-party repo world are between livna and ATrpms. Now they'll just be between rpmfusion and ATrpms. Suck. End-users still lose. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Tue Sep 11 21:39:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 11 Sep 2007 23:39:18 +0200 Subject: gcompris license changed to GPLv3+ Message-ID: <46E70B06.7080403@hhs.nl> Hi All, For those who want to know I'll be pushing a new gcompris version to rawhide soon which has its licensed changed to GPLv3+ Regards, Hans From snecklifter at gmail.com Tue Sep 11 21:42:20 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 11 Sep 2007 22:42:20 +0100 Subject: Announcing rpmfusion In-Reply-To: <46E7093A.8050303@redhat.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <46E66EC5.8000307@redhat.com> <46E68DD0.2020400@hep.phy.cam.ac.uk> <46E7093A.8050303@redhat.com> Message-ID: <364d303b0709111442n45be857bqcf5a1c0abaa43f6a@mail.gmail.com> On 11/09/2007, Jarod Wilson wrote: > > Chris Jones wrote: > > Also, +1 to the fact its not as good a news as if ATrpms had also been > > incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say > > livna and ATrpms are now, then on a practical level the merger is no > > where near as useful as it could have been. > > Yeah, +10 to it being nowhere as good as if ATrpms were included in the > merger, since the bulk of the overlap/conflicts in the 3rd-party repo > world are between livna and ATrpms. Now they'll just be between > rpmfusion and ATrpms. Suck. End-users still lose. > Yeah but it sucks less and end-users lose less. My conflicts have been between freshrpms and livna on occasion. Plus once all the dust has settled maybe things can be tweaked and merges can be discussed again. Its a good thing. Anyway, nvidia will soon be open source their drivers in response to ATI and we'll lose a whole lot of conflict in one go. :D Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at fedoraproject.org Tue Sep 11 21:44:44 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 11 Sep 2007 17:44:44 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-11 Message-ID: <20070911214444.6EC49152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 1 wordpress-2.2.3-0.fc6 Changes in Fedora Extras 6: wordpress-2.2.3-0.fc6 --------------------- * Tue Sep 11 2007 Adrian Reber - 2.2.3-0 - updated to 2.2.3 (security release) * Wed Aug 29 2007 John Berninger - 2.2.2-0 - update to upstream 2.2.2 - license tag update From opensource at till.name Tue Sep 11 21:44:50 2007 From: opensource at till.name (Till Maas) Date: Tue, 11 Sep 2007 23:44:50 +0200 Subject: Exclude Requires for some archs In-Reply-To: <200709111114.30647.dennis@ausil.us> References: <200709111045.03218.opensource@till.name> <200709111114.30647.dennis@ausil.us> Message-ID: <200709112345.03254.opensource@till.name> On Di September 11 2007, Dennis Gilmore wrote: > When doing this please also consider Secondary Archs. I try to consider everything that is properly documented. I do not even know, how secondary archs use Fedora, e.g. do they need rebuilds of packages to obtain changes or do they use specs directy from the cvs. > what archs does it make sense to have vbetool on? I do not know, I guess every arch that supports real-mode video BIOS codes. Debian provides only packages for i386 and x86_64 according to packages.debian.org, so maybe it does not work for other archs. I do not know and I do not have the means to test this. In case there is a hidden koji setup with secondary arch builders, where I can submit srpms to test whether a package compiles, I will send my packages there and add the required ExcludeArchs/%ifnarchs where needed. Btw. if you know more about secondary archs, maybe you want to check, whether the requires for radeontool in pm-utils is also a problem. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From snecklifter at gmail.com Tue Sep 11 21:53:13 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 11 Sep 2007 22:53:13 +0100 Subject: vorbis-tools in 7.90 In-Reply-To: <124299980709110705j6b4e86b0pb2b8acd10b89e88d@mail.gmail.com> References: <124299980709110705j6b4e86b0pb2b8acd10b89e88d@mail.gmail.com> Message-ID: <364d303b0709111453l78677e89h4e52f699128020c6@mail.gmail.com> Hello Ian, On 11/09/2007, Ian Malone wrote: > > Hi, > > I notice that Fedora 7.90 still has vorbis-tools-1.1.1.svn20070412-2. > A newer version of svn would fix bug 244757[1]. Given that an > svn version rather than an official release is being used anyway > wouldn't testing be a good time to try to bump to a slightly newer > revision that doesn't contain this disabling bug for oggdec? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=244757 > Hmm, looks like no response from the maintainer for a while. Try contacting them directly and give it a week or so. If still no response you might want to consider orphaning it: http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages and finding someone else who wants to pick it up - there seems to be a few takers from that bz entry. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodd at clarkson.id.au Wed Sep 12 00:37:02 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 12 Sep 2007 10:37:02 +1000 Subject: Announcing rpmfusion In-Reply-To: <1189546003.13590.38.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> Message-ID: <1189557422.4727.11.camel@localhost.localdomain> On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote: > On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote: > > On Tue, 11 Sep 2007 20:03:51 +0200 > > Jaroslaw Gorny wrote: > > > > > Another example: inclusion of mp3 support libraries, but without > > > rebuilding audio players. > > > > > > If this is the case, wouldn't such a repo be useless? > > > > With things like gstreamer you don't have to rebuild audio apps. > > gstreamer plugins will plug into the base gstreamer framework and audio > > apps just make use of whatever plugins are available. > > Now if only that were as easy as "yum install gstreamer-plugin-lame" or > "yum install lame-plugin-gstreamer" (in case you wanted to do "yum > install lame lame-plugin-*"). It is that easy. go to rpm.livna.org and download the correct repository rpm. Once this is installed, type: yum install gstreamer-plugins-bad This will install the mp3 codec along with a bunch of other 'bad' codecs. R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Wed Sep 12 00:40:06 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 12 Sep 2007 10:40:06 +1000 Subject: Announcing rpmfusion In-Reply-To: <20070911160537.696c6a25@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> Message-ID: <1189557606.4727.14.camel@localhost.localdomain> On Tue, 2007-09-11 at 16:05 -0400, Jesse Keating wrote: > On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) > Kevin Kofler wrote: > > > Rahul Sundaram fedoraproject.org> writes: > > > Thanks for this split. Hopefully we will able to link to the free > > > part from within Fedora. > > > > Unfortunately I don't think you will be able to. The stuff in the > > free part (or most of it, at least) is going to be exactly the stuff > > which Legal is most uncomfortable with: Free Software, but > > patent-encumbered in the US. > > And really, if we could reference it, then why the crap couldn't we > just package it in our repo? The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens. Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer? R. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- "It's a fine line between denial and faith. It's much better on my side" From jspaleta at gmail.com Wed Sep 12 00:53:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Sep 2007 16:53:55 -0800 Subject: Announcing rpmfusion In-Reply-To: <1189557606.4727.14.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> Message-ID: <604aa7910709111753u54fce8a1pfa3ce53f843f0c17@mail.gmail.com> On 9/11/07, Rodd Clarkson wrote: > The installer asks you to locate your time-zone. Couldn't you use this > as a trigger for including the US patent encumbered stuff for non US > citizens. I'm pretty sure it would be just as inappropriate for me, as a US citizen, to be in a US embassy in Spain as it would be for me to be in Seattle. -jef"Clearly the solution is to start supporting US passport swiping technology at install time, so that each US citizen can 'register' with the US government their intent to perform a Fedora install, and the US government can tell the installer exactly what that US citizen is allowed to install, based on their personalized US government profile. Registered republicans would be unable to install 'gimp', registered Democrats would be unable to install 'gnucash', and Libertarians would be forced to install a government approved keylogger"spaleta From michel.sylvan at gmail.com Wed Sep 12 01:49:44 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 11 Sep 2007 21:49:44 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189557606.4727.14.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> Message-ID: On 11/09/2007, Rodd Clarkson wrote: > Oh and could this be used for setting my paper preference to A4 by > default instead of having to change this each time I set up a printer? > That is actually a good idea! Shouldn't something like this be standardized in Freedesktop.org ? -- Michel From skvidal at fedoraproject.org Wed Sep 12 01:50:18 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Sep 2007 21:50:18 -0400 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> Message-ID: <1189561818.6704.87.camel@cutter> On Tue, 2007-09-11 at 21:49 -0400, Michel Salim wrote: > On 11/09/2007, Rodd Clarkson wrote: > > > Oh and could this be used for setting my paper preference to A4 by > > default instead of having to change this each time I set up a printer? > > > That is actually a good idea! Shouldn't something like this be > standardized in Freedesktop.org ? > and with more and more distros using system-config-printer tied in there, too. -sv From mike at miketc.com Wed Sep 12 02:01:00 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 11 Sep 2007 21:01:00 -0500 Subject: Volume control problems Message-ID: <1189562460.15173.2.camel@scrappy.miketc.com> Latest rawhide install as of this morning, and am running into a volume control situation. It seems that the icon in the panel is muted and/or won't show a volume control. And the error message is something like below... No volume control GStreamer plugins and/or devices found. Yet if I do a detect sound card, it finds it (SB Audigy LS?) and plays the sample sound just fine. Any ideas? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From myfedora at richip.dhs.org Wed Sep 12 02:16:00 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 11 Sep 2007 20:16:00 -0600 Subject: Announcing rpmfusion In-Reply-To: <1189557422.4727.11.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> Message-ID: <1189563360.20578.4.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 10:37 +1000, Rodd Clarkson wrote: > On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote: > > On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote: > > > On Tue, 11 Sep 2007 20:03:51 +0200 > > > Jaroslaw Gorny wrote: > > > > > > > Another example: inclusion of mp3 support libraries, but without > > > > rebuilding audio players. > > > > > > > > If this is the case, wouldn't such a repo be useless? > > > > > > With things like gstreamer you don't have to rebuild audio apps. > > > gstreamer plugins will plug into the base gstreamer framework and audio > > > apps just make use of whatever plugins are available. > > > > Now if only that were as easy as "yum install gstreamer-plugin-lame" or > > "yum install lame-plugin-gstreamer" (in case you wanted to do "yum > > install lame lame-plugin-*"). > > It is that easy. go to rpm.livna.org and download the correct > repository rpm. Once this is installed, type: > > yum install gstreamer-plugins-bad I'm sorry. You missed my point. You can't just install lame and it's accompanying application plugins. Sure, you can install gstreamer-plugins-bad, but even different repositories have support for different libraries. Speaking of gstreamer-plugins-bad, I don't even grab mine from any repository. I have to compile my own as I use the timidity and wildmidi plugins (which aren't enabled in any of the repos, as far as I can tell). -- Richi Plana From rodd at clarkson.id.au Wed Sep 12 02:46:58 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 12 Sep 2007 12:46:58 +1000 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709111753u54fce8a1pfa3ce53f843f0c17@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> <604aa7910709111753u54fce8a1pfa3ce53f843f0c17@mail.gmail.com> Message-ID: <1189565218.4727.16.camel@localhost.localdomain> On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote: > On 9/11/07, Rodd Clarkson wrote: > > The installer asks you to locate your time-zone. Couldn't you use this > > as a trigger for including the US patent encumbered stuff for non US > > citizens. > > I'm pretty sure it would be just as inappropriate for me, as a US > citizen, to be in a US embassy in Spain as it would be for me to be in > Seattle. Okay, well then include a question about citizenship in the installer and use that! R. -- "It's a fine line between denial and faith. It's much better on my side" From notting at redhat.com Wed Sep 12 03:19:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Sep 2007 23:19:43 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189557606.4727.14.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> Message-ID: <20070912031943.GB28185@nostromo.devel.redhat.com> Rodd Clarkson (rodd at clarkson.id.au) said: > The installer asks you to locate your time-zone. Couldn't you use this > as a trigger for including the US patent encumbered stuff for non US > citizens. > > Oh and could this be used for setting my paper preference to A4 by > default instead of having to change this each time I set up a printer? Doesn't LC_PAPER cover this? Bill From loganjerry at gmail.com Wed Sep 12 03:31:30 2007 From: loganjerry at gmail.com (Jerry James) Date: Tue, 11 Sep 2007 21:31:30 -0600 Subject: findbugs & bcel Message-ID: <870180fe0709112031l6b33546l64b7248dd3c27858@mail.gmail.com> I'm hoping to get findbugs [1] packaged up for Fedora, as it's been a darn useful tool for me in the past. An asm3 package is hopefully on its way, and I've got the last 2 other prerequisites for it submitted [2][3]. However, I have discovered that findbugs depends on a modified (by the findbugs team) version of bcel 5.2. The modifications will not be submitted upstream [4]. We currently ship bcel 5.1. Is this a problem? Can I ship the modified bcel 5.2 JAR with findbugs, with a suitably modified name (perhaps findbugs-bcel.jar)? [1] http://findbugs.googlecode.com/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=262401 [3] https://bugzilla.redhat.com/show_bug.cgi?id=285551 [4] https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2007-August/002016.html -- Jerry James http://loganjerry.googlepages.com/ From nicolas.mailhot at laposte.net Wed Sep 12 05:42:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 07:42:36 +0200 Subject: Announcing rpmfusion In-Reply-To: <1189545479.13590.34.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <46E640B7.4030803@hhs.nl> <1189512816.4916.1.camel@dhollis-lnx.sunera.com> <46E6F19C.4010002@ncsu.edu> <1189545479.13590.34.camel@localhost6.localdomain6> Message-ID: <1189575756.3648.3.camel@rousalka.dyndns.org> Le mardi 11 septembre 2007 ? 15:17 -0600, Richi Plana a ?crit : > Unfortunately, spamassassin razor functionality probably couldn't be > separated into an optional package and Axel decided to name the combined > integrated package spamassassin "Spamassassion rezor functionnality" is one config setting upstream sets to off by default because razor licensing prohibits use in a commercial context. So you just need to chnage this setting to use fedora sa with razor as-is Try again -- 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 Wed Sep 12 06:08:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 08:08:08 +0200 Subject: Announcing rpmfusion In-Reply-To: <20070912031943.GB28185@nostromo.devel.redhat.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> <20070912031943.GB28185@nostromo.devel.redhat.com> Message-ID: <1189577288.4682.4.camel@rousalka.dyndns.org> Le mardi 11 septembre 2007 ? 23:19 -0400, Bill Nottingham a ?crit : > Rodd Clarkson (rodd at clarkson.id.au) said: > > The installer asks you to locate your time-zone. Couldn't you use this > > as a trigger for including the US patent encumbered stuff for non US > > citizens. > > > > Oh and could this be used for setting my paper preference to A4 by > > default instead of having to change this each time I set up a printer? > > Doesn't LC_PAPER cover this? If apps respected it. locale|grep PAPER LC_PAPER="fr_FR.UTF-8 ? should not be letter So many apps hardcode letter by default and revert to it at the slightest excuse it's not even remotely funny. (another favorite is if you press print in the app before powering on your printer, the system will remember the printer was stopped and you have to go into system-config-printer to restart the print queue) -- 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 Wed Sep 12 06:14:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 08:14:09 +0200 Subject: findbugs & bcel In-Reply-To: <870180fe0709112031l6b33546l64b7248dd3c27858@mail.gmail.com> References: <870180fe0709112031l6b33546l64b7248dd3c27858@mail.gmail.com> Message-ID: <1189577649.4682.10.camel@rousalka.dyndns.org> Le mardi 11 septembre 2007 ? 21:31 -0600, Jerry James a ?crit : > However, I have discovered that findbugs depends on a > modified (by the findbugs team) version of bcel 5.2. Typical java f-up > The > modifications will not be submitted upstream [4]. We currently ship > bcel 5.1. Is this a problem? Yes > Can I ship the modified bcel 5.2 JAR > with findbugs, with a suitably modified name (perhaps > findbugs-bcel.jar)? Please try very hard to get findbugs upstream to merge @bcel first. (Or ask bcel upstream to look at findbugs bcel to check if they can not pull stuff) Do remind them that when java 1.7 with 277 ships everyong will be asking for them to use the system bcel, not just Linux people. -- 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 harald at redhat.com Wed Sep 12 06:49:37 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 08:49:37 +0200 Subject: udev performance In-Reply-To: <20070911181552.GA5755@nostromo.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <20070911181552.GA5755@nostromo.devel.redhat.com> Message-ID: <46E78C01.7020006@redhat.com> Bill Nottingham schrieb: > Harald Hoyer (harald at redhat.com) said: >> Ok, did this with a rules-everything-rawhide on my laptop: >> >> 26 seconds >> >> 85% (22.3s) in modprobe > > That doesn't make sense. Why does adding more rules make it call > modprobe that much more? > > Bill > Different system -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From harald at redhat.com Wed Sep 12 07:04:09 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 09:04:09 +0200 Subject: udev performance In-Reply-To: <46E6B814.5000404@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> Message-ID: <46E78F69.5020400@redhat.com> Using a modprobe wrapper, I count 56 /sbin/modprobe calls taking ~4s (non-profiling udev) on my laptop, from which 23 are not found. 23 * /sbin/modprobe with a modalias, which is not found, sums up to ~1s (25%) of the time. So we can easily eliminate 25% of the modprobe time (on my laptop), by collecting all /sys/***/modalias at depmod time, which cannot be resolved, and store them in /lib/modules/$(uname -r)/modules.unresolved, which could be searched first by modprobe. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From jakub at redhat.com Wed Sep 12 07:23:31 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 12 Sep 2007 03:23:31 -0400 Subject: udev performance In-Reply-To: <46E78F69.5020400@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> Message-ID: <20070912072331.GQ20571@devserv.devel.redhat.com> On Wed, Sep 12, 2007 at 09:04:09AM +0200, Harald Hoyer wrote: > Using a modprobe wrapper, I count 56 /sbin/modprobe calls taking ~4s > (non-profiling udev) on my laptop, from which 23 are not found. > 23 * /sbin/modprobe with a modalias, which is not found, sums up to ~1s > (25%) of the time. > So we can easily eliminate 25% of the modprobe time (on my laptop), by > collecting all /sys/***/modalias at depmod time, which cannot be resolved, > and store them in /lib/modules/$(uname -r)/modules.unresolved, which could > be searched first by modprobe. BTW, each read_depends below will scan the whole modules.dep (if unsuccessful) or first part thereof. In the modprobes that take most of the time, is modules.dep read just once or multiple times? /* Returns the resolved alias, options */ read_toplevel_config(config, modulearg, 0, remove, &modoptions, &commands, &aliases, &blacklist); /* No luck? Try symbol names, if starts with symbol:. */ if (!aliases && strncmp(modulearg, "symbol:", strlen("symbol:")) == 0) read_config(symfilename, modulearg, 0, remove, &modoptions, &commands, &aliases, &blacklist); if (!aliases) { /* We only use canned aliases as last resort. */ read_depends(dirname, modulearg, &list); if (list_empty(&list) && !find_command(modulearg, commands)) { read_config(aliasfilename, modulearg, 0, remove, &modoptions, &commands, &aliases, &blacklist); aliases = apply_blacklist(aliases, blacklist); } } if (aliases) { errfn_t err = error; /* More than one alias? Don't bail out on failure. */ if (aliases->next) err = warn; while (aliases) { /* Add the options for this alias. */ char *opts = NOFAIL(strdup(optstring)); opts = add_extra_options(modulearg, opts, modoptions); read_depends(dirname, aliases->module, &list); handle_module(aliases->module, &list, newname, remove, opts, first_time, err, dry_run, verbose, modoptions, commands, ignore_commands, ignore_proc, strip_vermagic, strip_modversion, unknown_silent, optstring); aliases = aliases->next; INIT_LIST_HEAD(&list); } } else { if (use_blacklist && find_blacklist(modulearg, blacklist)) continue; handle_module(modulearg, &list, newname, remove, optstring, first_time, error, dry_run, verbose, modoptions, commands, ignore_commands, ignore_proc, strip_vermagic, strip_modversion, unknown_silent, optstring); } Jakub From harald at redhat.com Wed Sep 12 07:29:45 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 09:29:45 +0200 Subject: udev performance In-Reply-To: <20070912072331.GQ20571@devserv.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> Message-ID: <46E79569.3040301@redhat.com> Jakub Jelinek schrieb: > BTW, each read_depends below will scan the whole modules.dep (if unsuccessful) > or first part thereof. In the modprobes that take most of the time, is > modules.dep read just once or multiple times? Hmm, don't know exactly what you mean... attached are the times. modalias;real;user;sys First modprobe takes the longest, as it fills the cache. -------------- next part -------------- A non-text attachment was scrubbed... Name: tt.csv Type: text/csv Size: 2778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From fedora at theholbrooks.org Wed Sep 12 08:02:22 2007 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Wed, 12 Sep 2007 03:02:22 -0500 Subject: open-vm-tools Message-ID: <46E79D0E.2010409@theholbrooks.org> Hey all, So vmware announced to us this morning at vmworld that they are open sourcing their VMware Tools product; releasing their immediate code under GPL, and gradually moving development to SourceForge's SVN servers. You can get the tarball at http://open-vm-tools.sf.net/ As an every day user of vmware tools in Fedora, I'd love to be involved in packaging open-vm-tools (I've already compiled it several times and am quite pleased), so normally this would look like an opportunity to put together some SPECs and submit reviews. However, in vmware's announcement this morning they had some reaction quotes from their Linux distro partners, including RedHat, whom they informed about this decision several days ago. So since this particular package involves RedHat corporate partnerships and quotes and stuff like that, should I wait for RH employees to package this and then request myself be added as a comaintainer, or is this still up for grabs? -Brandon From aportal at univ-montp2.fr Wed Sep 12 07:56:22 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Wed, 12 Sep 2007 09:56:22 +0200 Subject: desc and summary In-Reply-To: <200709091230.29181.alain.portal@free.fr> References: <200709091230.29181.alain.portal@free.fr> Message-ID: <200709120956.23133.aportal@univ-montp2.fr> Le Sunday 09 September 2007 12:30:28 Alain PORTAL, vous avez ?crit?: > Hi, > > How are built these pot files? > > There are macro and tag in spec(ification) files, that accept options to > allow translations: > > Summary -> Summary(fr) > %description -> %description -l fr > > So, as packager of some programs, I always add the french translation of > description and summary in the spec file. > > But it seems that these translations aren't used to build the summary and > desc fr.po files. > > Why? Nobody can answer? -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From j.w.r.degoede at hhs.nl Wed Sep 12 08:02:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Sep 2007 10:02:24 +0200 Subject: Announcing rpmfusion In-Reply-To: <1189563360.20578.4.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> Message-ID: <46E79D10.6060902@hhs.nl> Richi Plana wrote: > On Wed, 2007-09-12 at 10:37 +1000, Rodd Clarkson wrote: >> On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote: >>> On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote: >>>> On Tue, 11 Sep 2007 20:03:51 +0200 >>>> Jaroslaw Gorny wrote: >>>> >>>>> Another example: inclusion of mp3 support libraries, but without >>>>> rebuilding audio players. >>>>> >>>>> If this is the case, wouldn't such a repo be useless? >>>> With things like gstreamer you don't have to rebuild audio apps. >>>> gstreamer plugins will plug into the base gstreamer framework and audio >>>> apps just make use of whatever plugins are available. >>> Now if only that were as easy as "yum install gstreamer-plugin-lame" or >>> "yum install lame-plugin-gstreamer" (in case you wanted to do "yum >>> install lame lame-plugin-*"). >> It is that easy. go to rpm.livna.org and download the correct >> repository rpm. Once this is installed, type: >> >> yum install gstreamer-plugins-bad > > I'm sorry. You missed my point. You can't just install lame and it's > accompanying application plugins. Sure, you can install > gstreamer-plugins-bad, but even different repositories have support for > different libraries. > > Speaking of gstreamer-plugins-bad, I don't even grab mine from any > repository. I have to compile my own as I use the timidity and wildmidi > plugins (which aren't enabled in any of the repos, as far as I can > tell). Argh, you are right they aren't enabled in livna. Next time please file a bug about things like this. I specially packaged libtimidity and wildimidi for Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for livna fixing this shortly. Regards, Hans From snecklifter at gmail.com Wed Sep 12 08:17:51 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 12 Sep 2007 09:17:51 +0100 Subject: open-vm-tools In-Reply-To: <46E79D0E.2010409@theholbrooks.org> References: <46E79D0E.2010409@theholbrooks.org> Message-ID: <364d303b0709120117me4a2471k83d566641fb0f126@mail.gmail.com> On 12/09/2007, Brandon Holbrook wrote: > > Hey all, > > So vmware announced to us this morning at vmworld that they are open > sourcing their VMware Tools product; releasing their immediate code > under GPL, and gradually moving development to SourceForge's SVN > servers. You can get the tarball at http://open-vm-tools.sf.net/ As an > every day user of vmware tools in Fedora, I'd love to be involved in > packaging open-vm-tools (I've already compiled it several times and am > quite pleased), so normally this would look like an opportunity to put > together some SPECs and submit reviews. However, in vmware's > announcement this morning they had some reaction quotes from their Linux > distro partners, including RedHat, whom they informed about this > decision several days ago. So since this particular package involves > RedHat corporate partnerships and quotes and stuff like that, should I > wait for RH employees to package this and then request myself be added > as a comaintainer, or is this still up for grabs? I don't see a review request and no-one should be "waiting" for other people to package something, just dive in! The following will help: http://open-vm-tools.wiki.sourceforge.net/Packaging Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald at redhat.com Wed Sep 12 08:31:06 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 10:31:06 +0200 Subject: udev performance In-Reply-To: <20070911181552.GA5755@nostromo.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <20070911181552.GA5755@nostromo.devel.redhat.com> Message-ID: <46E7A3CA.9060208@redhat.com> Bill Nottingham schrieb: > Harald Hoyer (harald at redhat.com) said: >> Ok, did this with a rules-everything-rawhide on my laptop: >> >> 26 seconds >> >> 85% (22.3s) in modprobe > > That doesn't make sense. Why does adding more rules make it call > modprobe that much more? > > Bill > Doh.. had one firmware loading timeout due to the sequential profiling code. Here are the numbers without the timeout: 80-drivers.rules 2,922281 46,57% 95-pam-console.rules 1,130553 18,02% 60-net.rules 0,552256 8,80% 60-persistent-storage.rules 0,443388 7,07% 60-libsane.rules 0,307528 4,90% 90-alsa.rules 0,265658 4,23% -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Wed Sep 12 08:31:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 14:01:17 +0530 Subject: open-vm-tools In-Reply-To: <46E79D0E.2010409@theholbrooks.org> References: <46E79D0E.2010409@theholbrooks.org> Message-ID: <46E7A3D5.2040507@fedoraproject.org> Brandon Holbrook wrote: > Hey all, > > So vmware announced to us this morning at vmworld that they are open > sourcing their VMware Tools product; releasing their immediate code > under GPL, and gradually moving development to SourceForge's SVN > servers. You can get the tarball at http://open-vm-tools.sf.net/ As an > every day user of vmware tools in Fedora, I'd love to be involved in > packaging open-vm-tools (I've already compiled it several times and am > quite pleased), so normally this would look like an opportunity to put > together some SPECs and submit reviews. However, in vmware's > announcement this morning they had some reaction quotes from their Linux > distro partners, including RedHat, whom they informed about this > decision several days ago. So since this particular package involves > RedHat corporate partnerships and quotes and stuff like that, should I > wait for RH employees to package this and then request myself be added > as a comaintainer, or is this still up for grabs? You don't really have to wait for anyone. If you are interested post a spec for review. If others want to participate, they can become co-maintainers. Rahul From nicolas.mailhot at laposte.net Wed Sep 12 08:36:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 10:36:40 +0200 (CEST) Subject: desc and summary In-Reply-To: <200709120956.23133.aportal@univ-montp2.fr> References: <200709091230.29181.alain.portal@free.fr> <200709120956.23133.aportal@univ-montp2.fr> Message-ID: <34302.192.54.193.51.1189586200.squirrel@rousalka.dyndns.org> Le Mer 12 septembre 2007 09:56, Alain PORTAL a ?crit : > Le Sunday 09 September 2007 12:30:28 Alain PORTAL, vous avez ?crit : >> Why? > > Nobody can answer? Because the rh localisation team decided years ago they wanted localisation in one place not spread over every package in the distro. IMHO this was a short-sighted decision as centralization does not scale and screws third-party repositories (basically anything the central project does not now of beforehand is not localised) But anyway: 1. you're looking for specspo 2. it'd be nice if you could talk with the people behind transifex to figure how to put localisation back in the individual packages where it belongs Regards, -- Nicolas Mailhot From denis at poolshark.org Wed Sep 12 08:37:58 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 12 Sep 2007 10:37:58 +0200 Subject: open-vm-tools In-Reply-To: <46E79D0E.2010409@theholbrooks.org> References: <46E79D0E.2010409@theholbrooks.org> Message-ID: <46E7A566.2050507@poolshark.org> Brandon Holbrook wrote: > Hey all, > > So vmware announced to us this morning at vmworld that they are open > sourcing their VMware Tools product; releasing their immediate code > under GPL, and gradually moving development to SourceForge's SVN > servers. You can get the tarball at http://open-vm-tools.sf.net/ As an > every day user of vmware tools in Fedora, I'd love to be involved in > packaging open-vm-tools (I've already compiled it several times and am > quite pleased), so normally this would look like an opportunity to put > together some SPECs and submit reviews. However, in vmware's > announcement this morning they had some reaction quotes from their Linux > distro partners, including RedHat, whom they informed about this > decision several days ago. So since this particular package involves > RedHat corporate partnerships and quotes and stuff like that, should I > wait for RH employees to package this and then request myself be added > as a comaintainer, or is this still up for grabs? Was going to work on it too as soon as I read the announcement. I say go right ahead and post a review to bugzilla. I'll help as co-maintainer and for testing. Or i'll do the review. -denis From jakub at redhat.com Wed Sep 12 08:48:35 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 12 Sep 2007 04:48:35 -0400 Subject: udev performance In-Reply-To: <46E79569.3040301@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> Message-ID: <20070912084835.GR20571@devserv.devel.redhat.com> On Wed, Sep 12, 2007 at 09:29:45AM +0200, Harald Hoyer wrote: > Jakub Jelinek schrieb: > >BTW, each read_depends below will scan the whole modules.dep (if > >unsuccessful) > >or first part thereof. In the modprobes that take most of the time, is > >modules.dep read just once or multiple times? > > Hmm, don't know exactly what you mean... attached are the times. > > modalias;real;user;sys > > First modprobe takes the longest, as it fills the cache. E.g. strace /sbin/modprobe pci:v0000104Cd0000803Bsv0000104Dsd000081EFbc01sc80i00 shows open("/lib/modules/2.6.22.1-27.fc7/modules.dep", O_RDONLY) = 3 + ~ 65 x 4KB read + parsing it in userspace open("/lib/modules/2.6.22.1-27.fc7/modules.alias", O_RDONLY) = 3 + ~ 65 x 4KB read + parsing it in userspace open("/lib/modules/2.6.22.1-27.fc7/modules.dep", O_RDONLY) = 3 + ~ 40 x 4KB read + parsing it in userspace While both the big files are probably cached already, even the reads from cache and especially parsing can mean significant time spent in it. I have ran 50 times /sbin/modprobe pci:v0000104Cd0000803Bsv0000104Dsd000081EFbc01sc80i00 under oprofile, 37.9% is spent in the kernel which I didn't have debuginfo for. But then we have: 0000003a628672a0 7031 24.6745 libc-2.6.so fgetc 0000000000402370 2974 10.4369 modprobe getline_wrapped 0000003a62877580 1299 4.5587 libc-2.6.so strpbrk 0000000000401310 871 3.0567 modprobe .plt 0000000000402d70 808 2.8356 modprobe underscores 0000003a628778c0 567 1.9898 libc-2.6.so strspn 0000003a62876a20 492 1.7266 libc-2.6.so strchr 0000003a6286e360 441 1.5476 libc-2.6.so malloc_consolidate 0000003a628705b0 396 1.3897 libc-2.6.so _int_malloc static int fgetc_wrapped(FILE *file, unsigned int *linenum) { for (;;) { int ch = fgetc(file); if (ch != '\\') return ch; ch = fgetc(file); if (ch != '\n') return ch; if (linenum) (*linenum)++; } } static char *getline_wrapped(FILE *file, unsigned int *linenum) { int size = 1024; int i = 0; char *buf = NOFAIL(malloc(size)); for(;;) { int ch = fgetc_wrapped(file, linenum); if (i == size) { size *= 2; buf = NOFAIL(realloc(buf, size)); } if (ch < 0 && i == 0) { free(buf); return NULL; } if (ch < 0 || ch == '\n') { if (linenum) (*linenum)++; buf[i] = '\0'; return NOFAIL(realloc(buf, i+1)); } buf[i++] = ch; } } Even just replacing fgetc with fgetc_unlocked should help tremendously, fgetc needs to lock the stream, so 2 atomic instructions per character plus it is a library call. fgetc_unlocked is inlined, needs no locking (modprobe isn't threaded, right?) and if there is anything buffered already (4095 out of 4096 times) it is just dereferencing a few pointers. The malloc/realloc/free per each line in the file (in my case 1486 malloc/frees times 2 for modules.dep and 5872 for modules.alias can be also avoided, from what I see all users of getline_wrapped always free what it returned and it is never called recursively. Which means there is no reason to malloc/free this every time. If instead this does: static int size = 0; static char *buf = NULL; ... if (i == size) { size = size ? size * 2 : 1024; buf = NOFAIL(realloc(buf, size)); } ... return buf; /* No second realloc. */ and never frees what getline_wrapped returned, you can always use the same buffer. Still, it is processing a significant amount of data, so while the above two proposed simple changes could give 10% or so, they won't kill the cost altogether. There are other inefficiencies all over, like: len = strlen(modname); if (strchr(modname, '.')) len = strchr(modname, '.') - modname; which gcc is at least ATM not able to optimize (while the duplicate strchr is called just once, gcc will call strlen unconditionally, even when it should be only called if strchr failed - though best is just use len = strchrnul(modname, '.') - modname; here. With a prepared binary blob which would include a hash table for easy finding of dependencies for a module we could just open that, and only once. If the binary blob starts with a magic number and then has st_ino/st_dev/st_ctime of both modules.dep and modules.aliases in the same dir, then you can easily keep the text files for handediting purposes and only use the binary blob if the text files haven't changed since the binary blob was recreated, and let the depmod or whatever creates the binary files also create the binary blob and have a mode in which it creates the blob from the text files rather than from whatever it found on disk. modules.dep searches just for the basenames of modules without extension and dir component, and ignores differences between - and _. So, just create a hash function which handles - and _ the same and gives good results on the usual module names and stick a hash table (e.g. with chains) after the file header, then the chains would contain the actual module name's basename for module_equal comparison, full 32-bit hash and pointer to where the full strings are found in the string table (which should probably be compressed using a directory table). module.aliases is harder, because it contains wildcards, so hash table isn't useful, but some kind of tree, where each node would contain a length, sorted prefixes of that length plus leaf nodes that contain wildcards at that point already and thus need to be tested all by fnmatch. Searching would just in each node test all the wildcardish leaf nodes, if none matched binary search for what matches the prefix and recurse into that node. E.g. root node could have length of minimum of smallest alias name and smallest number of chars before first wildcard in any alias name (unless that is zero, otherwise the alias names starting with wildcard would go into the set needed to go through fnmatch at that level). Jakub From harald at redhat.com Wed Sep 12 08:57:16 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 10:57:16 +0200 Subject: udev performance In-Reply-To: <20070912084835.GR20571@devserv.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> Message-ID: <46E7A9EC.6080702@redhat.com> Jakub Jelinek schrieb: > With a prepared binary blob which would include a hash table for easy > finding of dependencies for a module we could just open that, and only > once. If the binary blob starts with a magic number and then has > st_ino/st_dev/st_ctime of both modules.dep and modules.aliases in the > same dir, then you can easily keep the text files for handediting > purposes and only use the binary blob if the text files haven't > changed since the binary blob was recreated, and let the depmod or > whatever creates the binary files also create the binary blob and > have a mode in which it creates the blob from the text files rather > than from whatever it found on disk. > modules.dep searches just for the basenames of modules without extension > and dir component, and ignores differences between - and _. So, just create > a hash function which handles - and _ the same and gives good results > on the usual module names and stick a hash table (e.g. with chains) > after the file header, then the chains would contain the actual module > name's basename for module_equal comparison, full 32-bit hash and pointer > to where the full strings are found in the string table (which should probably be > compressed using a directory table). module.aliases is harder, because > it contains wildcards, so hash table isn't useful, but some kind of > tree, where each node would contain a length, sorted prefixes of that > length plus leaf nodes that contain wildcards at that point already and > thus need to be tested all by fnmatch. Searching would just in each node > test all the wildcardish leaf nodes, if none matched binary search > for what matches the prefix and recurse into that node. > E.g. root node could have length of minimum of smallest alias name > and smallest number of chars before first wildcard in any alias name > (unless that is zero, otherwise the alias names starting with > wildcard would go into the set needed to go through fnmatch at that level). > > Jakub udev linked with libmodprobe.so, reading the config only once and having the above search tables in memory, would be the fastest solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From chitlesh at fedoraproject.org Wed Sep 12 09:01:14 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 12 Sep 2007 11:01:14 +0200 Subject: Licensing: dual licenses - icons Message-ID: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> Hello there, My package kmenu-gnome entails some icons taken from right to left by upstream. Upstream uses a dual license. I've changed the license from GPL/LGPL to LGPLv2 on the last rebuild. However I'm not sure that the icons taken from GPL'd packages may be relicensed under the LGPL. Althouh ?3 of the LGPL allows relicensing LGPL-licensed code or data under the LGPL, I have not found such permission in the GPL. Or, perhaps, simple data files like icons are not treated as binary executables and the difference between GPL/LGPL does not matter? As on the wiki page: http://fedoraproject.org/wiki/Licensing, the 2 matrices refer to : * code and * libraries. As for icons/artwork, what will the matrices proposed? Shall I revert to the old dual license of GPL/LGPL, use the more lenient LGPL since the package does not contain binary executables, or unify its license under the GPL, a move permited by ?3 of the LGPL? regards, Chitlesh -- http://clunixchit.blogspot.com From buildsys at redhat.com Wed Sep 12 09:08:59 2007 From: buildsys at redhat.com (Build System) Date: Wed, 12 Sep 2007 05:08:59 -0400 Subject: rawhide report: 20070912 changes Message-ID: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> New package boswars Bos Wars is a futuristic real-time strategy game New package dbench Filesystem load benchmarking tool New package ksirk Turnbased multiplayer board strategy game (conquer the world!) New package wdaemon Hotplug helper for Wacom X.org driver Updated Packages: GConf2-2.19.1-5.fc8 ------------------- * Tue Sep 11 2007 Matthias Clasen - 2.19.1-5 - Some more leak fixes * Tue Sep 11 2007 Matthias Clasen - 2.19.1-4 - Fix memory leaks apr-1.2.11-1 ------------ * Sun Sep 09 2007 Bojan Smojver 1.2.11-1 - bump up to 1.2.11 - drop openlfs patch (fixed upstream) * Sun Sep 02 2007 Joe Orton 1.2.9-4 - fix API/ABI of 32-bit builds (#254241) * Tue Aug 21 2007 Joe Orton 1.2.9-2 - fix License apr-util-1.2.10-1 ----------------- * Sun Sep 09 2007 Bojan Smojver 1.2.10-1 - bump up to 1.2.10 - pick up newly checked in MySQL DBD driver directly from ASF - remove dbdopen patch (fixed upstream) - remove xmlns patch (fixed upstream) - remove autoexpat patch (fixed upstream) bigboard-0.5.15-1.fc8 --------------------- * Mon Sep 10 2007 Colin Walters - 0.5.15-1 - new upstream bigloo-3.0b-1.fc8 ----------------- * Tue Sep 11 2007 Gerard Milmeister - 3.0b-1 - new release 3.0b childsplay_plugins-0.90-2.fc8 ----------------------------- * Tue Sep 11 2007 Hans de Goede 0.90-2 - Adapt gcompris alphabet sounds using patch for new gcompris alphabet sounds location devhelp-0.16-1.fc8 ------------------ * Tue Sep 11 2007 Matthew Barnes - 0.16-1.fc8 - Update to 0.16 emacs-22.1-4.fc8 ---------------- * Mon Sep 10 2007 Chip Coldwell - 22.1-4 - fix pkgconfig path (from pkg-config to pkgconfig (Jonathan Underwood) - use macro instead of variable style for buildroot. evolution-2.11.92-3.fc8 ----------------------- * Tue Sep 11 2007 Matthew Barnes - 2.11.92-3.fc8 - Add patch for GNOME bug #476040 (fix attachment icon). * Sat Sep 08 2007 Matthias Clasen - 2.11.92-2.fc8 - Split off an evolution-help package * Mon Sep 03 2007 Matthew Barnes - 2.11.92-1.fc8 - Update to 2.11.92 exaile-0.2.10-3.fc8 ------------------- * Tue Sep 11 2007 Deji Akingunola - 0.2.10-3 - Require pygtk2-libglade (BZ #278471) firefox-2.0.0.6-8.fc8 --------------------- * Tue Sep 11 2007 Christopher Aillon 2.0.0.6-8 - Fix crashes when using GTK+ themes containing a gtkrc which specify GtkOptionMenu::indicator_size and GtkOptionMenu::indicator_spacing flac-1.2.0-2.fc8 ---------------- * Tue Sep 11 2007 - Bastien Nocera - 1.2.0-2 - Update GNU stack patch to cover all the NASM sources used * Mon Sep 10 2007 - Bastien Nocera - 1.2.0-1 - Update for 1.20 and drop obsolete patches (#285161) * Fri Aug 24 2007 Adam Jackson - 1.1.4-5 - Rebuild for build ID gcompris-8.4-1.fc8 ------------------ * Tue Sep 11 2007 Hans de Goede 8.4-1 - New upstream release 8.4 - Drop -flags sub-package, the idea was that by putting the flags in a subpackage they could be used by other packages, but this never happened. - License changed to GPL version 3 (or higher) gnome-session-2.19.92-3.fc8 --------------------------- * Tue Sep 11 2007 Matthias Clasen - 2.19.92-3 - Plug memory leaks in the ICE code gnome-user-share-0.11-9.fc8 --------------------------- * Tue Sep 11 2007 Matthias Clasen - 0.11-9 - Fix a memory leak gperiodic-2.0.10-2.fc8 ---------------------- * Sat Sep 08 2007 Eric Tanguy 2.0.10-2 - Patch to erase DGTK_DISABLE_DEPRECATED flag from the Makefile * Sat Sep 08 2007 Eric Tanguy 2.0.10-1 - New upstream version gtksourceview2-1.90.5-1.fc8 --------------------------- * Tue Sep 11 2007 Matthew Barnes - 1.90.5-1 - Update to 1.90.5 highlight-2.6.3-1.fc8 --------------------- * Tue Sep 11 2007 Jochen Schmitt 2.6.3-1 - New upstream release kernel-2.6.23-0.174.rc6.fc8 --------------------------- * Tue Sep 11 2007 Chuck Ebbert - fix emulated vmware SCSI disks - add option to disable libata PATA DMA * Tue Sep 11 2007 Chuck Ebbert - utrace update * Tue Sep 11 2007 Chuck Ebbert - Linux 2.6.23-rc6 krb5-1.6.2-8.fc8 ---------------- * Tue Sep 11 2007 Nalin Dahyabhai 1.6.2-8 - move the db2 kdb plugin from -server to -libs, because a multilib libkdb might need it * Tue Sep 11 2007 Nalin Dahyabhai 1.6.2-7 - also perform PAM session and credential management when ftpd accepts a client using strong authentication, missed earlier - also label kadmind log files and files created by the db2 plugin * Thu Sep 06 2007 Nalin Dahyabhai 1.6.2-6 - incorporate updated fix for CVE-2007-3999 - fix incorrect call to "test" in the kadmin init script libpng10-1.0.28-1.fc8 --------------------- * Tue Sep 11 2007 Paul Howarth 1.0.28-1 - update to 1.0.28 librsvg2-2.18.2-2.fc8 --------------------- * Tue Sep 11 2007 Matthias Clasen - 2.18.2-2 - Plug memory leaks metacity-2.19.55-4.fc8 ---------------------- * Tue Sep 11 2007 Ray Strode - 2.19.55-4 - fix crash on logout (and on the subsequent login, bug 243761) mkinitrd-6.0.16-1.fc8 --------------------- * Tue Sep 11 2007 Peter Jones - 6.0.16-1 - Fix handling of CCISS one more time (bz#274201) mksh-31b-1.fc8 -------------- * Tue Sep 11 2007 Robert Scheck 31b-1 - Upgrade to 31b - Use script to get %check happy (thanks to Thorsten Glaser) mugshot-1.1.52-2.fc8 -------------------- * Tue Sep 11 2007 Colin Walters - 1.1.52-2 - shuffle .sos around (b.r.c 286371) - make devel package require dbus-devel nsd-3.0.6-1.fc8 --------------- * Tue Sep 11 2007 Paul Wouters 3.0.6-1 - Upgraded to 3.0.6 - Do not include bind2nsd, since it didn't compile for me * Fri Jul 13 2007 Paul Wouters 3.0.5-2 - Fix init script, bug #245546 ode-0.8.1-0.1.rc1.fc8 --------------------- * Tue Sep 11 2007 Hans de Goede 0.8.1-0.1.rc1 - New upstream release 0.8.1-rc1 online-desktop-0.2.12-2.fc8 --------------------------- * Tue Sep 11 2007 Colin Walters - 0.2.12-2 - require devilspie pdns-2.9.21-2.fc8 ----------------- * Tue Sep 11 2007 Ruben Kerkhof 2.9.21-2 - Fix license tag - Add README for geo backend to docs php-pear-PHPUnit-3.1.8-1.fc8 ---------------------------- * Sat Sep 08 2007 Christopher Stone 3.1.8-1 - Upstream sync pm-utils-0.99.4-2.fc8 --------------------- * Tue Sep 11 2007 Till Maas - 0.99.4-2 - Require vbetool not on ppc and ppc64 policycoreutils-2.0.25-12.fc8 ----------------------------- * Tue Sep 11 2007 Dan Walsh 2.0.25-12 - Remove bogus import libxml2 pygtksourceview-1.90.5-1.fc8 ---------------------------- * Tue Sep 11 2007 Matthew Barnes - 1.90.5-1 - Update to 1.90.5 python-virtinst-0.300.0-3.fc8 ----------------------------- * Tue Sep 11 2007 Daniel P. Berrange - 0.300.0-3.fc8 - Fixed default architecture. Again. * Tue Sep 11 2007 Daniel P. Berrange - 0.300.0-2.fc8 - Fixed detection of Fedora 8 distro trees (rhbz #273781) * Wed Aug 29 2007 Daniel P. Berrange - 0.300.0-1.fc8 - Updated to 0.300.0 - Added virt-image tool - Switched to calling virsh console and virt-viewer - Improved user input validation rpm-4.4.2.2-0.5.rc2 ------------------- * Tue Sep 11 2007 Panu Matilainen 4.4.2.2-0.5.rc2 - 4.4.2.2-rc2 - resolves #180996, #281611, #259961, #277161, #155079 - drop debugedit-names patch now that it's really upstream samba-0:3.0.26a-0.fc8 --------------------- * Tue Sep 11 2007 Simo Sorce 3.0.26a-0.fc8 - upgrade to the latest upstream realease - includes security fixes released today in 3.0.26 selinux-policy-3.0.7-10.fc8 --------------------------- * Tue Sep 11 2007 Dan Walsh 3.0.7-10 - Allow NetworkManager to dbus chat with yum-updated * Tue Sep 11 2007 Dan Walsh 3.0.7-9 - Allow xfs to bind to port 7100 suck-4.3.2-18.fc8 ----------------- * Mon Sep 10 2007 Jochen Schmitt 4.3.2-18 - Allow usage of several sites thunderbird-2.0.0.6-4.fc8 ------------------------- * Tue Sep 11 2007 Christopher Aillon 2.0.0.6-4 - Fix crashes when using GTK+ themes containing a gtkrc which specify GtkOptionMenu::indicator_size and GtkOptionMenu::indicator_spacing tracker-0.6.2-2.fc8 ------------------- * Tue Sep 11 2007 Deji Akingunola - 0.6.2-2 - Make trackerd start on x86_64 (Bug #286361, fix by Will Woods) wordpress-2.2.3-0.fc8 --------------------- * Tue Sep 11 2007 Adrian Reber - 2.2.3-0 - updated to 2.2.3 (security release) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From tagoh at redhat.com Wed Sep 12 09:11:23 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 12 Sep 2007 18:11:23 +0900 (JST) Subject: [Guidelines Change] Emacs Guidelines In-Reply-To: <1189535065.3964.24.camel@localhost.localdomain> References: <1189535065.3964.24.camel@localhost.localdomain> Message-ID: <20070912.181123.861063662.tagoh@redhat.com> >>>>> On Tue, 11 Sep 2007 14:24:25 -0400, >>>>> "TC" == "Tom \"spot\" Callaway" wrote: TC> New guidelines describing how to package GNU Emacs and XEmacs addon TC> packages can be found here: TC> http://fedoraproject.org/wiki/Packaging/Emacs I just looked at that guideline and realized that the template suggests making emacs-common-%{pkg} as srpm. I thought CVS module name should be the same as srpm name and it should be usually the same as the upstream tarball name or what they prefer. or does this mean we are going to make an exception for Emacsen packages to have such CVS module name? Regards, -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Wed Sep 12 09:13:57 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 12 Sep 2007 05:13:57 -0400 Subject: udev performance In-Reply-To: <46E7A9EC.6080702@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> <46E7A9EC.6080702@redhat.com> Message-ID: <20070912091357.GS20571@devserv.devel.redhat.com> On Wed, Sep 12, 2007 at 10:57:16AM +0200, Harald Hoyer wrote: > udev linked with libmodprobe.so, reading the config only once and having > the above search tables in memory, would be the fastest solution. No. If they are just read, rather than preparing hash table for modules.dep and search tree for modules.alias, then you just avoid the cost of reading it many times, but still spend the significant time parsing the data to find what you are looking for. Jakub From kevin.kofler at chello.at Wed Sep 12 09:16:10 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 12 Sep 2007 09:16:10 +0000 (UTC) Subject: Licensing: dual licenses - icons References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > However I'm not sure that the icons taken from GPL'd packages may be > relicensed under the LGPL. Althouh ?3 of the LGPL allows relicensing > LGPL-licensed code or data under the LGPL, I have not found such > permission in the GPL. GPL->LGPL is not a valid conversion indeed. > Or, perhaps, simple data files like icons are not treated as binary > executables and the difference between GPL/LGPL does not matter? It's more likely that the affected upstream projects either aren't aware of what's going on or don't really care about the license for something as simple as an icon. Most likely both. Still, it's bad. > Shall I revert to the old dual license of GPL/LGPL, use the more > lenient LGPL since the package does not contain binary executables, or > unify its license under the GPL, a move permited by ?3 of the LGPL? I'd say declare the license as GPL to be on the safe side. In this context, it probably doesn't make a real difference anyway. (How do you "link" a menu icon?) Kevin Kofler From harald at redhat.com Wed Sep 12 09:18:21 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 11:18:21 +0200 Subject: udev performance In-Reply-To: <20070912091357.GS20571@devserv.devel.redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> <46E7A9EC.6080702@redhat.com> <20070912091357.GS20571@devserv.devel.redhat.com> Message-ID: <46E7AEDD.5050608@redhat.com> Jakub Jelinek schrieb: > On Wed, Sep 12, 2007 at 10:57:16AM +0200, Harald Hoyer wrote: >> udev linked with libmodprobe.so, reading the config only once and having >> the above search tables in memory, would be the fastest solution. > > No. If they are just read, rather than preparing hash table for > modules.dep and search tree for modules.alias, then you just avoid > the cost of reading it many times, but still spend the significant > time parsing the data to find what you are looking for. > > Jakub > And that data parsing time can also be reduced by collecting the unresolvable modaliases at depmod time. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Wed Sep 12 09:15:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 14:45:50 +0530 Subject: Licensing: dual licenses - icons In-Reply-To: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> Message-ID: <46E7AE46.9030803@fedoraproject.org> Chitlesh GOORAH wrote: > Hello there, > > My package kmenu-gnome entails some icons taken from right to left by > upstream. Right to left as in random places? If so upstream needs to verify the licenses of these icons carefully. Upstream uses a dual license. I've changed the license from > GPL/LGPL to LGPLv2 on the last rebuild. You are not allowed to change the license of a package. However when you distribute software which is dual licensed, you are allowed to distribute under any one of those license if you wish to do so. > > However I'm not sure that the icons taken from GPL'd packages may be > relicensed under the LGPL. It does not. However the other way around is possible. What problem are you trying to solve? Rahul From chitlesh at fedoraproject.org Wed Sep 12 09:29:50 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 12 Sep 2007 11:29:50 +0200 Subject: Licensing: dual licenses - icons In-Reply-To: <46E7AE46.9030803@fedoraproject.org> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> Message-ID: <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> On 9/12/07, Rahul Sundaram wrote: > Right to left as in random places? If so upstream needs to verify the > licenses of these icons carefully. We are both uncertain about the licensing right now. That's why I'm asking on this mailing list. > It does not. However the other way around is possible. What problem are > you trying to solve? The problem I'm trying to solve is: which license should I use with fedora's new licensing guidelines ? On 9/12/07, Kevin Kofler wrote: > GPL->LGPL is not a valid conversion indeed. Ok, for now I'll be using GPLv2. > It's more likely that the affected upstream projects either aren't aware of > what's going on or don't really care about the license for something as simple > as an icon. Most likely both. Still, it's bad. kmenu-gnome's upstream cares, but needs advice. > I'd say declare the license as GPL to be on the safe side. In this context, it > probably doesn't make a real difference anyway. (How do you "link" a menu > icon?) The icons are listed on the desktop files. Chitlesh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Wed Sep 12 09:31:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 15:01:47 +0530 Subject: Licensing: dual licenses - icons In-Reply-To: <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> Message-ID: <46E7B203.7040106@fedoraproject.org> Chitlesh GOORAH wrote: > On 9/12/07, Rahul Sundaram wrote: >> Right to left as in random places? If so upstream needs to verify the >> licenses of these icons carefully. > > We are both uncertain about the licensing right now. That's why I'm > asking on this mailing list. If upstream isn't sure about the license of the icons they picked they should remove and replace them with properly licensed icons, be it LGPL, GPL or another license. There are many such good icon sets. Rahul From skvidal at fedoraproject.org Wed Sep 12 10:01:27 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Sep 2007 06:01:27 -0400 Subject: open-vm-tools In-Reply-To: <46E79D0E.2010409@theholbrooks.org> References: <46E79D0E.2010409@theholbrooks.org> Message-ID: <1189591287.6704.91.camel@cutter> On Wed, 2007-09-12 at 03:02 -0500, Brandon Holbrook wrote: > Hey all, > > So vmware announced to us this morning at vmworld that they are open > sourcing their VMware Tools product; releasing their immediate code > under GPL, and gradually moving development to SourceForge's SVN > servers. You can get the tarball at http://open-vm-tools.sf.net/ As an > every day user of vmware tools in Fedora, I'd love to be involved in > packaging open-vm-tools (I've already compiled it several times and am > quite pleased), so normally this would look like an opportunity to put > together some SPECs and submit reviews. However, in vmware's > announcement this morning they had some reaction quotes from their Linux > distro partners, including RedHat, whom they informed about this > decision several days ago. So since this particular package involves > RedHat corporate partnerships and quotes and stuff like that, should I > wait for RH employees to package this and then request myself be added > as a comaintainer, or is this still up for grabs? Brandon, Just to pile on the answers you've already gotten: There is no need to wait for anyone who works for Red Hat to do anything. In all seriousness, the success of Fedora is that there is no longer the requirement to wait for approval or first motion of anyone who works for Red Hat (myself included). Thanks for asking but more importantly thanks for wanting to work on things. -sv From chitlesh at fedoraproject.org Wed Sep 12 10:06:58 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 12 Sep 2007 12:06:58 +0200 Subject: Licensing: dual licenses - icons In-Reply-To: <46E7B203.7040106@fedoraproject.org> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> <46E7B203.7040106@fedoraproject.org> Message-ID: <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> On 9/12/07, Rahul Sundaram wrote: > If upstream isn't sure about the license of the icons they picked they > should remove and replace them with properly licensed icons, be it LGPL, > GPL or another license. There are many such good icon sets. > Upstream IS SURE about the licenses of the icons see: /usr/share/doc/kmenu-gnome-0.6.8/COPYING As you can see icons are either GPL'd or LGPL'd. http://chitlesh.fedorapeople.org/COPYING Now, which license is appropriate ? GPLv2, LGPLv2 or GPLv2/LGPLv2 ? As I can see GPLv2 is more appropriate. Do you second ? Chitlesh. PS: we are working to replace the icons in the sources by requiring the appropriate packages. However, we are struggling to cope with the differences among various distributions. Progress is being made. -- http://clunixchit.blogspot.com From rc040203 at freenet.de Wed Sep 12 10:11:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 12 Sep 2007 12:11:57 +0200 Subject: Licensing: dual licenses - icons In-Reply-To: <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> <46E7B203.7040106@fedoraproject.org> <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> Message-ID: <1189591917.3157.237.camel@mccallum.corsepiu.local> On Wed, 2007-09-12 at 12:06 +0200, Chitlesh GOORAH wrote: > On 9/12/07, Rahul Sundaram wrote: > > If upstream isn't sure about the license of the icons they picked they > > should remove and replace them with properly licensed icons, be it LGPL, > > GPL or another license. There are many such good icon sets. > > > > Upstream IS SURE about the licenses of the icons see: > /usr/share/doc/kmenu-gnome-0.6.8/COPYING > > As you can see icons are either GPL'd or LGPL'd. > http://chitlesh.fedorapeople.org/COPYING > > Now, which license is appropriate ? GPLv2, LGPLv2 or GPLv2/LGPLv2 ? > > As I can see GPLv2 is more appropriate. Do you second ? No. Your list mentions some icons to be GPL'ed and some to be LGPL'ed. I.e. if you want to use them as source files inside of one single package, GPL (rsp. GPLv2) is the _only_ possibility for this package's licensing. Ralf From sundaram at fedoraproject.org Wed Sep 12 10:12:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 15:42:29 +0530 Subject: Licensing: dual licenses - icons In-Reply-To: <1189591917.3157.237.camel@mccallum.corsepiu.local> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> <46E7B203.7040106@fedoraproject.org> <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> <1189591917.3157.237.camel@mccallum.corsepiu.local> Message-ID: <46E7BB8D.5090605@fedoraproject.org> Ralf Corsepius wrote: > On Wed, 2007-09-12 at 12:06 +0200, Chitlesh GOORAH wrote: >> On 9/12/07, Rahul Sundaram wrote: >>> If upstream isn't sure about the license of the icons they picked they >>> should remove and replace them with properly licensed icons, be it LGPL, >>> GPL or another license. There are many such good icon sets. >>> >> Upstream IS SURE about the licenses of the icons see: >> /usr/share/doc/kmenu-gnome-0.6.8/COPYING >> >> As you can see icons are either GPL'd or LGPL'd. >> http://chitlesh.fedorapeople.org/COPYING >> >> Now, which license is appropriate ? GPLv2, LGPLv2 or GPLv2/LGPLv2 ? >> >> As I can see GPLv2 is more appropriate. Do you second ? > No. Your list mentions some icons to be GPL'ed and some to be LGPL'ed. > > I.e. if you want to use them as source files inside of one single > package, GPL (rsp. GPLv2) is the _only_ possibility for this package's > licensing. Correct. When you combine packages with more permissive and less permissive copyleft licenses, the license with the least permissions apply to the combination. Rahul From billcrawford1970 at gmail.com Wed Sep 12 10:20:59 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 12 Sep 2007 11:20:59 +0100 Subject: Announcing rpmfusion In-Reply-To: <1189557422.4727.11.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> Message-ID: <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> On 12/09/2007, Rodd Clarkson wrote: > On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote: ... > > Now if only that were as easy as "yum install gstreamer-plugin-lame" or > > "yum install lame-plugin-gstreamer" (in case you wanted to do "yum > > install lame lame-plugin-*"). > > It is that easy. go to rpm.livna.org and download the correct > repository rpm. Once this is installed, type: > > yum install gstreamer-plugins-bad Exactly. Not specific. > This will install the mp3 codec along with a bunch of other 'bad' > codecs. Quite. Again, it would be nice to be able to install *the plugin that's wanted*. And *only* the plugin that's wanted. From nicu_fedora at nicubunu.ro Wed Sep 12 10:31:32 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 12 Sep 2007 13:31:32 +0300 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> Message-ID: <46E7C004.9000707@nicubunu.ro> Bill Crawford wrote: > On 12/09/2007, Rodd Clarkson wrote: >> yum install gstreamer-plugins-bad >> This will install the mp3 codec along with a bunch of other 'bad' >> codecs. > > Quite. Again, it would be nice to be able to install *the plugin that's wanted*. > > And *only* the plugin that's wanted. Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From billcrawford1970 at gmail.com Wed Sep 12 10:47:44 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 12 Sep 2007 11:47:44 +0100 Subject: Announcing rpmfusion In-Reply-To: <46E7C004.9000707@nicubunu.ro> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> Message-ID: <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> On 12/09/2007, Nicu Buculei wrote: ... > Balance this with the convenience, useful for most users, to not have to > hunt for codecs/plugins, install one package and be sure the multimedia > playing troubles are solved. "not have to hunt for" => either 1) *all* plugins, evar, are in the one package, innit OR 2) each plugin is appropriately named (and perhaps we need some extra Provides: or maybe a package that pulls in appropriate ones via Requires:, so that one can indeed install "DVD support" and get libdvd{read,nav,css} pulled in, the last of them should of course be optional). Seriously, that's half the problem. When I want "mp3 playing" support, I have to install "xine-lib-moles" ... From agostino.russo at gmail.com Wed Sep 12 10:43:45 2007 From: agostino.russo at gmail.com (Ago) Date: Wed, 12 Sep 2007 10:43:45 +0000 (UTC) Subject: Windows based installation of Fedora Linux? Message-ID: Hi all, I am Wubi's author. I'd be happy to help you out if you wish to implement something like Wubi for Fedora. I will not have much time to do actual coding but at least I can point you out to the relevant code snippets (which is spread over different projects and files). As you are probably aware Wubi is now included within Ubuntu 7.10. The interface will change slightly to reflect that. Notably it is now also possible to boot a LiveCD/ISO from HD (handy to go around bios issues and helping out people with no CD). The frontend can be used almost as is, you need to change the branding, version.nsh, IsoList.ini, and preseed.nsh (to generate appropriate preseeding information for an automatic installation). There should be little Ubuntu/Debian specific code in there. The relevant code is in: https://launchpad.net/~ubuntu-installer/wubi/gutsy. If you want to submit patches to "isolate" even more the frontend from Ubuntu specific code, you are most welcome. On the backend side, you need to have ntfs-3g pre-installed by default (https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs), have an installer that can work in non-interactive mode (https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-automation), modify the standard initrd (grep loop in https://launchpad.net/ubuntu/+source/initramfs- tools) and the liveCD initrd (https://launchpad.net/~ubuntu- installer/lupin/gutsy). And of course have the installer be aware of loopfile targets (https://code.launchpad.net/~ubuntu-core-dev/partman-auto-loop/ubuntu). If you kill all userspace processes at shutdown you have to skip fuse/ntfs-g (https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763). Note: if you poked with the old installer, things have changed quite a bit. We used to embed the initrd within the frontend, and that initrd used to override the ISO initrd/standard installer which in turns used to override the installed (normal boot) initrd. It does not work like that anymore, all initrd changes (liveCD initrd and normal-boot initrd) have been moved upstream and the frontend extracts the initrd directly from the CD/ISO. Hope it helps. Regards, Ago From jonathan.underwood at gmail.com Wed Sep 12 10:54:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 12 Sep 2007 11:54:19 +0100 Subject: [Guidelines Change] Emacs Guidelines In-Reply-To: <20070912.181123.861063662.tagoh@redhat.com> References: <1189535065.3964.24.camel@localhost.localdomain> <20070912.181123.861063662.tagoh@redhat.com> Message-ID: <645d17210709120354l645fef19l9be293e88f5131e3@mail.gmail.com> On 12/09/2007, Akira TAGOH wrote: > >>>>> On Tue, 11 Sep 2007 14:24:25 -0400, > >>>>> "TC" == "Tom \"spot\" Callaway" wrote: > > TC> New guidelines describing how to package GNU Emacs and XEmacs addon > TC> packages can be found here: > TC> http://fedoraproject.org/wiki/Packaging/Emacs > > I just looked at that guideline and realized that the > template suggests making emacs-common-%{pkg} as srpm. I > thought CVS module name should be the same as srpm name and > it should be usually the same as the upstream tarball name > or what they prefer. or does this mean we are going to make > an exception for Emacsen packages to have such CVS module > name? Yes - that's been the case for a long time now - this comes from the previous package naming guidelines and was discussed at length previously - please see threads on fedora-packaging recently for those references. From nicolas.mailhot at laposte.net Wed Sep 12 11:07:38 2007 From: nicolas.mailhot at laposte.net (nicolas.mailhot at laposte.net) Date: Wed, 12 Sep 2007 13:07:38 +0200 (CEST) Subject: [Guidelines Change] Emacs Guidelines Message-ID: <22261365.1497251189595258182.JavaMail.www@wwinf8402> > I thought CVS module name should be the same as srpm > name Yes > and it should be usually the same as the upstream > tarball name This is not even remotely true for a huge proportion of our packages. For one, many upstreams have junk tarbal naming. srpm name/casing is 'what users are likely to expect' based on upstream project name and conventions used by similar packages. -- Nicolas Mailhot From rodd at clarkson.id.au Wed Sep 12 11:55:28 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 12 Sep 2007 21:55:28 +1000 Subject: Announcing rpmfusion In-Reply-To: <1189577288.4682.4.camel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> <20070912031943.GB28185@nostromo.devel.redhat.com> <1189577288.4682.4.camel@rousalka.dyndns.org> Message-ID: <1189598128.4727.24.camel@localhost.localdomain> On Wed, 2007-09-12 at 08:08 +0200, Nicolas Mailhot wrote: > Le mardi 11 septembre 2007 ? 23:19 -0400, Bill Nottingham a ?crit : > > Rodd Clarkson (rodd at clarkson.id.au) said: > > > The installer asks you to locate your time-zone. Couldn't you use this > > > as a trigger for including the US patent encumbered stuff for non US > > > citizens. > > > > > > Oh and could this be used for setting my paper preference to A4 by > > > default instead of having to change this each time I set up a printer? > > > > Doesn't LC_PAPER cover this? > > If apps respected it. > locale|grep PAPER > LC_PAPER="fr_FR.UTF-8 ? should not be letter Hmmm, I get [rodd at localhost ~]$ locale | grep PAPER LC_PAPER="en_US.UTF-8" I use US english, but I live in Australia (which is used as my timezone) so what should it do? Personally, I think it should default to ISO (A4) and then this might get the attention of US developers who find themselves using the wrong paper and fixing this properly. I don't know how many countries use non-ISO paper sizes, but there can't be too many (Rumor has it, it's the US and one small country nobody knows the name of) > So many apps hardcode letter by default and revert to it at the > slightest excuse it's not even remotely funny. (another favorite is if > you press print in the app before powering on your printer, the system > will remember the printer was stopped and you have to go into > system-config-printer to restart the print queue) I thought this was fixed, but maybe it isn't. It was (however) very annoying. R. -- "It's a fine line between denial and faith. It's much better on my side" From dmc.fedora at filteredperception.org Wed Sep 12 12:03:07 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 12 Sep 2007 07:03:07 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: Message-ID: <46E7D57B.8020902@filteredperception.org> Ago wrote: > Hi all, > > I am Wubi's author. I'd be happy to help you out if you wish to implement > something like Wubi for Fedora. I will not have much time to do actual coding > but at least I can point you out to the relevant code snippets (which is spread > over different projects and files). Since I've advocated a win32 installer for Fedora in the past, I'll at least say - cool. Unfortunately I also don't forsee myself having time to dedicate to this in the near future(nor the desire, as I am and hope to stay winblowz free ;). But I hope someone else finds the time :) Out of curiosity, I notice on your page mention of the ntfs-loopback method being somewhat brittle, as you suggest "don't yank the plug if you can avoid it". Can you point me to any further info on this issue. (mail list archive threads...) I think something similar is causing me trouble in a different scenario. Thanks again, very cool stuff. -dmc > > As you are probably aware Wubi is now included within Ubuntu 7.10. The > interface will change slightly to reflect that. Notably it is now also possible > to boot a LiveCD/ISO from HD (handy to go around bios issues and helping out > people with no CD). The frontend can be used almost as is, you need to change > the branding, version.nsh, IsoList.ini, and preseed.nsh (to generate > appropriate preseeding information for an automatic installation). There should > be little Ubuntu/Debian specific code in there. The relevant code is in: > https://launchpad.net/~ubuntu-installer/wubi/gutsy. If you want to submit > patches to "isolate" even more the frontend from Ubuntu specific code, you are > most welcome. > > On the backend side, you need to have ntfs-3g pre-installed by default > (https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs), have an > installer that can work in non-interactive mode > (https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-automation), modify the > standard initrd (grep loop in https://launchpad.net/ubuntu/+source/initramfs- > tools) and the liveCD initrd (https://launchpad.net/~ubuntu- > installer/lupin/gutsy). And of course have the installer be aware of loopfile > targets (https://code.launchpad.net/~ubuntu-core-dev/partman-auto-loop/ubuntu). > If you kill all userspace processes at shutdown you have to skip fuse/ntfs-g > (https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763). > > Note: if you poked with the old installer, things have changed quite a bit. We > used to embed the initrd within the frontend, and that initrd used to override > the ISO initrd/standard installer which in turns used to override the installed > (normal boot) initrd. It does not work like that anymore, all initrd changes > (liveCD initrd and normal-boot initrd) have been moved upstream and the > frontend extracts the initrd directly from the CD/ISO. > > Hope it helps. > > Regards, > > Ago > From kanarip at kanarip.com Wed Sep 12 12:41:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 12 Sep 2007 14:41:48 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E6F59B.7010506@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> Message-ID: <46E7DE8C.7020508@kanarip.com> Rahul Sundaram wrote: > Jesse Keating wrote: >> On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) >> Kevin Kofler wrote: >> >>> Rahul Sundaram fedoraproject.org> writes: >>>> Thanks for this split. Hopefully we will able to link to the free >>>> part from within Fedora. >>> Unfortunately I don't think you will be able to. The stuff in the >>> free part (or most of it, at least) is going to be exactly the stuff >>> which Legal is most uncomfortable with: Free Software, but >>> patent-encumbered in the US. >> >> And really, if we could reference it, then why the crap couldn't we >> just package it in our repo? > > There is a lot of differences between pointing to the repository and > including the packages directly as I already explained in Fedora > Advisory Board list so I won't rehash all the arguments again now. > Please read the releated threads if you missed it. In short, it is not > possible to include patent-encumbered packages directly in the > repository as long as it hosted in US. Pointing to it might very well be > possible. > Seriously though, this is just plain dumb wrong: If we cannot include the packages in our own repositories but we can point to other repositories that do have the packages, nothing prevents us from distributing the appropriate /etc/yum.repos.d/ files in the fedora-release package. So, I'll back up Jesse's question: >> And really, if we could reference it, then why the crap couldn't we >> just package it in our repo? -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From mike at miketc.com Wed Sep 12 12:53:32 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 12 Sep 2007 07:53:32 -0500 Subject: Volume control problems In-Reply-To: <1189562460.15173.2.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> Message-ID: <1189601612.16561.1.camel@scrappy.miketc.com> On Tue, 2007-09-11 at 21:01 -0500, Mike Chambers wrote: > Latest rawhide install as of this morning, and am running into a volume > control situation. It seems that the icon in the panel is muted and/or > won't show a volume control. And the error message is something like > below... > > No volume control GStreamer plugins and/or devices found. > > Yet if I do a detect sound card, it finds it (SB Audigy LS?) and plays > the sample sound just fine. I noticed this in my logs this morning, that might have to do with this? Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-sink.c: Error opening PCM device hw:1: No such device Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:1 sink_name=alsa_output.pci_1039_7012_alsa_playback_0"): initialization failed. Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-source.c: Error opening PCM device hw:1: No such device Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0"): initialization failed. Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-sink.c: Error opening PCM device hw:0: No such device Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:0 sink_name=alsa_output.pci_1102_7_alsa_playback_0"): initialization failed. Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-source.c: Error opening PCM device hw:0: No such device Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1102_7_alsa_capture_0"): initialization failed. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From sundaram at fedoraproject.org Wed Sep 12 12:52:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 18:22:27 +0530 Subject: Announcing rpmfusion In-Reply-To: <46E7DE8C.7020508@kanarip.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> Message-ID: <46E7E10B.1010800@fedoraproject.org> Jeroen van Meeuwen wrote: > Seriously though, this is just plain dumb wrong: > > If we cannot include the packages in our own repositories but we can > point to other repositories that do have the packages, nothing prevents > us from distributing the appropriate /etc/yum.repos.d/ files in the > fedora-release package. This is again different from including the packages. The details are important from a legal perspective. > So, I'll back up Jesse's question: > >> And really, if we could reference it, then why the crap couldn't we > >> just package it in our repo? Same answer. Go and read the Fedora Advisory Board list threads which already answer this question. Rahul From martin.sourada at seznam.cz Wed Sep 12 12:59:49 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 12 Sep 2007 14:59:49 +0200 Subject: Is hang better than crash? Message-ID: <1189601989.11397.13.camel@pc-notebook> Hi, I finally got build xulrunner on my rawhide machine with the sources, patches and settings from devel and built a hg version of gxine against it, so far it works and so I'll probably prepare my specfile for the xulrunner coming. I also consider upgrade to hg version in rawhide as it seems stable and has some better features (and various fixes for newer xine-lib and pthreads) than last stable release. I am however unsure as to whether enable watchdog feature - it aborts gxine if it hangs for 30s. I am asking for your opinions about this. Is hang better than crash or is it otherwise? Thanks, Martin -------------- 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 kanarip at kanarip.com Wed Sep 12 13:20:36 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 12 Sep 2007 15:20:36 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E7E10B.1010800@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> Message-ID: <46E7E7A4.7070707@kanarip.com> Rahul Sundaram wrote: > Jeroen van Meeuwen wrote: > >> Seriously though, this is just plain dumb wrong: >> >> If we cannot include the packages in our own repositories but we can >> point to other repositories that do have the packages, nothing >> prevents us from distributing the appropriate /etc/yum.repos.d/ files >> in the fedora-release package. > > This is again different from including the packages. The details are > important from a legal perspective. > Sure it is different from including the packages ourselves, that wasn't the point. My point is, that if we can refer to anything, we might as well include the configuration files for those third party repositories that hold the packages we can't ship/include. In other words: there's no difference in being allowed to link to anything and actually shipping the link in that very package. Functionally, the effects of the latter actually isn't anything different from shipping the packages from a host set up on the other side of the pond. >> So, I'll back up Jesse's question: >> >> And really, if we could reference it, then why the crap couldn't we >> >> just package it in our repo? This time, substitute "our repo" for: "some repo being 'ours' -though not really /ours/- (but replicated over non-US mirrors only?)". Next reply I'll send you a regex. > > Same answer. Can't be. Go and read the Fedora Advisory Board list threads which > already answer this question. > -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 From katzj at redhat.com Wed Sep 12 13:08:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Sep 2007 09:08:30 -0400 Subject: desc and summary In-Reply-To: <34302.192.54.193.51.1189586200.squirrel@rousalka.dyndns.org> References: <200709091230.29181.alain.portal@free.fr> <200709120956.23133.aportal@univ-montp2.fr> <34302.192.54.193.51.1189586200.squirrel@rousalka.dyndns.org> Message-ID: <1189602510.4971.28.camel@localhost.localdomain> On Wed, 2007-09-12 at 10:36 +0200, Nicolas Mailhot wrote: > Le Mer 12 septembre 2007 09:56, Alain PORTAL a ?crit : > > Le Sunday 09 September 2007 12:30:28 Alain PORTAL, vous avez ?crit : > > >> Why? > > > > Nobody can answer? > > Because the rh localisation team decided years ago they wanted > localisation in one place not spread over every package in the distro. > IMHO this was a short-sighted decision as centralization does not > scale and screws third-party repositories (basically anything the > central project does not now of beforehand is not localised) Actually, nothing says that additional repos can't have their own specspo-type package as well. And if you drop a macro file defining %{_i18ndomains} as the current value + your repo's value, then with pirut, it'll now follow that rather than just using redhat-dist. Also, moving the translations into the spec files is pretty painful also. It makes the spec file _much_ more complicated to actually edit and work with and it also means the package has to be rebuilt to get translations of package metadata added. And going through and rebuilding every package to add translations to package headers at the last minute doesn't work either. All of the above said, specspo probably _isn't_ the right answer... but just moving everything to be back in the spec files isn't the answer either. If someone would like to work on what a better answer is, it would definitely be a welcome and long-overdue improvement Jeremy From katzj at redhat.com Wed Sep 12 13:12:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Sep 2007 09:12:30 -0400 Subject: udev performance In-Reply-To: <46E7AEDD.5050608@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> <46E7A9EC.6080702@redhat.com> <20070912091357.GS20571@devserv.devel.redhat.com> <46E7AEDD.5050608@redhat.com> Message-ID: <1189602750.4971.34.camel@localhost.localdomain> On Wed, 2007-09-12 at 11:18 +0200, Harald Hoyer wrote: > And that data parsing time can also be reduced by collecting the > unresolvable modaliases at depmod time. But given that hardware can and does change, I don't know that counting on this is really the best option. Especially when you think about things like live CDs, etc where the hardware you're running on is going to be vastly different than the hardware that depmod was run on Jeremy From chitlesh at fedoraproject.org Wed Sep 12 13:29:57 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 12 Sep 2007 15:29:57 +0200 Subject: Licensing: dual licenses - icons In-Reply-To: <46E7BB8D.5090605@fedoraproject.org> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> <46E7B203.7040106@fedoraproject.org> <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> <1189591917.3157.237.camel@mccallum.corsepiu.local> <46E7BB8D.5090605@fedoraproject.org> Message-ID: <13dbfe4f0709120629l57dafbf1sc99abd7f76378391@mail.gmail.com> On 9/12/07, Rahul Sundaram wrote: > Correct. When you combine packages with more permissive and less > permissive copyleft licenses, the license with the least permissions > apply to the combination. That is LGPLv2 in this case, right ? Chitlesh -- http://clunixchit.blogspot.com From michel.sylvan at gmail.com Wed Sep 12 13:35:13 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 12 Sep 2007 09:35:13 -0400 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> Message-ID: On 12/09/2007, Bill Crawford wrote: > Seriously, that's half the problem. When I want "mp3 playing" support, > I have to install "xine-lib-moles" ... > A viable solution will be to use Gentoo-esque "USE flags". Tag (sub)packages with what feature they provide -- e.g. MP3, DVD playback -- and also the package(s) for which they enable this functionality. Thus xine-lib-moles will have this: If xine-lib is installed on your computer, and you ask for MP3 support, it will install xine-lib-moles; if not, it won't. Likewise, if you have enabled MP3 support and then later install xine-lib, it should pull in xine-lib-moles as well. Thoughts? This could almost be fitted into Provides: / Requires:, but I don't think it actually can. Regards, -- Michel From lesmikesell at gmail.com Wed Sep 12 13:38:10 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 12 Sep 2007 08:38:10 -0500 Subject: Announcing rpmfusion In-Reply-To: <46E7DE8C.7020508@kanarip.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> Message-ID: <46E7EBC2.5070400@gmail.com> Jeroen van Meeuwen wrote: >> There is a lot of differences between pointing to the repository and >> including the packages directly as I already explained in Fedora >> Advisory Board list so I won't rehash all the arguments again now. >> Please read the releated threads if you missed it. In short, it is not >> possible to include patent-encumbered packages directly in the >> repository as long as it hosted in US. Pointing to it might very well >> be possible. >> > > Seriously though, this is just plain dumb wrong: > > If we cannot include the packages in our own repositories but we can > point to other repositories that do have the packages, nothing prevents > us from distributing the appropriate /etc/yum.repos.d/ files in the > fedora-release package. Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might. > So, I'll back up Jesse's question: > >> And really, if we could reference it, then why the crap couldn't we > >> just package it in our repo? Or - why not move the entire repo to places that can have all the contents? What's the point of even worrying about this issue? -- Les Mikesell lesmikesesll at gmail.com From myfedora at richip.dhs.org Wed Sep 12 13:37:50 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 07:37:50 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E79D10.6060902@hhs.nl> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> Message-ID: <1189604270.7051.7.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 10:02 +0200, Hans de Goede wrote: > Richi Plana wrote: > > Speaking of gstreamer-plugins-bad, I don't even grab mine from any > > repository. I have to compile my own as I use the timidity and wildmidi > > plugins (which aren't enabled in any of the repos, as far as I can > > tell). > > Argh, you are right they aren't enabled in livna. Next time please file a bug > about things like this. I specially packaged libtimidity and wildimidi for > Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for > livna fixing this shortly. I was wondering why there was a wildmidi-related patch in the srpm. Sorry if I hadn't filed a bug report. It's hard to tell what was intended and what isn't. Would it interest you to know that on my machine, I also have the mpeg2enc and nassink plugins enabled? Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in? I was going to do that for my system, privately. Unfortunately, I don't know how to rename the main part of the sub-packages name. I was planning on using the scheme "gstreamer-plugin-" for the modules and "gstreamer-plugins-bad" for the virtual package, but I can't figure out how to change the root name. I'd really rather not use "gstreamer-plugins-bad-" if possible (actually, I'd rather not use ANY filenames, if possible. I've posted several times against the idea of storing meta-info in filenames). Any ideas? -- Richi Plana From jima at beer.tclug.org Wed Sep 12 13:41:06 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 12 Sep 2007 08:41:06 -0500 (CDT) Subject: Announcing rpmfusion In-Reply-To: <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> Message-ID: On Wed, 12 Sep 2007, Bill Crawford wrote: > On 12/09/2007, Nicu Buculei wrote: > ... >> Balance this with the convenience, useful for most users, to not have to >> hunt for codecs/plugins, install one package and be sure the multimedia >> playing troubles are solved. > > "not have to hunt for" => either > > 1) *all* plugins, evar, are in the one package, innit > OR > 2) each plugin is appropriately named (and perhaps we need some extra > Provides: or maybe a package that pulls in appropriate ones via > Requires:, so that one can indeed install "DVD support" and get > libdvd{read,nav,css} pulled in, the last of them should of course be > optional). Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`... Jima From nicolas.mailhot at laposte.net Wed Sep 12 13:43:11 2007 From: nicolas.mailhot at laposte.net (nicolas.mailhot at laposte.net) Date: Wed, 12 Sep 2007 15:43:11 +0200 (CEST) Subject: desc and summary Message-ID: <27834210.1539991189604591702.JavaMail.www@wwinf8403> > De : "Jeremy Katz" > Actually, nothing says that additional repos can't have their own > specspo-type package as well. This is considerably upping the bar to creation of a new repository, and making impossible the common "collect rpms, launch createrepo" workflow > Also, moving the translations into the spec files is pretty painful > also. It makes the spec file _much_ more complicated to actually edit Note I'm not advocating pushing the translations in the spec file, but somewhere within the package (could be a SourceX-like declaration referencing a detached translation file) > and work with and it also means the package has to be rebuilt to get > translations of package metadata added. Packages need to be rebuilt anyway when the localisation teams translate the app (and translators complain we don't do it) Also how often are Description and Summary changed? Pretty never in my experience. That would mean a new Fedora package would be rebuilt a few times for translations just after hitting the repository and then never again. (and this can be hidden to users by pushing new packages to rawhide-only the time translators work on them) > All of the above said, specspo probably _isn't_ the > right answer... Yes, it was hyped as necessary to make translator work easy, and now you have translators complaining of it. Regards, -- Nicolas Mailhot From jkeating at redhat.com Wed Sep 12 13:45:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 09:45:28 -0400 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> Message-ID: <20070912094528.3e22794f@lumos.localdomain> On Wed, 12 Sep 2007 08:41:06 -0500 (CDT) Jima wrote: > Couldn't this be managed by rpmfusion using a comps file, and > grouping various packages with "DVD support," "MP3 support," or > whatnot? `yum groupinstall "DVD Support"`... This sounds like a good thought. The problem would be "what if I don't have xine, but installing mp3 support drags in xine just for the plugin?" Usually the answer is "well, use conditionals" which are a way to say "only include this package, if this other package is already selected or installed". However I think there is some desire to do away with conditionals. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Wed Sep 12 13:45:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 07:45:19 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E7C004.9000707@nicubunu.ro> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> Message-ID: <1189604719.7051.15.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 13:31 +0300, Nicu Buculei wrote: > Bill Crawford wrote: > > On 12/09/2007, Rodd Clarkson wrote: > >> yum install gstreamer-plugins-bad > > >> This will install the mp3 codec along with a bunch of other 'bad' > >> codecs. > > > > Quite. Again, it would be nice to be able to install *the plugin that's wanted*. > > > > And *only* the plugin that's wanted. > > Balance this with the convenience, useful for most users, to not have to > hunt for codecs/plugins, install one package and be sure the multimedia > playing troubles are solved. The Right Way(TM) (IMHO) to do that is to have a system that will 1) find the name of the correct plugin to handle the multimedia file from a directory, and 2) yum install it on-the-fly. Remember that formats and plugins are popping up left and right. Some are encompassing, some are more esoteric. You'll either be forced to keep updating the one-package-to-rule-them-all file everytime something new comes up, or you have the automated system I just mentioned. You can't have one big package for all the plugins that you can enable at one time and have the users hunt manually for the others as they come up. Besides, it's also possible to create a virtual package (say: gstreamer-plugins-audio ... to illustrate that we do not need to follow the upstream packaging scheme. They have their reasons for packaging things -good, -bad, -base and -ugly and they MIGHT not coincide with the needs of our users) and have that virtual package pull in the individual plugin packages. IF they really wanted the world. -- Richi Plana From sundaram at fedoraproject.org Wed Sep 12 13:43:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 19:13:50 +0530 Subject: Announcing rpmfusion In-Reply-To: <46E7E7A4.7070707@kanarip.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> Message-ID: <46E7ED16.7050404@fedoraproject.org> Jeroen van Meeuwen wrote: > > In other words: there's no difference in being allowed to link to > anything and actually shipping the link in that very package. > > Functionally, the effects of the latter actually isn't anything > different from shipping the packages from a host set up on the other > side of the pond. We can't primarily concerned with functionality without understanding the legal implications. >> Same answer. > > Can't be. It is. All the different scenarios were hashed out there. Read them first completely. Rahul From sundaram at fedoraproject.org Wed Sep 12 13:46:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 19:16:58 +0530 Subject: Licensing: dual licenses - icons In-Reply-To: <13dbfe4f0709120629l57dafbf1sc99abd7f76378391@mail.gmail.com> References: <13dbfe4f0709120201q4af2d36et95d0b1b8400e67a3@mail.gmail.com> <46E7AE46.9030803@fedoraproject.org> <13dbfe4f0709120229k788bc90di1d92b20bae04375b@mail.gmail.com> <46E7B203.7040106@fedoraproject.org> <13dbfe4f0709120306v3f43f9b7qfd570f2fadde78c6@mail.gmail.com> <1189591917.3157.237.camel@mccallum.corsepiu.local> <46E7BB8D.5090605@fedoraproject.org> <13dbfe4f0709120629l57dafbf1sc99abd7f76378391@mail.gmail.com> Message-ID: <46E7EDD2.5090800@fedoraproject.org> Chitlesh GOORAH wrote: > On 9/12/07, Rahul Sundaram wrote: >> Correct. When you combine packages with more permissive and less >> permissive copyleft licenses, the license with the least permissions >> apply to the combination. > > That is LGPLv2 in this case, right ? GPLv2 in this instance since it is less permissive than LGPL. Rahul From michel.sylvan at gmail.com Wed Sep 12 13:51:09 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 12 Sep 2007 09:51:09 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189604719.7051.15.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <1189604719.7051.15.camel@localhost6.localdomain6> Message-ID: On 12/09/2007, Richi Plana wrote: > On Wed, 2007-09-12 at 13:31 +0300, Nicu Buculei wrote: > > Bill Crawford wrote: > > > On 12/09/2007, Rodd Clarkson wrote: > > >> yum install gstreamer-plugins-bad > > > > >> This will install the mp3 codec along with a bunch of other 'bad' > > >> codecs. > > > > > > Quite. Again, it would be nice to be able to install *the plugin that's wanted*. > > > > > > And *only* the plugin that's wanted. > > > > Balance this with the convenience, useful for most users, to not have to > > hunt for codecs/plugins, install one package and be sure the multimedia > > playing troubles are solved. > > The Right Way(TM) (IMHO) to do that is to have a system that will 1) > find the name of the correct plugin to handle the multimedia file from a > directory, and 2) yum install it on-the-fly. Remember that formats and > plugins are popping up left and right. Some are encompassing, some are > more esoteric. You'll either be forced to keep updating the > one-package-to-rule-them-all file everytime something new comes up, or > you have the automated system I just mentioned. You can't have one big > package for all the plugins that you can enable at one time and have the > users hunt manually for the others as they come up. Codec Buddy: http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy though in F-8 it won't integrate with third-party repos just yet, so it will probably only redirect you to Fluendo's shop. -- Michel From harald at redhat.com Wed Sep 12 14:08:46 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 12 Sep 2007 16:08:46 +0200 Subject: udev performance In-Reply-To: <1189602750.4971.34.camel@localhost.localdomain> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> <46E7A9EC.6080702@redhat.com> <20070912091357.GS20571@devserv.devel.redhat.com> <46E7AEDD.5050608@redhat.com> <1189602750.4971.34.camel@localhost.localdomain> Message-ID: <46E7F2EE.90209@redhat.com> Jeremy Katz schrieb: > On Wed, 2007-09-12 at 11:18 +0200, Harald Hoyer wrote: >> And that data parsing time can also be reduced by collecting the >> unresolvable modaliases at depmod time. > > But given that hardware can and does change, I don't know that counting > on this is really the best option. Especially when you think about > things like live CDs, etc where the hardware you're running on is going > to be vastly different than the hardware that depmod was run on > > Jeremy > LiveCDs wouldn't benefit from it. True. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From billcrawford1970 at gmail.com Wed Sep 12 14:17:32 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 12 Sep 2007 15:17:32 +0100 Subject: Announcing rpmfusion In-Reply-To: <1189604270.7051.7.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> Message-ID: <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> On 12/09/2007, Richi Plana wrote: > Hans, how about this for an idea: re-write the > gstreamer-plugins-bad.spec so that it puts the various plugins in > separate packages and make gstreamer-plugins-bad a virtual package that > Requires all of the plugins to pull them in? +2 > I was going to do that for my system, privately. Unfortunately, I don't > know how to rename the main part of the sub-packages name. I was > planning on using the scheme "gstreamer-plugin-" for the modules > and "gstreamer-plugins-bad" for the virtual package, but I can't figure > out how to change the root name. I'd really rather not use > "gstreamer-plugins-bad-" if possible (actually, I'd rather not > use ANY filenames, if possible. I've posted several times against the > idea of storing meta-info in filenames). Any ideas? Yes, this is an excellent plan. The only thing that stopped me doing it myself was that I'd have ended up having to rebuild a load of *other* packages to change their Requires: and so on ... From tcallawa at redhat.com Wed Sep 12 14:17:51 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 12 Sep 2007 10:17:51 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E7EBC2.5070400@gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> Message-ID: <1189606671.3567.5.camel@localhost.localdomain> On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > Or - why not move the entire repo to places that can have all the > contents? What's the point of even worrying about this issue? It's not where the repo sits, its where Red Hat is based out of. ~spot From loganjerry at gmail.com Wed Sep 12 14:20:03 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 12 Sep 2007 08:20:03 -0600 Subject: findbugs & bcel In-Reply-To: <1189577649.4682.10.camel@rousalka.dyndns.org> References: <870180fe0709112031l6b33546l64b7248dd3c27858@mail.gmail.com> <1189577649.4682.10.camel@rousalka.dyndns.org> Message-ID: <870180fe0709120720s390a2719j7abab77fb120da9b@mail.gmail.com> On 9/12/07, Nicolas Mailhot wrote: > Please try very hard to get findbugs upstream to merge @bcel first. (Or > ask bcel upstream to look at findbugs bcel to check if they can not pull > stuff) > > Do remind them that when java 1.7 with 277 ships everyong will be asking > for them to use the system bcel, not just Linux people. Thanks for the response, Nicolas. I'll see what I can do. -- Jerry James http://loganjerry.googlepages.com/ From michel.sylvan at gmail.com Wed Sep 12 14:50:40 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 12 Sep 2007 10:50:40 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189604270.7051.7.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> Message-ID: On 12/09/2007, Richi Plana wrote: > Hans, how about this for an idea: re-write the > gstreamer-plugins-bad.spec so that it puts the various plugins in > separate packages and make gstreamer-plugins-bad a virtual package that > Requires all of the plugins to pull them in? > That's how FreshRPMS packaged gstreamer in the past, AFAIK -- until upstream actually moved to aggregating plugins based on quality. -- Michel From mzerqung at 0pointer.de Wed Sep 12 15:01:32 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 12 Sep 2007 17:01:32 +0200 Subject: Volume control problems In-Reply-To: <1189601612.16561.1.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> Message-ID: <20070912150131.GA6177@tango.0pointer.de> On Wed, 12.09.07 07:53, Mike Chambers (mike at miketc.com) wrote: > > On Tue, 2007-09-11 at 21:01 -0500, Mike Chambers wrote: > > Latest rawhide install as of this morning, and am running into a volume > > control situation. It seems that the icon in the panel is muted and/or > > won't show a volume control. And the error message is something like > > below... > > > > No volume control GStreamer plugins and/or devices found. > > > > Yet if I do a detect sound card, it finds it (SB Audigy LS?) and plays > > the sample sound just fine. > > I noticed this in my logs this morning, that might have to do with this? > > Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-sink.c: Error > opening PCM device hw:1: No such device > Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:1 sink_name=alsa_output.pci_1039_7012_alsa_playback_0"): initialization failed. > Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-source.c: Error opening PCM device hw:1: No such device > Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0"): initialization failed. > Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-sink.c: Error opening PCM device hw:0: No such device > Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:0 sink_name=alsa_output.pci_1102_7_alsa_playback_0"): initialization failed. > Sep 11 12:32:29 scrappy pulseaudio[2079]: module-alsa-source.c: Error opening PCM device hw:0: No such device > Sep 11 12:32:29 scrappy pulseaudio[2079]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1102_7_alsa_capture_0"): initialization failed. Hmm. PulseAudio is unable to open your audio device. Are you sure it is properly available in the system? Could you please run "pulsaudio -vv"? And check whether "aplay -D hw:0 /dev/urandom" works? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From agostino.russo at gmail.com Wed Sep 12 15:37:10 2007 From: agostino.russo at gmail.com (Ago) Date: Wed, 12 Sep 2007 15:37:10 +0000 (UTC) Subject: Windows based installation of Fedora Linux? References: <46E7D57B.8020902@filteredperception.org> Message-ID: > Since I've advocated a win32 installer for Fedora in the past, > I'll at least say - cool. Unfortunately I also don't forsee myself > having time to dedicate to this in the near future(nor the desire, as I > am and hope to stay winblowz free ;). But I hope someone else finds the > time :) Good questions. There are in fact 2 separate issues. 1) Hosting filesystem corruption (ntfs). We had a few reports where people were not able to boot into Windows after an hardreboot in Wubi. Filesystem corruption does happen when you hardreboot, whether you use Wubi or not. Sometimes you get lucky (also with Wubi) sometimes you do not. The real question is whether Wubi (ntfs-3g in this case) makes things any worse. On average, we have 1 such report every 10K downloads. Add that Wubi users tend to reboot more often than usual, since they are in a new environment and often they do not know how to get out of a real or apparent deadlock. So are the numbers we see physiological? Honest answer is that I have no clue. I discussed that with Szaka (ntfs-3g author) and according to him, ntfs-3g does not make things any worse and there is little to be done on his side. If you have a different opinion on this I would like to hear from you. 2) Hosted filesystem corruption (ext3). When Ext3 writes the journal, the data does not end up on the HD but gets handled by ntfs, which in turns may or may not write the data to the HD. So if you hard reboot, data loss in the hosting filesystem may cause journal corruption of the hosted filesystem, which makes recovery quite challenging. This is not an ntfs/ext3 specific issue, you would have that in any nested filesystem configuration (or at least this is my understanding). What we have done was to tweak sysctl dirty settings, so that dirty pages are flushed to disk as often as possible. That seems to have done the trick. Since we did that, I cannot recall any complaint due to ext3 data loss, but of course that does not eliminate the issue. On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because of the ordering in which userspace processes are terminated/resumed which becomes an issue if you use a userspace filesystem (if the loopfile is hosted on vfat, suspend works fine). With hibernation you also have to handle the issue of having swap on a file. My take on all this is that Wubi is a "short term" installation. It's good enough for a few days and far more captivating than a live CD or a VM. But it's not ok for data-sensitive situations or for long term use. I would use the word "demo" if it did not have a try-then-pay connotation. And yes, because of the above, some users will be left with a bitter taste in their mouth, and the reputation for reliability will be negatively affected. On the other hand you will be able to reach many users that would not dare to try Linux otherwise, you will provide Joe Average (read 90% of the users out there) with a one-click installer and that helps a lot when you have to bear the stigmata of being seen as a "difficult OS". It's a trade-off. Regards, Ago From billcrawford1970 at gmail.com Wed Sep 12 15:44:30 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 12 Sep 2007 16:44:30 +0100 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> Message-ID: <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> On 12/09/2007, Jima wrote: > Couldn't this be managed by rpmfusion using a comps file, and grouping > various packages with "DVD support," "MP3 support," or whatnot? `yum > groupinstall "DVD Support"`... I think that's the best suggestion on how to balance packaging versus usability, so far ... >From the UI perspective, many users will indeed want to just say "give me support for playing MP3" or "I want to watch a DVD now". From dwmw2 at infradead.org Wed Sep 12 15:56:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Sep 2007 17:56:46 +0200 Subject: Bugzilla account. Message-ID: <1189612606.3570.50.camel@shinybook.infradead.org> Please could someone restore my personal bugzilla account (dwmw2 at infradead.org) to its normal functionality. For reasons which I'll explain (in graphic detail) quite soon, my other account is temporarily inaccessible. Until that particular silliness is concluded, however, there's no reason why I should not be able to use my personal bugzilla account as any normal Fedora contributor would. Please could the Fedora Board ensure that we re-enable my account ASAP? Thanks. -- dwmw2 From fedora at leemhuis.info Wed Sep 12 15:58:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 17:58:37 +0200 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> Message-ID: <46E80CAD.2000104@leemhuis.info> On 12.09.2007 17:44, Bill Crawford wrote: > On 12/09/2007, Jima wrote: > >> Couldn't this be managed by rpmfusion using a comps file, and grouping >> various packages with "DVD support," "MP3 support," or whatnot? `yum >> groupinstall "DVD Support"`... > I think that's the best suggestion on how to balance packaging versus > usability, so far ... FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't). I think they should (I filed a bug, but it got closed iirc), as that way would be the cleanest for a 3rd party repo to get the right packages (e.g. depending on the groups they selected) to the users. Cu knurd From myfedora at richip.dhs.org Wed Sep 12 16:08:47 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 10:08:47 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E7E7A4.7070707@kanarip.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> Message-ID: <1189613327.7051.19.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 15:20 +0200, Jeroen van Meeuwen wrote: > Sure it is different from including the packages ourselves, that wasn't > the point. My point is, that if we can refer to anything, we might as > well include the configuration files for those third party repositories > that hold the packages we can't ship/include. > > In other words: there's no difference in being allowed to link to > anything and actually shipping the link in that very package. Hold on. I think you two are on different pages here. You're both making sense, but seem to be talking about different things. Rahul, exactly what constitutes "linking" or "pointing" to these external packages? Do you mean a Note in some documentation somewhere? Perhaps in the distro or on a website somewhere? Or is it an actual entry in /etc/yum.respos.d/ pointing directly to the repo where the packages can be downloaded from? -- Richi Plana From jkeating at redhat.com Wed Sep 12 16:13:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 12:13:13 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E80CAD.2000104@leemhuis.info> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> Message-ID: <20070912121313.2b3bfa19@lumos.localdomain> On Wed, 12 Sep 2007 17:58:37 +0200 Thorsten Leemhuis wrote: > FYI for Livna I tried something else, but it didn't work out. I just > used the same groups as Fedora in Livna (as Fedora Extras did in the > past for Core as well) and made some crucial packages 'type="default"' > -- for example gstreamer-plugins-ugly for the "GNOME Desktop > Environment" . I assumed anaconda would then install > gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is > selected by default. But anaconda/pirut did not do that (and I assume > it still don't). > > I think they should (I filed a bug, but it got closed iirc), as that > way would be the cleanest for a 3rd party repo to get the right > packages (e.g. depending on the groups they selected) to the users. At initial install time, if the livna repo is added, then what is selected by default is the aggregate of all the repos contents of a group. So yes, at install time this would be selected. After that though, stuff isn't magically "added" just because it's marked as a default in a group when you launch pirut, nor should it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Sep 12 16:17:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Sep 2007 08:17:38 -0800 Subject: Announcing rpmfusion In-Reply-To: <46E7EBC2.5070400@gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> Message-ID: <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> On 9/12/07, Les Mikesell wrote: > Or, if you need another level of indirection, include a repo that > doesn't itself have anything controversial but has a package that > configures yum for repos that might. oh classy. So how would that work from a user perspective? Let's say the repo you describe exists... let's call it the repo-clearinghouse repo. It essentially holds release packages for each addon repo that can be installed thus configuring the client to pull packages from different addon repos. Obviously yum install repoA-release will install the release package for repoA, as held in the clearinghouse repo... but how do you expose things in a way that a user can ask which addon repo they need to configure? Say I want support for the new foo codec that can't be shipped in Fedora. Do i look in repoA or repoB or repoC ? How would the repo-clearinghouse repo expose that repoA was the correct location to find all things related to foo codec? How do I ask which repo to configure through interaction with the repo-clearinghouse metadata specifically to get access to all foo codec related packages? -jef From rdieter at math.unl.edu Wed Sep 12 16:12:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Sep 2007 11:12:29 -0500 Subject: Announcing rpmfusion References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > On 12.09.2007 17:44, Bill Crawford wrote: >> On 12/09/2007, Jima wrote: >> >>> Couldn't this be managed by rpmfusion using a comps file, and grouping >>> various packages with "DVD support," "MP3 support," or whatnot? `yum >>> groupinstall "DVD Support"`... >> I think that's the best suggestion on how to balance packaging versus >> usability, so far ... > > FYI for Livna I tried something else, but it didn't work out. I just > used the same groups as Fedora in Livna (as Fedora Extras did in the > past for Core as well) and made some crucial packages 'type="default"' > -- for example gstreamer-plugins-ugly for the "GNOME Desktop > Environment" . I assumed anaconda would then install > gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is > selected by default. But anaconda/pirut did not do that (and I assume it > still don't). At our site, we include a custom repo adding default items to the same groups (exactly as you described), and it works for us here (using f7). -- Rex From sundaram at fedoraproject.org Wed Sep 12 16:19:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Sep 2007 21:49:22 +0530 Subject: Announcing rpmfusion In-Reply-To: <1189613327.7051.19.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> Message-ID: <46E8118A.5060506@fedoraproject.org> Richi Plana wrote: > Rahul, exactly what constitutes "linking" or "pointing" to these > external packages? Do you mean a Note in some documentation somewhere? > Perhaps in the distro or on a website somewhere? Or is it an actual > entry in /etc/yum.respos.d/ pointing directly to the repo where the > packages can be downloaded from? I am not talking about any repo files. Just a pointer in documentation or in any application. The details are explained in FAB list. That requires Legal to look into this. No amount of layman arguments can help us make a decision and legal perspectives doesn't always make logical sense which many tend to assume. Rahul From jspaleta at gmail.com Wed Sep 12 16:27:04 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Sep 2007 08:27:04 -0800 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> Message-ID: <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> On 9/12/07, Bill Crawford wrote: > On 12/09/2007, Richi Plana wrote: > > > Hans, how about this for an idea: re-write the > > gstreamer-plugins-bad.spec so that it puts the various plugins in > > separate packages and make gstreamer-plugins-bad a virtual package that > > Requires all of the plugins to pull them in? > > +2 -100 The discussion on how gstreamer's source codebase needs to be happening with gstreamer upstream. if gstreamer upstream continues to aggregate, splitting modules out one by one is guaranteed to be a fragile exercise of frustration. If it makes sense for the users of distributions to consume the modules as separate packages then it makes just as much sense for the gstreamer upstream to treat the modules as separate codebases so the entire gstreamer user/developer/tester base can consume them piecemeal as well. Everyone who wants to see more modularity, feel free to bring this desire up with the gstreamer upstream and make a reasoned argument to try to persuade them to change how they are packaging the modules. -jef"I'd love to consume gstreamer modules piecemeal for testing"spaleta From lesmikesell at gmail.com Wed Sep 12 16:38:31 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 12 Sep 2007 11:38:31 -0500 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> Message-ID: <46E81607.40504@gmail.com> Jeff Spaleta wrote: > On 9/12/07, Les Mikesell wrote: >> Or, if you need another level of indirection, include a repo that >> doesn't itself have anything controversial but has a package that >> configures yum for repos that might. > > oh classy. So how would that work from a user perspective? > > Let's say the repo you describe exists... let's call it the > repo-clearinghouse repo. It essentially holds release packages for > each addon repo that can be installed thus configuring the client to > pull packages from different addon repos. > > Obviously yum install repoA-release will install the release > package for repoA, as held in the clearinghouse repo... but how do you > expose things in a way that a user can ask which addon repo they need > to configure? How does a user know about any other package and decide if they would like yum to install it? A name convention for packages so something like 'yum search repo' would find a list of repos that yum could add to itself. > Say I want support for the new foo codec that can't be shipped in > Fedora. Do i look in repoA or repoB or repoC ? How would the > repo-clearinghouse repo expose that repoA was the correct location to > find all things related to foo codec? How do I ask which repo to > configure through interaction with the repo-clearinghouse metadata > specifically to get access to all foo codec related packages? 'yum info repoA-release' might describe why you would want to install access to that repo, perhaps to the extent of having the package list or at least the ones that you felt could be legally mentioned everywhere. But, I thought the point of rpm-fusion was to become the only extra repo you might need so this decision wouldn't be too complicated. -- Les Mikesell lesmikesell at gmail.com From fedora at leemhuis.info Wed Sep 12 16:47:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 18:47:36 +0200 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> Message-ID: <46E81828.7000006@leemhuis.info> On 12.09.2007 18:12, Rex Dieter wrote: > Thorsten Leemhuis wrote: > >> On 12.09.2007 17:44, Bill Crawford wrote: >>> On 12/09/2007, Jima wrote: >>> >>>> Couldn't this be managed by rpmfusion using a comps file, and grouping >>>> various packages with "DVD support," "MP3 support," or whatnot? `yum >>>> groupinstall "DVD Support"`... >>> I think that's the best suggestion on how to balance packaging versus >>> usability, so far ... >> FYI for Livna I tried something else, but it didn't work out. I just >> used the same groups as Fedora in Livna (as Fedora Extras did in the >> past for Core as well) and made some crucial packages 'type="default"' >> -- for example gstreamer-plugins-ugly for the "GNOME Desktop >> Environment" . I assumed anaconda would then install >> gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is >> selected by default. But anaconda/pirut did not do that (and I assume it >> still don't). > At our site, kde-redhat? > we include a custom repo adding default items to the same > groups (exactly as you described), KDE I suppose? > and it works for us here (using f7). Yeah, it works, afaics only because you have to select KDE always. But it doesn't work for the default install with gnome, as gnome is selected already as default, and todays anaconda does not add the packages from the 3rd party repo to the to-be-installed-pacakge-set if you don't switch off gnome once and reenable it. CU knurd From jspaleta at gmail.com Wed Sep 12 16:48:51 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Sep 2007 08:48:51 -0800 Subject: Announcing rpmfusion In-Reply-To: <46E81607.40504@gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <46E81607.40504@gmail.com> Message-ID: <604aa7910709120948s439cfb98jfe0fb006a7e09cb9@mail.gmail.com> On 9/12/07, Les Mikesell wrote: > 'yum info repoA-release' might describe why you would want to install > access to that repo, perhaps to the extent of having the package list or > at least the ones that you felt could be legally mentioned everywhere. > But, I thought the point of rpm-fusion was to become the only extra repo > you might need so this decision wouldn't be too complicated. rpm-fusion is actually... 2 repos. free and non-free. But if repo-fusion is the only extra repo(s) that the redirectory is going to actual contain information for.. then i very much doubt that the redirection trick provides any cover from a legal perspective. But what the hell do I know. -jef"Anyone happen to have a C implementation of the generalized Lomb periodogram for quadrature signals with Lagrangian amplitude envelope decay functions just sitting around collecting dust that I could mooch?"spaleta From myfedora at richip.dhs.org Wed Sep 12 17:26:40 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 11:26:40 -0600 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> Message-ID: <1189618000.7051.29.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote: > On 9/12/07, Bill Crawford wrote: > > On 12/09/2007, Richi Plana wrote: > > > > > Hans, how about this for an idea: re-write the > > > gstreamer-plugins-bad.spec so that it puts the various plugins in > > > separate packages and make gstreamer-plugins-bad a virtual package that > > > Requires all of the plugins to pull them in? > > > > +2 > > -100 > > The discussion on how gstreamer's source codebase needs to be > happening with gstreamer upstream. if gstreamer upstream continues to > aggregate, splitting modules out one by one is guaranteed to be a > fragile exercise of frustration. If it makes sense for the users of > distributions to consume the modules as separate packages then it > makes just as much sense for the gstreamer upstream to treat the > modules as separate codebases so the entire gstreamer > user/developer/tester base can consume them piecemeal as well. No, the needs and requirements of upstream and that of Fedora's users do not necessarily coincide. They have a reason to package things the way they did, and believe me, it has nothing to do with what users want. They are most certainly not trying to make it hard for users, and if asked they might sometimes give in, but they have their own concerns. If asked to separate them, they will most likely say that it is the distro's or the packagers responsibility to do that. We already have several of Fedora's users asking for it, so there obviously is a demand. If someone thinks the users are being stupid, then I suggest that enlightening them and showing them the error of their ways is the correct approach. But the correct approach isn't to say that upstream always cares about the needs and requirements of their users. Most of upstream's decision are based on development or legal decisions. Sometimes the needs and wants of the users, the packagers and upstream developers sometimes coincide and THAT'S when it makes sense to go to them, but such isn't always the case. -- Richi "ah, what the heck?" Plana From alain.portal at free.fr Wed Sep 12 17:32:52 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Wed, 12 Sep 2007 19:32:52 +0200 Subject: desc and summary In-Reply-To: <34302.192.54.193.51.1189586200.squirrel@rousalka.dyndns.org> References: <200709091230.29181.alain.portal@free.fr> <200709120956.23133.aportal@univ-montp2.fr> <34302.192.54.193.51.1189586200.squirrel@rousalka.dyndns.org> Message-ID: <200709121932.52898.alain.portal@free.fr> Le mercredi 12 septembre 2007, Nicolas Mailhot a ?crit : > But anyway: > 1. you're looking for specspo > 2. it'd be nice if you could talk with the people behind transifex to > figure how to put localisation back in the individual packages where > it belongs I don't want translation be put in package spec file, I just want that if a french translation exist, this translation have to be got and merge in the fr.po. That's why I wanted to know how are build these pot an po files. Regards -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 pertusus at free.fr Wed Sep 12 17:46:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 12 Sep 2007 19:46:18 +0200 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <20070907214812.05d204e1@ender> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> Message-ID: <20070912174618.GC4328@free.fr> On Fri, Sep 07, 2007 at 09:48:12PM -0400, Jesse Keating wrote: > On Thu, 30 Aug 2007 20:53:14 -0400 > Jesse Keating wrote: > > These are now the minimal build group. Reasonable requests to add more > of what is currently implicit into the explicit list will gladly be > discussed, but for now the important thing was to get util-linux-ng > back in the set, and to remove perl(-devel) from the set. I propose: glibc-devel libstdc++-devel cpp -- Pat From myfedora at richip.dhs.org Wed Sep 12 17:51:25 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 11:51:25 -0600 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <1189604719.7051.15.camel@localhost6.localdomain6> Message-ID: <1189619485.7051.33.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 09:51 -0400, Michel Salim wrote: > Codec Buddy: > > http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy > > though in F-8 it won't integrate with third-party repos just yet, so > it will probably only redirect you to Fluendo's shop. Ahh, but the mindset and the infrastructure are there! :) It's really the computer's task to figure everything out that it can and only go back to humans for things that it can't. But to do that needs the right kind of programming. Not the easiest thing, but we shouldn't shy away from the challenge. -- Richi Plana From fedora at leemhuis.info Wed Sep 12 16:44:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 18:44:40 +0200 Subject: Announcing rpmfusion In-Reply-To: <20070912121313.2b3bfa19@lumos.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <20070912121313.2b3bfa19@lumos.localdomain> Message-ID: <46E81778.4040108@leemhuis.info> On 12.09.2007 18:13, Jesse Keating wrote: > On Wed, 12 Sep 2007 17:58:37 +0200 > Thorsten Leemhuis wrote: > >> FYI for Livna I tried something else, but it didn't work out. I just >> used the same groups as Fedora in Livna (as Fedora Extras did in the >> past for Core as well) and made some crucial packages 'type="default"' >> -- for example gstreamer-plugins-ugly for the "GNOME Desktop >> Environment" . I assumed anaconda would then install >> gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is >> selected by default. But anaconda/pirut did not do that (and I assume >> it still don't). >> >> I think they should (I filed a bug, but it got closed iirc), as that >> way would be the cleanest for a 3rd party repo to get the right >> packages (e.g. depending on the groups they selected) to the users. > > At initial install time, if the livna repo is added, then what is > selected by default is the aggregate of all the repos contents of a > group. So yes, at install time this would be selected. No, it's not, if you don't change anything after activating livna. Only if you unselect the gnome group (which is enabled by default) once and select it again, then the livna-package gets added as well. (BTW, even livna-specific groups that are marked as "default" don't get installed, thus there is not even a way to get the livna-release package automatically installed with anaconda in F7; yes, there is a bug about it somewhere in bugzilla, but it got closed) > After that > though, stuff isn't magically "added" just because it's marked as a > default in a group when you launch pirut, nor should it. I'm not really sure about the "nor should it" part. Maybe yes, maybe no. Example: For user "eve" that is a tough girl and remembers to enable livna during install it would really be the easiest solution if she gets some of the livna packages by default depending on the groups she selects/that got selected by anaconda/yum by default. But consider user "adam", who forgot to enable livna during install or was not able to do so -- for him it would mean that he needs to look through all all the groups and guess which packages he might needs to add to get the important stuff. The only "workaround" today afaics: create special groups, e.g. "livna/rpmfusion gnome" and "livna/rpmfusion kde" and mark the "livna/rpmfusion gnome" group as default. Then adam can easily select the group later and eve will get the gnome package by default. But then evetoo would need to remember to switch of both the "livna/rpmfusion gnome" and "Fedora gnome" and enable both "livna/rpmfusion kde" and "Fedora KDE" if she wants to use KDE -- that sucks as well. If there is any better way: please let me know. CU knurd From myfedora at richip.dhs.org Wed Sep 12 18:00:49 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 12 Sep 2007 12:00:49 -0600 Subject: Announcing rpmfusion In-Reply-To: <46E8118A.5060506@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> Message-ID: <1189620049.7051.38.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote: > I am not talking about any repo files. Just a pointer in documentation > or in any application. The details are explained in FAB list. That > requires Legal to look into this. No amount of layman arguments can help > us make a decision and legal perspectives doesn't always make logical > sense which many tend to assume. In other words, Fedora's lawyers have deemed it risky (or even downright illegal) to include in the distro .repo files that would allow users to download, say, US-illegal codecs even if the repository itself physically and logistically isn't connected to Fedora. But pointers in documents can. There we go. That's what the legal experts are saying. Do I have it about right? -- Richi Plana From pertusus at free.fr Wed Sep 12 18:01:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 12 Sep 2007 20:01:35 +0200 Subject: obsoleting in compat packages: is it right? In-Reply-To: <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> References: <20070827192643.GB24132@free.fr> <20070907003616.c635c44e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070912180135.GE4328@free.fr> On Fri, Sep 07, 2007 at 12:36:16AM +0200, Michael Schwendt wrote: > > IMO it is right. "Obsoletes" in compat packages is used to rename > a package, to move it from the old name to the new name. It doesn't > matter whether there is a separate package that upgrades the old > one: > > automake = 1.6.3 renamed to automake16 = 1.6.3 > automake = 1.10 replaces automake = 1.6.3 Ok. I hadn't understood it did that. So it fully does what I was asking for, that is install both automake = 1.10 and automake16 = 1.6.3. Maybe this should be documented somewhere? -- Pat From bpepple at fedoraproject.org Wed Sep 12 17:58:15 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 12 Sep 2007 13:58:15 -0400 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> Message-ID: <1189619895.23953.3.camel@kennedy> On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote: > On 9/12/07, Bill Crawford wrote: > > On 12/09/2007, Richi Plana wrote: > > > > > Hans, how about this for an idea: re-write the > > > gstreamer-plugins-bad.spec so that it puts the various plugins in > > > separate packages and make gstreamer-plugins-bad a virtual package that > > > Requires all of the plugins to pull them in? > > > > +2 > > -100 > > The discussion on how gstreamer's source codebase needs to be > happening with gstreamer upstream. +1. This should be worked out upstream. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed Sep 12 18:04:50 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Sep 2007 20:04:50 +0200 Subject: Announcing rpmfusion In-Reply-To: <1189604270.7051.7.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> Message-ID: <46E82A42.7000403@hhs.nl> Richi Plana wrote: > On Wed, 2007-09-12 at 10:02 +0200, Hans de Goede wrote: >> Richi Plana wrote: >>> Speaking of gstreamer-plugins-bad, I don't even grab mine from any >>> repository. I have to compile my own as I use the timidity and wildmidi >>> plugins (which aren't enabled in any of the repos, as far as I can >>> tell). >> Argh, you are right they aren't enabled in livna. Next time please file a bug >> about things like this. I specially packaged libtimidity and wildimidi for >> Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for >> livna fixing this shortly. > > I was wondering why there was a wildmidi-related patch in the srpm. Well, because I intended to enable wildmidi support as soon as wildmidi got approved, but I forgot :| > Sorry if I hadn't filed a bug report. It's hard to tell what was > intended and what isn't. Would it interest you to know that on my > machine, I also have the mpeg2enc and nassink plugins enabled? > mpeg2enc should already be enabled I indeed missed nas thats enabled now too > Hans, how about this for an idea: re-write the > gstreamer-plugins-bad.spec so that it puts the various plugins in > separate packages and make gstreamer-plugins-bad a virtual package that > Requires all of the plugins to pull them in? > I think this is a bad idea, we really want the user to have todo less to get a complete set of codecs, not more. It might be an idea to put some of the less often used sinks (jack, nas, ?) in a -extras package though, to avoid pulling in deps most people don't have a use for. Regards, Hans From jkeating at redhat.com Wed Sep 12 18:14:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 14:14:22 -0400 Subject: Announcing rpmfusion In-Reply-To: <46E81778.4040108@leemhuis.info> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <20070912121313.2b3bfa19@lumos.localdomain> <46E81778.4040108@leemhuis.info> Message-ID: <20070912141422.20ea6a05@lumos.localdomain> On Wed, 12 Sep 2007 18:44:40 +0200 Thorsten Leemhuis wrote: > No, it's not, if you don't change anything after activating livna. > Only if you unselect the gnome group (which is enabled by default) > once and select it again, then the livna-package gets added as well. I wonder if this is different if you kickstart and add the repo in kickstart. Might be worth trying. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Sep 12 18:03:33 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 12 Sep 2007 14:03:33 -0400 Subject: Plan for tomorrows (20070913) FESCO meeting Message-ID: <1189620213.23953.6.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 /topic FESCO-Meeting -- MISC -- keep fedora-test-list & fedora-packaging-list? - all /topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy /topic Status Update: FESCo Proposal Template - f13 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cjdahlin at ncsu.edu Wed Sep 12 18:10:30 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 12 Sep 2007 14:10:30 -0400 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> Message-ID: <46E82B96.2080204@ncsu.edu> So if I install MP3 support, I get as dependancies the KDE mp3 plugins and an entire KDE multimedia subsystem, even though I don't use KDE? This seems to fail to take into account what it is we want to support mp3s, and how we want to do it. On the one hand that seems like more info than the user cares about, but on the other hand, if you end up pulling two desktop environments along with your single codec for dependancies (I've seen a few fedora users who did not realize they had a full KDE install on their system because they installed a few QT-based games). Bill Crawford wrote: > On 12/09/2007, Jima wrote: > > >> Couldn't this be managed by rpmfusion using a comps file, and grouping >> various packages with "DVD support," "MP3 support," or whatnot? `yum >> groupinstall "DVD Support"`... >> > > I think that's the best suggestion on how to balance packaging versus > usability, so far ... > > >From the UI perspective, many users will indeed want to just say "give > me support for playing MP3" or "I want to watch a DVD now". > > From j.w.r.degoede at hhs.nl Wed Sep 12 18:19:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Sep 2007 20:19:20 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E82B96.2080204@ncsu.edu> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E82B96.2080204@ncsu.edu> Message-ID: <46E82DA8.2010700@hhs.nl> Casey Dahlin wrote: > So if I install MP3 support, I get as dependancies the KDE mp3 plugins > and an entire KDE multimedia subsystem, even though I don't use KDE? > > This seems to fail to take into account what it is we want to support > mp3s, and how we want to do it. On the one hand that seems like more > info than the user cares about, but on the other hand, if you end up > pulling two desktop environments along with your single codec for > dependancies (I've seen a few fedora users who did not realize they had > a full KDE install on their system because they installed a few QT-based > games). > If they didn't know and they can miss the diskspace, then why is this a problem? Regards, Hans From notting at redhat.com Wed Sep 12 18:25:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Sep 2007 14:25:18 -0400 Subject: Announcing rpmfusion In-Reply-To: <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> Message-ID: <20070912182518.GB8628@nostromo.devel.redhat.com> Bill Crawford (billcrawford1970 at gmail.com) said: > I think that's the best suggestion on how to balance packaging versus > usability, so far ... > > >From the UI perspective, many users will indeed want to just say "give > me support for playing MP3" or "I want to watch a DVD now". Why not just have the package system key off of mime-types when you try and play a file? Bill From rdieter at math.unl.edu Wed Sep 12 18:27:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Sep 2007 13:27:44 -0500 Subject: Announcing rpmfusion References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <46E81828.7000006@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > > > On 12.09.2007 18:12, Rex Dieter wrote: >> Thorsten Leemhuis wrote: >> >>> On 12.09.2007 17:44, Bill Crawford wrote: >>>> On 12/09/2007, Jima wrote: >>>> >>>>> Couldn't this be managed by rpmfusion using a comps file, and >>>>> grouping >>>>> various packages with "DVD support," "MP3 support," or whatnot? `yum >>>>> groupinstall "DVD Support"`... >>>> I think that's the best suggestion on how to balance packaging versus >>>> usability, so far ... >>> FYI for Livna I tried something else, but it didn't work out. I just >>> used the same groups as Fedora in Livna (as Fedora Extras did in the >>> past for Core as well) and made some crucial packages 'type="default"' >>> -- for example gstreamer-plugins-ugly for the "GNOME Desktop >>> Environment" . I assumed anaconda would then install >>> gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is >>> selected by default. But anaconda/pirut did not do that (and I assume it >>> still don't). >> At our site, > > kde-redhat? @ UNL. We add items to various groups, say, kde-desktop, and then $ yum groupinstall kde-desktop not only includes the fedora items, but our added ones as well. -- Rex From katzj at redhat.com Wed Sep 12 18:28:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Sep 2007 14:28:49 -0400 Subject: Announcing rpmfusion In-Reply-To: <20070912141422.20ea6a05@lumos.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <20070912121313.2b3bfa19@lumos.localdomain> <46E81778.4040108@leemhuis.info> <20070912141422.20ea6a05@lumos.localdomain> Message-ID: <1189621729.16586.1.camel@localhost.localdomain> On Wed, 2007-09-12 at 14:14 -0400, Jesse Keating wrote: > On Wed, 12 Sep 2007 18:44:40 +0200 > Thorsten Leemhuis wrote: > > > No, it's not, if you don't change anything after activating livna. > > Only if you unselect the gnome group (which is enabled by default) > > once and select it again, then the livna-package gets added as well. > > I wonder if this is different if you kickstart and add the repo in > kickstart. Might be worth trying. It is because then the repo gets set up "initially" When doing the interactive install, we don't take the time hit of having to re-determine all of the defaults, etc based on the added repo. That said, some future (F9 hopefully; didn't have enough time to get it all in for F8) changes might make that a lot less painful Jeremy From fedora at leemhuis.info Wed Sep 12 18:31:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 20:31:14 +0200 Subject: Announcing rpmfusion In-Reply-To: <20070912141422.20ea6a05@lumos.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <20070912121313.2b3bfa19@lumos.localdomain> <46E81778.4040108@leemhuis.info> <20070912141422.20ea6a05@lumos.localdomain> Message-ID: <46E83072.4010500@leemhuis.info> On 12.09.2007 20:14, Jesse Keating wrote: > On Wed, 12 Sep 2007 18:44:40 +0200 > Thorsten Leemhuis wrote: > >> No, it's not, if you don't change anything after activating livna. >> Only if you unselect the gnome group (which is enabled by default) >> once and select it again, then the livna-package gets added as well. > I wonder if this is different if you kickstart and add the repo in > kickstart. Might be worth trying. Well, I don't think it will change anything even if it does work. Reply from Jeremy in https://bugzilla.redhat.com/show_bug.cgi?id=239167#c1 : > Adding the repository happens _after_ the default packages are selected (also, > the default selection is under control of anaconda and not entirely based on > the comps file). For F7 at least, this isn't going to change. With some of the > bigger changes with how package repositories tie in with package selections, > etc, this may end up changing in the future but not guaranteed to do so. I have no idea if anything changed for F8. CU knurd From fedora at leemhuis.info Wed Sep 12 18:35:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 20:35:27 +0200 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <46E81828.7000006@leemhuis.info> Message-ID: <46E8316F.1090808@leemhuis.info> On 12.09.2007 20:27, Rex Dieter wrote: > Thorsten Leemhuis wrote: >> On 12.09.2007 18:12, Rex Dieter wrote: >>> Thorsten Leemhuis wrote: >>>> On 12.09.2007 17:44, Bill Crawford wrote: >>>>> On 12/09/2007, Jima wrote: >>>>>> Couldn't this be managed by rpmfusion using a comps file, and >>>>>> grouping >>>>>> various packages with "DVD support," "MP3 support," or whatnot? `yum >>>>>> groupinstall "DVD Support"`... >>>>> I think that's the best suggestion on how to balance packaging versus >>>>> usability, so far ... >>>> FYI for Livna I tried something else, but it didn't work out. I just >>>> used the same groups as Fedora in Livna (as Fedora Extras did in the >>>> past for Core as well) and made some crucial packages 'type="default"' >>>> -- for example gstreamer-plugins-ugly for the "GNOME Desktop >>>> Environment" . I assumed anaconda would then install >>>> gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is >>>> selected by default. But anaconda/pirut did not do that (and I assume it >>>> still don't). >>> At our site, >> kde-redhat? > @ UNL. > We add items to various groups, say, kde-desktop, and then > $ yum groupinstall kde-desktop > not only includes the fedora items, but our added ones as well. That should work for livna as well. Say you installed with KDE and now want to switch to gnome you should get the gstreamer-plugins-ugly as well. Other way around worked, too -- but I did not try it in the past past months. But it does not work directly in the installer properly... Cu knurd From tcallawa at redhat.com Wed Sep 12 18:48:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 12 Sep 2007 14:48:59 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189620049.7051.38.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> Message-ID: <1189622939.3567.11.camel@localhost.localdomain> On Wed, 2007-09-12 at 12:00 -0600, Richi Plana wrote: > On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote: > > I am not talking about any repo files. Just a pointer in documentation > > or in any application. The details are explained in FAB list. That > > requires Legal to look into this. No amount of layman arguments can help > > us make a decision and legal perspectives doesn't always make logical > > sense which many tend to assume. > > In other words, Fedora's lawyers have deemed it risky (or even downright > illegal) to include in the distro .repo files that would allow users to > download, say, US-illegal codecs even if the repository itself > physically and logistically isn't connected to Fedora. But pointers in > documents can. > > There we go. That's what the legal experts are saying. Do I have it > about right? It's called contributory infringement. In the United States, 35 U.S.C. ? 271(b) defines (active) induced infringement: "Whoever actively induces infringement of a patent shall be liable as an infringer." This means, we cannot point to a repo which contains software which infringes upon software patents, or we are just as liable as the people actually infringing the patents. We can't include a repo file, nor can we say "the files are over there". Not in CodecBuddy, not in yum, not in a tree, not with a cat. No. ~spot From jspaleta at gmail.com Wed Sep 12 18:50:47 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Sep 2007 10:50:47 -0800 Subject: Announcing rpmfusion In-Reply-To: <46E82A42.7000403@hhs.nl> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> <46E82A42.7000403@hhs.nl> Message-ID: <604aa7910709121150t420ad048k6ef208d440e82575@mail.gmail.com> On 9/12/07, Hans de Goede wrote: > I think this is a bad idea, we really want the user to have todo less to get a > complete set of codecs, not more. Am I reading this correctly... are you arguing that aggregation is advisable at the packaging level for gstreamer plugins. Doesn't this contradict your previously communicated view that upstream aggregation is un-advisable as expressed for the case of kdesdk? Welcome to my world of gray. -jef"or is it grey?"spaleta From fedora at leemhuis.info Wed Sep 12 18:55:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Sep 2007 20:55:09 +0200 Subject: Announcing rpmfusion In-Reply-To: <1189621729.16586.1.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <200709112003.58735.jaroslav@aster.pl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <544eb990709120320y5a561eb0wb3610c5d3a539bef@mail.gmail.com> <46E7C004.9000707@nicubunu.ro> <544eb990709120347k4d4a47b5ha17a22588e0fcbb1@mail.gmail.com> <544eb990709120844h729b2384o16e0e0ec47d6eb73@mail.gmail.com> <46E80CAD.2000104@leemhuis.info> <20070912121313.2b3bfa19@lumos.localdomain> <46E81778.4040108@leemhuis.info> <20070912141422.20ea6a05@lumos.localdomain> <1189621729.16586.1.camel@localhost.localdomain> Message-ID: <46E8360D.3000701@leemhuis.info> On 12.09.2007 20:28, Jeremy Katz wrote: > On Wed, 2007-09-12 at 14:14 -0400, Jesse Keating wrote: >> On Wed, 12 Sep 2007 18:44:40 +0200 > [...] When doing the interactive install, we don't take the time hit > of having to re-determine all of the defaults, etc based on the added > repo. That said, some future (F9 hopefully; didn't have enough time > to get it all in for F8) changes might make that a lot less painful thx Jeremy for clarifying that (and tia for fixing it in the long term hopefully). I'll think about a solution for rpmfusion (likely the rpmfusion specific groups -- that's not perfect, but better than nothing. I even always wanted to do that for livna in the past months as well, but did not come around to it...) CU knurd From qspencer at ieee.org Wed Sep 12 19:03:02 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 12 Sep 2007 14:03:02 -0500 Subject: Package EOL troubles Message-ID: <46E837E6.3040601@ieee.org> Because of an upstream name change, some time ago, I built a version of suitesparse, which obsoletes ufsparse, and is now in rawhide. I have tried to complete the package EOL process for ufsparse (remove everything and check in a dead.package file), but I can no longer commit changes because for some reason I have been removed from the ACL. The next step in the instructions was to send an e-mail to rel-eng at fedoraproject.org requesting removal of the package from the repository, which I did weeks ago, including an explanation of my inability to check in changes to rpms/ufsparse/devel. Also, someone else mentioned that ufsparse should be removed from rawhide on this list nearly a month ago. The package is still in the rawhide repository. Is there something else I should have done? Quentin From jkeating at redhat.com Wed Sep 12 19:17:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Sep 2007 15:17:55 -0400 Subject: Package EOL troubles In-Reply-To: <46E837E6.3040601@ieee.org> References: <46E837E6.3040601@ieee.org> Message-ID: <20070912151755.34638186@lumos.localdomain> On Wed, 12 Sep 2007 14:03:02 -0500 Quentin Spencer wrote: > Because of an upstream name change, some time ago, I built a version > of suitesparse, which obsoletes ufsparse, and is now in rawhide. I > have tried to complete the package EOL process for ufsparse (remove > everything and check in a dead.package file), but I can no longer > commit changes because for some reason I have been removed from the > ACL. The next step in the instructions was to send an e-mail to > rel-eng at fedoraproject.org requesting removal of the package from the > repository, which I did weeks ago, including an explanation of my > inability to check in changes to rpms/ufsparse/devel. Also, someone > else mentioned that ufsparse should be removed from rawhide on this > list nearly a month ago. The package is still in the rawhide > repository. Is there something else I should have done? d'oh, I somehow lost that mail. I'm blocking it now. As to the dead.package, I can probably do that for you. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From qspencer at ieee.org Wed Sep 12 19:21:40 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 12 Sep 2007 14:21:40 -0500 Subject: Package EOL troubles In-Reply-To: <20070912151755.34638186@lumos.localdomain> References: <46E837E6.3040601@ieee.org> <20070912151755.34638186@lumos.localdomain> Message-ID: <46E83C44.20108@ieee.org> Jesse Keating wrote: > On Wed, 12 Sep 2007 14:03:02 -0500 > Quentin Spencer wrote: > > >> Because of an upstream name change, some time ago, I built a version >> of suitesparse, which obsoletes ufsparse, and is now in rawhide. I >> have tried to complete the package EOL process for ufsparse (remove >> everything and check in a dead.package file), but I can no longer >> commit changes because for some reason I have been removed from the >> ACL. The next step in the instructions was to send an e-mail to >> rel-eng at fedoraproject.org requesting removal of the package from the >> repository, which I did weeks ago, including an explanation of my >> inability to check in changes to rpms/ufsparse/devel. Also, someone >> else mentioned that ufsparse should be removed from rawhide on this >> list nearly a month ago. The package is still in the rawhide >> repository. Is there something else I should have done? >> > > d'oh, I somehow lost that mail. I'm blocking it now. As to the > dead.package, I can probably do that for you. > Thank you. Quentin From 440volt.tux at gmail.com Wed Sep 12 19:25:23 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Thu, 13 Sep 2007 00:55:23 +0530 Subject: koji build failed In-Reply-To: <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> Hi ! > > > > However dist-f8 fails with following error :- > > var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw/constants.py:libdir > > = > > os.path.normpath('/var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw') > > Found '/var/tmp/straw-0.27-4-F13608' in installed files; aborting > > error: Bad exit status from /var/tmp/rpm-tmp.65277 (%install) > > > > > > > > Tried to fix it with the following > > > > sed -i -e "s@${RPM_BUILD_ROOT}@@" constants.py.in > > > > > You need to find out why and when constants.py (not constants.py.in) > is created with $RPM_BUILD_ROOT filled into it. Then replacing the > buildroot string in the %install section would very likely work. Also > note that the %build section should not do anything with $RPM_BUILD_ROOT > unless it cannot be avoided. > constant.py is used to constants.py is there so that the program knows its version and the location of its data files Placed in straw_distutils.py (attached) here it is pointing to tmp which causes an error in check build root how can i prevent constants.py from pinting to tmp?? please help -------------- next part -------------- A non-text attachment was scrubbed... Name: straw_distutils.py Type: text/x-python Size: 19797 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Sep 12 19:42:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 21:42:13 +0200 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> Message-ID: <1189626133.3999.5.camel@rousalka.dyndns.org> Le mercredi 12 septembre 2007 ? 08:17 -0800, Jeff Spaleta a ?crit : > On 9/12/07, Les Mikesell wrote: > > Or, if you need another level of indirection, include a repo that > > doesn't itself have anything controversial but has a package that > > configures yum for repos that might. > > oh classy. So how would that work from a user perspective? I hope yum has a check somewhere to forbid installation of unknown default-on repositories. -- 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 skvidal at fedoraproject.org Wed Sep 12 19:43:09 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Sep 2007 15:43:09 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189626133.3999.5.camel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> Message-ID: <1189626190.6704.106.camel@cutter> On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote: > Le mercredi 12 septembre 2007 ? 08:17 -0800, Jeff Spaleta a ?crit : > > On 9/12/07, Les Mikesell wrote: > > > Or, if you need another level of indirection, include a repo that > > > doesn't itself have anything controversial but has a package that > > > configures yum for repos that might. > > > > oh classy. So how would that work from a user perspective? > > I hope yum has a check somewhere to forbid installation of unknown > default-on repositories. how on earth would yum know? Do you want yum to have special behavior if it detects a .repo file? That's just ludicrous. If you cannot trust the repo then don't use it. That's it. -sv From michel.sylvan at gmail.com Wed Sep 12 19:47:06 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 12 Sep 2007 15:47:06 -0400 Subject: koji build failed In-Reply-To: <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> Message-ID: On 12/09/2007, subhodip biswas <440volt.tux at gmail.com> wrote: > > > However dist-f8 fails with following error :- > > > var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw/constants.py:libdir > > > = > > > os.path.normpath('/var/tmp/straw-0.27-4-F13608/usr/lib/python2.5/site-packages/straw') > > > Found '/var/tmp/straw-0.27-4-F13608' in installed files; aborting > > > error: Bad exit status from /var/tmp/rpm-tmp.65277 (%install) > > > > > > > > > > > > Tried to fix it with the following > > > > > > sed -i -e "s@${RPM_BUILD_ROOT}@@" constants.py.in > > > > > > > > > You need to find out why and when constants.py (not constants.py.in) > > is created with $RPM_BUILD_ROOT filled into it. Then replacing the > > buildroot string in the %install section would very likely work. Also > > note that the %build section should not do anything with $RPM_BUILD_ROOT > > unless it cannot be avoided. > > > constant.py is used to constants.py is there so that the program knows > its version and the location of its data files > > Placed in straw_distutils.py (attached) > > here it is pointing to tmp which causes an error in check build root > > how can i prevent constants.py from pinting to tmp?? please help > You should perhaps try building on your own machine first. It's easier to debug when you can actually poke into the files being installed in $RPM_BUILD_ROOT. Regards, -- Michel From 440volt.tux at gmail.com Wed Sep 12 20:05:16 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Thu, 13 Sep 2007 01:35:16 +0530 Subject: koji build failed In-Reply-To: References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> Message-ID: <539333cb0709121305g513f08adhfcca95e688e1deb5@mail.gmail.com> hi ! I am currently using fedora 7 and rpmbuild -ba straw.spec is somehow falling through check-buildroot. so cant really notice the problem. koji build for --dist-fc7 and both my machine shows a succesful " build" > > > You should perhaps try building on your own machine first. It's easier > to debug when you can actually poke into the files being installed in > $RPM_BUILD_ROOT. > > Regards, > > -- > Michel > apologies beforehand for the inconvenience caused. Regards Subhodip Biswas From ville.skytta at iki.fi Wed Sep 12 20:26:34 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 12 Sep 2007 23:26:34 +0300 Subject: Making the xine-lib-extras nondependent on xine-lib-arts? In-Reply-To: References: <1189286936.3143.20.camel@pc-notebook> <200709110937.29935.ville.skytta@iki.fi> Message-ID: <200709122326.34622.ville.skytta@iki.fi> On Tuesday 11 September 2007, Kevin Kofler wrote: > > (Disclaimer: I have not tested the Xine PulseAudio plugin yet. IMHO, the > important part there is not "Does the code look good?", but "Does it work > well?".) So far all we have is the recommendation from the PA upstream and Fedora maintainer to not ship it in the main package, which I think especially in absence of reports that it works well (enough?) should not be taken lightly. From ville.skytta at iki.fi Wed Sep 12 20:27:50 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 12 Sep 2007 23:27:50 +0300 Subject: Proposed changes to buildsys-build group (otherwise known as the Exceptions list) In-Reply-To: <200709081212.47162.ville.skytta@iki.fi> References: <20070830205314.7e66bdff@ender> <20070907214812.05d204e1@ender> <200709081212.47162.ville.skytta@iki.fi> Message-ID: <200709122327.50706.ville.skytta@iki.fi> On Saturday 08 September 2007, Ville Skytt? wrote: > On Saturday 08 September 2007, Jesse Keating wrote: > > On Thu, 30 Aug 2007 20:53:14 -0400 > > > > Jesse Keating wrote: > > > The proposed new explicit list would look like: > > [...] > > > These are now the minimal build group. Reasonable requests to add more > > of what is currently implicit into the explicit list will gladly be > > discussed, but for now the important thing was to get util-linux-ng > > back in the set, and to remove perl(-devel) from the set. > > Which distro branches does this change affect? EPEL too? > > util-linux-ng is only in Fedora devel, will util-linux be included in the > list for earlier distro versions? If yes, I think it'd be good to clarify > that in Wiki. > > Things at http://buildsys.fedoraproject.org/buildgroups/ don't seem to have > been updated yet. Ping? From michel.sylvan at gmail.com Wed Sep 12 20:36:23 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 12 Sep 2007 16:36:23 -0400 Subject: koji build failed In-Reply-To: <539333cb0709121305g513f08adhfcca95e688e1deb5@mail.gmail.com> References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> <539333cb0709121305g513f08adhfcca95e688e1deb5@mail.gmail.com> Message-ID: On 12/09/2007, subhodip biswas <440volt.tux at gmail.com> wrote: > hi ! > > I am currently using fedora 7 and rpmbuild -ba straw.spec is somehow > falling through check-buildroot. so cant really notice the problem. > koji build for --dist-fc7 and both my machine shows a succesful " > build" Find the file on your local machine's buildroot that contains the buildroot path, find out how it gets installed there (there should be a file in the tarball with a similar name to the file that ends up installed) and work out how the file ends up containing the buildroot path. If nothing works, download an earlier version of the source tarball and do a recursive diff to see what has changed. If it's an upstream bug, report it. If not, made any change you need to your packaging script. Let me know if you can't figure it out by Friday, I should be able to help you then. Regards, -- Michel From nicolas.mailhot at laposte.net Wed Sep 12 20:58:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Sep 2007 22:58:17 +0200 Subject: Announcing rpmfusion In-Reply-To: <1189626133.3999.5.camel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> Message-ID: <1189630697.3139.0.camel@rousalka.dyndns.org> Le mercredi 12 septembre 2007 ? 21:42 +0200, Nicolas Mailhot a ?crit : > Le mercredi 12 septembre 2007 ? 08:17 -0800, Jeff Spaleta a ?crit : > > On 9/12/07, Les Mikesell wrote: > > > Or, if you need another level of indirection, include a repo that > > > doesn't itself have anything controversial but has a package that > > > configures yum for repos that might. > > > > oh classy. So how would that work from a user perspective? > > I hope yum has a check somewhere to forbid installation of unknown > default-on repositories. There is a difference between trusting a repo and trusting it to authorize other repos -- 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 skvidal at fedoraproject.org Wed Sep 12 21:02:42 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Sep 2007 17:02:42 -0400 Subject: Announcing rpmfusion In-Reply-To: <1189630697.3139.0.camel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> <1189630697.3139.0.camel@rousalka.dyndns.org> Message-ID: <1189630962.6704.108.camel@cutter> On Wed, 2007-09-12 at 22:58 +0200, Nicolas Mailhot wrote: > Le mercredi 12 septembre 2007 ? 21:42 +0200, Nicolas Mailhot a ?crit : > > Le mercredi 12 septembre 2007 ? 08:17 -0800, Jeff Spaleta a ?crit : > > > On 9/12/07, Les Mikesell wrote: > > > > Or, if you need another level of indirection, include a repo that > > > > doesn't itself have anything controversial but has a package that > > > > configures yum for repos that might. > > > > > > oh classy. So how would that work from a user perspective? > > > > I hope yum has a check somewhere to forbid installation of unknown > > default-on repositories. > > There is a difference between trusting a repo and trusting it to > authorize other repos > trusting the repo to have packagers who won't do that stuff. -sv From jspaleta at gmail.com Wed Sep 12 21:07:27 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Sep 2007 13:07:27 -0800 Subject: Announcing rpmfusion In-Reply-To: <1189630697.3139.0.camel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> <1189630697.3139.0.camel@rousalka.dyndns.org> Message-ID: <604aa7910709121407q62081865s3fba2301528fdffb@mail.gmail.com> On 9/12/07, Nicolas Mailhot wrote: > There is a difference between trusting a repo and trusting it to > authorize other repos This is a rat hole. If repositories are going to maliciously add additional repositories, then the packages from that repo can very well do pretty much all sorts of malicious reconfiguration. I don't see why repo configuration is any more sensitive than other package payloads or scriptlet actions. Hell you don't even need to add an additional file all you need to do is add additional repository definitions in the repo file you already provide. I simply don't understand how you could protect a client system from a repository that wanted to ensure that a new repository definition was installed and enabled by default. On top of that there are justifiable reasons to need to add additional repo files and additional repository tags inside a repo file due to repository re-organization. -jef From seg at haxxed.com Wed Sep 12 21:11:25 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 12 Sep 2007 16:11:25 -0500 Subject: Volume control problems In-Reply-To: <1189562460.15173.2.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> Message-ID: <1189631485.18800.50.camel@localhost> On Tue, 2007-09-11 at 21:01 -0500, Mike Chambers wrote: > Latest rawhide install as of this morning, and am running into a volume > control situation. It seems that the icon in the panel is muted and/or > won't show a volume control. And the error message is something like > below... > > No volume control GStreamer plugins and/or devices found. > > Yet if I do a detect sound card, it finds it (SB Audigy LS?) and plays > the sample sound just fine. > > Any ideas? Do you by any chance have a USB MIDI device plugged in? I've noticed that a MIDI-only device still takes up a card slot, and USB devices get detected first. Thus upon every boot, if I forget to unplug or turn off my MIDI keyboard, it takes card slot 0, the motherboard audio ends up in slot 1, and sound output is basically fucked as everything tries to output to the MIDI keyboard, which doesn't do PCM. This is on Fedora 7. Maybe pulseaudio actually fixes this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From z.kota at gmx.net Wed Sep 12 21:18:19 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Wed, 12 Sep 2007 23:18:19 +0200 (CEST) Subject: openoffice-pyuno and external python programs Message-ID: Hi, Files from openoffice.org-pyuno are installed under /usr/lib/openoffice.org2.0. So, 'import uno' from python gives an import error. How should we support external programs to use this module? Should we patch the program to import uno.py from this directory somehow? Or would be better to change the installation path in the openoffice.org-pyuno package? Debian for instance installs /usr/share/pycentral/python-uno/site-packages/uno.py /usr/share/pycentral/python-uno/site-packages/unohelper.py /usr/lib/python2.4/site-packages/pyuno.so Zoltan From seg at haxxed.com Wed Sep 12 21:26:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 12 Sep 2007 16:26:47 -0500 Subject: udev performance In-Reply-To: <46E7AEDD.5050608@redhat.com> References: <46E69B37.3000604@redhat.com> <20070911141738.GA23797@nostromo.devel.redhat.com> <46E6A4B2.1040507@redhat.com> <46E6B814.5000404@redhat.com> <46E78F69.5020400@redhat.com> <20070912072331.GQ20571@devserv.devel.redhat.com> <46E79569.3040301@redhat.com> <20070912084835.GR20571@devserv.devel.redhat.com> <46E7A9EC.6080702@redhat.com> <20070912091357.GS20571@devserv.devel.redhat.com> <46E7AEDD.5050608@redhat.com> Message-ID: <1189632407.18800.52.camel@localhost> On Wed, 2007-09-12 at 11:18 +0200, Harald Hoyer wrote: > Jakub Jelinek schrieb: > > On Wed, Sep 12, 2007 at 10:57:16AM +0200, Harald Hoyer wrote: > >> udev linked with libmodprobe.so, reading the config only once and having > >> the above search tables in memory, would be the fastest solution. > > > > No. If they are just read, rather than preparing hash table for > > modules.dep and search tree for modules.alias, then you just avoid > > the cost of reading it many times, but still spend the significant > > time parsing the data to find what you are looking for. > > > > Jakub > > > > And that data parsing time can also be reduced by collecting the unresolvable modaliases at depmod time. Bloom filter? http://en.wikipedia.org/wiki/Bloom_filter -------------- 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 mike at miketc.com Wed Sep 12 21:58:34 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 12 Sep 2007 16:58:34 -0500 Subject: Volume control problems In-Reply-To: <20070912150131.GA6177@tango.0pointer.de> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> Message-ID: <1189634314.2993.2.camel@scrappy.miketc.com> On Wed, 2007-09-12 at 17:01 +0200, Lennart Poettering wrote: > Hmm. PulseAudio is unable to open your audio device. Are you sure it > is properly available in the system? Could you please run "pulsaudio > -vv"? And check whether "aplay -D hw:0 /dev/urandom" works? [mike at scrappy ~]$ pulseaudio -vv E: pid.c: daemon already running. E: main.c: pa_pid_file_create() failed. [mike at scrappy ~]$ aplay -D hw:0 /dev/urandom ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card aplay: main:545: audio open error: No such device Here is all I can see in modprobe.conf on audio.. options snd-card-0 index=0 options snd-ca0106 index=0 Maybe mine isn't found as there is nothing else on sound? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From buildsys at fedoraproject.org Wed Sep 12 22:11:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 12 Sep 2007 18:11:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-12 Message-ID: <20070912221130.72928152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 6 (!) edac-utils-0.9-6.fc6 : INVALID rebuild, not published! lesstif-0.95.0-19.fc6 mediawiki-1.8.5-9.fc6 mksh-31c-1.fc6 NEW wdaemon-0.11-1.fc6 : Hotplug helper for Wacom X.org driver NEW xsc-1.5-2.fc6 : A clone of the old vector graphics video game Star Castle Changes in Fedora Extras 6: edac-utils-0.9-6.fc6 -------------------- * Tue Jul 17 2007 Aristeu Rozanski 0.9-6 - Building for FC6 package lesstif-0.95.0-19.fc6 --------------------- * Sat Sep 01 2007 Hans de Goede 0.95.0-19 - Fix more 64 bit XChange/GetWindowProperty issues (inspired by the cut and paste 64 bit fix which was an XChange/GetWindowProperty issue too) - Fix z88: http://www.z88.uni-bayreuth.de/ not working with lesstif - Stop lessstif from spewing messages about XtUngrab... (bz 210384) * Thu Aug 30 2007 Hans de Goede 0.95.0-18 - Fix cut and paste from / to lesstif apps on 64 bits machines (bz 243508) - Fix accelkeys which use more then one modifier (bz 214018) * Thu Aug 30 2007 Hans de Goede 0.95.0-17 - Update included Debian 0.94.4-2 patch to the Debian 0.95.0-2 patch - Not only include but also actually apply Debian's patches (bz 261821) - Add 2 patches with small fixes from lesstif CVS (bz 261821) - Do not apply lesstif-64.patch it causes more issues then it fixes (bz 253456) * Wed Aug 15 2007 Patrice Dumas 0.95.0-16 - conform better to openmotif API, lesstif-64.patch, by kgallowa at redhat.com - fix licenses - keep timestamps - add mwm xsession file mediawiki-1.8.5-9.fc6 --------------------- * Wed Sep 12 2007 Ville Skytt? - 1.8.5-9 - Update to 1.8.5 (security; http://secunia.com/advisories/26772/, #287881) mksh-31c-1.fc6 -------------- * Wed Sep 12 2007 Robert Scheck 31c-1 - Upgrade to 31c - Added a buildrequirement to ed, added arc4random.c file * Tue Sep 11 2007 Robert Scheck 31b-1 - Upgrade to 31b - Use script to get %check happy (thanks to Thorsten Glaser) wdaemon-0.11-1.fc6 ------------------ * Wed Aug 01 2007 Aristeu Rozanski 0.11-1 - Updated to version 0.11 xsc-1.5-2.fc6 ------------- * Sat Sep 08 2007 Jon Ciesla - 1.5-2 - Added h-i-theme requires, xparentfied icon. * Thu Sep 06 2007 Jon Ciesla - 1.5-1 - create. From mzerqung at 0pointer.de Wed Sep 12 22:19:24 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 13 Sep 2007 00:19:24 +0200 Subject: Volume control problems In-Reply-To: <1189634314.2993.2.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> Message-ID: <20070912221924.GA20538@tango.0pointer.de> On Wed, 12.09.07 16:58, Mike Chambers (mike at miketc.com) wrote: > > On Wed, 2007-09-12 at 17:01 +0200, Lennart Poettering wrote: > > > Hmm. PulseAudio is unable to open your audio device. Are you sure it > > is properly available in the system? Could you please run "pulsaudio > > -vv"? And check whether "aplay -D hw:0 /dev/urandom" works? > > [mike at scrappy ~]$ pulseaudio -vv > E: pid.c: daemon already running. > E: main.c: pa_pid_file_create() failed. Try "pulseaudio -k" first to shut down the running instance. > [mike at scrappy ~]$ aplay -D hw:0 /dev/urandom > ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card > aplay: main:545: audio open error: No such device Apparently there is no sound card detected at all. Please check wheter anything is listed in /proc/asound/cards. Check if you plugged everything in correctly. PulseAudio is not going to make your sound magically work if your sound card is not recognized at all by the Linux kernel. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From sertac.liste at gmail.com Wed Sep 12 22:36:57 2007 From: sertac.liste at gmail.com (=?utf-8?B?U2VydGHDpyDDli4gWcSxbGTEsXo=?=) Date: Thu, 13 Sep 2007 01:36:57 +0300 Subject: Trusting repositories (was: Re: Announcing rpmfusion) In-Reply-To: <1189626190.6704.106.camel@cutter> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> <1189626190.6704.106.camel@cutter> Message-ID: <20070912223657.GA3613@kerouac> [12.Eyl.07 15:43 -0400] seth vidal: >On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote: >> I hope yum has a check somewhere to forbid installation of unknown >> default-on repositories. > > how on earth would yum know? Do you want yum to have special behavior > if it detects a .repo file? Not for .repo files, but it would be nice to check for GPG keys it installs. > If you cannot trust the repo then don't use it. Building a chain of trust that way looks wrong. -- ~serta? From ihok at hotmail.com Wed Sep 12 23:17:27 2007 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 12 Sep 2007 23:17:27 +0000 (UTC) Subject: weird kernel update? Message-ID: Installing for dependencies: kernel x86_64 2.6.22.5-76.fc7 updates 17 M Removing: kernel x86_64 2.6.22.1-41.fc7 installed 63 M That's quite a difference in file sizes. Is something fishy? From skvidal at fedoraproject.org Wed Sep 12 23:17:06 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Sep 2007 19:17:06 -0400 Subject: weird kernel update? In-Reply-To: References: Message-ID: <1189639026.6704.115.camel@cutter> On Wed, 2007-09-12 at 23:17 +0000, Jack Tanner wrote: > Installing for dependencies: > kernel x86_64 2.6.22.5-76.fc7 updates 17 M > > Removing: > kernel x86_64 2.6.22.1-41.fc7 installed 63 M > > That's quite a difference in file sizes. Is something fishy? Pretty sure it is just download size (ie: size of pkg) and installed size differences -sv From ihok at hotmail.com Wed Sep 12 23:29:32 2007 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 12 Sep 2007 23:29:32 +0000 (UTC) Subject: weird kernel update? References: <1189639026.6704.115.camel@cutter> Message-ID: seth vidal fedoraproject.org> writes: > > Pretty sure it is just download size (ie: size of pkg) and installed > size differences So the sizes below aren't directly comparable? If that's true, it's confusing to display them that way. $ yum info kernel Installed Packages Name : kernel Arch : x86_64 Version: 2.6.22.1 Release: 41.fc7 Size : 63 M Repo : installed Summary: The Linux kernel (the core of the Linux operating system) Description: The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. Name : kernel Arch : x86_64 Version: 2.6.22.4 Release: 65.fc7 Size : 63 M Repo : installed Summary: The Linux kernel (the core of the Linux operating system) Description: The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. Available Packages Name : kernel Arch : x86_64 Version: 2.6.22.5 Release: 76.fc7 Size : 17 M Repo : updates Summary: The Linux kernel (the core of the Linux operating system) Description: The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. From skvidal at fedoraproject.org Wed Sep 12 23:31:13 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Sep 2007 19:31:13 -0400 Subject: weird kernel update? In-Reply-To: References: <1189639026.6704.115.camel@cutter> Message-ID: <1189639873.6704.117.camel@cutter> On Wed, 2007-09-12 at 23:29 +0000, Jack Tanner wrote: > seth vidal fedoraproject.org> writes: > > > > Pretty sure it is just download size (ie: size of pkg) and installed > > size differences > > So the sizes below aren't directly comparable? If that's true, it's confusing to > display them that way. okay, please file a bug. -sv From ihok at hotmail.com Wed Sep 12 23:40:41 2007 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 12 Sep 2007 23:40:41 +0000 (UTC) Subject: weird kernel update? References: <1189639026.6704.115.camel@cutter> <1189639873.6704.117.camel@cutter> Message-ID: seth vidal fedoraproject.org> writes: > > > On Wed, 2007-09-12 at 23:29 +0000, Jack Tanner wrote: > > So the sizes below aren't directly comparable? If that's true, it's > > confusing to display them that way. > > okay, please file a bug. https://bugzilla.redhat.com/show_bug.cgi?id=288681 From ngompa13 at gmail.com Thu Sep 13 00:15:44 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 12 Sep 2007 19:15:44 -0500 Subject: Announcing rpmfusion In-Reply-To: <1189606671.3567.5.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> Message-ID: <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied. This is why Fedora has such a bad rep (I am not saying it is a bad distro, I use it for everything!) with uninformed people (people making the choice of using Linux for the first time). Though I think CodecBuddy NEEDS support for reading through repositories to find codecs because there ARE Free codecs not in the Fedora DVD by default and should be able to be detected and installed. On 9/12/07, Tom spot Callaway wrote: > > > On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > > > Or - why not move the entire repo to places that can have all the > > contents? What's the point of even worrying about this issue? > > It's not where the repo sits, its where Red Hat is based out of. > > ~spot > > -- > 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 ngompa13 at gmail.com Thu Sep 13 00:25:07 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 12 Sep 2007 19:25:07 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> Message-ID: <8278b1b0709121725r6b7cdf78rc1cbde56833327eb@mail.gmail.com> Well, I have actually used Wubi a few days ago on a recently purchased family Vista (blech) laptop, and I really haven't experienced any issues with it. Actually those FS issues in NTFS have nothing to do with Wubi in particular, but rather with the way fragmentation in NTFS is and how it affects disk images and vice versa (at least from a user PoV I can explain it, i know no technical details about it). Whenever you have an NTFS partition with files that are large compressed filesystems (any form of compressed tree, e.g. tarballs, disk images, ISO, zip), fragmentation occurs more rapidly and FS degeneration seems to become more likely. This issue is less likely on ext3 in my experience, but it is still possible. This issue is probably why FAT32 has the filesize limitation it does. NTFS probably was supposed to fix that, but obviously didn't. Though those are merely speculations (regarding the whys about design). Anyways, that is my educated uneducated opinion :) And anaconda does support completely automated installation (kickstart files!), for the others, someone else needs to answer.... On 9/12/07, Ago wrote: > > > Since I've advocated a win32 installer for Fedora in the past, > > I'll at least say - cool. Unfortunately I also don't forsee myself > > having time to dedicate to this in the near future(nor the desire, as I > > am and hope to stay winblowz free ;). But I hope someone else finds the > > time :) > > Good questions. There are in fact 2 separate issues. > > 1) Hosting filesystem corruption (ntfs). We had a few reports where people > were > not able to boot into Windows after an hardreboot in Wubi. Filesystem > corruption does happen when you hardreboot, whether you use Wubi or not. > Sometimes you get lucky (also with Wubi) sometimes you do not. The real > question is whether Wubi (ntfs-3g in this case) makes things any worse. On > average, we have 1 such report every 10K downloads. Add that Wubi users > tend to > reboot more often than usual, since they are in a new environment and > often > they do not know how to get out of a real or apparent deadlock. So are the > numbers we see physiological? Honest answer is that I have no clue. I > discussed > that with Szaka (ntfs-3g author) and according to him, ntfs-3g does not > make > things any worse and there is little to be done on his side. If you have a > different opinion on this I would like to hear from you. > > 2) Hosted filesystem corruption (ext3). When Ext3 writes the journal, the > data > does not end up on the HD but gets handled by ntfs, which in turns may or > may > not write the data to the HD. So if you hard reboot, data loss in the > hosting > filesystem may cause journal corruption of the hosted filesystem, which > makes > recovery quite challenging. This is not an ntfs/ext3 specific issue, you > would > have that in any nested filesystem configuration (or at least this is my > understanding). What we have done was to tweak sysctl dirty settings, so > that > dirty pages are flushed to disk as often as possible. That seems to have > done > the trick. Since we did that, I cannot recall any complaint due to ext3 > data > loss, but of course that does not eliminate the issue. > > On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem > because > of the ordering in which userspace processes are terminated/resumed which > becomes an issue if you use a userspace filesystem (if the loopfile is > hosted > on vfat, suspend works fine). With hibernation you also have to handle the > issue of having swap on a file. > > My take on all this is that Wubi is a "short term" installation. It's good > enough for a few days and far more captivating than a live CD or a VM. But > it's > not ok for data-sensitive situations or for long term use. I would use the > word "demo" if it did not have a try-then-pay connotation. And yes, > because of > the above, some users will be left with a bitter taste in their mouth, and > the > reputation for reliability will be negatively affected. On the other hand > you > will be able to reach many users that would not dare to try Linux > otherwise, > you will provide Joe Average (read 90% of the users out there) with a > one-click > installer and that helps a lot when you have to bear the stigmata of being > seen > as a "difficult OS". > > It's a trade-off. > > > Regards, > > Ago > > -- > 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 dmc.fedora at filteredperception.org Thu Sep 13 01:27:07 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 12 Sep 2007 20:27:07 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> Message-ID: <46E891EB.8010408@filteredperception.org> Ago wrote: > Good questions. There are in fact 2 separate issues. > > > 2) Hosted filesystem corruption (ext3). When Ext3 writes the journal, the data > does not end up on the HD but gets handled by ntfs, which in turns may or may > not write the data to the HD. So if you hard reboot, data loss in the hosting > filesystem may cause journal corruption of the hosted filesystem, which makes > recovery quite challenging. This is I think what I've been noticing as well in a similar situation. The one time I tried to recover, fsck _completely_ horked the ext3 fs. This is not an ntfs/ext3 specific issue, you would > have that in any nested filesystem configuration (or at least this is my > understanding). What we have done was to tweak sysctl dirty settings, so that > dirty pages are flushed to disk as often as possible. This was also my first thought. The down side, is that in my usage scenario, the fs would be typically on a usb-flash-stick, and it seems like an undesirable thing to be writing to it as often as possible, rather than periodically. Question- are these sysctl settings controlling the writes from the hosted-fs->host-fs, or from the host-fs->disk, or both? That seems to have done > the trick. Since we did that, I cannot recall any complaint due to ext3 data > loss, but of course that does not eliminate the issue. > > On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because > of the ordering in which userspace processes are terminated/resumed which > becomes an issue if you use a userspace filesystem (if the loopfile is hosted > on vfat, suspend works fine). With hibernation you also have to handle the > issue of having swap on a file. This sounds like it could be fixed with smarter ordering. Do you foresee that, or is it for some reason a more-or-less unfixable problem? > > My take on all this is that Wubi is a "short term" installation. It's good ... > It's a trade-off. That's engineering ;) thx... -dmc From cjdahlin at ncsu.edu Thu Sep 13 02:55:50 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 12 Sep 2007 22:55:50 -0400 Subject: Announcing rpmfusion In-Reply-To: <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> Message-ID: <46E8A6B6.5070606@ncsu.edu> King InuYasha wrote: > Unfortunately, because Red Hat IS a USA-based company, they (and all > us Americans) cannot make a distro available that is directly > connected in ANY fashion to repositories containing patented > technologies that do not have an license explicitly stating that there > will be no repercussions for such aforementioned inclusion scenarios > to be applied. This is why Fedora has such a bad rep (I am not saying > it is a bad distro, I use it for everything!) with uninformed people > (people making the choice of using Linux for the first time). Though I > think CodecBuddy NEEDS support for reading through repositories to > find codecs because there ARE Free codecs not in the Fedora DVD by > default and should be able to be detected and installed. > Maybe web2.0 is the solution :) . What if we have a way to query a list of repos that is stored on a central site that can be appended to by anyone? Then we might be able to disclaim responsibility for pointing it out. > On 9/12/07, *Tom spot Callaway* > wrote: > > > On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > > > Or - why not move the entire repo to places that can have all the > > contents? What's the point of even worrying about this issue? > > It's not where the repo sits, its where Red Hat is based out of. > > ~spot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From ngompa13 at gmail.com Thu Sep 13 03:00:44 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 12 Sep 2007 22:00:44 -0500 Subject: Announcing rpmfusion In-Reply-To: <46E8A6B6.5070606@ncsu.edu> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <46E8A6B6.5070606@ncsu.edu> Message-ID: <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> We might be in hot water still, but at least liability could possibly not be claimed if it is in the Terms of Use of this community list of repositories... On 9/12/07, Casey Dahlin wrote: > > King InuYasha wrote: > > Unfortunately, because Red Hat IS a USA-based company, they (and all > > us Americans) cannot make a distro available that is directly > > connected in ANY fashion to repositories containing patented > > technologies that do not have an license explicitly stating that there > > will be no repercussions for such aforementioned inclusion scenarios > > to be applied. This is why Fedora has such a bad rep (I am not saying > > it is a bad distro, I use it for everything!) with uninformed people > > (people making the choice of using Linux for the first time). Though I > > think CodecBuddy NEEDS support for reading through repositories to > > find codecs because there ARE Free codecs not in the Fedora DVD by > > default and should be able to be detected and installed. > > > Maybe web2.0 is the solution :) . What if we have a way to query a list > of repos that is stored on a central site that can be appended to by > anyone? Then we might be able to disclaim responsibility for pointing it > out. > > On 9/12/07, *Tom spot Callaway* > > wrote: > > > > > > On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > > > > > Or - why not move the entire repo to places that can have all the > > > contents? What's the point of even worrying about this issue? > > > > It's not where the repo sits, its where Red Hat is based out of. > > > > ~spot > > > > -- > > 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 limb at jcomserv.net Thu Sep 13 02:37:23 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 12 Sep 2007 21:37:23 -0500 (CDT) Subject: Announcing rpmfusion In-Reply-To: <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <46E8A6B6.5070606@ncsu.edu> <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> Message-ID: <1656.192.168.0.1.1189651043.squirrel@mail.jcomserv.net> > We might be in hot water still, but at least liability could possibly not > be > claimed if it is in the Terms of Use of this community list of > repositories... > > On 9/12/07, Casey Dahlin wrote: >> >> King InuYasha wrote: >> > Unfortunately, because Red Hat IS a USA-based company, they (and all >> > us Americans) cannot make a distro available that is directly >> > connected in ANY fashion to repositories containing patented >> > technologies that do not have an license explicitly stating that there >> > will be no repercussions for such aforementioned inclusion scenarios >> > to be applied. This is why Fedora has such a bad rep (I am not saying >> > it is a bad distro, I use it for everything!) with uninformed people >> > (people making the choice of using Linux for the first time). Though I >> > think CodecBuddy NEEDS support for reading through repositories to >> > find codecs because there ARE Free codecs not in the Fedora DVD by >> > default and should be able to be detected and installed. >> > >> Maybe web2.0 is the solution :) . What if we have a way to query a list >> of repos that is stored on a central site that can be appended to by >> anyone? Then we might be able to disclaim responsibility for pointing it >> out. Except that now it's mentioned on the list, and will be in the publicly viewable list archives, which smacks of premeditation. ;) >> > On 9/12/07, *Tom spot Callaway* > > > wrote: >> > >> > >> > On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: >> > >> > > Or - why not move the entire repo to places that can have all >> the >> > > contents? What's the point of even worrying about this issue? >> > >> > It's not where the repo sits, its where Red Hat is based out of. >> > >> > ~spot >> > >> > -- >> > 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 >> > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From tcallawa at redhat.com Thu Sep 13 03:04:28 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 12 Sep 2007 23:04:28 -0400 Subject: Announcing rpmfusion In-Reply-To: <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <46E8A6B6.5070606@ncsu.edu> <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> Message-ID: <1189652668.3767.2.camel@localhost.localdomain> On Wed, 2007-09-12 at 22:00 -0500, King InuYasha wrote: > We might be in hot water still, but at least liability could possibly > not be claimed if it is in the Terms of Use of this community list of > repositories... We're almost certainly still liable. Sorry. ~spot From chris.stone at gmail.com Thu Sep 13 03:24:18 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 12 Sep 2007 20:24:18 -0700 Subject: rawhide report: 20070912 changes In-Reply-To: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: Ralf Corsepius, the maintainer of the OpenSceneGraph packages in Fedora is being extremely difficult in helping to fix this dependency problem. I have a new osgcal ready to build and soon a new osgal package, but I need a pkgconfig file from the OpenSceneGraph maintainer Ralf Corsepius. However Ralf is being extremely difficult and refuses to add a pkgconfig file to OpenSceneGraph-devel package which I have already provided for him. His reason is that upstream did not provide one, so therefore it is wrong for him to do so. My packages are the *only* packages which BuildRequire OpenSceneGraph-devel. Not only has Ralf upgraded to OSG 2.0 without any warnings whatsoever, he also has not provided an OSG-1 compat package to help with these dependency problems. Now after we have spent hours of work getting our packages to work with OSG2, all we need is a pkgconfig file, and Ralf is refusing to cooperate. What am I suppposed to do in this situation? I am forced now to go through the long process of contacting OSG upstream to get the pkgconfig file re-added (it used to be included with OSG1). I am afraid we will not be able to accomplish this before F8, and Ralf refuses to simply add a pkgconfig file to his package. It seems Ralf cannot think on his own, and we have to go through upstream in order to get Ralf to actually do anything to the package. https://bugzilla.redhat.com/show_bug.cgi?id=247376 Can anyone please help resolve this conflict? On 9/12/07, Build System wrote: > Broken deps for i386 > ---------------------------------------------------------- > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 From mike at miketc.com Thu Sep 13 04:14:44 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 12 Sep 2007 23:14:44 -0500 Subject: Volume control problems In-Reply-To: <20070912221924.GA20538@tango.0pointer.de> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> <20070912221924.GA20538@tango.0pointer.de> Message-ID: <1189656884.4095.6.camel@scrappy.miketc.com> On Thu, 2007-09-13 at 00:19 +0200, Lennart Poettering wrote: > Try "pulseaudio -k" first to shut down the running instance. [mike at scrappy ~]$ pulseaudio -k [mike at scrappy ~]$ pulseaudio -vv I: main.c: Page size is 4096 bytes I: main.c: Fresh high-resolution timers available! Bon appetit! D: cli-command.c: Checking for existance of '/usr/lib/pulse-0.9/modules//module-hal-detect.so': success I: module-hal-detect.c: Trying capability alsa D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/computer_alsa_timer D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/computer_alsa_sequencer D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1039_7012_alsa_capture_1 D: module-hal-detect.c: Loading module-alsa-sink with arguments 'device=hw:1 sink_name=alsa_output.pci_1039_7012_alsa_playback_0' ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card E: module-alsa-sink.c: Error opening PCM device hw:1: No such device E: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:1 sink_name=alsa_output.pci_1039_7012_alsa_playback_0"): initialization failed. D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1039_7012_alsa_playback_0 D: module-hal-detect.c: Loading module-alsa-source with arguments 'device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0' ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card E: module-alsa-source.c: Error opening PCM device hw:1: No such device E: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0"): initialization failed. D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1039_7012_alsa_capture_0 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_playback_3 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_capture_3 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_playback_2 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_capture_2 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_playback_1 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_capture_1 D: module-hal-detect.c: Loading module-alsa-sink with arguments 'device=hw:0 sink_name=alsa_output.pci_1102_7_alsa_playback_0' ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card E: module-alsa-sink.c: Error opening PCM device hw:0: No such device E: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:0 sink_name=alsa_output.pci_1102_7_alsa_playback_0"): initialization failed. D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_playback_0 D: module-hal-detect.c: Loading module-alsa-source with arguments 'device=hw:0 source_name=alsa_input.pci_1102_7_alsa_capture_0' ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card E: module-alsa-source.c: Error opening PCM device hw:0: No such device E: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1102_7_alsa_capture_0"): initialization failed. D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_capture_0 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_midi_0 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1039_7012_alsa_control__1 D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_1102_7_alsa_control__1 I: module-hal-detect.c: Loaded 0 modules. I: module.c: Loaded "module-hal-detect" (index: #0; argument: ""). I: module.c: Loaded "module-esound-protocol-unix" (index: #1; argument: ""). I: protocol-native.c: loading cookie from disk. I: module.c: Loaded "module-native-protocol-unix" (index: #2; argument: ""). I: module-volume-restore.c: starting with empty ruleset. I: module.c: Loaded "module-volume-restore" (index: #3; argument: ""). I: module.c: Loaded "module-default-device-restore" (index: #4; argument: ""). I: module.c: Loaded "module-rescue-streams" (index: #5; argument: ""). I: module.c: Loaded "module-suspend-on-idle" (index: #6; argument: ""). D: cli-command.c: Checking for existance of '/usr/lib/pulse-0.9/modules//module-x11-publish.so': success D: module-x11-publish.c: using already loaded auth cookie. I: module.c: Loaded "module-x11-publish" (index: #7; argument: ""). D: cli-command.c: Checking for existance of '/usr/lib/pulse-0.9/modules//module-gconf.so': success I: module.c: Loaded "module-gconf" (index: #8; argument: ""). I: main.c: Daemon startup complete. D: module-hal-detect.c: dbus: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=NameAcquired > > [mike at scrappy ~]$ aplay -D hw:0 /dev/urandom > > ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card > > aplay: main:545: audio open error: No such device > > Apparently there is no sound card detected at all. > > Please check wheter anything is listed in /proc/asound/cards. Check if > you plugged everything in correctly. [mike at scrappy ~]$ more /proc/asound/cards 0 [CA0106 ]: CA0106 - CA0106 Audigy SE [SB0570] at 0xe300 irq 22 1 [SI7012 ]: ICH - SiS SI7012 SiS SI7012 with ALC655 at irq 23 > PulseAudio is not going to make your sound magically work if your > sound card is not recognized at all by the Linux kernel. Thanks for helping out so far. And as I stated originally (or I left it out), if I run the "Soundcard Detection" program, it finds the card as well as on board sound (SiS MB), and I can hear the sample sound it plays (speakers are pluggined into the Audigy SE card not the onboard). So I don't get why it's not being picked up otherwise. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From ngompa13 at gmail.com Thu Sep 13 04:28:04 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 12 Sep 2007 23:28:04 -0500 Subject: Announcing rpmfusion In-Reply-To: <1189652668.3767.2.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <46E8A6B6.5070606@ncsu.edu> <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> <1189652668.3767.2.camel@localhost.localdomain> Message-ID: <8278b1b0709122128g69f6e070ib7037085f95bb918@mail.gmail.com> You know what!!?!?!? Software Patents suck... So do algorithm patents on ubiquitous things, like mp3.... and stupid licensing like for DVD, etc. Now that it is out of my system.... Then how do you propose to be able to point to them without stabbing yourselves? It would be nice if some of the this problem could be fixed, and CodecBuddy doesn't count.... If Fedora had something like Ubuntu's codec searcher, then I would be happy. But we don't have that, and that is probably the only thing that Ubuntu has that I want in Fedora.... On 9/12/07, Tom spot Callaway wrote: > > > On Wed, 2007-09-12 at 22:00 -0500, King InuYasha wrote: > > We might be in hot water still, but at least liability could possibly > > not be claimed if it is in the Terms of Use of this community list of > > repositories... > > We're almost certainly still liable. Sorry. > > ~spot > > -- > 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 smooge at gmail.com Thu Sep 13 04:36:23 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Sep 2007 22:36:23 -0600 Subject: Announcing rpmfusion In-Reply-To: <8278b1b0709122128g69f6e070ib7037085f95bb918@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <46E8A6B6.5070606@ncsu.edu> <8278b1b0709122000v2beb11f2he74723c8249275f6@mail.gmail.com> <1189652668.3767.2.camel@localhost.localdomain> <8278b1b0709122128g69f6e070ib7037085f95bb918@mail.gmail.com> Message-ID: <80d7e4090709122136r77775433q62c87100b2e96c51@mail.gmail.com> On 9/12/07, King InuYasha wrote: > > You know what!!?!?!? > > Software Patents suck... So do algorithm patents on ubiquitous things, like > mp3.... and stupid licensing like for DVD, etc. > > > Now that it is out of my system.... Then how do you propose to be able to > point to them without stabbing yourselves? It would be nice if some of the > this problem could be fixed, and CodecBuddy doesn't count.... If Fedora had > something like Ubuntu's codec searcher, then I would be happy. But we don't > have that, and that is probably the only thing that Ubuntu has that I want > in Fedora.... > Other than moving the entire personell and company to outside of the US.. and not doing business in the US.. not sure. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jdieter at gmail.com Thu Sep 13 05:08:52 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 13 Sep 2007 08:08:52 +0300 Subject: Volume control problems In-Reply-To: <1189656884.4095.6.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> <20070912221924.GA20538@tango.0pointer.de> <1189656884.4095.6.camel@scrappy.miketc.com> Message-ID: <1189660132.21101.2.camel@jndwidescreen.lesbg.loc> On Wed, 2007-09-12 at 23:14 -0500, Mike Chambers wrote: > ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card > E: module-alsa-sink.c: Error opening PCM device hw:1: No such device > E: module.c: Failed to load module "module-alsa-sink" (argument: > "device=hw:1 sink_name=alsa_output.pci_1039_7012_alsa_playback_0"): > initialization failed. > D: module-hal-detect.c: Not loaded > device /org/freedesktop/Hal/devices/pci_1039_7012_alsa_playback_0 > D: module-hal-detect.c: Loading module-alsa-source with arguments > 'device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0' > ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card > E: module-alsa-source.c: Error opening PCM device hw:1: No such device > E: module.c: Failed to load module "module-alsa-source" (argument: > "device=hw:1 source_name=alsa_input.pci_1039_7012_alsa_capture_0"): > initialization failed. I ran into this error message setting up pulseaudio on an F7 system when I was trying to run the pulseaudio daemon system-wide. In my case, it was because /dev/snd/* wasn't readable by the daemon (which runs under the user "pulse" when running in system-wide mode). Not sure if this might be your problem. 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 kevin.kofler at chello.at Thu Sep 13 05:40:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 05:40:35 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: Christopher Stone gmail.com> writes: > Ralf Corsepius, the maintainer of the OpenSceneGraph packages in > Fedora is being extremely difficult in helping to fix this dependency > problem. Oh no, not again! I am starting to get really fed up with Ralf's continuous lack of cooperation (also when it comes to stuff like properly following procedures). :-( Even though I'm not personally interested in these packages, I added a comment (actually 2 because I forgot something in the first one) to the bug report. For the record, I completely agree with you, adding the .pc file is the right thing to do here. Kevin Kofler From chris.stone at gmail.com Thu Sep 13 05:44:28 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 12 Sep 2007 22:44:28 -0700 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: On 9/12/07, Christopher Stone wrote: > Ralf Corsepius, the maintainer of the OpenSceneGraph packages in > Fedora is being extremely difficult in helping to fix this dependency > problem. > > I have a new osgcal ready to build and soon a new osgal package, but I > need a pkgconfig file from the OpenSceneGraph maintainer Ralf > Corsepius. > > However Ralf is being extremely difficult and refuses to add a > pkgconfig file to OpenSceneGraph-devel package which I have already > provided for him. > > His reason is that upstream did not provide one, so therefore it is > wrong for him to do so. My packages are the *only* packages which > BuildRequire OpenSceneGraph-devel. > > Not only has Ralf upgraded to OSG 2.0 without any warnings whatsoever, > he also has not provided an OSG-1 compat package to help with these > dependency problems. Now after we have spent hours of work getting > our packages to work with OSG2, all we need is a pkgconfig file, and > Ralf is refusing to cooperate. > > What am I suppposed to do in this situation? I am forced now to go > through the long process of contacting OSG upstream to get the > pkgconfig file re-added (it used to be included with OSG1). I am > afraid we will not be able to accomplish this before F8, and Ralf > refuses to simply add a pkgconfig file to his package. > > It seems Ralf cannot think on his own, and we have to go through > upstream in order to get Ralf to actually do anything to the package. > > https://bugzilla.redhat.com/show_bug.cgi?id=247376 > > Can anyone please help resolve this conflict? I would also like to point out that while we have jumped through hoops in order to get our applications running with OSG2, Ralf has responded by calling our applications "crap" [1] and "Trashy" [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=247376#c23 [2] https://bugzilla.redhat.com/show_bug.cgi?id=247376#c25 The upstream maintainers of osgcal and osgal have gone out of their way and taken time out of their busy schedule to accommodate Fedora's early adoption of OSG 2.0. It is a shame that their efforts have been greeted by such hostility from Fedora's OSG packager. I have decided to just use a hack and redefine my PKGCONFIG_PATH to . within my spec file and use my own OSG pkgconfig file, and keep Ralf completely out of the picture. From ville.skytta at iki.fi Thu Sep 13 06:16:11 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 13 Sep 2007 09:16:11 +0300 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: <200709130916.11375.ville.skytta@iki.fi> On Thursday 13 September 2007, Christopher Stone wrote: > Not only has Ralf upgraded to OSG 2.0 without any warnings whatsoever, I don't really want to get involved in this flamefest, but just to point out that that's not quite fair, see the thread named "OpenSceneGraph" at http://www.redhat.com/archives/fedora-devel-list/2007-June/thread.html and http://www.redhat.com/archives/fedora-devel-list/2007-July/thread.html From dwmw2 at infradead.org Thu Sep 13 06:17:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 08:17:23 +0200 Subject: Bugzilla account. In-Reply-To: <1189653854.4067.0.camel@localhost.localdomain> References: <1189612606.3570.50.camel@shinybook.infradead.org> <1189653854.4067.0.camel@localhost.localdomain> Message-ID: <1189664243.3570.100.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 13:24 +1000, Noura Elhawary wrote: > I see that your email account is not disabled, so has this issue been > resolved for you? My bugzilla account has now been re-enabled, yes. Thank you to whoever did that so promptly. -- dwmw2 From nicolas.mailhot at laposte.net Thu Sep 13 06:39:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Sep 2007 08:39:30 +0200 Subject: Announcing rpmfusion In-Reply-To: <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> Message-ID: <1189665570.9380.3.camel@rousalka.dyndns.org> Le mercredi 12 septembre 2007 ? 19:15 -0500, King InuYasha a ?crit : > Unfortunately, because Red Hat IS a USA-based company, they (and all > us Americans) cannot make a distro available that is directly > connected in ANY fashion to repositories containing patented > technologies that do not have an license explicitly stating that there > will be no repercussions for such aforementioned inclusion scenarios > to be applied. I'd have an evil plan. That would be to register rpmfusion.us and rpmfusion.eu (or rpmfusion.org), have all fedora docs point to rpmfusion.us, and do whatever is possible outside of USA in the other one. I wonder if that'd satisfy lawyers. -- 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 kevin.kofler at chello.at Thu Sep 13 06:46:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 06:46:07 +0000 (UTC) Subject: Announcing rpmfusion References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <1189665570.9380.3.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > I'd have an evil plan. That would be to register rpmfusion.us and > rpmfusion.eu (or rpmfusion.org), have all fedora docs point to > rpmfusion.us, and do whatever is possible outside of USA in the other > one. Unfortunately, I think many users wouldn't find the real rpmfusion that way. Kevin Kofler From sundaram at fedoraproject.org Thu Sep 13 07:50:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 13:20:11 +0530 Subject: Announcing rpmfusion In-Reply-To: <1189620049.7051.38.camel@localhost6.localdomain6> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> Message-ID: <46E8EBB3.4090701@fedoraproject.org> Richi Plana wrote: > On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote: >> I am not talking about any repo files. Just a pointer in documentation >> or in any application. The details are explained in FAB list. That >> requires Legal to look into this. No amount of layman arguments can help >> us make a decision and legal perspectives doesn't always make logical >> sense which many tend to assume. > > In other words, Fedora's lawyers have deemed it risky (or even downright > illegal) to include in the distro .repo files that would allow users to > download, say, US-illegal codecs even if the repository itself > physically and logistically isn't connected to Fedora. But pointers in > documents can. > > There we go. That's what the legal experts are saying. Do I have it > about right? We do not know yet if pointers to a repository are ok since the legal situation has changed. http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717 Last time we consulted with legal, it was ok to point a website as long as it didn't host directly such a software repository and we didn't include information on what to find in such websites (ie) pointing to a website like fedorafaq.org is ok as long as we don't tell them "go here for mp3 codecs". Rahul From rc040203 at freenet.de Thu Sep 13 08:14:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 10:14:58 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: <1189671298.3157.324.camel@mccallum.corsepiu.local> On Wed, 2007-09-12 at 20:24 -0700, Christopher Stone wrote: > Ralf Corsepius, the maintainer of the OpenSceneGraph packages in > Fedora is being extremely difficult in helping to fix this dependency > problem. > > I have a new osgcal ready to build and soon a new osgal package, but I > need a pkgconfig file from the OpenSceneGraph maintainer Ralf > Corsepius. > > However Ralf is being extremely difficult and refuses to add a > pkgconfig file to OpenSceneGraph-devel package which I have already > provided for him. If you had a look into the OpenSceneGraph package's sources (which you apparently didn't) you'd know that Fedora's OSG packages carries around a different implementation of pkgconfig files commented out. If I'd activate this, it would not help you much. You are wanting me to adopt Debian's proprietary and isolated solution. > His reason is that upstream did not provide one, so therefore it is > wrong for him to do so. Wrong, I do not add them, because upstream decided to abandon them. > Not only has Ralf upgraded to OSG 2.0 without any warnings whatsoever, This is not correct. 1. I explicitly asked and warned in advance, but you did not answer. 2. I explicitly asked if somebody wanted backward compatible packages, but you did not answer. > he also has not provided an OSG-1 compat package to help with these > dependency problems. I had offered to implement them, but you did not answer. Now, we am going the upstream path. > Now after we have spent hours of work getting > our packages to work with OSG2, all we need is a pkgconfig file, and > Ralf is refusing to cooperate. Not true. Your packages require the pkgconfig files, because these package's configure scripts carry bugs which prevent them from working without them. They expect OSG-1.2 compatibility and/or a Debian patched OSG-2. > What am I suppposed to do in this situation? Fix your packages, such they work without pkgconfig. I had offered you to help you, but you did not answer. Ralf From nicolas.mailhot at laposte.net Thu Sep 13 08:17:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Sep 2007 10:17:03 +0200 (CEST) Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <1189665570.9380.3.camel@rousalka.dyndns.org> Message-ID: <45669.192.54.193.51.1189671423.squirrel@rousalka.dyndns.org> Le Jeu 13 septembre 2007 08:46, Kevin Kofler a ?crit : > Nicolas Mailhot laposte.net> writes: >> I'd have an evil plan. That would be to register rpmfusion.us and >> rpmfusion.eu (or rpmfusion.org), have all fedora docs point to >> rpmfusion.us, and do whatever is possible outside of USA in the >> other >> one. > > Unfortunately, I think many users wouldn't find the real rpmfusion > that way. But then one could have documentation and word-of-mouth documenting one just has to replace .us with .org/.eu in the fedora-approved repo files for stuff to just work. Not to mention the power of google in that case - I doubt it would rank the .eu site higher than the other one. -- Nicolas Mailhot From rc040203 at freenet.de Thu Sep 13 08:52:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 10:52:29 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: <1189673549.3157.337.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 05:40 +0000, Kevin Kofler wrote: > Christopher Stone gmail.com> writes: > > Ralf Corsepius, the maintainer of the OpenSceneGraph packages in > > Fedora is being extremely difficult in helping to fix this dependency > > problem. > > Oh no, not again! > > I am starting to get really fed up with Ralf's continuous lack of cooperation > (also when it comes to stuff like properly following procedures). :-( What are you referring to? Where am I not cooperating? The things I am actively boycotting are - acls, because they prevent cooperation - EPEL, because I consider it harmful to Fedora. - the fedora sponsorship model, because it has regressed into a bad joke. > Even though I'm not personally interested in these packages, I added a comment > (actually 2 because I forgot something in the first one) to the bug report. For > the record, I completely agree with you, adding the .pc file is the right thing > to do here. Once again: 1. Upstream has abandoned the *.pc's. => They decided to change their programmmer's infrastructure. 2. The patch Chris wants me to add is Debian's *.pc's. => They are a vendor specific and proprietary approach => They are designed in a way, they prevent parallel installation of a potential OSG1 and OSG2 package. 3. At the very moment I activate the *.pc's I carry around for months, will not help Chris. They are designed to support parallel installation of OSG1 and OSG2 (openscenegraph-2.pc) To me, Chris simply has not understood that OSG2 is completely incompatible to OSG1. Having abandoned the *.pc's, and now being confronted with competing implementations of *.pc are symptoms of this. Also he doesn't want to understand that the packages he is maintaining carry bugs which prevent them from being used without pkgconfig files. Ralf From kevin.kofler at chello.at Thu Sep 13 08:56:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 08:56:35 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189671298.3157.324.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > > However Ralf is being extremely difficult and refuses to add a > > pkgconfig file to OpenSceneGraph-devel package which I have already > > provided for him. > If you had a look into the OpenSceneGraph package's sources (which you > apparently didn't) you'd know that Fedora's OSG packages carries around > a different implementation of pkgconfig files commented out. If I'd > activate this, it would not help you much. > > You are wanting me to adopt Debian's proprietary and isolated solution. The "proprietary and isolated solution" would be implementing the pkgconfig files differently from (and incompatibly with) Debian like you're suggesting. As I said at https://bugzilla.redhat.com/show_bug.cgi?id=247376#c27 : | Ralf, if another package requires that pkgconfig file, I don't see what's | wrong with adding it, especially given that the file has been provided | already! There are other packages with Fedora-added .pc files too. Please try | thinking in the overall interest of Fedora instead of defending principles | all the time. | | Additionally, compatibility with Debian is also an important reason to add | the .pc file. Even if you don't like what Debian is doing, being gratuitously | incompatible with them helps no one. Ralf Corsepius freenet.de> writes: > > His reason is that upstream did not provide one, so therefore it is > > wrong for him to do so. > Wrong, I do not add them, because upstream decided to abandon them. I don't think that's enough of a reason if packages still require it and at least one other distribution still provides it. In fact, _you_ as the Fedora maintainer should be asking upstream to reinclude it, and in the meantime provide it yourself (that's what Source1 is for). > > Not only has Ralf upgraded to OSG 2.0 without any warnings whatsoever, > This is not correct. > 1. I explicitly asked and warned in advance, but you did not answer. > 2. I explicitly asked if somebody wanted backward compatible packages, > but you did not answer. > > > he also has not provided an OSG-1 compat package to help with these > > dependency problems. > I had offered to implement them, but you did not answer. Now, we am > going the upstream path. He probably missed that thread, this is unfortunate, but that isn't really related to the issue at hand. > > What am I suppposed to do in this situation? > Fix your packages, such they work without pkgconfig. In fact, that's essentially what he has done now, but the "fix" is an ugly workaround which would be easy to avoid by just shipping that .pc file. Kevin Kofler From rc040203 at freenet.de Thu Sep 13 09:08:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 11:08:01 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189671298.3157.324.camel@mccallum.corsepiu.local> Message-ID: <1189674481.3157.348.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 08:56 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > > However Ralf is being extremely difficult and refuses to add a > > > pkgconfig file to OpenSceneGraph-devel package which I have already > > > provided for him. > > If you had a look into the OpenSceneGraph package's sources (which you > > apparently didn't) you'd know that Fedora's OSG packages carries around > > a different implementation of pkgconfig files commented out. If I'd > > activate this, it would not help you much. > > > > You are wanting me to adopt Debian's proprietary and isolated solution. > > The "proprietary and isolated solution" would be implementing the pkgconfig > files differently from (and incompatibly with) Debian like you're suggesting. Right, we would be inventing our own proprietary and isolated solution. ATM, I prefer not doing so. > As I said at https://bugzilla.redhat.com/show_bug.cgi?id=247376#c27 : > | Ralf, if another package requires that pkgconfig file, I don't see what's > | wrong with adding it, especially given that the file has been provided > | already! There are other packages with Fedora-added .pc files too. Please try > | thinking in the overall interest of Fedora instead of defending principles > | all the time. > | > | Additionally, compatibility with Debian is also an important reason to add > | the .pc file. Even if you don't like what Debian is doing, being gratuitously > | incompatible with them helps no one. > > Ralf Corsepius freenet.de> writes: > > > His reason is that upstream did not provide one, so therefore it is > > > wrong for him to do so. > > Wrong, I do not add them, because upstream decided to abandon them. > > I don't think that's enough of a reason if packages still require it These package require them, because their configure scripts are bugged. > and at > least one other distribution still provides it. In fact, _you_ as the Fedora > maintainer should be asking upstream to reinclude it, and in the meantime > provide it yourself (that's what Source1 is for). I, the Fedora maintainer, have decided to respect upstream's decisions. People can't expect a package to stay backward compatible for ever. Esp. not when it comes to complex packages such a OSG. This thing is a fat monster with many questionable and discuss-worthy design decisions lurking inside. > > > he also has not provided an OSG-1 compat package to help with these > > > dependency problems. > > I had offered to implement them, but you did not answer. Now, we am > > going the upstream path. > > He probably missed that thread, this is unfortunate, but that isn't really > related to the issue at hand. Well, now the train has left the station, ... we are heading the "rough ride" upstream wants us to go. > > > What am I suppposed to do in this situation? > > Fix your packages, such they work without pkgconfig. > > In fact, that's essentially what he has done now, but the "fix" is an ugly > workaround which would be easy to avoid by just shipping that .pc file. Where did he do so? I had asked him for his sources, but ... I am still waiting for an answer. Ralf From kevin.kofler at chello.at Thu Sep 13 09:06:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 09:06:56 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > What are you referring to? Where am I not cooperating? You keep complaining loudly about freezes and Bodhi, and blaming the upgrade path reports in cases where you should have sent the appropriate freeze tagging requests to rel-eng or the appropriate update requests through Bodhi. Then there was also the cross-compiler guidelines thread where you complained about your packages not getting reviewed when actually they were stuck waiting for a set of guidelines you were supposed to be responsible for (because you were the one listed as the contact and also the one who took responsibility for it in FPC meetings as far as I know). > => They are designed in a way, they prevent parallel installation of a > potential OSG1 and OSG2 package. This is a valid technical reason, the ones you gave before aren't. > 3. At the very moment I activate the *.pc's I carry around for months, > will not help Chris. They are designed to support parallel installation > of OSG1 and OSG2 (openscenegraph-2.pc) I see, but it would be easy to patch his packages to support that (he'd just have to replace openscenegraph with openscenegraph-2 in one place). That said, if we aren't even shipping a compat package, I wonder if it's worth being incompatible with Debian for. Have you talked to the Debian maintainer about this issue? Kevin Kofler From agostino.russo at gmail.com Thu Sep 13 09:09:34 2007 From: agostino.russo at gmail.com (Ago) Date: Thu, 13 Sep 2007 09:09:34 +0000 (UTC) Subject: Windows based installation of Fedora Linux? References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> Message-ID: Douglas McClendon filteredperception.org> writes: > This is I think what I've been noticing as well in a similar situation. > The one time I tried to recover, fsck _completely_ horked the ext3 fs. I am no fs expert, but my understanding is: nested filesystem => forget about the journal in the nested fs I may be wrong, but I'd guess that VMs suffer the same problem, and the hosted fs journal can also get corrupted in case of a hard reboot of the hosting system. In short I would expect Wubi I/O behavior/performance to be on par or better than a VM, under all scenarios. BUT in a VM under windows you would use windows fs driver for the hosting system, while we use ntfs-3g/vfat. So the above statement assumes that ntfs-3g/vfat behaviour/perfomance is equivalent to the windows counterpart. > This was also my first thought. The down side, is that in my usage > scenario, the fs would be typically on a usb-flash-stick, and it seems > like an undesirable thing to be writing to it as often as possible, > rather than periodically. You can always tweak the scripts affecting sysctl > Question- are these sysctl settings controlling the writes from the > hosted-fs-?host-fs, or from the host-fs-?disk, or both? Should be both since that affects the kernel. > This sounds like it could be fixed with smarter ordering. Do you > foresee that, or is it for some reason a more-or-less unfixable problem? Yes Ubuntu kernel hackers have been looking into this, there was just no time to do it for the 7.10 release, it will probably be fixed for the next release. But that is beyond my skills. Regards, Ago From kevin.kofler at chello.at Thu Sep 13 09:11:47 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 09:11:47 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189671298.3157.324.camel@mccallum.corsepiu.local> <1189674481.3157.348.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > I, the Fedora maintainer, have decided to respect upstream's decisions. > People can't expect a package to stay backward compatible for ever. pkgconfig files have other benefits than just backwards-compatibility with older versions which used them. > > In fact, that's essentially what he has done now, but the "fix" is an ugly > > workaround which would be easy to avoid by just shipping that .pc file. > Where did he do so? I had asked him for his sources, but ... I am still > waiting for an answer. He mentioned it right here in this thread: https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01001.html Quoting him: | I have decided to just use a hack and redefine my PKGCONFIG_PATH to . | within my spec file and use my own OSG pkgconfig file, and keep Ralf | completely out of the picture. Kevin Kofler From rc040203 at freenet.de Thu Sep 13 09:26:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 11:26:06 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> Message-ID: <1189675566.3157.365.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 09:06 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > What are you referring to? Where am I not cooperating? > > You keep complaining loudly about freezes and Bodhi, and blaming the upgrade > path reports in cases where you should have sent the appropriate freeze tagging > requests to rel-eng or the appropriate update requests through Bodhi. Complaining about lack of usability of the infrastructure is "non-cooperation"? Shall video tape the cases, I am encountering almost every day? Not agreeing with management decisions is "non-cooperation"? Yes, I feel the current release procedures are a mal-designed, overengineered and yes, I feel fedora's management hardly could do worse. > Then there was also the cross-compiler guidelines thread where you complained > about your packages not getting reviewed when actually they were stuck waiting > for a set of guidelines you were supposed to be responsible for (because you > were the one listed as the contact and also the one who took responsibility for > it in FPC meetings as far as I know). :) yawn. Do you know that you are reheating "yesterday's gossip"? Meanwhile, the embedded SIG has implemented facts. > > => They are designed in a way, they prevent parallel installation of > a > > potential OSG1 and OSG2 package. > > This is a valid technical reason, the ones you gave before aren't. Yes, I didn't mention them, because I respected to upstream's decision not to ship *.pc's. > > 3. At the very moment I activate the *.pc's I carry around for months, > > will not help Chris. They are designed to support parallel installation > > of OSG1 and OSG2 (openscenegraph-2.pc) > > I see, but it would be easy to patch his packages to support that (he'd just > have to replace openscenegraph with openscenegraph-2 in one place). He'd have to patch the configure scripts. The effort to get these configure scripts to work without pkgconfig files would only be marginally different. It's simply that osgal's and osgcal's configure scripts mis-apply pkgconfig and do not acknowledge things similar to this: configure OPENTHREADS_CFLAGS=' ' OPENTHREAD_LIBS='-lOpenThreads' openalpp's configure does acknowledge this and can be compiled against OSG-2 this way. Ralf From rc040203 at freenet.de Thu Sep 13 09:31:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 11:31:59 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189671298.3157.324.camel@mccallum.corsepiu.local> <1189674481.3157.348.camel@mccallum.corsepiu.local> Message-ID: <1189675919.3157.367.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 09:11 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > > In fact, that's essentially what he has done now, but the "fix" is an ugly > > > workaround which would be easy to avoid by just shipping that .pc file. > > Where did he do so? I had asked him for his sources, but ... I am still > > waiting for an answer. > > He mentioned it right here in this thread: > https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01001.html > > Quoting him: > | I have decided to just use a hack and redefine my PKGCONFIG_PATH to . > | within my spec file and use my own OSG pkgconfig file, and keep Ralf > | completely out of the picture. Where inside of this is a link to his sources? Ralf From kevin.kofler at chello.at Thu Sep 13 09:43:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 09:43:07 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > :) yawn. Do you know that you are reheating "yesterday's gossip"? > Meanwhile, the embedded SIG has implemented facts. Yes, by either ignoring your non-existent guidelines or just treating the current unfinished draft as authoritative. IMHO that's not something to be proud of. > It's simply that osgal's and osgcal's configure scripts mis-apply > pkgconfig and do not acknowledge things similar to this: > configure OPENTHREADS_CFLAGS=' ' OPENTHREAD_LIBS='-lOpenThreads' How is this better than ./configure working out of the box (as it would with a proper pkgconfig setup)? Now if -lOpenThreads is really _all_ that's needed and on all platforms supported by upstream, then not using a configure check at all might work (still, it doesn't allow checking that the library is there and of the proper version, which pkgconfig allows), but requiring CFLAGS and LIBS to be passed to configure by hand is hardly a workable solution. Kevin Kofler From rc040203 at freenet.de Thu Sep 13 10:04:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 12:04:13 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> Message-ID: <1189677853.3157.382.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 09:43 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > :) yawn. Do you know that you are reheating "yesterday's gossip"? > > Meanwhile, the embedded SIG has implemented facts. > > Yes, by either ignoring your non-existent guidelines or just treating the > current unfinished draft as authoritative. Right. > IMHO that's not something to be proud of. Right - We (The Embedded Sig) had decided to let the facts speak and not to contact the FPC. I agreed to this approach, because it implemented viable precedences and avoided lengthy and fruitless discussions, as I had been confronted with before in FPC. > > It's simply that osgal's and osgcal's configure scripts mis-apply > > pkgconfig and do not acknowledge things similar to this: > > configure OPENTHREADS_CFLAGS=' ' OPENTHREAD_LIBS='-lOpenThreads' > > How is this better than ./configure working out of the box * It works without vendor-specific pkg-config files. > (as it would with a > proper pkgconfig setup)? * Which pkgconfig files? Debian? > Now if -lOpenThreads is really _all_ that's needed and on all platforms > supported by upstream, In case of openalpp it's only -lOpenThreads. I can't comment on the situation of osgal and osgcal, because I haven't seen Chris sources, yet. IIRC, at least one of these packages currently to be found in CVS, still uses Producer and relies on OSG1's API. > then not using a configure check at all might work > (still, it doesn't allow checking that the library is there and of the proper > version, which pkgconfig allows), but requiring CFLAGS and LIBS to be passed to > configure by hand is hardly a workable solution. Pardon? - It's how things are supposed to work with pkg-config: From /usr/share/aclocal/pkg.m4: ... AC_DEFUN([PKG_CHECK_MODULES], [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl - It's how things are supposed to work with autoconf in general: configure CFLAGS=... Ralf From ngompa13 at gmail.com Thu Sep 13 11:40:02 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Thu, 13 Sep 2007 06:40:02 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> Message-ID: <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> Perhaps then, if someone with the skill to work on the Linux side of the stuff can figure out how to solve some of the issues, the patches could be sent into the upstream for affected components, and I do have some knowledge of NSIS, but Wubi code is somewhat difficult for me to sift through.... So how does the latest version of the installer work exactly? I am somewhat confused now.... On 9/13/07, Ago wrote: > > Douglas McClendon filteredperception.org> writes: > > > This is I think what I've been noticing as well in a similar situation. > > The one time I tried to recover, fsck _completely_ horked the ext3 fs. > > I am no fs expert, but my understanding is: > > nested filesystem => forget about the journal in the nested fs > > I may be wrong, but I'd guess that VMs suffer the same problem, and the > hosted > fs journal can also get corrupted in case of a hard reboot of the hosting > system. > > In short I would expect Wubi I/O behavior/performance to be on par or > better > than a VM, under all scenarios. BUT in a VM under windows you would use > windows > fs driver for the hosting system, while we use ntfs-3g/vfat. So the above > statement assumes that ntfs-3g/vfat behaviour/perfomance is equivalent to > the > windows counterpart. > > > This was also my first thought. The down side, is that in my usage > > scenario, the fs would be typically on a usb-flash-stick, and it seems > > like an undesirable thing to be writing to it as often as possible, > > rather than periodically. > > You can always tweak the scripts affecting sysctl > > > Question- are these sysctl settings controlling the writes from the > > hosted-fs-?host-fs, or from the host-fs-?disk, or both? > > Should be both since that affects the kernel. > > > This sounds like it could be fixed with smarter ordering. Do you > > foresee that, or is it for some reason a more-or-less unfixable problem? > > Yes Ubuntu kernel hackers have been looking into this, there was just no > time > to do it for the 7.10 release, it will probably be fixed for the next > release. > But that is beyond my skills. > > Regards, > > Ago > > > -- > 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 Thu Sep 13 11:58:52 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 13 Sep 2007 06:58:52 -0500 Subject: Volume control problems In-Reply-To: <1189660132.21101.2.camel@jndwidescreen.lesbg.loc> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> <20070912221924.GA20538@tango.0pointer.de> <1189656884.4095.6.camel@scrappy.miketc.com> <1189660132.21101.2.camel@jndwidescreen.lesbg.loc> Message-ID: <1189684732.2635.2.camel@scrappy.miketc.com> On Thu, 2007-09-13 at 08:08 +0300, Jonathan Dieter wrote: > I ran into this error message setting up pulseaudio on an F7 system when > I was trying to run the pulseaudio daemon system-wide. In my case, it > was because /dev/snd/* wasn't readable by the daemon (which runs under > the user "pulse" when running in system-wide mode). Not sure if this > might be your problem. root is owner/group of that path, so not sure what pulse is running under or if that is the problem. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From dmc.fedora at filteredperception.org Thu Sep 13 12:01:09 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 07:01:09 -0500 Subject: Windows based installation of Fedora Linux? In-Reply-To: <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> Message-ID: <46E92685.1020002@filteredperception.org> King InuYasha wrote: > Perhaps then, if someone with the skill to work on the Linux side of the > stuff can figure out how to solve some of the issues, the patches could be > sent into the upstream for affected components, and I do have some knowledge > of NSIS, but Wubi code is somewhat difficult for me to sift through.... So > how does the latest version of the installer work exactly? I am somewhat > confused now.... First, you can pretty much ignore the message you replied to. Those were rather esoteric issues that would not get in the way of porting wubi. But the installers for ubuntu and fedora are quite different. Nothing that would preclude the porting, but certainly a fair amount of work. One thing mentioned was installing to loop files. I believe this was a feature fedora/rh had a long time ago (to vfat). Probably this would be the place to start, as this itself is probably a fair amount of work, but one which even by itself adds functionality. I'm not exactly sure how wubi works. One way it might work would be to copy the iso of the install cd/dvd to ntfs, then setup a very custom initramfs. Then setup a bootloader (native windows bootloader, or grub that talks ntfs?) to boot the install-cd-iso-on-ntfs with the custom initramfs. The custom initramfs would handle the cd-iso-on-ntfs issue, then with an append string, or something more complicated, cause the resulting boot to launch a kickstart installation, that using the above install-to-loop file support, installs to a file on the ntfs. That would probably(?) be the method that mirrors what wubi is doing with ubuntu. (or rather than the full livecd installer, just a minimal network installer bootiso) Though given the differences between ubuntu livecd installer, and fedora livecd installer (slow flexible file based copy from squashfs versus fast less-flexible block based copy from squashed ext3 image), there may be other ways (still using the wubi win32 front end) to install. I sortof alluded to them in a recent thread prior to this one. I.e. how my mods to anaconda to support rebootless installation from livecd, could be used for a win32 installer. Maybe someone else will volunteer a better outline for you. My point is that it is a rather large can of worms. Some of the stuff I am going to be working on in the coming weeks/months, may make the problem easier. But independent of that, I'd still recommend that the starting point being (re)adding support to install-to-loop files (on ntfs) to anaconda. Get that done, and in addition to it just being plain cool, you will be more or less half-way done. -dmc > On 9/13/07, Ago wrote: >> Douglas McClendon filteredperception.org> writes: >> >>> This is I think what I've been noticing as well in a similar situation. >>> The one time I tried to recover, fsck _completely_ horked the ext3 fs. >> I am no fs expert, but my understanding is: >> >> nested filesystem => forget about the journal in the nested fs >> >> I may be wrong, but I'd guess that VMs suffer the same problem, and the >> hosted >> fs journal can also get corrupted in case of a hard reboot of the hosting >> system. >> >> In short I would expect Wubi I/O behavior/performance to be on par or >> better >> than a VM, under all scenarios. BUT in a VM under windows you would use >> windows >> fs driver for the hosting system, while we use ntfs-3g/vfat. So the above >> statement assumes that ntfs-3g/vfat behaviour/perfomance is equivalent to >> the >> windows counterpart. >> >>> This was also my first thought. The down side, is that in my usage >>> scenario, the fs would be typically on a usb-flash-stick, and it seems >>> like an undesirable thing to be writing to it as often as possible, >>> rather than periodically. >> You can always tweak the scripts affecting sysctl >> >>> Question- are these sysctl settings controlling the writes from the >>> hosted-fs-?host-fs, or from the host-fs-?disk, or both? >> Should be both since that affects the kernel. >> >>> This sounds like it could be fixed with smarter ordering. Do you >>> foresee that, or is it for some reason a more-or-less unfixable problem? >> Yes Ubuntu kernel hackers have been looking into this, there was just no >> time >> to do it for the 7.10 release, it will probably be fixed for the next >> release. >> But that is beyond my skills. >> >> Regards, >> >> Ago >> >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> From sundaram at fedoraproject.org Thu Sep 13 12:05:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 17:35:47 +0530 Subject: old_passwords=1 in /etc/my.cnf In-Reply-To: <20070905050124.3a83b47a@reaver.lamontpeterson.net> References: <20070905050124.3a83b47a@reaver.lamontpeterson.net> Message-ID: <46E9279B.7000202@fedoraproject.org> Lamont Peterson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm wondering just how many packages still in Fedora need MySQL 5.0.x > to continue to support some things (and not others?) for MySQL 3.x > clients. Are there any that have to use the old_passwords format, for > example. > > If not, could we please have MySQL 5.x packages ship an /etc/my.cnf > file with "old_passwords=0"? You probably should file a bug report. Rahul From agostino.russo at gmail.com Thu Sep 13 13:56:34 2007 From: agostino.russo at gmail.com (Ago) Date: Thu, 13 Sep 2007 13:56:34 +0000 (UTC) Subject: Windows based installation of Fedora Linux? References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> <46E92685.1020002@filteredperception.org> Message-ID: Douglas McClendon filteredperception.org> writes: > First, you can pretty much ignore the message you replied to. Those > were rather esoteric issues that would not get in the way of porting wubi. Yeah, to summarize the hardreboot issues in one sentence: there is not much that we can do! If anything, ntfs-3g might be improved, but ntfs-3g author does not think there is anything to be done there either (other than fschk...). > But the installers for ubuntu and fedora are quite different. Nothing > that would preclude the porting, but certainly a fair amount of work. I would encourage to split the backend work from the windows frontend. The frontend has to do +/- the same stuff whatever distro you use, so cooperation should be more straightforward. I'd be pleased if the wubi frontend code had to be used by other distros (feel free to rebrand as you like). Some common tasks include: * Detect all windows settings that may be useful during installation * Show user interface for the few settings left * Detect a physical CD and if found copy it to the HD * If no appropriate physical CD is found, look for an ISO on the HD * Run the checksum * Download the ISO if one is not found or checksum is wrong * Install grub4dos * Extract initrd/kernel from the ISO and copy it to the HD * Write preseed/kickseed/younameit * Add an entry to the windows bootloader * Create the uninstaller The only distro-specific piece is the one that writes the preseed/kickseed. It should not be too difficulto to make it easy to "swap". The ISOs information is embedded in a single text file, so adding/changing ISOs is fairly straightforward. Rebranding involves replacing a few bitmap files and editing version.nsh. As mentioned, if anyone is interested in helping with the frontend code and make it distro-neutral, I'd be highly receptive... If instead of nsis you'd rather use some cross platform framework (within resaonable size constraints) I'd be also quite keen to jump ship. The backend though is distro-specific, you can have a look at the work involved in Ubuntu, and implement something similar within Fedora. I provided the links to the relevant Ubuntu files, it might save you some time and at the very least should give you a better understanding of the work involved. > I'm not exactly sure how wubi works. One way it might work would be to > copy the iso of the install cd/dvd to ntfs, then setup a very custom > initramfs. Then setup a bootloader (native windows bootloader, or grub > that talks ntfs?) to boot the install-cd-iso-on-ntfs with the custom > initramfs. The custom initramfs would handle the cd-iso-on-ntfs issue, > then with an append string, or something more complicated, cause the > resulting boot to launch a kickstart installation, that using the above > install-to-loop file support, installs to a file on the ntfs. Something like that, see above. Note that we do not use anymore a custom initrd, instead the kernel/initrd is extracted from the ISO and saved to disk. Such initrd must accept 2 optional arguments: find_iso and find_preseed, so that the initrd can in turn load the ISO (as opposed to load the CD) and the preseed file. Then grub4dos is installed, this grub4dos tries first to load an installed version of the distro (/distroname/disks/boot), otherwise it tries to launch the installer (/distroname/install/boot). > Though given the differences between ubuntu livecd installer, and fedora > livecd installer (slow flexible file based copy from squashfs versus > fast less-flexible block based copy from squashed ext3 image), there may > be other ways (still using the wubi win32 front end) to install. I > sortof alluded to them in a recent thread prior to this one. I.e. how > my mods to anaconda to support rebootless installation from livecd, > could be used for a win32 installer. I'd be interested to know more about it. > But independent of that, I'd still recommend that the starting point > being (re)adding support to install-to-loop files (on ntfs) to anaconda. The equivalent Ubuntu file you really want to look at is partman-auto-loop. That adds the capabilities of targeting a loopfile to the old-school Ubuntu installer. You'd have to implement something similar within anaconda. Regards, Ago From johannbg at hi.is Thu Sep 13 14:09:02 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 14:09:02 +0000 Subject: Disable IPv6 by default. Message-ID: <46E9447E.9080105@hi.is> Let's disable IPv6 by default and let the user enable it. Which means if not enabled, all service's and configuration should be clean of IPv6 entry's until enabled. The WorldWideWeb is far from switching to IPv6. Institutions/company's wont spent $$$ in buying expensive IPv6 or dual capable IPv4/IPv6 Hardware unless they are forced to do due so... I don't know the strategy behind this decision from the beginning? ( maybe publicity stunt or to show the world we could ) Yeah, weee, the crowd goes wild *applause applause* Throw the dice and see if you make the reality check.. Let's turn it of by default and reconsider it after 3 - 5 years or later Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From cra at WPI.EDU Thu Sep 13 14:17:57 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 13 Sep 2007 10:17:57 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E9447E.9080105@hi.is> References: <46E9447E.9080105@hi.is> Message-ID: <20070913141757.GJ8380@angus.ind.WPI.EDU> On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: > Let's disable IPv6 by default and let the user enable it. Why? Is it causing a problem for you? IPv6 deployment is a chicken-and-egg problem. Everything Fedora can do to be proactive about encouraging its use should be applauded. One day we will eventually need it, and if we don't work out the wrinkles now, we'll be in trouble later. Windows Vista has it enabled by default. So should Fedora. From tagoh at redhat.com Thu Sep 13 14:22:08 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Thu, 13 Sep 2007 23:22:08 +0900 (JST) Subject: [Guidelines Change] Emacs Guidelines In-Reply-To: <645d17210709120354l645fef19l9be293e88f5131e3@mail.gmail.com> References: <1189535065.3964.24.camel@localhost.localdomain> <20070912.181123.861063662.tagoh@redhat.com> <645d17210709120354l645fef19l9be293e88f5131e3@mail.gmail.com> Message-ID: <20070913.232208.43048712.tagoh@redhat.com> >>>>> On Wed, 12 Sep 2007 11:54:19 +0100, >>>>> "JU" == "Jonathan Underwood" wrote: JU> On 12/09/2007, Akira TAGOH wrote: >> >>>>> On Tue, 11 Sep 2007 14:24:25 -0400, >> >>>>> "TC" == "Tom \"spot\" Callaway" wrote: >> TC> New guidelines describing how to package GNU Emacs and XEmacs addon TC> packages can be found here: TC> http://fedoraproject.org/wiki/Packaging/Emacs >> >> I just looked at that guideline and realized that the >> template suggests making emacs-common-%{pkg} as srpm. I >> thought CVS module name should be the same as srpm name and >> it should be usually the same as the upstream tarball name >> or what they prefer. or does this mean we are going to make >> an exception for Emacsen packages to have such CVS module >> name? JU> Yes - that's been the case for a long time now - this comes from the JU> previous package naming guidelines and was discussed at length JU> previously - please see threads on fedora-packaging recently for those JU> references. Ah, thank you for the reference. I entirely missed that mailing list :/ let me read them through the archives. Thanks, -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From markg85 at gmail.com Thu Sep 13 14:23:22 2007 From: markg85 at gmail.com (Mark) Date: Thu, 13 Sep 2007 16:23:22 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46E9447E.9080105@hi.is> References: <46E9447E.9080105@hi.is> Message-ID: <6e24a8e80709130723t1aa2f374v423e0d687dc5b9a6@mail.gmail.com> 2007/9/13, "J?hann B. Gu?mundsson" : > Let's disable IPv6 by default and let the user enable it. > Which means if not enabled, all service's and configuration should be > clean of IPv6 entry's > until enabled. > > The WorldWideWeb is far from switching to IPv6. > Institutions/company's wont spent $$$ in buying expensive IPv6 or dual > capable IPv4/IPv6 Hardware > unless they are forced to do due so... > > I don't know the strategy behind this decision from the beginning? > ( maybe publicity stunt or to show the world we could ) > Yeah, weee, the crowd goes wild *applause applause* > > Throw the dice and see if you make the reality check.. > > Let's turn it of by default and reconsider it after 3 - 5 years or later > > Best regards. > Johann B. Hi, it would be stupid to disable it now that it's in (for a while) there are sites and servers out there that use IPv6 so for that reason alone it should be enabled. It's also the future for the internet ip's so it just should be in fedora (and not because it's in vista). Mark. From dennis at ausil.us Thu Sep 13 14:23:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 13 Sep 2007 09:23:46 -0500 Subject: Disable IPv6 by default. In-Reply-To: <20070913141757.GJ8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> Message-ID: <200709130923.47235.dennis@ausil.us> On Thursday 13 September 2007 9:17:57 am Chuck Anderson wrote: > On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: > > Let's disable IPv6 by default and let the user enable it. > > Why? Is it causing a problem for you? > > IPv6 deployment is a chicken-and-egg problem. Everything Fedora can > do to be proactive about encouraging its use should be applauded. One > day we will eventually need it, and if we don't work out the wrinkles > now, we'll be in trouble later. Windows Vista has it enabled by > default. So should Fedora. I use ipv6 daily. why should i go through extra steps when having both enabled does not hurt people with ipv4 only connections? Dennis From snecklifter at gmail.com Thu Sep 13 14:24:55 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 13 Sep 2007 15:24:55 +0100 Subject: Disable IPv6 by default. In-Reply-To: <46E9447E.9080105@hi.is> References: <46E9447E.9080105@hi.is> Message-ID: <364d303b0709130724i61467105v7d7e74a7a6041914@mail.gmail.com> On 13/09/2007, "J?hann B. Gu?mundsson" wrote: > > Let's disable IPv6 by default and let the user enable it. No, lets not. Users don't have to care about IPv6. Which means if not enabled, all service's and configuration should be > clean of IPv6 entry's > until enabled. So lets revert a few years of software development then. The WorldWideWeb is far from switching to IPv6. Really? Institutions/company's wont spent $$$ in buying expensive IPv6 or dual > capable IPv4/IPv6 Hardware > unless they are forced to do due so... Or the equipment that is produced comes with IPv6 capability by default to give the hardware folks a reason to sell more hardware. I don't know the strategy behind this decision from the beginning? The world is running out of IPv4 addresses and NAT is a stop-gap that breaks things. Plus other nice things like QOS. ( maybe publicity stunt or to show the world we could ) > Yeah, weee, the crowd goes wild *applause applause* Yep, you got it. _That's_ the reason it is being implemented. Throw the dice and see if you make the reality check.. Let's turn it of by default and reconsider it after 3 - 5 years or later Hell, let's just stop progress altogether. We've landed on the moon after all. There's nothing left to do is there? Seriously, can I ask what has prompted this or is it just a slow day at the office? Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannbg at hi.is Thu Sep 13 14:31:49 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 14:31:49 +0000 Subject: Disable IPv6 by default. In-Reply-To: <20070913141757.GJ8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> Message-ID: <46E949D5.9010004@hi.is> Chuck Anderson wrote: > On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: > >> Let's disable IPv6 by default and let the user enable it. >> > > Why? Is it causing a problem for you? > > Waste of time and resources... > IPv6 deployment is a chicken-and-egg problem. Everything Fedora can > do to be proactive about encouraging its use should be applauded. One > day we will eventually need it, and if we don't work out the wrinkles > now, we'll be in trouble later. Windows Vista has it enabled by > default. So should Fedora. > > Not saying that we should stop working on. Just stop enable it by default. Oh just because M$ doe's it doesn't mean it's right.. Maybe we should follow M$ in blindly and imitate all their stupididly... Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From dcantrell at redhat.com Thu Sep 13 14:30:42 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 13 Sep 2007 10:30:42 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E9447E.9080105@hi.is> References: <46E9447E.9080105@hi.is> Message-ID: <20070913103042.86853409.dcantrell@redhat.com> On Thu, 13 Sep 2007 14:09:02 +0000 "J?hann B. Gu?mundsson" wrote: > I don't know the strategy behind this decision from the beginning? > ( maybe publicity stunt or to show the world we could ) > Yeah, weee, the crowd goes wild *applause applause* Not really intended as a publicity stunt. It's a real pain working on IPv6 because very few people actually use it in Fedoraland right now. Most people just complain about it because it's new and different. While most users won't switch over to it until absolutely necessary and most companies don't want to change over to it for the sake of changing, the United States Department of Defense is asking for software and hardware to support IPv6 now. If you want to disable it, you can blacklist the ipv6 module on your system. Note that actually *having* the module loaded on your system doesn't mean you're using it. And we really shouldn't be requiring users to enable or disable it to make things work. IPv6 support should be loaded and the system should work fine even if you are only using IPv4. And it doesn't now, so other than wanting to remove some lines from ifconfig(8) output or remove some boot up scripts, why do you want it disabled by default? -- David Cantrell Red Hat / Westford, MA -------------- 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 Sep 13 14:30:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Sep 2007 10:30:50 -0400 Subject: Announcing Fedora 8 Test 2 (7.91) Message-ID: <20070913103050.33a03547@lumos.localdomain> Batten down the hatches, Fedora 8 Test 2 spotted just over the port side bow! A veritable "sea" of choices await you in this release. First up is the "Fedora" installable 'choose your own adventure' style set of isos and trees for i386, x86_64, and ppc(64). Next up we have a variety of Live images: * Fedora Live (i686, x86_64, ppc) - A good general use Desktop live image. i686 even fits on a CD! * Fedora KDE Live (i686, x86_64) - A Desktop based on the KDE software suite. i686 even fits on a CD! * Fedora Developer Live (i686) - A Live image designed for software developers. * Fedora Electronic Lab (FEL) Live (i686) - A live image designed for engineers working on electronics. Fits on a CD! Remember that these Live images can be used on USB meida via the 'livecd-iso-to-disk' utility available in the livecd-tools package. Test 2 is for "beta" users. This is the time where we have more features in a "testable" state where the more people using them and the more feedback we get the better. So please help us make Fedora 8 as good as we can! Release Notes ============================= Work in progress release notes for this test release can be found in the Fedora wiki: http://fedoraproject.org/wiki/F8Test2/ReleaseNotes Road Map And Release Schedule ============================= This is the second test release of the Fedora 8 release, which is scheduled for November 8, 2007. For further information see http://fedoraproject.org/wiki/Releases/8/ How to get it: ============= DVD and network installation are available. We also offer a few different varieties of installable Live media. http://fedoraproject.org/get-fedora.html For those of you already running rawhide, all you need to do is yum update. You may already have packages newer than Test 2 installed. Bug reporting and tracking: ========================== The Release Engineering and QA teams keep track of bugs that are considered release blockers. You can see that list here: http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Blocker In addition, a list of non-blocker bugs that should be fixed for Fedora 8 if possible can be found here: http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Target Please check these lists before reporting new bugs! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From johannbg at hi.is Thu Sep 13 14:35:20 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 14:35:20 +0000 Subject: Disable IPv6 by default. In-Reply-To: <6e24a8e80709130723t1aa2f374v423e0d687dc5b9a6@mail.gmail.com> References: <46E9447E.9080105@hi.is> <6e24a8e80709130723t1aa2f374v423e0d687dc5b9a6@mail.gmail.com> Message-ID: <46E94AA8.8050705@hi.is> Mark wrote: > 2007/9/13, "J?hann B. Gu?mundsson" : > >> Let's disable IPv6 by default and let the user enable it. >> Which means if not enabled, all service's and configuration should be >> clean of IPv6 entry's >> until enabled. >> >> The WorldWideWeb is far from switching to IPv6. >> Institutions/company's wont spent $$$ in buying expensive IPv6 or dual >> capable IPv4/IPv6 Hardware >> unless they are forced to do due so... >> >> I don't know the strategy behind this decision from the beginning? >> ( maybe publicity stunt or to show the world we could ) >> Yeah, weee, the crowd goes wild *applause applause* >> >> Throw the dice and see if you make the reality check.. >> >> Let's turn it of by default and reconsider it after 3 - 5 years or later >> >> Best regards. >> Johann B. >> > > Hi, > > it would be stupid to disable it now that it's in (for a while) there > are sites and servers out there that use IPv6 so for that reason alone > it should be enabled. It's also the future for the internet ip's so it > just should be in fedora (and not because it's in vista). > > Mark. > > If enabled ( upgrade would keep it enabled ) Otherwise manually choose to enabled it during install ( Anaconda ) If not enabled, config and services should be left explicitly to IPv4 Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From johannbg at hi.is Thu Sep 13 14:36:28 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 14:36:28 +0000 Subject: Disable IPv6 by default. In-Reply-To: <200709130923.47235.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <200709130923.47235.dennis@ausil.us> Message-ID: <46E94AEC.6010900@hi.is> Dennis Gilmore wrote: > On Thursday 13 September 2007 9:17:57 am Chuck Anderson wrote: > >> On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: >> >>> Let's disable IPv6 by default and let the user enable it. >>> >> Why? Is it causing a problem for you? >> >> IPv6 deployment is a chicken-and-egg problem. Everything Fedora can >> do to be proactive about encouraging its use should be applauded. One >> day we will eventually need it, and if we don't work out the wrinkles >> now, we'll be in trouble later. Windows Vista has it enabled by >> default. So should Fedora. >> > > I use ipv6 daily. why should i go through extra steps when having both > enabled does not hurt people with ipv4 only connections? > > Dennis > > Why should it be turned on for you and the few others that are using it? Best regards Johann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From agostino.russo at gmail.com Thu Sep 13 14:36:16 2007 From: agostino.russo at gmail.com (Ago) Date: Thu, 13 Sep 2007 14:36:16 +0000 (UTC) Subject: Windows based installation of Fedora Linux? References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> Message-ID: King InuYasha gmail.com> writes: > > > Perhaps then, if someone with the skill to work on the Linux side of the stuff can figure out how to solve some of the issues, the patches could be sent into the upstream for affected components, and I do have some knowledge of NSIS, but Wubi code is somewhat difficult for me to sift through.... So how does the latest version of the installer work exactly? I am somewhat confused now.... Please see the other post for how it works. Feel free to ask if you need more details. Some front-end related projects: * Find a reliable way to map windows drives to linux devices * Make wubi code distro-neutral and easy to rebrand * Improve detection of relevant windows settings (detect screen readers/accessibility options, improve timezone detection, current screen settings...) * Improve downloader. The current metadl library already supports download resume, metalinks and partial checksums. But the mirror selector is too basic (random choice). The library is being rewritten in c++ to add segmented downloads. Hampus Wessman is working on it, but he could probably do with some help. * Improve skin (ExperienceUI?) * Code clean-up / refactoring * Change interface language at runtime * Change branding at runtime ... From tcallawa at redhat.com Thu Sep 13 14:36:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 13 Sep 2007 10:36:43 -0400 Subject: Fedora pointing to third party repositories (Was Re: Announcing rpmfusion) In-Reply-To: <46E8EBB3.4090701@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> <46E8EBB3.4090701@fedoraproject.org> Message-ID: <1189694203.3773.4.camel@localhost.localdomain> On Thu, 2007-09-13 at 13:20 +0530, Rahul Sundaram wrote: > We do not know yet if pointers to a repository are ok since the legal > situation has changed. > > http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717 > > Last time we consulted with legal, it was ok to point a website as long > as it didn't host directly such a software repository and we didn't > include information on what to find in such websites (ie) pointing to a > website like fedorafaq.org is ok as long as we don't tell them "go here > for mp3 codecs". Since I'm now the "Fedora Legal Contact Person", I formally relayed this question to the Red Hat lawyers 10 minutes ago (in person, no less). They're going to get back to me with a response. ~spot From jreiser at BitWagon.com Thu Sep 13 14:40:18 2007 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 13 Sep 2007 07:40:18 -0700 Subject: Disable IPv6 by default. In-Reply-To: <200709130923.47235.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <200709130923.47235.dennis@ausil.us> Message-ID: <46E94BD2.5080506@BitWagon.com> > I use ipv6 daily. why should i go through extra steps when having both > enabled does not hurt people with ipv4 only connections? Perhaps you've heard of the recommended policy "turn off all unused services"? Enabling IPv6 wastes RAM (several dozen pages) and is a security risk when the only connections used are IPv4. Just publicize the easy OFF switch: ----- /etc/modprobe.conf alias net-pf-10 off ----- -- From myfedora at richip.dhs.org Thu Sep 13 14:42:33 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 08:42:33 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: <1189675566.3157.365.camel@mccallum.corsepiu.local> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> Message-ID: <1189694553.10318.8.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 11:26 +0200, Ralf Corsepius wrote: > On Thu, 2007-09-13 at 09:06 +0000, Kevin Kofler wrote: > > Ralf Corsepius freenet.de> writes: > > > What are you referring to? Where am I not cooperating? > > > > You keep complaining loudly about freezes and Bodhi, and blaming the upgrade > > path reports in cases where you should have sent the appropriate freeze tagging > > requests to rel-eng or the appropriate update requests through Bodhi. > Complaining about lack of usability of the infrastructure is "non-cooperation"? > Shall video tape the cases, I am encountering almost every day? > > Not agreeing with management decisions is "non-cooperation"? > Yes, I feel the current release procedures are a mal-designed, > overengineered and yes, I feel fedora's management hardly could do > worse. I don't know about past issues, but from reading Ralf's responses in this thread, I would agree that he's behaving in a non-cooperative and non-constructive manner ... > > > => They are designed in a way, they prevent parallel installation of > > a > > > potential OSG1 and OSG2 package. > > > > This is a valid technical reason, the ones you gave before aren't. > Yes, I didn't mention them, because I respected to upstream's decision > not to ship *.pc's. ... And this is why. Ralf, all you did was explain why you're doing what you're doing (and not even going into the details and the rationale). However, you didn't really offer a solution to Chris (or Kevin) that would appeal to their technical skills and know-how. If upstream decided to do things the way they did, they must be satisfying a requirement, need or want that they have. How does that translate to the Fedora related package packager's needs? What would the alternative to pkgconfig .pc files then be? I don't know how OSG 1 or 2 works, but from what I know, pkgconfig was designed and supplied to make compile configurations and options for dependent packages easier. Amd parallel installs have been done using them. -- Richi Plana From jkeating at redhat.com Thu Sep 13 14:43:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Sep 2007 10:43:56 -0400 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <20070913103050.33a03547@lumos.localdomain> References: <20070913103050.33a03547@lumos.localdomain> Message-ID: <20070913104356.1f793f3a@lumos.localdomain> On Thu, 13 Sep 2007 10:30:50 -0400 Jesse Keating wrote: > Batten down the hatches, Fedora 8 Test 2 spotted just over the port > side bow! > > A veritable "sea" of choices await you in this release. First up is > the "Fedora" installable 'choose your own adventure' style set of isos > and trees for i386, x86_64, and ppc(64). Next up we have a variety of > Live images: I seemed to have missed the obligatory "ARRRRRR!" -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Thu Sep 13 14:45:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 08:45:58 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> Message-ID: <1189694758.10318.12.camel@localhost6.localdomain6> On Wed, 2007-09-12 at 22:44 -0700, Christopher Stone wrote: > I have decided to just use a hack and redefine my PKGCONFIG_PATH to . > within my spec file and use my own OSG pkgconfig file, and keep Ralf > completely out of the picture. Just be wary that this could fall out-of-sync with upstream packages should they decide to change anything in the previous version that might not necessarily cause a compile-time error but result in unexpected or erroneous results at run-time. Work would have to be doubled. -- Richi Plana From sundaram at fedoraproject.org Thu Sep 13 14:42:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 20:12:58 +0530 Subject: Fedora pointing to third party repositories (Was Re: Announcing rpmfusion) In-Reply-To: <1189694203.3773.4.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> <46E8EBB3.4090701@fedoraproject.org> <1189694203.3773.4.camel@localhost.localdomain> Message-ID: <46E94C72.1000907@fedoraproject.org> Tom "spot" Callaway wrote: > On Thu, 2007-09-13 at 13:20 +0530, Rahul Sundaram wrote: > >> We do not know yet if pointers to a repository are ok since the legal >> situation has changed. >> >> http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717 >> >> Last time we consulted with legal, it was ok to point a website as long >> as it didn't host directly such a software repository and we didn't >> include information on what to find in such websites (ie) pointing to a >> website like fedorafaq.org is ok as long as we don't tell them "go here >> for mp3 codecs". > > Since I'm now the "Fedora Legal Contact Person", I formally relayed this > question to the Red Hat lawyers 10 minutes ago (in person, no less). Thanks very much. I have been trying to get someone to do it for months together now with pretty much no response. > They're going to get back to me with a response. Excellent. Do you want to be listed as the legal contact in http://fedoraproject.org/wiki/Legal instead of Max Spevack? Rahul From dmc.fedora at filteredperception.org Thu Sep 13 14:44:20 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 09:44:20 -0500 Subject: ZyX Rebootless LiveOS Installer, was Re: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> <46E92685.1020002@filteredperception.org> Message-ID: <46E94CC4.50005@filteredperception.org> Ago wrote: > Douglas McClendon filteredperception.org> writes: > >> Though given the differences between ubuntu livecd installer, and fedora >> livecd installer (slow flexible file based copy from squashfs versus >> fast less-flexible block based copy from squashed ext3 image), there may >> be other ways (still using the wubi win32 front end) to install. I >> sortof alluded to them in a recent thread prior to this one. I.e. how >> my mods to anaconda to support rebootless installation from livecd, >> could be used for a win32 installer. > > I'd be interested to know more about it. rebootless installer - originally- http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html as of a couple days ago - (now with GUI and no patch to F7 required) http://gzyx.org (screenshots even- ooh! ahh!) 059fbb7736cccc30f23162ee3411c27639e061f7 gzyx-0.5.004.2k70908a.iso As it relates to a win32 installer, see my discussion at the beginning of the current thread- http://www.redhat.com/archives/rhl-devel-list/2007-September/msg00099.html (really the differentiation from current wubi, would be not needing a 2nd reboot. But to do it for ubuntu, you'd have to get them to go back to their early 2005 devicemapper-snapshot copy-on-write livecd mechanism) Enjoy... ;) -dmc P.S. - I'll try to have a yum repo up soon for the "ZyX Rebootless Installer" so that anyone who wants to can just boot up the F7 livecd like normal, do a yum install of it, and enjoy the primitive coolness. ;) From myfedora at richip.dhs.org Thu Sep 13 14:53:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 08:53:16 -0600 Subject: Disable IPv6 by default. In-Reply-To: <20070913141757.GJ8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> Message-ID: <1189695196.10318.19.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 10:17 -0400, Chuck Anderson wrote: > On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: > > Let's disable IPv6 by default and let the user enable it. > > Why? Is it causing a problem for you? > > IPv6 deployment is a chicken-and-egg problem. Everything Fedora can > do to be proactive about encouraging its use should be applauded. One > day we will eventually need it, and if we don't work out the wrinkles > now, we'll be in trouble later. Windows Vista has it enabled by > default. So should Fedora. It might be causing problems for me that I'm just not aware of. Once when I was tailing my syslog files, I'd catch NM blocking for a few seconds on some IPv6 operation. It might be asynchronous or it might not be, but it's something that I (as a Fedora user) don't want to enable consciously at this time. At the very least, make disabling it a one-step process (and free up ALL resources related to IPv6). Right now, I can't even figure out how to disable it entirely. There's online documentation on doing this by editing /etc/sysctl.conf flags, editing files in /etc/sysconfig/ and removing kernel modules from configuration. I understand the chicken-and-egg thing, but please help me exercise my freedom and make it easier for me to disable it. -- Richi Plana From johannbg at hi.is Thu Sep 13 15:00:11 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 15:00:11 +0000 Subject: Disable IPv6 by default. In-Reply-To: <364d303b0709130724i61467105v7d7e74a7a6041914@mail.gmail.com> References: <46E9447E.9080105@hi.is> <364d303b0709130724i61467105v7d7e74a7a6041914@mail.gmail.com> Message-ID: <46E9507B.4000800@hi.is> Christopher Brown wrote: > On 13/09/2007, *"J?hann B. Gu?mundsson"* > wrote: > > Let's disable IPv6 by default and let the user enable it. > > > No, lets not. Users don't have to care about IPv6. True but in case they want and care to disable IPv6 ( or visa versa ) Services and config files should stickt to either one not both. Unless user choose not not "care". ( services listening to IPv6 when IPv6 is not enabled? ) > > Which means if not enabled, all service's and configuration should be > clean of IPv6 entry's > until enabled. > > > So lets revert a few years of software development then. > If that actually what it takes to do make it listen to eithver IPv6 or visa versa then yes.. > > The WorldWideWeb is far from switching to IPv6. > > > Really? > Let me refrase that the people that are running the hardware behing the WWW are not IPv6 ready atleast the majority of them, thou protocols and standards are ( mostly ) > > Institutions/company's wont spent $$$ in buying expensive IPv6 or > dual > capable IPv4/IPv6 Hardware > unless they are forced to do due so... > > > Or the equipment that is produced comes with IPv6 capability by > default to give the hardware folks a reason to sell more hardware. > > I don't know the strategy behind this decision from the beginning? > > > The world is running out of IPv4 addresses and NAT is a stop-gap that > breaks things. Plus other nice things like QOS. > > ( maybe publicity stunt or to show the world we could ) > Yeah, weee, the crowd goes wild *applause applause* > > > Yep, you got it. _That's_ the reason it is being implemented. > > > > Throw the dice and see if you make the reality check.. > > > > Let's turn it of by default and reconsider it after 3 - 5 years or > later > > > Hell, let's just stop progress altogether. We've landed on the moon > after all. There's nothing left to do is there? > > Seriously, can I ask what has prompted this or is it just a slow day > at the office? > If I choose to disable something, it should be disabled and those thing related to it. > Cheers > Chris > > -- > http://www.chruz.com Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From johannbg at hi.is Thu Sep 13 15:01:25 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 15:01:25 +0000 Subject: Disable IPv6 by default. In-Reply-To: <46E94BD2.5080506@BitWagon.com> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <200709130923.47235.dennis@ausil.us> <46E94BD2.5080506@BitWagon.com> Message-ID: <46E950C5.301@hi.is> John Reiser wrote: >> I use ipv6 daily. why should i go through extra steps when having both >> enabled does not hurt people with ipv4 only connections? >> > > Perhaps you've heard of the recommended policy "turn off all unused services"? > Enabling IPv6 wastes RAM (several dozen pages) and is a security risk > when the only connections used are IPv4. > > Just publicize the easy OFF switch: > ----- /etc/modprobe.conf > alias net-pf-10 off > ----- > > Hear Hear... Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From myfedora at richip.dhs.org Thu Sep 13 15:02:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 09:02:16 -0600 Subject: Disable IPv6 by default. In-Reply-To: <46E9447E.9080105@hi.is> References: <46E9447E.9080105@hi.is> Message-ID: <1189695736.10318.25.camel@localhost6.localdomain6> Isn't there a way to determine at boot-time whether the network infrastructure the computer is on actually supports IPv6 or not? For ubiquitous protocols like IPv4, it isn't needed, but for IPv6, it just makes more sense. The question is, is it possible to determine it in a continuous manner? Kind of like hot-plugging. Maybe a check can be performed everytime an interface goes up (assuming it CAN be detected). If it isn't used, then free up the unused resources. -- Richi Plana From rc040203 at freenet.de Thu Sep 13 15:08:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 17:08:52 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: <1189694553.10318.8.camel@localhost6.localdomain6> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> Message-ID: <1189696132.3157.462.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 08:42 -0600, Richi Plana wrote: > On Thu, 2007-09-13 at 11:26 +0200, Ralf Corsepius wrote: > > On Thu, 2007-09-13 at 09:06 +0000, Kevin Kofler wrote: > > > Ralf Corsepius freenet.de> writes: > > > > => They are designed in a way, they prevent parallel installation of > > > a > > > > potential OSG1 and OSG2 package. > > > > > > This is a valid technical reason, the ones you gave before aren't. > > Yes, I didn't mention them, because I respected to upstream's decision > > not to ship *.pc's. > > ... And this is why. Ralf, all you did was explain why you're doing what > you're doing (and not even going into the details and the rationale). This whole thing has a long history, so let me reiterate it one final time: * OSG1 upstream had shipped *.pcs. This had let applications caused to rely on them being present. * OSG has decided to abandoned *.pcs with OSG2. This causes applications to break. Working around this reveal bugs in applications. I decided to follow upstream and not to re-add a proprietary isolated "wanna-be solution" like Debian does. > However, you didn't really offer a solution to Chris (or Kevin) that > would appeal to their technical skills and know-how. What more than offering Chris to help him in person to bring his packages to compile can I offer? What he did was to take out a gun, aim at my head and yell "Arse, you add them package config files immediately or I'll shoot" He preferred to pull the trigger. > If upstream decided to do things the way they did, they must be > satisfying a requirement, need or want that they have. How does that > translate to the Fedora related package packager's needs? Upstream released a new MAJOR release - This broke applications. This is expected to happen, maintainer either get their things functional or retire these packages. > What would the > alternative to pkgconfig .pc files then be? Passing CFLAGS and LIBS from the command line, like with any other package on this planet. Ralf From dennis at ausil.us Thu Sep 13 15:12:18 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 13 Sep 2007 10:12:18 -0500 Subject: Disable IPv6 by default. In-Reply-To: <46E950C5.301@hi.is> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> Message-ID: <200709131012.18983.dennis@ausil.us> On Thursday 13 September 2007 10:01:25 am J?hann B. Gu?mundsson wrote: > John Reiser wrote: > >> I use ipv6 daily. why should i go through extra steps when having both > >> enabled does not hurt people with ipv4 only connections? > > > > Perhaps you've heard of the recommended policy "turn off all unused > > services"? Enabling IPv6 wastes RAM (several dozen pages) and is a > > security risk when the only connections used are IPv4. > > > > Just publicize the easy OFF switch: > > ----- /etc/modprobe.conf > > alias net-pf-10 off > > ----- > > Hear Hear... > > Best regards. > Johann B. Please provide proof of your claims. where is the security risk? Johann. why exactly do you want ipv6 disabled? Personally other than using it now. i think that it will be a big step backwards if we disabled ipv6 by default. for one thing the DOD has mandated that all there systems be running ipv6 by 2008 http://www.networkworld.com/news/2005/080105-ipv6.html so you will see much faster acceleration of ipv6 services and usage within the next year since US govt contractors will need to have ipv6 to do there job. Dennis From tcallawa at redhat.com Thu Sep 13 15:20:57 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 13 Sep 2007 11:20:57 -0400 Subject: Fedora pointing to third party repositories (Was Re: Announcing rpmfusion) In-Reply-To: <46E94C72.1000907@fedoraproject.org> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> <46E8EBB3.4090701@fedoraproject.org> <1189694203.3773.4.camel@localhost.localdomain> <46E94C72.1000907@fedoraproject.org> Message-ID: <1189696857.3773.6.camel@localhost.localdomain> On Thu, 2007-09-13 at 20:12 +0530, Rahul Sundaram wrote: > Excellent. Do you want to be listed as the legal contact in > http://fedoraproject.org/wiki/Legal instead of Max Spevack? Yep. I talked to Max about that yesterday and he was more than happy to pass that burden on to me. ~spot From cra at WPI.EDU Thu Sep 13 15:22:11 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 13 Sep 2007 11:22:11 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189695736.10318.25.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> Message-ID: <20070913152211.GM8380@angus.ind.WPI.EDU> On Thu, Sep 13, 2007 at 09:02:16AM -0600, Richi Plana wrote: > Isn't there a way to determine at boot-time whether the network > infrastructure the computer is on actually supports IPv6 or not? For > ubiquitous protocols like IPv4, it isn't needed, but for IPv6, it just > makes more sense. The question is, is it possible to determine it in a > continuous manner? Kind of like hot-plugging. Maybe a check can be > performed everytime an interface goes up (assuming it CAN be detected). Yes, the system sends out IPv6 Neighbor Discovery messages and listens for IPv6 Router Advertisement messages. This all happens automatically by default in Fedora thanks to the hard work that has gone into enabling IPv6 by default in the OS, applications, and services. If you are on a network that supports IPv6, it all Just Works(TM), just the same as IPv4 has up to this point. > If it isn't used, then free up the unused resources. IMHO the resource argument is a red herring. Perhaps we should not ship GNOME by default because it uses too much resources? OTOH, perhaps we should disable IPv4 by default, or free all kernel resources related to IPv4 if there is no response from an IPv4 DHCP server? I don't think these are very good arguments. From myfedora at richip.dhs.org Thu Sep 13 15:25:40 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 09:25:40 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: <1189696132.3157.462.camel@mccallum.corsepiu.local> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> Message-ID: <1189697140.10318.35.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 17:08 +0200, Ralf Corsepius wrote: > > What would the > > alternative to pkgconfig .pc files then be? > Passing CFLAGS and LIBS from the command line, like with any other > package on this planet. Where would dependent packages intending on developing with OSG 1 or 2 get the values for CFLAGS and LIBS, then? The whole point to doing pkg-config is exactly so that developers wouldn't need to know where the providing packages files are located, what flags it requires and what libraries to link against. Granted some can be guessed due to Fedora's layout restrictions, but wouldn't that be taking a step back in the evolutionary process of development? Ultimately, the installed package would know best what it requires and not dependent developers. It was my impression that developers are moving towards pkg-config and not away. Even gnome followed this process. At one point in time, all the options had to be supplied to the "configure" script. Then they provided gnome-config, probably patterned after pkg-config. Finally they decided to settle on pkgconfig's standard. Even now with parallel installs, they've decided to adopt the [-].pc convention. -- Richi Plana From chris.stone at gmail.com Thu Sep 13 15:31:21 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 13 Sep 2007 08:31:21 -0700 Subject: rawhide report: 20070912 changes In-Reply-To: <1189696132.3157.462.camel@mccallum.corsepiu.local> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> Message-ID: I did not see Ralf's announcement on the mailing list where he asked who uses OSG-devel. Ralf, I would suggest you use repoquery to find the answer to this question in the future. Ralf, we appreciate your offer to help, but the fact is that you completely misunderstand the problem. The problem does not lie with osgcal/osgal, the problem is with osg. osg needs to re-add their pkgconfig file (the one provided by debian). If you truly wish to help out, then please just re-add the pkgconfig file, and then send it to the osg folks for them to include. I have tried to explain this to you several times now, but you keep on insisting that osgal/osgcal are "trashy" and "crappy" applications and that we should hard-code libraries by hand on the command line instead of using a more elegant solution such as a pkgconfig file. This is because you seem to think that the osg upstream folks are the smartest people in the world and they removed pkgconfig files from osg 2.0 for some technical reason which you are unaware of, but are sure exists. From sundaram at fedoraproject.org Thu Sep 13 15:31:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 21:01:37 +0530 Subject: Fedora pointing to third party repositories (Was Re: Announcing rpmfusion) In-Reply-To: <1189696857.3773.6.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7E10B.1010800@fedoraproject.org> <46E7E7A4.7070707@kanarip.com> <1189613327.7051.19.camel@localhost6.localdomain6> <46E8118A.5060506@fedoraproject.org> <1189620049.7051.38.camel@localhost6.localdomain6> <46E8EBB3.4090701@fedoraproject.org> <1189694203.3773.4.camel@localhost.localdomain> <46E94C72.1000907@fedoraproject.org> <1189696857.3773.6.camel@localhost.localdomain> Message-ID: <46E957D9.4040408@fedoraproject.org> Tom "spot" Callaway wrote: > On Thu, 2007-09-13 at 20:12 +0530, Rahul Sundaram wrote: > >> Excellent. Do you want to be listed as the legal contact in >> http://fedoraproject.org/wiki/Legal instead of Max Spevack? > > Yep. I talked to Max about that yesterday and he was more than happy to > pass that burden on to me. I have updated the page. You might want to get legal AT fedoraproject.org to point to you now. Rahul From rc040203 at freenet.de Thu Sep 13 15:37:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 17:37:08 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: <1189697140.10318.35.camel@localhost6.localdomain6> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> Message-ID: <1189697829.3157.469.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 09:25 -0600, Richi Plana wrote: > On Thu, 2007-09-13 at 17:08 +0200, Ralf Corsepius wrote: > > > What would the > > > alternative to pkgconfig .pc files then be? > > Passing CFLAGS and LIBS from the command line, like with any other > > package on this planet. > > Where would dependent packages intending on developing with OSG 1 or 2 > get the values for CFLAGS and LIBS, then? The whole point to doing > pkg-config is exactly so that developers wouldn't need to know where the > providing packages files are located, what flags it requires and what > libraries to link against. Right, but upstream has decided otherwise. > Granted some can be guessed due to Fedora's > layout restrictions, but wouldn't that be taking a step back in the > evolutionary process of development? Ultimately, the installed package > would know best what it requires and not dependent developers. > > It was my impression that developers are moving towards pkg-config and > not away. This impression is wrong. Some developers do, some don't. It's a tool devs can take or leave, it solves some issues, but it also introduces new ones. > Even gnome followed this process. It is in particular the GNOME community who follows it, because pkg-config has a gtk/glib/GNOME related past, while many other devel communities don't. > At one point in time, all > the options had to be supplied to the "configure" script. This still applies, this is what "packaging is about". Ralf From johannbg at hi.is Thu Sep 13 15:38:14 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 15:38:14 +0000 Subject: Disable IPv6 by default. In-Reply-To: <200709131012.18983.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> Message-ID: <46E95966.9030604@hi.is> Dennis Gilmore wrote: > On Thursday 13 September 2007 10:01:25 am J?hann B. Gu?mundsson wrote: > >> John Reiser wrote: >> >>>> I use ipv6 daily. why should i go through extra steps when having both >>>> enabled does not hurt people with ipv4 only connections? >>>> >>> Perhaps you've heard of the recommended policy "turn off all unused >>> services"? Enabling IPv6 wastes RAM (several dozen pages) and is a >>> security risk when the only connections used are IPv4. >>> >>> Just publicize the easy OFF switch: >>> ----- /etc/modprobe.conf >>> alias net-pf-10 off >>> ----- >>> >> Hear Hear... >> >> Best regards. >> Johann B. >> > Please provide proof of your claims. where is the security risk? > Johann. > why exactly do you want ipv6 disabled? > > Majority of user are not using it, it's wasting time and resources, faster boot time. When I turn things "off" or disable them programs should not be wasting time and resources to be running an constantly listening or checking and wondering if they are gonna receive "instruction" to process and further instruct a program that I have already disabled. > Personally other than using it now. i think that it will be a big step > backwards if we disabled ipv6 by default. for one thing the DOD has mandated > that all there systems be running ipv6 by 2008 > http://www.networkworld.com/news/2005/080105-ipv6.html so you will see much > faster acceleration of ipv6 services and usage within the next year since US > govt contractors will need to have ipv6 to do there job. > Maybe in the US but in the rest of the world and for companies and like, Unless you force them to use IPv6 and give them IPv6 compatable hardware they won't switch. > > Dennis > > > > -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From lightsolphoenix at gmail.com Thu Sep 13 15:40:36 2007 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Thu, 13 Sep 2007 11:40:36 -0400 Subject: Announcing rpmfusion In-Reply-To: <45669.192.54.193.51.1189671423.squirrel@rousalka.dyndns.org> References: <46E637DB.6060102@hhs.nl> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <1189665570.9380.3.camel@rousalka.dyndns.org> <45669.192.54.193.51.1189671423.squirrel@rousalka.dyndns.org> Message-ID: Is there a way for new packagers to get involved with RPM Fusion? I have a set of packages that can't go into Fedora's main repository for various reasons (emulators, non-free, etc.) and would be willing to maintain the packages for them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Sep 13 15:40:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 21:10:37 +0530 Subject: Fedora 8 Test 2 Release Notes Message-ID: <46E959F5.4010804@fedoraproject.org> Hi http://fedoraproject.org/wiki/F8Test2/ReleaseNotes I have updated the release notes with information on changes new to test 2. If there is anything important I have missed, please edit the wiki or let me know. Rahul From fedora at leemhuis.info Thu Sep 13 15:48:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 13 Sep 2007 17:48:07 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070913141757.GJ8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> Message-ID: <46E95BB7.70104@leemhuis.info> On 13.09.2007 16:17, Chuck Anderson wrote: > On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: >> Let's disable IPv6 by default and let the user enable it. > Why? Is it causing a problem for you? I'm all for leaving IPv6 enabled, but I'd like to abuse this thread to bring something up: At work we only have a IPv4 dhcp-server. But anaconda seems to look for a IPv6 dhcp-server during network-install -- that takes about one minute to time out, which is a bit annoying. Thus I use "noipv6" regularly when installing Fedora at work. Are other facing the same problem or is that something that only happens in this specific network? Does the timeout really have to be one minute? Wouldn't something like 10 or 15 seconds suffice if a IPv4 address was found already? CU knurd From myfedora at richip.dhs.org Thu Sep 13 15:47:51 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 09:47:51 -0600 Subject: Disable IPv6 by default. In-Reply-To: <20070913152211.GM8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> Message-ID: <1189698471.10318.56.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 11:22 -0400, Chuck Anderson wrote: > Yes, the system sends out IPv6 Neighbor Discovery messages and > listens > for IPv6 Router Advertisement messages. This all happens > automatically by default in Fedora thanks to the hard work that has > gone into enabling IPv6 by default in the OS, applications, and > services. If you are on a network that supports IPv6, it all Just > Works(TM), just the same as IPv4 has up to this point. How did enabling IPv6 by default contribute to the development of IPv6 Neighbor Discovery? Oh ... did you mean that the developers were motivated to do it because IPv6 was enabled by default? Could you tell me a little bit more about this IPv6 Neighbor Discovery? Perhaps I can get it to do what I want (remove the IPv6 modules when it hasn't discovered the IPv6 neighbor) > > If it isn't used, then free up the unused resources. > > IMHO the resource argument is a red herring. Perhaps we should not > ship GNOME by default because it uses too much resources? OTOH, > perhaps we should disable IPv4 by default, or free all kernel > resources related to IPv4 if there is no response from an IPv4 DHCP > server? I don't think these are very good arguments. The point isn't that the users have to justify their reasons. It's that it's what they want (for one reason or another) and the question becomes "Will Fedora help them exercise their freedom?". As for the Gnome argument: Fedora has decided (for their reasons) to make Gnome the default. But at the very least, Fedora makes it possible and even easy to install KDE instead or not install a desktop environment (albeit with some difficulty). KDE-switching was made easy because there was a demand for it. No DE is possible (and I applaud Fedora for it) but it requires some finagling, and that's alright because there's much less demand for it. Going back to IPv6: Sure, make it the default, but there's obviously quite a few people who are asking for it, and these people are asking to make things easier for them. Prior to the original poster's message, I actually have to disable IPv6 on ALL my computers by hand. This means going through editing a couple of config files some of which might even be unnecessary because there's no authority telling me what's needed. Having a simple Off switch in system-config-network would go a long way in helping me. One thing I've noticed is that people have this tendency to shove down people's throats their own brand of doing things. It's fine to suggest or even provide those solutions as default, but understand that so long as alternative solutions don't adversely affect other people, they shouldn't prevent them from doing so (not that a lot of people are doing this, but ... ->).. Better yet, HELP these people achieve their goals in the way they want if it's not too much to ask for. Unfortunately, a lot of people think that the less people adopt their solutions, the more their solutions adoptions are threatened. It's why those silly flamefests even exist. Freedom is mandatory but, unfortunately, cooperation is optional. -- Richi Plana From sandeen at redhat.com Thu Sep 13 15:49:39 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 13 Sep 2007 10:49:39 -0500 Subject: Disable IPv6 by default. In-Reply-To: <46E95BB7.70104@leemhuis.info> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> Message-ID: <46E95C13.5020006@redhat.com> Thorsten Leemhuis wrote: > On 13.09.2007 16:17, Chuck Anderson wrote: >> On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: >>> Let's disable IPv6 by default and let the user enable it. >> Why? Is it causing a problem for you? > > I'm all for leaving IPv6 enabled, but I'd like to abuse this thread to > bring something up: > > At work we only have a IPv4 dhcp-server. But anaconda seems to look for > a IPv6 dhcp-server during network-install -- that takes about one minute > to time out, which is a bit annoying. Thus I use "noipv6" regularly when > installing Fedora at work. > > Are other facing the same problem or is that something that only happens > in this specific network? I've seen the same thing at home. -Eric From dwmw2 at infradead.org Thu Sep 13 15:51:54 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 17:51:54 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189695196.10318.19.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <1189695196.10318.19.camel@localhost6.localdomain6> Message-ID: <1189698714.3570.158.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 08:53 -0600, Richi Plana wrote: > > It might be causing problems for me that I'm just not aware of. Once > when I was tailing my syslog files, I'd catch NM blocking for a few > seconds on some IPv6 operation. It might be asynchronous or it might not > be, but it's something that I (as a Fedora user) don't want to enable > consciously at this time. NetworkManager does almost nothing with IPv6 -- all it does it add and remove the link-local address when it decides the interface should be used/unused. It won't be blocking. > At the very least, make disabling it a one-step process (and free up > ALL > resources related to IPv6). Right now, I can't even figure out how to > disable it entirely. There's online documentation on doing this by > editing /etc/sysctl.conf flags, editing files in /etc/sysconfig/ and > removing kernel modules from configuration. It _is_ one step: echo blacklist ipv6 > /etc/modprobe.d/luddite -- dwmw2 From dwmw2 at infradead.org Thu Sep 13 15:54:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 17:54:43 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46E95BB7.70104@leemhuis.info> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> Message-ID: <1189698883.3570.160.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 17:48 +0200, Thorsten Leemhuis wrote: > > At work we only have a IPv4 dhcp-server. But anaconda seems to look for > a IPv6 dhcp-server during network-install -- that takes about one minute > to time out, which is a bit annoying. Thus I use "noipv6" regularly when > installing Fedora at work. I thought this was fixed. We shouldn't default to DHCPv6 at all -- but in F7 I think we still kept trying DHCPv6 even when the user explicitly turned it off in the UI. -- dwmw2 From myfedora at richip.dhs.org Thu Sep 13 15:54:46 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 09:54:46 -0600 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <20070913103050.33a03547@lumos.localdomain> References: <20070913103050.33a03547@lumos.localdomain> Message-ID: <1189698886.10318.60.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 10:30 -0400, Jesse Keating wrote: > * Fedora Developer Live (i686) - A Live image designed for software > developers. How does this work? What about it contributes to developers? And by developers, do you mean Fedora "core" developers or package developers? I can't seem to find that info on the Release Notes nor linked pages. -- Richi Plana From sundaram at fedoraproject.org Thu Sep 13 15:52:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 21:22:09 +0530 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <1189698886.10318.60.camel@localhost6.localdomain6> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> Message-ID: <46E95CA9.1020604@fedoraproject.org> Richi Plana wrote: > On Thu, 2007-09-13 at 10:30 -0400, Jesse Keating wrote: >> * Fedora Developer Live (i686) - A Live image designed for software >> developers. > > How does this work? What about it contributes to developers? And by > developers, do you mean Fedora "core" developers or package developers? > > I can't seem to find that info on the Release Notes nor linked pages. http://fedoraproject.org/wiki/FWN/Issue102#head-53444e1645ab6dc131718253c5300e6b55e60d92 linked from the release notes now. Rahul From myfedora at richip.dhs.org Thu Sep 13 15:59:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 09:59:10 -0600 Subject: Disable IPv6 by default. In-Reply-To: <1189698714.3570.158.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <1189695196.10318.19.camel@localhost6.localdomain6> <1189698714.3570.158.camel@shinybook.infradead.org> Message-ID: <1189699150.10318.63.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 17:51 +0200, David Woodhouse wrote: > It _is_ one step: > > echo blacklist ipv6 > /etc/modprobe.d/luddite To be honest, THAT'S the first time I've heard of that solution. Every other piece of documentation says edit /etc/modprobe.conf, edit /etc/sysconfig/network and/or edit /etc/sysctl.cfg Thanks for the help. -- Richi Plana From myfedora at richip.dhs.org Thu Sep 13 16:02:05 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:02:05 -0600 Subject: Disable IPv6 by default. In-Reply-To: <46E95BB7.70104@leemhuis.info> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> Message-ID: <1189699325.10318.67.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 17:48 +0200, Thorsten Leemhuis wrote: > On 13.09.2007 16:17, Chuck Anderson wrote: > > On Thu, Sep 13, 2007 at 02:09:02PM +0000, "J?hann B. Gu?mundsson" wrote: > >> Let's disable IPv6 by default and let the user enable it. > > Why? Is it causing a problem for you? > > I'm all for leaving IPv6 enabled, but I'd like to abuse this thread to > bring something up: > > At work we only have a IPv4 dhcp-server. But anaconda seems to look for > a IPv6 dhcp-server during network-install -- that takes about one minute > to time out, which is a bit annoying. Thus I use "noipv6" regularly when > installing Fedora at work. > > Are other facing the same problem or is that something that only happens > in this specific network? Does the timeout really have to be one > minute? Wouldn't something like 10 or 15 seconds suffice if a IPv4 > address was found already? Same here. That's the top-most reason I disable it (the others including that I don't need it in my network). It might actually be a bug that needs reporting. Or it might be a limitation of IPv6 (perhaps according to the specs, one minute is the timeout). -- Richi Plana From dwmw2 at infradead.org Thu Sep 13 16:04:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 18:04:09 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189699150.10318.63.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <1189695196.10318.19.camel@localhost6.localdomain6> <1189698714.3570.158.camel@shinybook.infradead.org> <1189699150.10318.63.camel@localhost6.localdomain6> Message-ID: <1189699449.3570.163.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 09:59 -0600, Richi Plana wrote: > To be honest, THAT'S the first time I've heard of that solution. Every > other piece of documentation says edit /etc/modprobe.conf, > edit /etc/sysconfig/network and/or edit /etc/sysctl.cfg > > Thanks for the help. Well, using /etc/modprobe.d is fairly much the same as editing /etc/modprobe.conf We _used_ to kind of theoretically be able to set NETWORKING_IPV6=no in /etc/sysconfig/network, but that apparently didn't really work anyway, and so it's been removed. I know not what you might have edited in /etc/sysctl.cfg -- dwmw2 From dcantrell at redhat.com Thu Sep 13 16:02:51 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 13 Sep 2007 12:02:51 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189698883.3570.160.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> Message-ID: <20070913120251.6377415d.dcantrell@redhat.com> On Thu, 13 Sep 2007 17:54:43 +0200 David Woodhouse wrote: > On Thu, 2007-09-13 at 17:48 +0200, Thorsten Leemhuis wrote: > > > > At work we only have a IPv4 dhcp-server. But anaconda seems to look for > > a IPv6 dhcp-server during network-install -- that takes about one minute > > to time out, which is a bit annoying. Thus I use "noipv6" regularly when > > installing Fedora at work. > > I thought this was fixed. We shouldn't default to DHCPv6 at all -- but > in F7 I think we still kept trying DHCPv6 even when the user explicitly > turned it off in the UI. This has been fixed since Fedora 7. If you specify no options, the defaults are DHCP for IPv4 and auto neighbor discovery for IPv6. Previously, if you disabled IPv6 during installation or selected auto neighbor discovery, DHCPv6 still occurred. -- David Cantrell Red Hat / Westford, MA -------------- 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 Thu Sep 13 16:05:36 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 18:05:36 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070913120251.6377415d.dcantrell@redhat.com> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> Message-ID: <1189699536.3570.165.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 12:02 -0400, David Cantrell wrote: > This has been fixed since Fedora 7. If you specify no options, the > defaults are DHCP for IPv4 and auto neighbor discovery for IPv6. > Previously, if you disabled IPv6 during installation or selected auto > neighbor discovery, DHCPv6 still occurred. That's what I thought. Thanks for the confirmation. -- dwmw2 From kevin.kofler at chello.at Thu Sep 13 16:06:33 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:06:33 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > What he did was to take out a gun, aim at my head and yell > "Arse, you add them package config files immediately or I'll shoot" He didn't say "arse". You were the one using vulgar words. > > What would the > > alternative to pkgconfig .pc files then be? > Passing CFLAGS and LIBS from the command line, like with any other > package on this planet. What planet are you living on? ;-) Here on Earth, most software builds with just: ./configure make make install (Even more if you accept "qmake", "qmake-qt4" or "cmake", again with no required arguments, as a configure step.) Sure, you _can_ pass CFLAGS, if you need to pass stuff like the RPM_OPT_FLAGS. But the package should compile with the default CFLAGS, in particular headers and libraries are supposed to be figured out automatically. (That's what the "auto" in "autotools" means. And other build systems, while not carrying "auto" in the name, are supposed to work the same way.) Kevin Kofler From myfedora at richip.dhs.org Thu Sep 13 16:08:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:08:06 -0600 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <46E95CA9.1020604@fedoraproject.org> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> Message-ID: <1189699686.10318.71.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 21:22 +0530, Rahul Sundaram wrote: > Richi Plana wrote: > > On Thu, 2007-09-13 at 10:30 -0400, Jesse Keating wrote: > >> * Fedora Developer Live (i686) - A Live image designed for software > >> developers. > > > > How does this work? What about it contributes to developers? And by > > developers, do you mean Fedora "core" developers or package developers? > > > > I can't seem to find that info on the Release Notes nor linked pages. > > http://fedoraproject.org/wiki/FWN/Issue102#head-53444e1645ab6dc131718253c5300e6b55e60d92 > linked from the release notes now. Thanks! I wasn't on the list, then. Darned fine idea, too! It's like hooking people on coke. "The first one's free. The following ones ... free as well!" I might just burn a couple of these spins and give them to former colleagues who've not tried developing on Linux, yet. I hope the docs (User's and API references are complete or bookmarked on Firefox). -- Richi Plana From dennis at ausil.us Thu Sep 13 16:10:14 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 13 Sep 2007 11:10:14 -0500 Subject: Disable IPv6 by default. In-Reply-To: <46E95966.9030604@hi.is> References: <46E9447E.9080105@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> Message-ID: <200709131110.15035.dennis@ausil.us> On Thursday 13 September 2007 10:38:14 am J?hann B. Gu?mundsson wrote: > Dennis Gilmore wrote: > > On Thursday 13 September 2007 10:01:25 am J?hann B. Gu?mundsson wrote: > >> John Reiser wrote: > >>>> I use ipv6 daily. why should i go through extra steps when having > >>>> both enabled does not hurt people with ipv4 only connections? > >>> > >>> Perhaps you've heard of the recommended policy "turn off all unused > >>> services"? Enabling IPv6 wastes RAM (several dozen pages) and is a > >>> security risk when the only connections used are IPv4. > >>> > >>> Just publicize the easy OFF switch: > >>> ----- /etc/modprobe.conf > >>> alias net-pf-10 off > >>> ----- > >> > >> Hear Hear... > >> > >> Best regards. > >> Johann B. > > > > Please provide proof of your claims. where is the security risk? > > Johann. > > why exactly do you want ipv6 disabled? > > Majority of user are not using it, it's wasting time and resources, > faster boot time. > > When I turn things "off" or disable them programs should not be wasting > time and resources > to be running an constantly listening or checking and wondering if they > are gonna receive "instruction" to process and further instruct > a program that I have already disabled. Please provide hard numbers to prove your claim. > > Personally other than using it now. i think that it will be a big step > > backwards if we disabled ipv6 by default. for one thing the DOD has > > mandated that all there systems be running ipv6 by 2008 > > http://www.networkworld.com/news/2005/080105-ipv6.html so you will see > > much faster acceleration of ipv6 services and usage within the next year > > since US govt contractors will need to have ipv6 to do there job. > > Maybe in the US but in the rest of the world and for companies and like, > Unless you force them to use > IPv6 and give them IPv6 compatable hardware they won't switch. > Asia is currently the largest ipv6 users. they make up over 1/3rd of the worlds population. so if europe gets dragged kicking and screaming so be it. but there will be a ripple effect. as the US starts using it more businesses in Europe will start needing to use it also. Dennis From dwmw2 at infradead.org Thu Sep 13 16:12:14 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 18:12:14 +0200 Subject: Disable IPv6 by default. In-Reply-To: <200709131110.15035.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <200709131110.15035.dennis@ausil.us> Message-ID: <1189699934.3570.167.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 11:10 -0500, Dennis Gilmore wrote: > > Maybe in the US but in the rest of the world and for companies and like, > > Unless you force them to use > > IPv6 and give them IPv6 compatable hardware they won't switch. > > > Asia is currently the largest ipv6 users. they make up over 1/3rd of the > worlds population. so if europe gets dragged kicking and screaming so be > it. but there will be a ripple effect. as the US starts using it more > businesses in Europe will start needing to use it also. Most serious hardware is capable of IPv6 anyway. The ISP I use even provides native IPv6 over PPP (along with IPv4, of course) on their DSL lines. -- dwmw2 From walters at redhat.com Thu Sep 13 16:13:29 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 13 Sep 2007 12:13:29 -0400 Subject: Disable IPv6 by default. In-Reply-To: <20070913120251.6377415d.dcantrell@redhat.com> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> Message-ID: On 9/13/07, David Cantrell wrote: > > > This has been fixed since Fedora 7. If you specify no options, the > defaults are DHCP for IPv4 and auto neighbor discovery for > IPv6. Previously, if you disabled IPv6 during installation or selected auto > neighbor discovery, DHCPv6 still occurred. Let me quote Havoc here (from http://ometer.com/free-software-ui.html): "Reading dozens of GNOME and Red Hat bugs per day, I find that users ask for a preference by default. If a user is using my app FooBar and they come to something they think is stupid - say the app deletes all their email - it's extremely common that they'll file a bug saying "there should be an option to disable eating all my email" instead of one saying "your craptastic junk-heap of an app ate my email." People just assume that FooBar was designed to eat your email, and humbly ask that you let them turn off this feature they don't like. Fight the temptation! Admit the truth to your users - you're a loser, FooBar just sucks and ate their email. ;-) This feature should be fixed, not made optional." This entire thread was a perfect example. It isn't a question of whether or not to enable IPv6; if we want IPv6, fix the bugs that adding it introduces. Don't add options to enable it or disable it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Sep 13 16:10:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 21:40:12 +0530 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <1189699686.10318.71.camel@localhost6.localdomain6> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> <1189699686.10318.71.camel@localhost6.localdomain6> Message-ID: <46E960E4.1030800@fedoraproject.org> Richi Plana wrote: > > I might just burn a couple of these spins and give them to former > colleagues who've not tried developing on Linux, yet. I hope the docs > (User's and API references are complete or bookmarked on Firefox) I don't think anything like that has been done yet but it could be easily done since bookmarks were separated out in a different package in the last release. File RFE's or bug reports for any desired changes. Rahul From kevin.kofler at chello.at Thu Sep 13 16:10:34 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:10:34 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > > At one point in time, all > > the options had to be supplied to the "configure" script. > This still applies, this is what "packaging is about". You're forgetting that not everyone who compiles software is a packager. Having to set CFLAGS and LIBS by hand might be acceptable to you as a packager, but most upstream projects will not consider this an acceptable solution, because they also have to support compilation from a tarball and want to make that as simple as possible. Now, of course, adding the .pc file in Fedora only won't help users on other distributions, but that's why you as a maintainer are expected to talk to upstream about such issues instead of sticking your head in the sand. And even for packagers, software which just compiles when you list the BRs and use %configure is much easier to work with than software which requires you to jump through hoops such as hand-set flags! Kevin Kofler From fedora at leemhuis.info Thu Sep 13 16:18:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 13 Sep 2007 18:18:03 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189699536.3570.165.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> <1189699536.3570.165.camel@shinybook.infradead.org> Message-ID: <46E962BB.4090207@leemhuis.info> On 13.09.2007 18:05, David Woodhouse wrote: > On Thu, 2007-09-13 at 12:02 -0400, David Cantrell wrote: >> This has been fixed since Fedora 7. If you specify no options, the >> defaults are DHCP for IPv4 and auto neighbor discovery for IPv6. >> Previously, if you disabled IPv6 during installation or selected auto >> neighbor discovery, DHCPv6 still occurred. > That's what I thought. Thanks for the confirmation. thx from me as well -- seems I saw the problem on FC6 (or maybe RHEL5 as well?) then and never retried it with F7. CU knurd From overholt at redhat.com Thu Sep 13 16:14:39 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 13 Sep 2007 12:14:39 -0400 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <1189699686.10318.71.camel@localhost6.localdomain6> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> <1189699686.10318.71.camel@localhost6.localdomain6> Message-ID: <20070913161439.GA12146@redhat.com> Hi Richi and others, * Richi Plana [2007-09-13 12:08]: > On Thu, 2007-09-13 at 21:22 +0530, Rahul Sundaram wrote: > > Richi Plana wrote: > > > On Thu, 2007-09-13 at 10:30 -0400, Jesse Keating wrote: > > >> * Fedora Developer Live (i686) - A Live image designed for software > > >> developers. > > > > > > How does this work? What about it contributes to developers? And by > > > developers, do you mean Fedora "core" developers or package developers? > > > > > > I can't seem to find that info on the Release Notes nor linked pages. > > > > http://fedoraproject.org/wiki/FWN/Issue102#head-53444e1645ab6dc131718253c5300e6b55e60d92 > > linked from the release notes now. > > Thanks! I wasn't on the list, then. Darned fine idea, too! It's like > hooking people on coke. "The first one's free. The following ones ... > free as well!" > > I might just burn a couple of these spins and give them to former > colleagues who've not tried developing on Linux, yet. I hope the docs > (User's and API references are complete or bookmarked on Firefox). I'd love it if you could help out with this side of things. Send me an email if you think you'll be able to contribute. We're in need of people to help out so if anyone has time, please send me an email. I'm going to set up a mailing list and announce it here soon. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcantrell at redhat.com Thu Sep 13 16:21:56 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 13 Sep 2007 12:21:56 -0400 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> Message-ID: <20070913122156.30d115f3.dcantrell@redhat.com> On Thu, 13 Sep 2007 12:13:29 -0400 "Colin Walters" wrote: > On 9/13/07, David Cantrell wrote: > > > > > > This has been fixed since Fedora 7. If you specify no options, the > > defaults are DHCP for IPv4 and auto neighbor discovery for > > IPv6. Previously, if you disabled IPv6 during installation or selected auto > > neighbor discovery, DHCPv6 still occurred. > > > Let me quote Havoc here (from http://ometer.com/free-software-ui.html): > > "Reading dozens of GNOME and Red Hat bugs per day, I find that users ask for > a preference by default. If a user is using my app FooBar and they come to > something they think is stupid - say the app deletes all their email - it's > extremely common that they'll file a bug saying "there should be an option > to disable eating all my email" instead of one saying "your craptastic > junk-heap of an app ate my email." People just assume that FooBar was > designed to eat your email, and humbly ask that you let them turn off this > feature they don't like. > > Fight the temptation! Admit the truth to your users - you're a loser, FooBar > just sucks and ate their email. ;-) This feature should be fixed, not made > optional." > > This entire thread was a perfect example. It isn't a question of whether or > not to enable IPv6; if we want IPv6, fix the bugs that adding it > introduces. Don't add options to enable it or disable it. Exactly. This is why it's IPv6 is enabled by default now. When the masses do want IPv6, they'll be glad that the legwork was done now to ensure it all works correctly. Of course, this is the kind of post that someone will dig up and quote me on in 5 years when we're all using IPv7. 640k of memory, anyone? :) -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Thu Sep 13 16:23:35 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:23:35 -0600 Subject: Disable IPv6 by default. In-Reply-To: <1189699449.3570.163.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <1189695196.10318.19.camel@localhost6.localdomain6> <1189698714.3570.158.camel@shinybook.infradead.org> <1189699150.10318.63.camel@localhost6.localdomain6> <1189699449.3570.163.camel@shinybook.infradead.org> Message-ID: <1189700615.10318.85.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 18:04 +0200, David Woodhouse wrote: > On Thu, 2007-09-13 at 09:59 -0600, Richi Plana wrote: > > To be honest, THAT'S the first time I've heard of that solution. Every > > other piece of documentation says edit /etc/modprobe.conf, > > edit /etc/sysconfig/network and/or edit /etc/sysctl.cfg > > > > Thanks for the help. > > Well, using /etc/modprobe.d is fairly much the same as > editing /etc/modprobe.conf Ahh! But now I'm assuming that's the Fedora-sanctioned way of doing things that works with every other part of Fedora's core system. That's why I was hoping for that one disable button on s-c-n: to make sure any changes I want work well with the rest of Fedora. (It's entirely possible that change I make might get trampled by other Fedora subsystems like editing /etc/sysconfig/iptables by hand. With a Fedora-sanctioned mechanism like the iptables "Custom Rules File", I can at least work WITH Fedora). > I know not what you might have edited in /etc/sysctl.cfg Whoops, you're right ... I can't find it in my "TODO list upon new installation document". My mistake. Here's an old document on why some users might want to disable IPv6 in the meantime: http://ipv6.niif.hu/m/IPv6hostslinux_disableIPv6 (I just found it after your giving that hint). It even specifically mentions how Fedora got things right. Cool. -- Richi Plana From dcantrell at redhat.com Thu Sep 13 16:22:54 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 13 Sep 2007 12:22:54 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E962BB.4090207@leemhuis.info> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> <1189699536.3570.165.camel@shinybook.infradead.org> <46E962BB.4090207@leemhuis.info> Message-ID: <20070913122254.589e3000.dcantrell@redhat.com> On Thu, 13 Sep 2007 18:18:03 +0200 Thorsten Leemhuis wrote: > On 13.09.2007 18:05, David Woodhouse wrote: > > On Thu, 2007-09-13 at 12:02 -0400, David Cantrell wrote: > >> This has been fixed since Fedora 7. If you specify no options, the > >> defaults are DHCP for IPv4 and auto neighbor discovery for IPv6. > >> Previously, if you disabled IPv6 during installation or selected auto > >> neighbor discovery, DHCPv6 still occurred. > > That's what I thought. Thanks for the confirmation. > > thx from me as well -- seems I saw the problem on FC6 (or maybe RHEL5 as > well?) then and never retried it with F7. Yeah, you would have seen it in RHEL 5.0 as well because its based was pre-FC6 Fedora. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Sep 13 16:25:50 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 18:25:50 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> Message-ID: <1189700750.3157.481.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 16:06 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > What he did was to take out a gun, aim at my head and yell > > "Arse, you add them package config files immediately or I'll shoot" > > He didn't say "arse". You were the one using vulgar words. Yes, he didn't use this word, he used more polite words with the same contents. > > > What would the > > > alternative to pkgconfig .pc files then be? > > Passing CFLAGS and LIBS from the command line, like with any other > > package on this planet. > > What planet are you living on? ;-) Here on Earth, most software builds with > just: > ./configure > make > make install This is an urban legend. Most packages build with %configure make make DESTDIR=... install If you have look into %configure you can observe what I say. Ralf From nalin at redhat.com Thu Sep 13 16:28:06 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 13 Sep 2007 12:28:06 -0400 Subject: rawhide report: 20070912 changes In-Reply-To: References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> Message-ID: <20070913162806.GA1318@redhat.com> On Thu, Sep 13, 2007 at 04:10:34PM +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > > At one point in time, all > > > the options had to be supplied to the "configure" script. > > This still applies, this is what "packaging is about". > > You're forgetting that not everyone who compiles software is a packager. Having > to set CFLAGS and LIBS by hand might be acceptable to you as a packager, but > most upstream projects will not consider this an acceptable solution, because > they also have to support compilation from a tarball and want to make that as > simple as possible. > > Now, of course, adding the .pc file in Fedora only won't help users on other > distributions, but that's why you as a maintainer are expected to talk to > upstream about such issues instead of sticking your head in the sand. Forgive me for wading in here, but upstream *has* to be where .pc files show up, and if they don't show up there, we absolutely shouldn't be adding them to binary packages. I believe this very strongly. Including a .pc file in a -devel package suggests, to maintainers of projects which use that -devel package, that the .pc file can be depended upon to always be there when the library is, that it's safe to have configure scripts depend on their presence. If I were a maintainer of a package which depended on a .pc file, and I started getting reports from people who couldn't install my package because they built a depended-upon package from source (because they're on another operating system or Linux flavor), and I then tracked the root cause down to my dependence on a .pc file which isn't available everywhere, I'd feel betrayed. Cheers, Nalin From rc040203 at freenet.de Thu Sep 13 16:33:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 18:33:55 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> Message-ID: <1189701235.3157.490.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 08:31 -0700, Christopher Stone wrote: > I did not see Ralf's announcement on the mailing list where he asked > who uses OSG-devel. Ralf, I would suggest you use repoquery to find > the answer to this question in the future. > > Ralf, we appreciate your offer to help, but the fact is that you > completely misunderstand the problem. The problem does not lie with > osgcal/osgal, the problem is with osg. osg needs to re-add their > pkgconfig file (the one provided by debian). If you truly wish to > help out, then please just re-add the pkgconfig file, Here you are aiming at my head with your gun, again. You effectively are saying: "I am leaving you no choice but to add these *.pcs", and leaving no choice. > and then send it > to the osg folks for them to include. > > I have tried to explain this to you several times now, but you keep on > insisting that osgal/osgcal are "trashy" and "crappy" applications There configure scripts as in CVS are - they violating autoconf principles all over the place. Will you finally send me links to your sources such I can point you to the bugs? Below is the diff to get osgalpp working w/o pkg-config. Index: openalpp.spec =================================================================== RCS file: /cvs/pkgs/rpms/openalpp/devel/openalpp.spec,v retrieving revision 1.14 diff -u -r1.14 openalpp.spec --- openalpp.spec 8 Jul 2007 12:20:50 -0000 1.14 +++ openalpp.spec 11 Sep 2007 23:03:22 -0000 @@ -1,6 +1,6 @@ Name: openalpp Version: 20060714 -Release: 4%{?dist} +Release: 5%{?dist} Summary: Object Oriented version of OpenAL Group: System Environment/Libraries @@ -22,6 +22,7 @@ Group: Development/Libraries Requires: %{name} = %{version}-%{release} Requires: openal-devel freealut-devel libvorbis-devel OpenThreads-devel +Requires: pkgconfig %description devel This package contains headers and libraries required to build applications that @@ -33,9 +34,14 @@ sed -i -e 's/^\(CXXFLAGS="[^"]*\)/\1 $CXXFLAGS/' configure ^[ IW diff Row 67 Col 1 6:29 Ctrl-K H for help Version: 20060714 -Release: 4%{?dist} +Release: 5%{?dist} Summary: Object Oriented version of OpenAL Group: System Environment/Libraries @@ -22,6 +22,7 @@ Group: Development/Libraries Requires: %{name} = %{version}-%{release} Requires: openal-devel freealut-devel libvorbis-devel OpenThreads-devel +Requires: pkgconfig %description devel This package contains headers and libraries required to build applications that @@ -33,9 +34,14 @@ sed -i -e 's/^\(CXXFLAGS="[^"]*\)/\1 $CXXFLAGS/' configure find -name "*.cpp" -o -name "*.h" | xargs chmod -c -x +# OSG-2 has abanded openthreads.pc, hard-code minimal requirements. +sed -i -e 's;^\(Requires:.*\) openthreads,;\1;' \ + -e 's;\(^Libs:.*\) @ALUT_LIB@;\1 -lOpenThreads @ALUT_LIB@;' \ + openalpp.pc.in %build -%configure --disable-static --disable-dependency-tracking +%configure --disable-static --disable-dependency-tracking \ +OPENTHREADS_CFLAGS=' ' OPENTHREADS_LIBS="-lOpenThreads" make %{?_smp_mflags} @@ -65,12 +71,18 @@ %{_libdir}/*.so.* %files devel +%defattr(-,root,root,-) %{_includedir}/openalpp %{_libdir}/pkgconfig/%{name}.pc %{_libdir}/*.so %changelog +* Sun Jul 29 2007 Ralf Cors?pius 20060714-5 +- Work-around OSG-2 having dropped openthreads.pc. +- Add missing R: pkgconfig to *-devel. +- Add missing %defattr to *-devel. + * Sun Jul 08 2007 Christopher Stone 20060714-4 - Rebuild for OSG 2.0 As you can see the work-around to pkgconfig is close to being trivial. configure OPENTHREADS_CFLAGS=' ' ... is one half The other half is massaging the openalpp.pc. Ralf From myfedora at richip.dhs.org Thu Sep 13 16:36:24 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:36:24 -0600 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <46E960E4.1030800@fedoraproject.org> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> <1189699686.10318.71.camel@localhost6.localdomain6> <46E960E4.1030800@fedoraproject.org> Message-ID: <1189701384.10318.95.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 21:40 +0530, Rahul Sundaram wrote: > Richi Plana wrote: > > > > > I might just burn a couple of these spins and give them to former > > colleagues who've not tried developing on Linux, yet. I hope the docs > > (User's and API references are complete or bookmarked on Firefox) > > I don't think anything like that has been done yet but it could be > easily done since bookmarks were separated out in a different package in > the last release. File RFE's or bug reports for any desired changes. What do I file the RFE against? It's just that whenever I talk about ease-of-development, the first thing that I bring up is documentation that makes it easy. And for that, I always go back to Javadoc. It is, by and large, the best way to hook a developer into using ones code. Unfortunately, the thing I noticed is that when I install javadoc packages (including the Sun manual), no links pointing to it are ever added. If there's an API to adding bookmarks to Firefox externally (or, better yet, a global bookmarks file for all browsers), that would help a lot. Imagine -devel packages hooking their documentations into Firefox. (I understand yelp is doing it but most of the good stuff is formatted a'la Javadoc and/or is available online like http://library.gnome.org/devel/ -- Richi Plana From rjones at redhat.com Thu Sep 13 16:33:04 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Sep 2007 17:33:04 +0100 Subject: rpmlint file-not-utf8 Message-ID: <46E96640.9050808@redhat.com> I'm getting warning below from rpmlint about "file-not-utf8". cduce-devel.x86_64: W: file-not-utf8 /usr/share/doc/cduce-devel-0.5.0/tutorial_getting_started.html cduce-devel.x86_64: W: file-not-utf8 /usr/share/doc/cduce-devel-0.5.0/manual_expressions.html cduce-devel.x86_64: W: file-not-utf8 /usr/share/doc/cduce-devel-0.5.0/AUTHORS The AUTHORS file is fair enough - I can use iconv to convert that to UTF-8. However I'm concerned about the HTML files. These are ISO-8859-1 files, and moreover they contain correct Content-Type metadata to mark them as such so I can't see there is a problem with these two files not being UTF-8. Do I need to worry about it? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Thu Sep 13 16:35:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Sep 2007 22:05:12 +0530 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <1189701384.10318.95.camel@localhost6.localdomain6> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> <1189699686.10318.71.camel@localhost6.localdomain6> <46E960E4.1030800@fedoraproject.org> <1189701384.10318.95.camel@localhost6.localdomain6> Message-ID: <46E966C0.4060608@fedoraproject.org> Richi Plana wrote: > On Thu, 2007-09-13 at 21:40 +0530, Rahul Sundaram wrote: >> Richi Plana wrote: >> >>> I might just burn a couple of these spins and give them to former >>> colleagues who've not tried developing on Linux, yet. I hope the docs >>> (User's and API references are complete or bookmarked on Firefox) >> I don't think anything like that has been done yet but it could be >> easily done since bookmarks were separated out in a different package in >> the last release. File RFE's or bug reports for any desired changes. > > What do I file the RFE against? If documentation is not available within help or elsewhere, against the package. If bookmarks needs to be added, against firefox. If you don't know precisely, best guess. If it is generic, against "distribution" component. Rahul From rc040203 at freenet.de Thu Sep 13 16:40:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 18:40:09 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: <20070913162806.GA1318@redhat.com> References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> Message-ID: <1189701609.3157.496.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 12:28 -0400, Nalin Dahyabhai wrote: > On Thu, Sep 13, 2007 at 04:10:34PM +0000, Kevin Kofler wrote: > > Ralf Corsepius freenet.de> writes: > > > > At one point in time, all > > > > the options had to be supplied to the "configure" script. > > > This still applies, this is what "packaging is about". > > > > You're forgetting that not everyone who compiles software is a packager. Having > > to set CFLAGS and LIBS by hand might be acceptable to you as a packager, but > > most upstream projects will not consider this an acceptable solution, because > > they also have to support compilation from a tarball and want to make that as > > simple as possible. > > > > Now, of course, adding the .pc file in Fedora only won't help users on other > > distributions, but that's why you as a maintainer are expected to talk to > > upstream about such issues instead of sticking your head in the sand. > > Forgive me for wading in here, but upstream *has* to be where .pc files > show up, and if they don't show up there, we absolutely shouldn't be > adding them to binary packages. I believe this very strongly. Thanks, for supporting me.- > Including a .pc file in a -devel package suggests, to maintainers of > projects which use that -devel package, that the .pc file can be > depended upon to always be there when the library is, that it's safe to > have configure scripts depend on their presence. Meanwhile I am considering to add packages called OpenThreads-devel-dontuse OpenSceneGraph-devel-dontuse which would only contain the package config files. openthreads.pc and openscenegraph-2.pc > If I were a maintainer of a package which depended on a .pc file, and I > started getting reports from people who couldn't install my package > because they built a depended-upon package from source (because they're > on another operating system or Linux flavor), and I then tracked the > root cause down to my dependence on a .pc file which isn't available > everywhere, I'd feel betrayed. except that these user (Chris) start to shoot a the Fedora package maintainer and not at upstream ;) Ralf From jreiser at BitWagon.com Thu Sep 13 16:43:13 2007 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 13 Sep 2007 09:43:13 -0700 Subject: Disable IPv6 by default. In-Reply-To: <200709131012.18983.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> Message-ID: <46E968A1.8090603@BitWagon.com> Dennis Gilmore wrote: > On Thursday 13 September 2007 10:01:25 am J?hann B. Gu?mundsson wrote: > >>John Reiser wrote: >> >>>>I use ipv6 daily. why should i go through extra steps when having both >>>>enabled does not hurt people with ipv4 only connections? >>> >>>Perhaps you've heard of the recommended policy "turn off all unused >>>services"? Enabling IPv6 wastes RAM (several dozen pages) and is a >>>security risk when the only connections used are IPv4. >>> >>>Just publicize the easy OFF switch: >>>----- /etc/modprobe.conf >>>alias net-pf-10 off >>>----- > Please provide proof of your claims. where is the security risk? *ALL* code that is not necessary for intended operation is a security risk. Code in the operating system kernel (including modules) is particularly risky because in general it has few restrictions on its access to all devices. "Turn off all unused services" is the *FIRST* item on most security checklists. IPv6 service currently is not available to the vast majority of residential DSL and cable customers in the US. Just publicize the "alias net-pf-10 off". -- From kevin.kofler at chello.at Thu Sep 13 16:44:22 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:44:22 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> Message-ID: Nalin Dahyabhai redhat.com> writes: > Forgive me for wading in here, but upstream *has* to be where .pc files > show up, and if they don't show up there, we absolutely shouldn't be > adding them to binary packages. I believe this very strongly. But there are actually cases where .pc files are being added in Fedora packages, for reasons such as the upstream foo-config script not being multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper foo-config script which just calls pkgconfig). There are also other reasons for adding .pc files in the distribution. That said, I do think this point needs to be taken upstream. Kevin Kofler From chris.stone at gmail.com Thu Sep 13 16:47:28 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 13 Sep 2007 09:47:28 -0700 Subject: rawhide report: 20070912 changes In-Reply-To: <1189701609.3157.496.camel@mccallum.corsepiu.local> References: <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <1189701609.3157.496.camel@mccallum.corsepiu.local> Message-ID: Guys, we have just contacted OSG upstream and we have full confidence that Robert will include the pkgconfig files soon. This matter is over. Ralf can add the packages once upstream adds them which will hopefully be any day now. Thanks. From pbrobinson at gmail.com Thu Sep 13 16:51:14 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 13 Sep 2007 17:51:14 +0100 Subject: Disable IPv6 by default. In-Reply-To: <46E95966.9030604@hi.is> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> Message-ID: <5256d0b0709130951s7eae9408w9e1329161c2efa59@mail.gmail.com> > >>>> I use ipv6 daily. why should i go through extra steps when having both > >>>> enabled does not hurt people with ipv4 only connections? > >>>> > >>> Perhaps you've heard of the recommended policy "turn off all unused > >>> services"? Enabling IPv6 wastes RAM (several dozen pages) and is a > >>> security risk when the only connections used are IPv4. > >>> > >>> Just publicize the easy OFF switch: > >>> ----- /etc/modprobe.conf > >>> alias net-pf-10 off > >>> ----- > >>> > >> Hear Hear... > >> > >> Best regards. > >> Johann B. > >> > > Please provide proof of your claims. where is the security risk? > > Johann. > > why exactly do you want ipv6 disabled? > > > > > > Majority of user are not using it, it's wasting time and resources, > faster boot time. > > When I turn things "off" or disable them programs should not be wasting > time and resources > to be running an constantly listening or checking and wondering if they > are gonna receive "instruction" to process and further instruct > a program that I have already disabled. I'm not sure how much of a saving (both in resources and time) turning off ipv6 would make. Most services support IPV6 out of the box and have it all compiled in. So by turning IPV6 off about all you would save is the memory of a few kernel modules. I'm not sure the best way to actually calculate this but doing a "lsmod | grep ip6" got me a few modules which totaled a huge 312 KB. Huge. As for startup time about the only thing I see that takes time is the ipv6 firewall. > > Personally other than using it now. i think that it will be a big step > > backwards if we disabled ipv6 by default. for one thing the DOD has mandated > > that all there systems be running ipv6 by 2008 > > http://www.networkworld.com/news/2005/080105-ipv6.html so you will see much > > faster acceleration of ipv6 services and usage within the next year since US > > govt contractors will need to have ipv6 to do there job. > > > Maybe in the US but in the rest of the world and for companies and like, > Unless you force them to use > IPv6 and give them IPv6 compatable hardware they won't switch. In fact IPV6 is getting quite popular through out Europe and Asia, more and more ISPs are offering IPV6 as an option, most (if not all) hosting providers offer IPV6. Most if not all modern OSes support IPV6 out of the box (MacOSX, Vista, Server 2008) and with the M$ products you can't disable it (you can on a particular interface but it still runs on loop back and for other bits). Also all corporate level hardware supports IPv6 out of the box, or has had firmwares available to support it for years. Peter From kevin.kofler at chello.at Thu Sep 13 16:50:39 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:50:39 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <1189701609.3157.496.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > except that these user (Chris) start to shoot a the Fedora package > maintainer and not at upstream ;) But why don't you forward the report to upstream instead of complaining in Bugzilla and here? If upstream says "no", then you can tell us about their reasons, which will also hopefully include a sane suggestion about what to use instead (not a crude hack like your hand-set LIBS; if hardcoding the library and nothing else is really all that's needed, that's what AC_CHECK_LIB is for). Now, Chris could (should?) have talked to upstream directly, however, I don't think forwarding a request like this is undoable. Kevin Kofler From myfedora at richip.dhs.org Thu Sep 13 16:53:43 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:53:43 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> Message-ID: <1189702423.10318.103.camel@localhost6.localdomain6> On Thu, 2007-09-13 at 16:44 +0000, Kevin Kofler wrote: > Nalin Dahyabhai redhat.com> writes: > > Forgive me for wading in here, but upstream *has* to be where .pc files > > show up, and if they don't show up there, we absolutely shouldn't be > > adding them to binary packages. I believe this very strongly. > > But there are actually cases where .pc files are being added in Fedora > packages, for reasons such as the upstream foo-config script not being > multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper > foo-config script which just calls pkgconfig). There are also other reasons for > adding .pc files in the distribution. > > That said, I do think this point needs to be taken upstream. That's the point that Nalin is trying to make, :). Two things unanimously agreed on: 1) *.pc files are important because these contain the options that the providing package would know and the dependent package developer shouldn't guess. 2) A mechanism for providing this (whether it's a *.pc file or something else) should be provided by the package developer and that means upstream. They should answer the question "How do I develop against your packages?" Now, there are more immediate concerns like "What to do in the meantime because certain packages are waiting?" That's where Ralf and Chris should cooperate and Ralf begrudgingly (and quite sarcastically, I might add ... It's a good thing I can see the humor in it sometimes ;) ) has declared he will provide .. ahm ... OpenThreads-devel-dontuse and OpenSceneGraph-devel-dontuse for people to, err, use. That might sound silly, but that's the package maintainers last word, ;). Just be glad it's not worse, :-p. Don't forget the BuildRequires in your spec file. -- Richi Plana From kevin.kofler at chello.at Thu Sep 13 16:53:28 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:53:28 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189701235.3157.490.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > As you can see the work-around to pkgconfig is close to being trivial. > configure OPENTHREADS_CFLAGS=' ' ... > is one half ... which is an ugly hack. What about a fix which would be acceptable for openalpp upstream? I'm pretty sure this one isn't! Using AC_CHECK_LIB instead might be. Kevin Kofler From myfedora at richip.dhs.org Thu Sep 13 16:57:24 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 13 Sep 2007 10:57:24 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: <1189702423.10318.103.camel@localhost6.localdomain6> References: <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <1189702423.10318.103.camel@localhost6.localdomain6> Message-ID: <1189702644.10318.106.camel@localhost6.localdomain6> Whoops ... race condition. Apparently fixed in upstream. All's well that ends well. Lessons learned and all that. On Thu, 2007-09-13 at 10:53 -0600, Richi Plana wrote: > On Thu, 2007-09-13 at 16:44 +0000, Kevin Kofler wrote: > > Nalin Dahyabhai redhat.com> writes: > > > Forgive me for wading in here, but upstream *has* to be where .pc files > > > show up, and if they don't show up there, we absolutely shouldn't be > > > adding them to binary packages. I believe this very strongly. > > > > But there are actually cases where .pc files are being added in Fedora > > packages, for reasons such as the upstream foo-config script not being > > multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper > > foo-config script which just calls pkgconfig). There are also other reasons for > > adding .pc files in the distribution. > > > > That said, I do think this point needs to be taken upstream. > > That's the point that Nalin is trying to make, :). > > Two things unanimously agreed on: > > 1) *.pc files are important because these contain the options that the > providing package would know and the dependent package developer > shouldn't guess. > 2) A mechanism for providing this (whether it's a *.pc file or something > else) should be provided by the package developer and that means > upstream. They should answer the question "How do I develop against your > packages?" > > Now, there are more immediate concerns like "What to do in the meantime > because certain packages are waiting?" That's where Ralf and Chris > should cooperate and Ralf begrudgingly (and quite sarcastically, I might > add ... It's a good thing I can see the humor in it sometimes ;) ) has > declared he will provide .. ahm ... OpenThreads-devel-dontuse and > OpenSceneGraph-devel-dontuse for people to, err, use. That might sound > silly, but that's the package maintainers last word, ;). Just be glad > it's not worse, :-p. > > Don't forget the BuildRequires in your spec file. > -- > > Richi Plana > > > From dwmw2 at infradead.org Thu Sep 13 16:59:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 18:59:18 +0200 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <46E95BB7.70104@leemhuis.info> <1189698883.3570.160.camel@shinybook.infradead.org> <20070913120251.6377415d.dcantrell@redhat.com> Message-ID: <1189702758.3241.1.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 12:13 -0400, Colin Walters wrote: > This entire thread was a perfect example. It isn't a question of whether or > not to enable IPv6; if we want IPv6, fix the bugs that adding it > introduces. Don't add options to enable it or disable it. There are occasionally valid reasons to disable it to work around real breakage. Sometimes I've known a DNS server on a hotel network just fail to respond at all to AAAA queries. They fixed it within a day or so of it being reported, but I did need a workaround in the meantime. But yes, this whole thread is noticeably short of bug numbers. -- dwmw2 From kevin.kofler at chello.at Thu Sep 13 16:59:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Sep 2007 16:59:38 +0000 (UTC) Subject: rawhide report: 20070912 changes References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189700750.3157.481.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > > What planet are you living on? Here on Earth, most software builds with > > just: > > ./configure > > make > > make install > This is an urban legend. No, it's not. > Most packages build with > %configure > make > make DESTDIR=... install > > If you have look into %configure you can observe what I say. Those flags configure the package for the defaults of Fedora. They aren't required to actually compile most software. Instead, they set distro-specific configuration such as optimization flags, security flags and some installation paths (such as the multilib libdir). Nowhere does %configure explicitly set SOMERANDOMBUILDREQUIRES_LIB or other package-specific flags. (That's why it's a common macro.) Kevin Kofler From dwmw2 at infradead.org Thu Sep 13 17:01:40 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Sep 2007 19:01:40 +0200 Subject: rpmlint file-not-utf8 In-Reply-To: <46E96640.9050808@redhat.com> References: <46E96640.9050808@redhat.com> Message-ID: <1189702900.3241.3.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 17:33 +0100, Richard W.M. Jones wrote: > The AUTHORS file is fair enough - I can use iconv to convert that to > UTF-8. However I'm concerned about the HTML files. These are > ISO-8859-1 files, and moreover they contain correct Content-Type > metadata to mark them as such so I can't see there is a problem with > these two files not being UTF-8. I don't think there's a _problem_ per se; but it's probably better to convert them anyway. -- dwmw2 From rc040203 at freenet.de Thu Sep 13 17:09:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 19:09:24 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189700750.3157.481.camel@mccallum.corsepiu.local> Message-ID: <1189703364.3157.499.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 16:59 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > > What planet are you living on? Here on Earth, most software builds with > > > just: > > > ./configure > > > make > > > make install > > This is an urban legend. > > No, it's not. > > > Most packages build with > > %configure > > make > > make DESTDIR=... install > > > > If you have look into %configure you can observe what I say. > > Those flags configure the package for the defaults of Fedora. They aren't > required to actually compile most software. Instead, they set distro-specific > configuration such as optimization flags, security flags and some installation > paths (such as the multilib libdir). Right, this is called "the art of packaging", and where the naughty details are lurking. Ralf From agostino.russo at gmail.com Thu Sep 13 17:10:15 2007 From: agostino.russo at gmail.com (Ago) Date: Thu, 13 Sep 2007 17:10:15 +0000 (UTC) Subject: ZyX Rebootless LiveOS Installer, was Re: Windows based installation of Fedora Linux? References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> <46E92685.1020002@filteredperception.org> <46E94CC4.50005@filteredperception.org> Message-ID: Douglas McClendon filteredperception.org> writes: > http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html > > http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html > > as of a couple days ago - (now with GUI and no patch to F7 required) > > http://gzyx.org (screenshots even- ooh! ahh!) Thanks looks very interesting, I'll pass it on to other ubuntu devs in case they missed that. I've always liked the idea to eliminate the last reboot, but never had time to look into that closely so far. From rc040203 at freenet.de Thu Sep 13 17:14:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Sep 2007 19:14:04 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189701235.3157.490.camel@mccallum.corsepiu.local> Message-ID: <1189703644.3157.505.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 16:53 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > As you can see the work-around to pkgconfig is close to being trivial. > > configure OPENTHREADS_CFLAGS=' ' ... > > is one half > > ... which is an ugly hack. What about a fix which would be acceptable for > openalpp upstream? The other fact Chris denys to accept: openalpp is dead and discontinued. > I'm pretty sure this one isn't! It even is documented: # openalpp-cvs-20060714]$ ./configure --help Some influential environment variables: ... OPENTHREADS_CFLAGS C compiler flags for OPENTHREADS, overriding pkg-config OPENTHREADS_LIBS linker flags for OPENTHREADS, overriding pkg-config Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Ralf From ville.skytta at iki.fi Thu Sep 13 17:18:04 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 13 Sep 2007 20:18:04 +0300 Subject: rpmlint file-not-utf8 In-Reply-To: <1189702900.3241.3.camel@shinybook.infradead.org> References: <46E96640.9050808@redhat.com> <1189702900.3241.3.camel@shinybook.infradead.org> Message-ID: <200709132018.05721.ville.skytta@iki.fi> On Thursday 13 September 2007, David Woodhouse wrote: > On Thu, 2007-09-13 at 17:33 +0100, Richard W.M. Jones wrote: > > The AUTHORS file is fair enough - I can use iconv to convert that to > > UTF-8. However I'm concerned about the HTML files. These are > > ISO-8859-1 files, and moreover they contain correct Content-Type > > metadata to mark them as such so I can't see there is a problem with > > these two files not being UTF-8. > > I don't think there's a _problem_ per se; but it's probably better to > convert them anyway. If you feel like it, why not. Be also sure to modify the meta http-equiv stuff to say UTF-8 if you do it (or use HTML entities to represent non-ASCII in which case I suppose you could also remove the meta tag). But quite honestly, I don't think it's a problem at all to leave them as is if the meta charset declaration is correct. In fact, I'm going to suppress this message (as well as the end-of-line char one) for HTML files in upstream rpmlint right now. From dmc.fedora at filteredperception.org Thu Sep 13 17:14:03 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 12:14:03 -0500 Subject: ZyX Rebootless LiveOS Installer, was Re: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> <46E92685.1020002@filteredperception.org> <46E94CC4.50005@filteredperception.org> Message-ID: <46E96FDB.1080306@filteredperception.org> Ago wrote: > Douglas McClendon filteredperception.org> writes: > >> http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html >> >> http://www.redhat.com/archives/rhl-devel-list/2007-July/msg00768.html >> >> as of a couple days ago - (now with GUI and no patch to F7 required) >> >> http://gzyx.org (screenshots even- ooh! ahh!) > > Thanks looks very interesting, I'll pass it on to other ubuntu devs in case > they missed that. I've always liked the idea to eliminate the last reboot, but > never had time to look into that closely so far. Actually, it wouldn't be that unreasonable an idea for ubuntu to create a devicemapper based 'spin' whose sole purpose would be for use with wubi. Honestly this is on my own personal todo list(until now, minus the 'for use with wubi' part)... But odds are I won't get around to it for quite some time. -dmc From lesmikesell at gmail.com Thu Sep 13 17:22:28 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 13 Sep 2007 12:22:28 -0500 Subject: rawhide report: 20070912 changes In-Reply-To: <1189703364.3157.499.camel@mccallum.corsepiu.local> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189700750.3157.481.camel@mccallum.corsepiu.local> <1189703364.3157.499.camel@mccallum.corsepiu.local> Message-ID: <46E971D4.3010401@gmail.com> Ralf Corsepius wrote: >>> >>> If you have look into %configure you can observe what I say. >> Those flags configure the package for the defaults of Fedora. They aren't >> required to actually compile most software. Instead, they set distro-specific >> configuration such as optimization flags, security flags and some installation >> paths (such as the multilib libdir). > Right, this is called "the art of packaging", and where the naughty details are lurking. Now _that_ is the problem that should be pushed "upstream". Make the distributions less incompatible and you wouldn't have to work around those problems in all of them. -- Les Mikesell lesmikesell at gmail.com From chris.stone at gmail.com Thu Sep 13 17:23:29 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 13 Sep 2007 10:23:29 -0700 Subject: rawhide report: 20070912 changes In-Reply-To: <1189703644.3157.505.camel@mccallum.corsepiu.local> References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189701235.3157.490.camel@mccallum.corsepiu.local> <1189703644.3157.505.camel@mccallum.corsepiu.local> Message-ID: On 9/13/07, Ralf Corsepius wrote: > On Thu, 2007-09-13 at 16:53 +0000, Kevin Kofler wrote: > > Ralf Corsepius freenet.de> writes: > > > As you can see the work-around to pkgconfig is close to being trivial. > > > configure OPENTHREADS_CFLAGS=' ' ... > > > is one half > > > > ... which is an ugly hack. What about a fix which would be acceptable for > > openalpp upstream? > > The other fact Chris denys to accept: openalpp is dead and discontinued. As I mentioned in the bug report, openalpp is being merged with osgal. I have been told that osgal is now working with osg2, and there should be a new release very soon now. We have also heard back from the OSG maintainer and he says "I have no problem with adding the packaging files" with regards to adding the pkgconfig files. We should have done this straight off, but we figured it was not much to ask you to just add them in the meantime. I'm sorry that you had to make up some fairy tale about OSG upstream not wanting to use pkgconfig files to help support your attitude and lack of cooperation. I will inform you with a bug report once the pkgconfig files have been added to OSG's CVS so that you may add them to Fedora's package. Thank you. From dmc.fedora at filteredperception.org Thu Sep 13 17:21:01 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 13 Sep 2007 12:21:01 -0500 Subject: ZyX Rebootless LiveOS Installer, was Re: Windows based installation of Fedora Linux? In-Reply-To: <46E96FDB.1080306@filteredperception.org> References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> <8278b1b0709130440x4ae2159bn872833dd4b9432c9@mail.gmail.com> <46E92685.1020002@filteredperception.org> <46E94CC4.50005@filteredperception.org> <46E96FDB.1080306@filteredperception.org> Message-ID: <46E9717D.5030507@filteredperception.org> Douglas McClendon wrote: > Ago wrote: > >> Thanks looks very interesting, I'll pass it on to other ubuntu devs in >> case they missed that. I've always liked the idea to eliminate the >> last reboot, but never had time to look into that closely so far. > > Actually, it wouldn't be that unreasonable an idea for ubuntu to create > a devicemapper based 'spin' whose sole purpose would be for use with wubi. > > Honestly this is on my own personal todo list(until now, minus the 'for > use with wubi' part)... But odds are I won't get around to it for quite > some time. PRE-EMPTIVE SELF FLAME - that reply should not have been posted to this list. Completely non-relevant to list. -dmc From nicolas.mailhot at laposte.net Thu Sep 13 17:31:06 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Sep 2007 19:31:06 +0200 Subject: rpmlint file-not-utf8 In-Reply-To: <200709132018.05721.ville.skytta@iki.fi> References: <46E96640.9050808@redhat.com> <1189702900.3241.3.camel@shinybook.infradead.org> <200709132018.05721.ville.skytta@iki.fi> Message-ID: <1189704666.3233.2.camel@rousalka.dyndns.org> Le jeudi 13 septembre 2007 ? 20:18 +0300, Ville Skytt? a ?crit : > But quite honestly, I don't think it's a problem at all to leave them as is if > the meta charset declaration is correct. In fact, I'm going to suppress this > message (as well as the end-of-line char one) for HTML files in upstream > rpmlint right now. I you were feeling evil, you'd have rpmlint rum tidy on (x)html files so problems are reported upstream. -- 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 johannbg at hi.is Thu Sep 13 17:32:21 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 17:32:21 +0000 Subject: Disable IPv6 by default. Message-ID: <46E97425.3080905@hi.is> Well i somehow manage to privately reply to David C. and thus our discussion went of topic and privately to each other.. Hence I'm throwing what went between us, back to the list to tear at, laugh at cry at, or to write on the marble tablets... My bad, my apologies... I guess I owe someone a beer :) Best regard Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 -------------- next part -------------- An embedded message was scrubbed... From: David Cantrell Subject: Re: Disable IPv6 by default. Date: Thu, 13 Sep 2007 13:14:48 -0400 Size: 14207 URL: From jamatos at fc.up.pt Thu Sep 13 17:35:05 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 13 Sep 2007 18:35:05 +0100 Subject: rpmlint file-not-utf8 In-Reply-To: <1189704666.3233.2.camel@rousalka.dyndns.org> References: <46E96640.9050808@redhat.com> <200709132018.05721.ville.skytta@iki.fi> <1189704666.3233.2.camel@rousalka.dyndns.org> Message-ID: <200709131835.05152.jamatos@fc.up.pt> On Thursday 13 September 2007 18:31:06 Nicolas Mailhot wrote: > I you were feeling evil, you'd have rpmlint rum tidy on (x)html files so > problems are reported upstream. Not only that but I remember to see html pages composed with latin1 and without the charset in metadata. So the warning has its uses. :-) FWIW tidy will complain as well in this case. :-) > -- > Nicolas Mailhot -- Jos? Ab?lio From rjones at redhat.com Thu Sep 13 17:35:14 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Sep 2007 18:35:14 +0100 Subject: rpmlint file-not-utf8 In-Reply-To: <1189704666.3233.2.camel@rousalka.dyndns.org> References: <46E96640.9050808@redhat.com> <1189702900.3241.3.camel@shinybook.infradead.org> <200709132018.05721.ville.skytta@iki.fi> <1189704666.3233.2.camel@rousalka.dyndns.org> Message-ID: <46E974D2.5090509@redhat.com> Nicolas Mailhot wrote: > Le jeudi 13 septembre 2007 ? 20:18 +0300, Ville Skytt? a ?crit : > >> But quite honestly, I don't think it's a problem at all to leave them as is if >> the meta charset declaration is correct. In fact, I'm going to suppress this >> message (as well as the end-of-line char one) for HTML files in upstream >> rpmlint right now. > > I you were feeling evil, you'd have rpmlint rum tidy on (x)html files so > problems are reported upstream. These files are actually generated from XML sources using cduce[1], so they are well-formed XHTML 1.0 strict already. Rich. [1] cduce is like XSLT, but without the crack. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Thu Sep 13 18:01:44 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 13 Sep 2007 21:01:44 +0300 Subject: rpmlint file-not-utf8 In-Reply-To: <200709131835.05152.jamatos@fc.up.pt> References: <46E96640.9050808@redhat.com> <1189704666.3233.2.camel@rousalka.dyndns.org> <200709131835.05152.jamatos@fc.up.pt> Message-ID: <200709132101.44453.ville.skytta@iki.fi> On Thursday 13 September 2007, Jos? Matos wrote: > On Thursday 13 September 2007 18:31:06 Nicolas Mailhot wrote: > > I you were feeling evil, you'd have rpmlint rum tidy on (x)html files so > > problems are reported upstream. Heh, actually doing a "tidy &>/dev/null" and whining if the exit status is not 0 could be nice :) > Not only that but I remember to see html pages composed with latin1 and > without the charset in metadata. So the warning has its uses. :-) Well, maybe, but an UTF-8 encoded HTML doc which lacks a declaration in which encoding it is will currently pass through rpmlint without warnings, and that's at least as bad as a ISO-8859-1 encoded HTML doc without it as far as HTML specs are concerned... From j.w.r.degoede at hhs.nl Thu Sep 13 18:03:59 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 13 Sep 2007 20:03:59 +0200 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <1189665570.9380.3.camel@rousalka.dyndns.org> <45669.192.54.193.51.1189671423.squirrel@rousalka.dyndns.org> Message-ID: <46E97B8F.3040209@hhs.nl> Kelly Miller wrote: > Is there a way for new packagers to get involved with RPM Fusion? I have a > set of packages that can't go into Fedora's main repository for various > reasons (emulators, non-free, etc.) and would be willing to maintain the > packages for them. > Hi, Yes new packagers are invited to join us, please subscribe to: http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion And introduce yourself there, the review procedure for rpmfusion will be just like the one for Fedora, except that we won't be using flags (we will probably be using blocker bugs but this still needs to be discussed). You can file review requests for any packages you have ready for review here: https://bugzilla.rpmfusion.org/ I just noticed that we currently don't have a package review component, I will ask the bugzilla admin to add one in the mean time just pick any component, we will reassign the bug to to a more appropriate component when that becomes available. Regards, Hans From ssorce at redhat.com Thu Sep 13 18:11:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 13 Sep 2007 14:11:05 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E968A1.8090603@BitWagon.com> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> Message-ID: <1189707065.18288.4.camel@localhost.localdomain> On Thu, 2007-09-13 at 09:43 -0700, John Reiser wrote: > > IPv6 service currently is not available to the vast majority of > residential DSL and cable customers in the US. Since when Fedora turned out to be a US-only distribution? Let me know, I may change my mind on a few things ... Simo. From fedora at leemhuis.info Thu Sep 13 18:17:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 13 Sep 2007 20:17:55 +0200 Subject: Announcing rpmfusion In-Reply-To: <46E97B8F.3040209@hhs.nl> References: <46E637DB.6060102@hhs.nl> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <1189606671.3567.5.camel@localhost.localdomain> <8278b1b0709121715t1918290bo87ce4ba53621d76c@mail.gmail.com> <1189665570.9380.3.camel@rousalka.dyndns.org> <45669.192.54.193.51.1189671423.squirrel@rousalka.dyndns.org> <46E97B8F.3040209@hhs.nl> Message-ID: <46E97ED3.8080102@leemhuis.info> On 13.09.2007 20:03, Hans de Goede wrote: > Kelly Miller wrote: >> Is there a way for new packagers to get involved with RPM Fusion? I have a >> set of packages that can't go into Fedora's main repository for various >> reasons (emulators, non-free, etc.) and would be willing to maintain the >> packages for them. > [...] > And introduce yourself there, the review procedure for rpmfusion will be just > like the one for Fedora, except that we won't be using flags (we will probably > be using blocker bugs but this still needs to be discussed). +1 for blocker bugs > You can file review requests for any packages you have ready for review here: > https://bugzilla.rpmfusion.org/ One note: before submitting packages please check if you package is in either freshrpms, dribble or livna already. If it is it's likely that the old maintainer will take care of it in rpmfusion as well (but maybe you can help as co-maintainer) > [...] CU knurd From johannbg at hi.is Thu Sep 13 18:19:20 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 13 Sep 2007 18:19:20 +0000 Subject: Disable IPv6 by default. In-Reply-To: <1189707065.18288.4.camel@localhost.localdomain> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> Message-ID: <46E97F28.1030002@hi.is> Simo Sorce wrote: > On Thu, 2007-09-13 at 09:43 -0700, John Reiser wrote: > >> IPv6 service currently is not available to the vast majority of >> residential DSL and cable customers in the US. >> > > Since when Fedora turned out to be a US-only distribution? > Let me know, I may change my mind on a few things ... > > Simo. > > "IPv6 service currently is not available to the vast majority of residential DSL and cable customers in the US." == "US-only distribution?" == ??? Me not compute!!! error error, logic error :) But then again that the Fedora/Redhat HQ based in US Does affect awful lot of ( Legal ) things.. Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From jreiser at BitWagon.com Thu Sep 13 18:35:30 2007 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 13 Sep 2007 11:35:30 -0700 Subject: Disable IPv6 by default. In-Reply-To: <1189707065.18288.4.camel@localhost.localdomain> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> Message-ID: <46E982F2.1030600@BitWagon.com> Simo Sorce wrote: > On Thu, 2007-09-13 at 09:43 -0700, John Reiser wrote: > >>IPv6 service currently is not available to the vast majority of >>residential DSL and cable customers in the US. > > > Since when Fedora turned out to be a US-only distribution? > Let me know, I may change my mind on a few things ... I didn't claim Fedora was US-only. I did point out a large group of Fedora users who have no effective access to IPv6. For such users, leaving IPv6 enabled is a security risk. Fedora should make it easy (perhaps even the default) to *propagate* "Disable IPv6" from the anaconda installer into the resulting installed system. -- From ssorce at redhat.com Thu Sep 13 18:41:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 13 Sep 2007 14:41:10 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E982F2.1030600@BitWagon.com> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: <1189708870.18288.9.camel@localhost.localdomain> On Thu, 2007-09-13 at 11:35 -0700, John Reiser wrote: > Simo Sorce wrote: > > On Thu, 2007-09-13 at 09:43 -0700, John Reiser wrote: > > > >>IPv6 service currently is not available to the vast majority of > >>residential DSL and cable customers in the US. > > > > > > Since when Fedora turned out to be a US-only distribution? > > Let me know, I may change my mind on a few things ... > > I didn't claim Fedora was US-only. I did point out a large group > of Fedora users who have no effective access to IPv6. For such > users, leaving IPv6 enabled is a security risk. Fedora should > make it easy (perhaps even the default) to *propagate* "Disable IPv6" > from the anaconda installer into the resulting installed system. On the anaconda propagate to install we may or may not agree, but you can't decide a group of people is more important then another. If US is back and can't keep up with technology, well too bad. Why should we punish people in other countries where IPv6 is starting becoming a reality? Remember that IPv6 will probably explode quite fast at some point, like any technology with important network effects do. We ought to be prepared. Simo. From ssorce at redhat.com Thu Sep 13 18:45:38 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 13 Sep 2007 14:45:38 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46E97F28.1030002@hi.is> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E97F28.1030002@hi.is> Message-ID: <1189709138.18288.15.camel@localhost.localdomain> On Thu, 2007-09-13 at 18:19 +0000, "J?hann B. Gu?mundsson" wrote: > "IPv6 service currently is not available to the vast majority of > residential DSL and cable customers in the US." > == > "US-only distribution?" > == ??? > > Me not compute!!! error error, logic error :) I know you see it, let's not pretend not to see what I meant. > But then again that the Fedora/Redhat HQ based in US > Does affect awful lot of ( Legal ) things.. Unfortunately this is an imposition from outside we can't do much about for now. But that's a completely different thing. I am worried about people that think that the only country that matters is the USA. The world is really bigger than that, and probably soon most users of free software (if not already which is probable) will be located outside of USA+Europe. Simo. From jima at beer.tclug.org Thu Sep 13 18:44:59 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 13 Sep 2007 13:44:59 -0500 (CDT) Subject: Disable IPv6 by default. In-Reply-To: <46E982F2.1030600@BitWagon.com> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: On Thu, 13 Sep 2007, John Reiser wrote: > Simo Sorce wrote: >> On Thu, 2007-09-13 at 09:43 -0700, John Reiser wrote: >> >>> IPv6 service currently is not available to the vast majority of >>> residential DSL and cable customers in the US. >> >> >> Since when Fedora turned out to be a US-only distribution? >> Let me know, I may change my mind on a few things ... > > I didn't claim Fedora was US-only. I did point out a large group > of Fedora users who have no effective access to IPv6. For such > users, leaving IPv6 enabled is a security risk. Fedora should > make it easy (perhaps even the default) to *propagate* "Disable IPv6" > from the anaconda installer into the resulting installed system. That's an incomplete argument; even people in the US can get tunnelled IPv6 access via various tunnel brokers. What's so scary about IPv6, anyway? Anything that justifies blowing off all the efforts many people have made at maturing the standard? Jima From cmadams at hiwaay.net Thu Sep 13 19:12:54 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 13 Sep 2007 14:12:54 -0500 Subject: Disable IPv6 by default. In-Reply-To: <1189708870.18288.9.camel@localhost.localdomain> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> <1189708870.18288.9.camel@localhost.localdomain> Message-ID: <20070913191253.GF1410972@hiwaay.net> Once upon a time, Simo Sorce said: > Remember that IPv6 will probably explode quite fast at some point, like > any technology with important network effects do. We ought to be > prepared. My main problem is that I configure IPv4 and I explicitly have IPv6 turned off (or so it appears in the interface), yet I still have IPv6 loaded and used. This causes annoying warnings from programs trying to use an unconfigured IPv6 interface. If I don't configure IPv4, the interface isn't configured; why is it that way with IPv6? If I don't configure anything for IPv6, it is still loaded. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From opensource at till.name Thu Sep 13 19:42:57 2007 From: opensource at till.name (Till Maas) Date: Thu, 13 Sep 2007 21:42:57 +0200 Subject: Disable IPv6 by default. In-Reply-To: <200709131012.18983.dennis@ausil.us> References: <46E9447E.9080105@hi.is> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> Message-ID: <200709132143.02536.opensource@till.name> On Do September 13 2007, Dennis Gilmore wrote: > Please provide proof of your claims. where is the security risk? Johann. > why exactly do you want ipv6 disabled? The problem are setups that use a custom iptables configuration but not ip6tables. I guess not enough people know, that they should also configure ip6tables or disable ipv6. Btw. according to the documentation the correct syntax to disable ipv6 ist to add | IPV6INIT=no to /etc/sysconfig/network But this does not work reliable for me on FC6, Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Thu Sep 13 19:49:28 2007 From: opensource at till.name (Till Maas) Date: Thu, 13 Sep 2007 21:49:28 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46E94BD2.5080506@BitWagon.com> References: <46E9447E.9080105@hi.is> <200709130923.47235.dennis@ausil.us> <46E94BD2.5080506@BitWagon.com> Message-ID: <200709132149.28750.opensource@till.name> On Do September 13 2007, John Reiser wrote: > Just publicize the easy OFF switch: > ----- /etc/modprobe.conf > alias net-pf-10 off > ----- On FC6 this is more obvious and works, too: | alias ipv6 off Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Thu Sep 13 19:54:04 2007 From: opensource at till.name (Till Maas) Date: Thu, 13 Sep 2007 21:54:04 +0200 Subject: Disable IPv6 by default. In-Reply-To: <200709132149.28750.opensource@till.name> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <200709132149.28750.opensource@till.name> Message-ID: <200709132154.04713.opensource@till.name> On Do September 13 2007, Till Maas wrote: > On FC6 this is more obvious and works, too: > | alias ipv6 off Hm, it does not work. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From johannbg at hi.is Thu Sep 13 20:03:49 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Thu, 13 Sep 2007 20:03:49 -0000 (GMT) Subject: Disable IPv6 by default. In-Reply-To: <1189709138.18288.15.camel@localhost.localdomain> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E97F28.1030002@hi.is> <1189709138.18288.15.camel@localhost.localdomain> Message-ID: <20731.88.149.97.225.1189713829.squirrel@webmail.hi.is> > On Thu, 2007-09-13 at 18:19 +0000, "J??hann B. Gu??mundsson" wrote: >> "IPv6 service currently is not available to the vast majority of >> residential DSL and cable customers in the US." >> == >> "US-only distribution?" >> == ??? >> >> Me not compute!!! error error, logic error :) > > I know you see it, let's not pretend not to see what I meant. > >> But then again that the Fedora/Redhat HQ based in US >> Does affect awful lot of ( Legal ) things.. > > Unfortunately this is an imposition from outside we can't do much about > for now. But that's a completely different thing. I am worried about > people that think that the only country that matters is the USA. The > world is really bigger than that, and probably soon most users of free > software (if not already which is probable) will be located outside of > USA+Europe. > > Simo. Be it as it may which continent will use most of the GNU/Linux hopefully GNU/Linux will be ruling the world in the near future :).. But the questions are. Should we or should we not disable IPv6 during installation/Anaconda Should we or should we not allow the user to decide during installation ( Anaconda or after installation S-C-N. * Default left as is support both * User can choose whether he wants to use either IPv6 or IPv4 * If users decides to choose either one the other one is properly turned off! * If user choose either one and service explicitly depend on either one the system could notify the user like.. Service A could not be started because it relies on IPv6 and IPv6 is currently disabled! To use this service ( service A ) please enabled it in system-config-network and then restart the service ( Service A ) If we decided not to allow the user to choose, were are we gonna draw the line on how *smarter* then the user is the system is supposed to be??? Look at M$ it takes all the intellect user decisions for the users and then questions everything else the user does ( are you sure you want to do this and that )!!!! When user is given option to turn something on ( enable/disable/start/stop ) the "program" is started and everything that relies on it as well or on demand and when that "program" is stopped then it and everything related stop programs should be notified and that option in them should be turned off so they can stop waiting and wondering if they receiving instruction regarding something that has been turned off. If not were just waisting resources... Best regards Johann B. From opensource at till.name Thu Sep 13 20:09:04 2007 From: opensource at till.name (Till Maas) Date: Thu, 13 Sep 2007 22:09:04 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189698714.3570.158.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <1189695196.10318.19.camel@localhost6.localdomain6> <1189698714.3570.158.camel@shinybook.infradead.org> Message-ID: <200709132209.08839.opensource@till.name> On Do September 13 2007, David Woodhouse wrote: > It _is_ one step: > > echo blacklist ipv6 > /etc/modprobe.d/luddite I did this on an FC6 machine and it still used ipv6. :-( Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Thu Sep 13 20:12:44 2007 From: opensource at till.name (Till Maas) Date: Thu, 13 Sep 2007 22:12:44 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070913103042.86853409.dcantrell@redhat.com> References: <46E9447E.9080105@hi.is> <20070913103042.86853409.dcantrell@redhat.com> Message-ID: <200709132212.44798.opensource@till.name> On Do September 13 2007, David Cantrell wrote: > and the system should work fine even if you are only using IPv4. And it > doesn't now, so other than wanting to remove some lines from ifconfig(8) > output or remove some boot up scripts, why do you want it disabled by > default? It circumenvents iptables rules. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jreiser at BitWagon.com Thu Sep 13 20:32:05 2007 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 13 Sep 2007 13:32:05 -0700 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: <46E99E45.2050208@BitWagon.com> > What's so scary about IPv6, anyway? 0) There exists > $1.0e10 of routers and switches that do not grok IPv6. Replacing or enhancing them will cost about that much more. 1) Many ISPs charge more for service via IPv6 than via IPv4. In some large markets in the US, every DSL and cable ISP either charges more, or does not offer IPv6 at all. 2) Most default configurations of IPv6, including Fedora, are about as unfriendly as possible towards inexpensive anonymity. (The default MAC address is part of the IPv6 address, etc.) Most environments, including Fedora, provide no ready means to ameliorate the increased risks. > Anything that justifies blowing > off all the efforts many people have made at maturing the standard? http://cr.yp.to/djbdns/ipv6mess.html and there has been little or no progress for a *decade*. [Executive summary: there is no reasonable transition plan. There cannot be any such plan because of the design of IPv6.] -- From benny+usenet at amorsen.dk Thu Sep 13 20:32:30 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 13 Sep 2007 22:32:30 +0200 Subject: Disable IPv6 by default. References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <5256d0b0709130951s7eae9408w9e1329161c2efa59@mail.gmail.com> Message-ID: >>>>> "PR" == Peter Robinson writes: PR> Also all corporate level hardware supports IPv6 out of the box, or PR> has had firmwares available to support it for years. Those firmwares sometimes costing more than the hardware cost originally, unfortunately. Though there's probably only one vendor who does something so silly, it's a very very important vendor. /Benny From mccann at jhu.edu Thu Sep 13 20:41:46 2007 From: mccann at jhu.edu (William Jon McCann) Date: Thu, 13 Sep 2007 16:41:46 -0400 Subject: Possible account information APIs? (lookupd etc) Message-ID: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> Hi, For some aspects of fast-user-switching and face browsing it would be useful to be able to: 1. Query / store user photos (avatars) 2. Query user account status in an implementation/backend independent way (locked, expired etc) 3. Query the user's real world name etc (ie. not just gecos) 4. Receive user added / removed notifications 5. Receive user property changed notifications (picture / real name / etc changed) 6. etc As far as I can tell these things are either very difficult to do cleanly with traditional Posix APIs and in-band with NSS modules or not possible at all. Though I'd love to be proven wrong. I ran across something that looks somewhat interesting. http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/lookupd.8.html http://docs.info.apple.com/article.html?artnum=30770 http://aplawrence.com/MacOSX/macosxlookupd.html Darwin seems (at least from these docs) to use lookupd for some of this. Anyone have any experience with lookupd specifically? Or pointers to different solutions? Thanks, Jon From notting at redhat.com Thu Sep 13 20:45:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 13 Sep 2007 16:45:32 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> Message-ID: <20070913204532.GA29167@nostromo.devel.redhat.com> William Jon McCann (mccann at jhu.edu) said: > 1. Query / store user photos (avatars) > 2. Query user account status in an implementation/backend independent > way (locked, expired etc) > 3. Query the user's real world name etc (ie. not just gecos) By this, you mean more than just the name in gecos? > Darwin seems (at least from these docs) to use lookupd for some of this. > > Anyone have any experience with lookupd specifically? Or pointers to > different solutions? First, is there even any standard for storing any of this extended account information? Bill From buildsys at redhat.com Thu Sep 13 20:55:53 2007 From: buildsys at redhat.com (Build System) Date: Thu, 13 Sep 2007 16:55:53 -0400 Subject: rawhide report: 20070913 changes Message-ID: <200709132055.l8DKtrt9004303@porkchop.devel.redhat.com> New package animorph 3D Animation and Morph Library New package micq Text/line based ICQ client with many features New package perl-Geo-IP Efficient Perl bindings for the GeoIP location database New package slingshot A Newtonian strategy game Removed package netpanzer-data Removed package gkrellm-hddtemp Removed package ufsparse Updated Packages: apr-api-docs-1.2.11-1.fc8 ------------------------- * Tue Sep 11 2007 Bojan Smojver 1.2.11-1 - Align with latest apr/apr-util bluez-libs-3.18-1.fc8 --------------------- * Wed Sep 12 2007 David Woodhouse - 3.18-1 - Update to bluez-libs 3.18 bluez-utils-3.18-1.fc8 ---------------------- * Wed Sep 12 2007 David Woodhouse 3.18-1 - Update to bluez-utils 3.18 byacc-1.9.20050813-2.fc8 ------------------------ * Wed Sep 12 2007 Matthias Saou 1.9.20050813-2 - Update summary. - Remove useless doc copying in install section. - Add NOTES and NO_WARRANTY docs. cadaver-0.23.0-2 ---------------- * Fri Sep 07 2007 Joe Orton 0.23.0-2 - spec file cleanup (#225634) deluge-0.5.5-1.fc8 ------------------ * Wed Sep 12 2007 Peter Gordon - 0.5.5 - Update to new upstream release (0.5.5) enigma-1.01-3.1 --------------- * Wed Sep 12 2007 Thorsten Leemhuis - 1.01-3.1 - use the newly 64bit-clean upstream tarball evolution-webcal-2.11.91-1.fc8 ------------------------------ * Fri Aug 31 2007 Matthew Barnes - 2.11.91-1.fc8 - Update to 2.11.91 flac-1.2.0-3.fc8 ---------------- * Wed Sep 12 2007 - Bastien Nocera - 1.2.0-3 - Make a few functions hidden, to try and avoid textrels - Disable optimisations on x86 for the same reason (#285961) gdm-1:2.19.8-4.fc8 ------------------ * Wed Sep 12 2007 Ray Strode - 1:2.19.8-4 - Change default password character back to circle instead of asterisk (bug 287951) gettext-0.16.1-10.fc8 --------------------- * Wed Sep 12 2007 Jens Petersen - 0.16.1-10 - buildrequire expat-devel - add gettext-xglade-include-expat-285701.patch to include expat.h to get xgettext to dl the right libexpat (Nils Philippsen, #285701) * Thu Aug 16 2007 Jens Petersen - specify license is GPL and LGPL version 2 or later gkrellm-freq-1.0-7.fc8 ---------------------- * Wed Sep 12 2007 Matthias Saou 1.0-7 - Fix License field, it's actually GPL+ which is okay for GPLv3 gkrellm. glom-1.6.0-1.fc8 ---------------- * Wed Sep 12 2007 Denis Leroy - 1.6.0-1 - Update to 1.6.0, updated BRs gnome-vfs2-2.19.91-2.fc8 ------------------------ * Wed Sep 12 2007 Matthias Clasen - 2.19.91-2 - Fix a small memory leak kdepim-6:3.5.7-8.fc8 -------------------- * Wed Sep 12 2007 Rex Dieter - 6:3.5.7-8 - drop OnlyShowIn=KDE munging - update %description - tidy up kdesdk-3.5.7-10.fc8 ------------------- * Wed Sep 12 2007 Rex Dieter - 3.5.7-10 - update %description to mention included apps - move manpages to main pkg. - Provides: cervisia umbrello - kbugbuster kuiviewer: drop --add-only-show-in KDE - kioslave/svn: --with-subversion, patch kernel-2.6.23-0.178.rc6.git2.fc8 -------------------------------- * Wed Sep 12 2007 Chuck Ebbert - Linux 2.6.23-rc6-git2 * Wed Sep 12 2007 Chuck Ebbert - Linux 2.6.23-rc6-git1 * Wed Sep 12 2007 Chuck Ebbert - better debug message for SSB driver - acpi: fix EC initialization (from linux-acpi.git) kernel-xen-2.6-2.6.21-2937.fc8 ------------------------------ * Wed Sep 12 2007 Eduardo Habkost - Disable CONFIG_HIGHPTE. It is not reliable and cause performance loss under Xen. kmenu-gnome-0.6.8-2.fc8 ----------------------- * Wed Sep 12 2007 Chitlesh Goorah - 0.6.8-2 - new upstream release * Wed Sep 12 2007 Ariszlo - 0.6.8-1 - release 0.6.8 - Added include categories to fc5-hide-bug196275.menu - Added remove-system-administration.patch ktechlab-0.3.69-5.fc8 --------------------- * Sat Sep 08 2007 Chitlesh Goorah - 0.3.69-5 - updated desktop file - fixed missing icon of bar graph display - disable rough oscilloscope * Sat Aug 18 2007 Chitlesh Goorah - 0.3.69-4.20070626svn - fixed conflict with alliance and changed license * Mon Aug 13 2007 Chitlesh Goorah - 0.3.69-3.20070626svn - added sdcc to path libbonobo-2.19.6-6.fc8 ---------------------- * Wed Sep 12 2007 Matthias Clasen - 2.19.6-6 - Plug a memory leak in bonobo-activation-server * Wed Sep 12 2007 Matthias Clasen - 2.19.6-5 - Plug a memory leak in bonobo-activation-server libdv-1.0.0-3.fc8 ----------------- * Wed Sep 12 2007 Jarod Wilson 1.0.0-3 - A few more fixes from Matthias Saou: - List man pages in %files consistently w/o gz extension - Add BR: popt-devel for f8+, its now split fromm rpm-devel * Wed Sep 12 2007 Jarod Wilson 1.0.0-2 - Update License field (Matthias Saou) - Remove useless zero epoch (Matthias Saou) - Add pkgconfig devel sub-package req (Matthias Saou) - Minor spec formatting changes and clean-ups * Fri Jan 19 2007 Jarod Wilson 1.0.0-1 - New upstream release - PIC patch from Mike Frysinger (#146596) - Re-enable asm on i386 liberation-fonts-0.2-3.fc8 -------------------------- * Wed Sep 12 2007 Jens Petersen - 0.2-3.fc8 - add fontdir macro - create fonts.dir and fonts.scale (reported by Mark Alford, #245961) - add catalogue symlink * Wed Sep 12 2007 Jens Petersen - 0.2-2.fc8 - update license field to GPLv2 libgdamm-2.9.8-1.fc8 -------------------- * Wed Sep 12 2007 Denis Leroy - 2.9.8-1 - Update to 2.9.8, a bugfix release libselinux-2.0.33-1.fc8 ----------------------- * Thu Sep 13 2007 Dan Walsh - 2.0.33-1 - Upgrade to latest from NSA * Re-map a getxattr return value of 0 to a getfilecon return value of -1 with errno EOPNOTSUPP from Stephen Smalley. * Fall back to the compat code for security_class_to_string and security_av_perm_to_string from Stephen Smalley. * Fix swig binding for rpm_execcon from James Athey. libsemanage-2.0.6-1.fc8 ----------------------- * Thu Sep 13 2007 Dan Walsh - 2.0.6-1 - Upgrade to latest from NSA * Change to use getpw* function calls to the _r versions from Todd Miller. mediawiki-1.10.2-36.fc8 ----------------------- * Wed Sep 12 2007 Ville Skytt?? - 1.10.2-36 - Update to 1.10.2 (security; http://secunia.com/advisories/26772/, #287881) mksh-31c-1.fc8 -------------- * Wed Sep 12 2007 Robert Scheck 31c-1 - Upgrade to 31c - Added a buildrequirement to ed, added arc4random.c file mod_security-2.1.3-1.fc8 ------------------------ * Thu Sep 13 2007 Michael Fleming 2.1.3-1 - Update to 2.1.3 - Update License tag per guidelines. msv-1:1.2-0.1.20050722.3jpp.3.fc8 --------------------------------- * Wed Sep 12 2007 Matt Wringe 0:1,2-0.1.20050722.3jpp.3 - Make package build with new gcj. Remove .class files from demo package and remove demo exclude from aot-compile-rpm * Tue Sep 11 2007 Matt Wringe 0:1.2-0.1.20050722.3jpp.2 - Fix unowned directories - Change copyright files to utf-8 format - Change license field to BSD (from BSD-Style) openoffice.org-1:2.3.0-4.1.fc8 ------------------------------ * Thu Sep 06 2007 Caolan McNamara - 1:2.3.0-4.1 - next version - ooo#77672 fix ::boost::spirit::parse to use ::boost::spirit::end_p to make drawing shapes work properly again with new boost 1.34 - add openoffice.org-2.3.0.ooo81321.cppu.silencewarnings.patch - add openoffice.org-2.3.0.ooo81323.svtools.sixtyfour.patch - disable custom launchers, it breaks icedtea for some reason I haven't time to figure out - disable visibility for now, seems screwed up. * Tue Sep 04 2007 Caolan McNamara - 1:2.3.0-3.2 - rebuild against icu - rebuild against icedtea - add openoffice.org-2.3.0.ooo74751.bean.mawt.patch to allow build against icedtea - don't prefer gcj over icedtea when both installed - add ooo#81253 connectivity uninit fix - add ooo#81258 sw uninit fix - package sandbox.jar where available * Sat Sep 01 2007 Caolan McNamara - 1:2.3.0-3.1 - release candidate - drop integrated openoffice.org-1.9.130.ooo67740.doublefree.xmlhelp.patch - drop integrated openoffice.org-2.2.0.ooo75790.sc.pa-IN.translate.patch - drop integrated openoffice.org-2.3.0.ooo80944.sd.sixtyfour.patch - drop integrated workspace.dba23e.patch - drop integrated openoffice.org-2.3.0.ooo80931.sysui.genericname.patch pan-1:0.132-2.fc8 ----------------- * Thu Sep 13 2007 Alexander Dalloz - 1:0.132-2 - Add patch for BZ #283241 (upstream #467446) pirut-1.3.18-1.fc8 ------------------ * Wed Sep 12 2007 Jeremy Katz - 1.3.18-1 - Add multiple selection in package view (#266141) - Make things like rpmnew/rpmsave more obvious to the user rather than hidden (#229671) - Use yum's transaction callback mechanism - Show details on package list (#227362) - Follow icon naming standard (#208698) - Improve display of what's being downloaded with progress bar (#284301) - Fix applying updates from puplet (#268141) policycoreutils-2.0.25-13.fc8 ----------------------------- * Thu Sep 13 2007 Dan Walsh 2.0.25-13 - Upgrade version of sepolgen from NSA * Expand the sepolgen parser to parse all current refpolicy modules from Karl MacMillan. * Suppress generation of rules for non-denials from Karl MacMillan (take 3). procps-3.2.7-17.fc8 ------------------- * Wed Sep 12 2007 Tomas Smetana 3.2.7-17 - fix #185994 - top "Cpu0" line never updates when using "Single Cpu = Off" option on single processor machine pykickstart-1.13-1.fc8 ---------------------- * Wed Sep 12 2007 Chris Lumens 1.13-1 - Add a function to convert URL method strings into repo objects (jkeating). - Writer formatting fixes. - Add kickstart documentation from the Fedora Wiki. python-GeoIP-1.2.1-9.fc8 ------------------------ * Thu Sep 13 2007 Michael Fleming 1.2.1-9 - Add patch to expose country codes courtesy of Ignacio Vazquez-Adams (bz #243696) - Update License tag per new guidelines - Fix requires per python packaging guidelines. python-vorbis-1.5-0.2.a ----------------------- * Wed Sep 12 2007 Matthias Saou 1.5-0.2.a - Update to 1.5a pre-release. - Include patch to fix crash with python 2.5 (#285341). rarian-0.6.0-1.fc8 ------------------ * Wed Sep 12 2007 Matthew Barnes - 0.6.0-1 - Update to 0.6.0 - Remove patch for RH bug #254301 (fixed upstream). re2c-0.12.3-1.fc8 ----------------- * Thu Sep 13 2007 Matthias Saou 0.12.3-1 - Update to 0.12.3. scim-1.4.7-3.fc8 ---------------- * Thu Sep 13 2007 Jens Petersen - 1.4.7-3 - add scim-1.4.7-ja-sinhala-236715.patch to add Japanese translation of Sinhala (#236715) - gtk2 now owns /usr/lib/gtk-2.0/immodules - add Nepali meta package - specify full paths in xinput script and use SHORT_DESC * Fri Aug 17 2007 Jens Petersen - 1.4.7-2 - update License field - modify xinput.d script to not startup scim if no IMEs are installed - devel package requires pkgconfig - improve meta package macro language in summary and description - subpackage rawcode engine - update meta packages for m17n-contrib - move ownership of libdir dirs to main package * Wed Jun 27 2007 Jens Petersen - 1.4.7-1 - update to 1.4.7 release system-config-firewall-1.0.6-1.fc8 ---------------------------------- * Wed Sep 12 2007 Thomas Woerner 1.0.6-1 - dropped --stop option from fw_gui::genArgs - new translations - sysctl support for masquerading (net.ipv4.ip_forward will be set) - glade file: fixed spacings, dropped not needed containers transmission-0.82-1.fc8 ----------------------- * Wed Sep 12 2007 Denis Leroy - 0.82-1 - Update to upstream 0.82, many bug fixes - Added patch to support default user download directory (Bastien Nocera) yum-3.2.5-2.fc8 --------------- * Wed Sep 12 2007 Jeremy Katz - 3.2.5-2 - add upstream patch to improve RPMTransaction display yum-updatesd-1:0.5-2.fc8 ------------------------ * Wed Sep 12 2007 Jeremy Katz - 1:0.5-2 - require the yum-refresh-updatesd plugin so that we get kicked after installs Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From ottohaliburton at tx.rr.com Thu Sep 13 21:09:45 2007 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 13 Sep 2007 16:09:45 -0500 Subject: Disable IPv6 by default. In-Reply-To: Message-ID: <00cc01c7f64a$6972ea20$0301a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Benny Amorsen > Sent: Thursday, September 13, 2007 3:33 PM > To: fedora-devel-list at redhat.com > Subject: Re: Disable IPv6 by default. > > >>>>> "PR" == Peter Robinson writes: > > PR> Also all corporate level hardware supports IPv6 out of the box, or > PR> has had firmwares available to support it for years. > > Those firmwares sometimes costing more than the hardware cost > originally, unfortunately. Though there's probably only one vendor who > does something so silly, it's a very very important vendor. > > > /Benny > I'm very late on this thread and really probably missing something, but I think that ipv6 is disabled by default and that in order to select it you need to go to /etc/sysconfig/network-script/ and edit ifcfg-ethx (or whatever) to turn it on. From mccann at jhu.edu Thu Sep 13 21:29:58 2007 From: mccann at jhu.edu (William Jon McCann) Date: Thu, 13 Sep 2007 17:29:58 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <20070913204532.GA29167@nostromo.devel.redhat.com> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> Message-ID: <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> Hi Bill, On 9/13/07, Bill Nottingham wrote: > William Jon McCann (mccann at jhu.edu) said: > > 1. Query / store user photos (avatars) > > 2. Query user account status in an implementation/backend independent > > way (locked, expired etc) > > 3. Query the user's real world name etc (ie. not just gecos) > > By this, you mean more than just the name in gecos? Ideally, yes. > > Darwin seems (at least from these docs) to use lookupd for some of this. > > > > Anyone have any experience with lookupd specifically? Or pointers to > > different solutions? > > First, is there even any standard for storing any of this extended account > information? There are various I guess. For example, for an LDAP agent: http://tools.ietf.org/html/rfc2798#section-2.6 This would be a reasonable standard to use and most likely a superset of any existing functionality. Jon From bloch at verdurin.com Thu Sep 13 21:57:34 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Thu, 13 Sep 2007 22:57:34 +0100 (BST) Subject: Volume control problems In-Reply-To: <1189684732.2635.2.camel@scrappy.miketc.com> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> <20070912221924.GA20538@tango.0pointer.de> <1189656884.4095.6.camel@scrappy.miketc.com> <1189660132.21101.2.camel@jndwidescreen.lesbg.loc> <1189684732.2635.2.camel@scrappy.miketc.com> Message-ID: <61987.87.194.100.54.1189720654.squirrel@webmail.cream.org> > On Thu, 2007-09-13 at 08:08 +0300, Jonathan Dieter wrote: > >> I ran into this error message setting up pulseaudio on an F7 system when >> I was trying to run the pulseaudio daemon system-wide. In my case, it >> was because /dev/snd/* wasn't readable by the daemon (which runs under >> the user "pulse" when running in system-wide mode). Not sure if this >> might be your problem. > > root is owner/group of that path, so not sure what pulse is running > under or if that is the problem. > I have what seems to be a fairly similar problem, listed in https://bugzilla.redhat.com/show_bug.cgi?id=290151 From bojan at rexursive.com Thu Sep 13 22:07:41 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 14 Sep 2007 08:07:41 +1000 Subject: Kernel updates for F7 Message-ID: <1189721261.2983.4.camel@shrek.rexursive.com> Today we got 2.6.22.5 kernel update to F7, although 2.6.22.6 was available for some time and initial build of it (i.e. rc1 of it) was already done in koji (http://koji.fedoraproject.org/koji/buildinfo?buildID=17377). Was there are reason for not going with .6? Will users eventually get that and then have to reboot again? -- Bojan From dwmw2 at infradead.org Thu Sep 13 22:26:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Sep 2007 00:26:39 +0200 Subject: rpmlint file-not-utf8 In-Reply-To: <200709131835.05152.jamatos@fc.up.pt> References: <46E96640.9050808@redhat.com> <200709132018.05721.ville.skytta@iki.fi> <1189704666.3233.2.camel@rousalka.dyndns.org> <200709131835.05152.jamatos@fc.up.pt> Message-ID: <1189722399.3241.7.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 18:35 +0100, Jos? Matos wrote: > Not only that but I remember to see html pages composed with latin1 > and without the charset in metadata. So the warning has its uses. :-) Well... doesn't HTTP default to ISO8859-1 unless the charset is otherwise specified? -- dwmw2 From orion at cora.nwra.com Thu Sep 13 22:31:26 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 13 Sep 2007 16:31:26 -0600 Subject: anaconda/yum depsolving speed Message-ID: <46E9BA3E.8030705@cora.nwra.com> I just kicked off a rawhide install and was amazed at how much faster it went through the depsolving stage. Kudos to all involved. Is this anaconda specific, or a general yum feature? -- 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 dwmw2 at infradead.org Thu Sep 13 22:38:04 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Sep 2007 00:38:04 +0200 Subject: Disable IPv6 by default. In-Reply-To: <200709132212.44798.opensource@till.name> References: <46E9447E.9080105@hi.is> <20070913103042.86853409.dcantrell@redhat.com> <200709132212.44798.opensource@till.name> Message-ID: <1189723084.3241.10.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 22:12 +0200, Till Maas wrote: > It circumenvents iptables rules. IPv6 doesn't 'circumvent' iptables rules any more than IPv4 'circumvents' ip6tables rules. Besides, http://www.advogato.org/person/dwmw2/diary/164.html -- dwmw2 From dwmw2 at infradead.org Thu Sep 13 22:40:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Sep 2007 00:40:03 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46E982F2.1030600@BitWagon.com> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: <1189723203.3241.12.camel@shinybook.infradead.org> On Thu, 2007-09-13 at 11:35 -0700, John Reiser wrote: > > I didn't claim Fedora was US-only. I did point out a large group > of Fedora users who have no effective access to IPv6. Crap. Proper IPv6 access is trivial to set up, even if your ISP sucks. -- dwmw2 From cra at WPI.EDU Thu Sep 13 22:41:54 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 13 Sep 2007 18:41:54 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189723084.3241.10.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913103042.86853409.dcantrell@redhat.com> <200709132212.44798.opensource@till.name> <1189723084.3241.10.camel@shinybook.infradead.org> Message-ID: <20070913224154.GT6066@angus.ind.WPI.EDU> On Fri, Sep 14, 2007 at 12:38:04AM +0200, David Woodhouse wrote: > On Thu, 2007-09-13 at 22:12 +0200, Till Maas wrote: > > It circumenvents iptables rules. > > IPv6 doesn't 'circumvent' iptables rules any more than IPv4 > 'circumvents' ip6tables rules. > > Besides, http://www.advogato.org/person/dwmw2/diary/164.html +1. Firewalls just break connectivity and are a handicap that enables people to be lazy about system security. And don't get me started on NAT :-) From Matt_Domsch at dell.com Thu Sep 13 23:02:14 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 13 Sep 2007 18:02:14 -0500 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: <20070913230214.GA6046@auslistsprd01.us.dell.com> On Thu, Sep 13, 2007 at 01:44:59PM -0500, Jima wrote: > That's an incomplete argument; even people in the US can get tunnelled > IPv6 access via various tunnel brokers. > What's so scary about IPv6, anyway? Anything that justifies blowing off > all the efforts many people have made at maturing the standard? Set up an account at http://noc.sixxs.net/, then # yum install aiccu edit /etc/aiccu.conf with your SixXS info, and: # /sbin/service aiccu start Voila, IPv6. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jspaleta at gmail.com Thu Sep 13 23:04:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Sep 2007 15:04:16 -0800 Subject: Disable IPv6 by default. In-Reply-To: <364d303b0709130724i61467105v7d7e74a7a6041914@mail.gmail.com> References: <46E9447E.9080105@hi.is> <364d303b0709130724i61467105v7d7e74a7a6041914@mail.gmail.com> Message-ID: <604aa7910709131604x6db793dbpfccea7bef8ec1e96@mail.gmail.com> On 9/13/07, Christopher Brown wrote: > Hell, let's just stop progress altogether. We've landed on the moon after > all. There's nothing left to do is there? You believed we landed on the moon? C'mon man don't believe the propaganda! -jef"that's no moon...."spaleta From mclasen at redhat.com Thu Sep 13 23:15:30 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 13 Sep 2007 19:15:30 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> Message-ID: <1189725330.4468.6.camel@localhost.localdomain> On Thu, 2007-09-13 at 17:29 -0400, William Jon McCann wrote: > Hi Bill, > > On 9/13/07, Bill Nottingham wrote: > > William Jon McCann (mccann at jhu.edu) said: > > > 1. Query / store user photos (avatars) > > > 2. Query user account status in an implementation/backend independent > > > way (locked, expired etc) > > > 3. Query the user's real world name etc (ie. not just gecos) > > > > By this, you mean more than just the name in gecos? > > Ideally, yes. > > > > Darwin seems (at least from these docs) to use lookupd for some of this. > > > > > > Anyone have any experience with lookupd specifically? Or pointers to > > > different solutions? > > > > First, is there even any standard for storing any of this extended account > > information? > > There are various I guess. For example, for an LDAP agent: > http://tools.ietf.org/html/rfc2798#section-2.6 > > This would be a reasonable standard to use and most likely a superset > of any existing functionality. Looks like it is a bit lighter on the various "contact ids" than what e.g. e-d-s stores (jabber, msn, aim, etc). But I grant you that the "license plate" field is pretty unique... From katzj at redhat.com Thu Sep 13 23:30:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Sep 2007 19:30:35 -0400 Subject: anaconda/yum depsolving speed In-Reply-To: <46E9BA3E.8030705@cora.nwra.com> References: <46E9BA3E.8030705@cora.nwra.com> Message-ID: <1189726235.14591.0.camel@localhost.localdomain> On Thu, 2007-09-13 at 16:31 -0600, Orion Poplawski wrote: > I just kicked off a rawhide install and was amazed at how much faster it > went through the depsolving stage. Kudos to all involved. Is this > anaconda specific, or a general yum feature? General yum. We've tried hard to make it so that anaconda _doesn't_ have any code that's not in yum in this area Jeremy From mattdm at mattdm.org Fri Sep 14 00:05:10 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Sep 2007 20:05:10 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> Message-ID: <20070914000510.GA2213@jadzia.bu.edu> On Thu, Sep 13, 2007 at 04:41:46PM -0400, William Jon McCann wrote: > 1. Query / store user photos (avatars) > 2. Query user account status in an implementation/backend independent > way (locked, expired etc) libuser? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Sep 14 00:07:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Sep 2007 20:07:24 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> Message-ID: <20070914000724.GB2213@jadzia.bu.edu> On Thu, Sep 13, 2007 at 05:29:58PM -0400, William Jon McCann wrote: > > > 3. Query the user's real world name etc (ie. not just gecos) > > By this, you mean more than just the name in gecos? > Ideally, yes. Why not just get the gecos name field right? There's reinventing the wheel, and then there's lifting the car up and putting it on a sled and pulling it with a team of carefully trained dancing ferrets. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From limb at jcomserv.net Fri Sep 14 00:12:32 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 13 Sep 2007 19:12:32 -0500 (CDT) Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <20070914000724.GB2213@jadzia.bu.edu> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> <20070914000724.GB2213@jadzia.bu.edu> Message-ID: <1956.192.168.0.1.1189728752.squirrel@mail.jcomserv.net> > On Thu, Sep 13, 2007 at 05:29:58PM -0400, William Jon McCann wrote: >> > > 3. Query the user's real world name etc (ie. not just gecos) >> > By this, you mean more than just the name in gecos? >> Ideally, yes. > > Why not just get the gecos name field right? There's reinventing the > wheel, > and then there's lifting the car up and putting it on a sled and pulling > it > with a team of carefully trained dancing ferrets. Been done. You've re-invented the dancing ferret sledomobile. Besides, what is backend-independent? Whatever was chosen would have to work with ldap, nis, winbind, etc. Although I suppose just targeting pam might work, but IANAexperienced system programmer. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lmacken at redhat.com Fri Sep 14 00:13:05 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 13 Sep 2007 20:13:05 -0400 Subject: bodhi 0.2.0 Message-ID: <20070914001304.GA4274@crow.myhome.westell.com> I'm pleased to announce that bodhi 0.2.0 has been released and deployed[0]. This release has fixed a ton of issues and introduces many new features, such as: ? Multi-build updates. You can add as many builds to a single update as you want. Bodhi will treat it as a single update, but will still send individual update notification mails for each build. ? New homepage widget that allows you to keep up with the happenings inside of bodhi. You can see the latest comments, testing/security/stable updates, and keep track of your own business. ? Enhanced notifications. If you commented on an update, you'll receive notifications when others comment on that update, and when that update is modified or changes states. ? Automatic closing of bugs is now optional. ? Build-completion improvements. Package names will be automagically completed, and if you type '-' after, it will complete versions as well. ? Positive/negative comments effect an updates 'karma'. After an update achieves a karma of 3, it will automatically be pushed to the stable updates repository. This will hopefully encourage testers to get involved with the updates-testing process a bit more, and will add some automation to the workflow. ? Extended metadata (updateinfo.xml.gz) should start appearing in the repodata, which will allow tools like pup and the yum-security plugin to take advantage of it and do some nifty stuff. ? Reminders. You'll get nagged when your update sits around in testing for too long, and so on.. This release introduces many database changes from the previous version, so it will be much easier to jump back into the release-early-release often cycle. Soon to come: ? bodhi command-line client is almost ready to go. It needs to be polished up a bit, but should be released soon. ? RSS feeds and public details. ? Better build-completion based on koji tags. ? More sanity checking (koji buildroot verification, dependency closure, etc) There is still much more work to be done with bodhi, so if you're interested in helping out, you can setup a local bodhi development playground with just a few commands[1] and dive in. As always, please file any bugs or enhancement requests here[2]. Thanks, luke [0]: http://bodhi.fedoraproject.org [1]: https://hosted.fedoraproject.org/projects/bodhi/wiki/Development [2]: https://hosted.fedoraproject.org/projects/bodhi/newticket _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From loganjerry at gmail.com Fri Sep 14 01:31:43 2007 From: loganjerry at gmail.com (Jerry James) Date: Thu, 13 Sep 2007 19:31:43 -0600 Subject: Build failed due to DNS error? Message-ID: <870180fe0709131831i43298a1ck1c2c6e34a1631ea5@mail.gmail.com> I just had a build fail, apparently because a DNS lookup of ppc2.fedora.redhat.com failed. I don't see any other errors in the build log: http://buildsys.fedoraproject.org/logs/fedora-6-extras/36321-latexmk-3.20-1.fc6/ What do I do now? -- Jerry James http://loganjerry.googlepages.com/ From rc040203 at freenet.de Fri Sep 14 01:34:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 14 Sep 2007 03:34:31 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: References: <200709120908.l8C98xu6018323@porkchop.devel.redhat.com> <1189673549.3157.337.camel@mccallum.corsepiu.local> <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189701235.3157.490.camel@mccallum.corsepiu.local> <1189703644.3157.505.camel@mccallum.corsepiu.local> Message-ID: <1189733671.3157.517.camel@mccallum.corsepiu.local> On Thu, 2007-09-13 at 10:23 -0700, Christopher Stone wrote: > On 9/13/07, Ralf Corsepius wrote: > > On Thu, 2007-09-13 at 16:53 +0000, Kevin Kofler wrote: > > > Ralf Corsepius freenet.de> writes: > > > > As you can see the work-around to pkgconfig is close to being trivial. > > > > configure OPENTHREADS_CFLAGS=' ' ... > > > > is one half > > > > > > ... which is an ugly hack. What about a fix which would be acceptable for > > > openalpp upstream? > > > > The other fact Chris denys to accept: openalpp is dead and discontinued. > We have also heard back from the OSG maintainer and he says "I have no > problem with adding the packaging files" with regards to adding the > pkgconfig files. We should have done this straight off, but we > figured it was not much to ask you to just add them in the meantime. I will wait for them to appear upstream. > I will inform you with a bug report once the pkgconfig files have been > added to OSG's CVS so that you may add them to Fedora's package. OSG uses SVN. Ralf From mmcgrath at redhat.com Fri Sep 14 01:40:48 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 13 Sep 2007 20:40:48 -0500 Subject: Build failed due to DNS error? In-Reply-To: <870180fe0709131831i43298a1ck1c2c6e34a1631ea5@mail.gmail.com> References: <870180fe0709131831i43298a1ck1c2c6e34a1631ea5@mail.gmail.com> Message-ID: <46E9E6A0.60601@redhat.com> Jerry James wrote: > I just had a build fail, apparently because a DNS lookup of > ppc2.fedora.redhat.com failed. I don't see any other errors in the > build log: > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36321-latexmk-3.20-1.fc6/ > > What do I do now? > Thats this: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 Feel free to resubmit until it gets fixed. I've been adding and removing code bits but so far nothing has worked. -Mike From loganjerry at gmail.com Fri Sep 14 01:46:29 2007 From: loganjerry at gmail.com (Jerry James) Date: Thu, 13 Sep 2007 19:46:29 -0600 Subject: Build failed due to DNS error? In-Reply-To: <46E9E6A0.60601@redhat.com> References: <870180fe0709131831i43298a1ck1c2c6e34a1631ea5@mail.gmail.com> <46E9E6A0.60601@redhat.com> Message-ID: <870180fe0709131846j38fe228as374f50995d1c0da@mail.gmail.com> On 9/13/07, Mike McGrath wrote: > Thats this: > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 > > Feel free to resubmit until it gets fixed. I've been adding and > removing code bits but so far nothing has worked. Okay, thanks ... and good luck! -- Jerry James http://loganjerry.googlepages.com/ From stickster at gmail.com Fri Sep 14 02:02:30 2007 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 13 Sep 2007 22:02:30 -0400 Subject: Announcing Fedora 8 Test 2 (7.91) In-Reply-To: <1189701384.10318.95.camel@localhost6.localdomain6> References: <20070913103050.33a03547@lumos.localdomain> <1189698886.10318.60.camel@localhost6.localdomain6> <46E95CA9.1020604@fedoraproject.org> <1189699686.10318.71.camel@localhost6.localdomain6> <46E960E4.1030800@fedoraproject.org> <1189701384.10318.95.camel@localhost6.localdomain6> Message-ID: <1189735350.13046.5.camel@localhost.localdomain> On Thu, 2007-09-13 at 10:36 -0600, Richi Plana wrote: > On Thu, 2007-09-13 at 21:40 +0530, Rahul Sundaram wrote: > > Richi Plana wrote: > > > > > > > > I might just burn a couple of these spins and give them to former > > > colleagues who've not tried developing on Linux, yet. I hope the docs > > > (User's and API references are complete or bookmarked on Firefox) > > > > I don't think anything like that has been done yet but it could be > > easily done since bookmarks were separated out in a different package in > > the last release. File RFE's or bug reports for any desired changes. > > What do I file the RFE against? > > It's just that whenever I talk about ease-of-development, the first > thing that I bring up is documentation that makes it easy. And for that, > I always go back to Javadoc. It is, by and large, the best way to hook a > developer into using ones code. Unfortunately, the thing I noticed is > that when I install javadoc packages (including the Sun manual), no > links pointing to it are ever added. If there's an API to adding > bookmarks to Firefox externally (or, better yet, a global bookmarks file > for all browsers), that would help a lot. Imagine -devel packages > hooking their documentations into Firefox. (I understand yelp is doing > it but most of the good stuff is formatted a'la Javadoc and/or is > available online like http://library.gnome.org/devel/ Are you looking for the devhelp package? I'm still downloading the F8test2 Development spin, but on my F7 box, that's what I primarily use for quickly finding things like GNOME API descriptions. I perpetually find myself needing the docs while coding since I don't do it as often as I'd like. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 stickster at gmail.com Fri Sep 14 02:07:59 2007 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 13 Sep 2007 22:07:59 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46E959F5.4010804@fedoraproject.org> References: <46E959F5.4010804@fedoraproject.org> Message-ID: <1189735679.13046.7.camel@localhost.localdomain> On Thu, 2007-09-13 at 21:10 +0530, Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/F8Test2/ReleaseNotes > > I have updated the release notes with information on changes new to test > 2. If there is anything important I have missed, please edit the wiki or > let me know. Excellent, thanks for pitching in here as usual. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 440volt.tux at gmail.com Fri Sep 14 03:14:45 2007 From: 440volt.tux at gmail.com (subhodip biswas) Date: Fri, 14 Sep 2007 08:44:45 +0530 Subject: koji build failed In-Reply-To: References: <539333cb0709110917ma55772dv771547bd61ac6341@mail.gmail.com> <46E6C4BC.1090601@ioa.s.u-tokyo.ac.jp> <539333cb0709110942n7455b608vd85c8b86ce4b4d40@mail.gmail.com> <539333cb0709111146u51b27d78l30737bcd499e7aad@mail.gmail.com> <20070911213358.297ded14.mschwendt.tmp0701.nospam@arcor.de> <539333cb0709121225p5aec30f5j661df9fd01139ccf@mail.gmail.com> <539333cb0709121305g513f08adhfcca95e688e1deb5@mail.gmail.com> Message-ID: <539333cb0709132014i43661f72p7c3fb4bd10b45ef9@mail.gmail.com> hi ! On 9/13/07, Michel Salim wrote: WIth the help of straw developers got a solution. > Let me know if you can't figure it out by Friday, I should be able to > help you then. Temporarily koji --scratch dist-f8 ..... provides no error during build process. Straw can be installed from the rpm generated. If you may like to see the srpm and the spec file . you may vist http://subhodip.fedorapeople.org Regards Subhodip Biswas From a.badger at gmail.com Fri Sep 14 02:31:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 13 Sep 2007 19:31:08 -0700 Subject: PackageDB 0.3.1 open for business Message-ID: <46E9F26C.1080407@gmail.com> Greetings all, After an extended period of testing, I'm officially announcing the PackageDB as open for (some) business. == What can you do == * Add yourself as an owner * Request to be a comaintainer or added to the CC List * Remove yourself from the above * Approve or reject people requesting the above == What can't you do == * Add new packages. The plan is to add a way to enter the package information via a packagedb interface eventually. Once entered, the information will either be queued for a cvsadmin to look at (similar to how requests are handled currently in bugzilla) or the request will automatically happen if a simple test can detect that the review bug was approved. In talks with a limited number of people, the favorite is queueing for an admin. Please discuss this if you think it should happen automatically. [1]_ * Add a branch. This needs a UI created for it as well. I haven't discussed this yet but it seems that adding branches for currently active Fedora (and EPEL) releases should be done automatically when a maintainer requests it. [2]_ * Add another user to a package. Currently, the person has to request the permissions that they want on the package. Then one of the maintainers approves the permissions. I need to code an interface to allow the package maintainers to add another user directly [3]_ .. _[1]: https://hosted.fedoraproject.org/projects/packagedb/ticket/18 .. _[2]: https://hosted.fedoraproject.org/projects/packagedb/ticket/65 .. _[3]: https://hosted.fedoraproject.org/projects/packagedb/ticket/63 == What's Next == The next few weeks of effort will be quick bugfixes and making sure we're ready for the branching of packages that will be done near Fedora 8 release. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From debarshi.ray at gmail.com Fri Sep 14 03:57:25 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 14 Sep 2007 09:27:25 +0530 Subject: PackageDB 0.3.1 open for business In-Reply-To: <46E9F26C.1080407@gmail.com> References: <46E9F26C.1080407@gmail.com> Message-ID: <3170f42f0709132057x5d0fb9depe535c73839652fc6@mail.gmail.com> Is it possible to have the upstream URL on each package's page (eg., https://admin.fedoraproject.org/pkgdb/packages/name/brightside) ? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From a.badger at gmail.com Fri Sep 14 04:20:24 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 13 Sep 2007 21:20:24 -0700 Subject: PackageDB 0.3.1 open for business In-Reply-To: <3170f42f0709132057x5d0fb9depe535c73839652fc6@mail.gmail.com> References: <46E9F26C.1080407@gmail.com> <3170f42f0709132057x5d0fb9depe535c73839652fc6@mail.gmail.com> Message-ID: <46EA0C08.4030409@gmail.com> Debarshi 'Rishi' Ray wrote: > Is it possible to have the upstream URL on each package's page (eg., > https://admin.fedoraproject.org/pkgdb/packages/name/brightside) ? > This information is available via the repository metadata and hence, repoview carries it. We could import that information into the packagedb or pull the information out of repoview. I think importing it is less than optimal because it spreads the information to multiple locations where they can get out of sync with each other. Unfortunately, repoview is not working for F7+ at the moment so it's not an ideal time to try building additional structures up around it. If you'll open a ticket[1]_ on the packagedb's hosted page, I'll look into linking with repoview and fixing it up if Jesse hasn't had a chance to work on that yet. It will probably happen in the post-F8 time frame. .. _[1]: https://hosted.fedoraproject.org/projects/packagedb/newticket -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Fri Sep 14 04:32:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 14 Sep 2007 06:32:58 +0200 Subject: bodhi 0.2.0 In-Reply-To: <20070914001304.GA4274@crow.myhome.westell.com> References: <20070914001304.GA4274@crow.myhome.westell.com> Message-ID: <46EA0EFA.8070709@hhs.nl> Luke Macken wrote: > I'm pleased to announce that bodhi 0.2.0 has been released and deployed[0]. > This release has fixed a ton of issues and introduces many new features, > such as: > > ? Multi-build updates. You can add as many builds to a single update as you > want. Bodhi will treat it as a single update, but will still send > individual update notification mails for each build. > ? New homepage widget that allows you to keep up with the happenings inside of > bodhi. You can see the latest comments, testing/security/stable updates, and > keep track of your own business. > ? Enhanced notifications. If you commented on an update, you'll receive > notifications when others comment on that update, and when that update is > modified or changes states. > ? Automatic closing of bugs is now optional. > ? Build-completion improvements. Package names will be automagically > completed, and if you type '-' after, it will complete versions as well. > ? Positive/negative comments effect an updates 'karma'. After an update > achieves a karma of 3, it will automatically be pushed to the stable updates > repository. This will hopefully encourage testers to get involved with the > updates-testing process a bit more, and will add some automation to the > workflow. > ? Extended metadata (updateinfo.xml.gz) should start appearing in the repodata, > which will allow tools like pup and the yum-security plugin to take advantage > of it and do some nifty stuff. > ? Reminders. You'll get nagged when your update sits around in testing for too > long, and so on.. > > This release introduces many database changes from the previous version, so it > will be much easier to jump back into the release-early-release often cycle. > > Soon to come: > ? bodhi command-line client is almost ready to go. It needs to be polished up > a bit, but should be released soon. > ? RSS feeds and public details. > ? Better build-completion based on koji tags. > ? More sanity checking (koji buildroot verification, dependency closure, etc) > As one of the long term bodhi complainers, I want to say that this all sounds very good! Regards, Hans From debarshi.ray at gmail.com Fri Sep 14 06:38:30 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 14 Sep 2007 12:08:30 +0530 Subject: PackageDB 0.3.1 open for business In-Reply-To: <46EA0C08.4030409@gmail.com> References: <46E9F26C.1080407@gmail.com> <3170f42f0709132057x5d0fb9depe535c73839652fc6@mail.gmail.com> <46EA0C08.4030409@gmail.com> Message-ID: <3170f42f0709132338q53d00e0aqea8fb950fe9c35dd@mail.gmail.com> > If you'll open a ticket[1]_ on the packagedb's hosted page, I'll look > into linking with repoview and fixing it up if Jesse hasn't had a chance > to work on that yet. It will probably happen in the post-F8 time frame. Done: https://hosted.fedoraproject.org/projects/packagedb/ticket/67 Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ville.skytta at iki.fi Fri Sep 14 06:41:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 14 Sep 2007 09:41:19 +0300 Subject: rpmlint file-not-utf8 In-Reply-To: <1189722399.3241.7.camel@shinybook.infradead.org> References: <46E96640.9050808@redhat.com> <200709131835.05152.jamatos@fc.up.pt> <1189722399.3241.7.camel@shinybook.infradead.org> Message-ID: <200709140941.19825.ville.skytta@iki.fi> On Friday 14 September 2007, David Woodhouse wrote: > On Thu, 2007-09-13 at 18:35 +0100, Jos? Matos wrote: > > Not only that but I remember to see html pages composed with latin1 > > and without the charset in metadata. So the warning has its uses. :-) > > Well... doesn't HTTP default to ISO8859-1 unless the charset is > otherwise specified? In the vast majority of cases, HTTP isn't involved with HTML files packaged as %doc. And even for HTML over HTTP, it's not quite that simple, see eg. http://www.w3.org/TR/html4/charset.html section 5.2.2. From nphilipp at redhat.com Fri Sep 14 08:12:10 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 14 Sep 2007 10:12:10 +0200 Subject: PackageDB 0.3.1 open for business In-Reply-To: <46E9F26C.1080407@gmail.com> References: <46E9F26C.1080407@gmail.com> Message-ID: <1189757530.8849.10.camel@wombat.tiptoe.de> On Thu, 2007-09-13 at 19:31 -0700, Toshio Kuratomi wrote: [ no way to find PackageDB ] I think the PackageDB lives at: https://admin.fedoraproject.org/pkgdb/ Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nicolas.mailhot at laposte.net Fri Sep 14 08:20:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Sep 2007 10:20:12 +0200 (CEST) Subject: rpmlint file-not-utf8 In-Reply-To: <1189722399.3241.7.camel@shinybook.infradead.org> References: <46E96640.9050808@redhat.com> <200709132018.05721.ville.skytta@iki.fi> <1189704666.3233.2.camel@rousalka.dyndns.org> <200709131835.05152.jamatos@fc.up.pt> <1189722399.3241.7.camel@shinybook.infradead.org> Message-ID: <41734.192.54.193.51.1189758012.squirrel@rousalka.dyndns.org> Le Ven 14 septembre 2007 00:26, David Woodhouse a ?crit : > On Thu, 2007-09-13 at 18:35 +0100, Jos? Matos wrote: >> Not only that but I remember to see html pages composed with >> latin1 >> and without the charset in metadata. So the warning has its uses. >> :-) > > Well... doesn't HTTP default to ISO8859-1 unless the charset is > otherwise specified? HTTP yes but HTML no -> see http://www.w3.org/TR/html4/charset.html ? The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as a default character encoding when the "charset" parameter is absent from the "Content-Type" header field. In practice, this recommendation has proved useless because some servers don't allow a "charset" parameter to be sent, and others may not be configured to send the parameter. Therefore, user agents must not assume any default value for the "charset" parameter. ? Also: 1. A lot of pages are not ISO8859-1 but ISO8859-15 or the windows latin variant, so *never* assume just because there is no charset declaration it's valid ISO8859-1 2. Default encoding is user-settable at the browser level and users do change the US-friendly ISO8859-1 default so any page without charset declaration will render wrongly on some systems 3. Local HTML pages are read without passing through HTTP so HTTP defaults do not apply So any HTML page without charset definition should be treated as a bug (unless it's in a webapp which Apache config file forces a particular encoding, or it's a xhtml page with encoding specified at the XML level) -- Nicolas Mailhot From laurent.rineau__fedora at normalesup.org Fri Sep 14 08:25:31 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 14 Sep 2007 10:25:31 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070913191253.GF1410972@hiwaay.net> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> Message-ID: <200709141025.31848@rineau.tsetse> On Thursday 13 September 2007 21:12:54 Chris Adams wrote: > Once upon a time, Simo Sorce said: > > Remember that IPv6 will probably explode quite fast at some point, like > > any technology with important network effects do. We ought to be > > prepared. > > My main problem is that I configure IPv4 and I explicitly have IPv6 > turned off (or so it appears in the interface), yet I still have IPv6 > loaded and used. This causes annoying warnings from programs trying to > use an unconfigured IPv6 interface. > > If I don't configure IPv4, the interface isn't configured; why is it > that way with IPv6? If I don't configure anything for IPv6, it is still > loaded. It is the way of doing for a end-user machin, in IPv6: you do not need to configure your IPv6 parameters. If an IPv6-enabled router exists in your local network, it will broadcast the needed configuration. In a sens IPv6 is more "plug and play" than IPv4. For that mecanism to work, IPv6 interfaces are always up. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From buildsys at redhat.com Fri Sep 14 09:56:37 2007 From: buildsys at redhat.com (Build System) Date: Fri, 14 Sep 2007 05:56:37 -0400 Subject: rawhide report: 20070914 changes Message-ID: <200709140956.l8E9ubC4007577@porkchop.devel.redhat.com> New package Io-language Io is a small, prototype-based programming language New package mhgui A simple GUI library for MakeHuman New package php-pear-HTML-QuickForm-advmultiselect Element for HTML_QuickForm that emulate a multi-select Updated Packages: TurboGears-1.0.3.2-1.fc8 ------------------------ * Thu Sep 13 2007 Luke Macken 1.0.3.2-1 - 1.0.3.2 - Remove etree patch anaconda-11.3.0.29-1 -------------------- * Thu Sep 13 2007 Chris Lumens 11.3.0.29-1 - On the graphical netconfig screen, only check the gateway address if provided (dcantrell). - Don't show wireless adapters unless explicitly requested (katzj). - Add user and services commands and scripts to anaconda-ks.cfg - Fix handling of groups from the kickstart user command. - Support loading updates from partitioned devices. - Rework netlink code to support > 10 devices and not get caught in an infinite loop (pjones, dcantrell). - Fix args passed to iscsiadm (k.georgiou AT imperial DOT ac DOT uk, - Set flags.selinux (katzj, #244691). - Be more accepting when waiting for an sshd response (alanm AT redhat DOT com, #286031). - Probe USB to make USB network installs work (H.J. Lu, #285491). - Rework driver package installation to be more generic. - Turn off swaps we didn't turn on so livecds don't blow up (katzj). - Add new Chinese and Japanese font packages (katzj, #279931). - Fix another upgrade GUI traceback (#281031). - Correctly identify when the VNC server doesn't start. - Display the correct signal name when loader exits (pjones). - Change method for determining maximum LV size (msivak, #242508). bouml-2.31.2-1.fc8 ------------------ * Fri Sep 14 2007 Debarshi Ray - 2.31.2-1 - Version bump to 2.31.2. * Thu Sep 06 2007 Debarshi Ray - 2.31.1-1 - Version bump to 2.31.1. * Wed Aug 22 2007 Debarshi Ray - 2.30.2-1 - Version bump to 2.30.2. - Cleaned up SPEC. cln-1.1.13-4.fc8 ---------------- * Thu Sep 13 2007 Quentin Spencer 1.1.13-4 - Add pkgconfig as a dependency of -devel. eclipse-mylyn-2.0.0-5.fc8 ------------------------- * Fri Sep 07 2007 Andrew Overholt 2.0.0-5 - Make web.core its own jar. - Unpack web.core so we can symlink to dependencies. - Symlink to dependencies of web.core. - Remove rome jar and exports from web.core. - BR/R all the versions of dependencies that have OSGi manifests. fedora-logos-7.92.1-1.fc8 ------------------------- * Thu Sep 13 2007 Bill Nottingham - 7.92.1-1 - add the powered-by logo (#250676) gnome-panel-2.19.92-4.fc8 ------------------------- * Thu Sep 13 2007 Matthias Clasen - 2.19.92-4 - Fix some memleaks - Remove OpenOffice launchers from the default configuration - Add Tomboy to the default configuration gtkhtml3-3.15.92-2.fc8 ---------------------- * Thu Sep 13 2007 Matthew Barnes - 3.15.92-2.fc8 - Add patch for GNOME bug #443850 (fix cursor position after typing halant). kdewebdev-6:3.5.7-2.fc8 ----------------------- * Thu Sep 13 2007 Rex Dieter 6:3.5.7-2 - License: GPLv2 - update %description - Provides: kdewebdev3 kommander - BR: kdelibs3 kernel-2.6.23-0.181.rc6.git4.fc8 -------------------------------- * Thu Sep 13 2007 Chuck Ebbert - Linux 2.6.23-rc6-git4 * Thu Sep 13 2007 Chuck Ebbert - Linux 2.6.23-rc6-git3 - disable stack overflow debugging on i386 * Wed Sep 12 2007 Dave Jones - Change ACPI dock drivers to be built-in. kernel-xen-2.6-2.6.21-2940.fc8 ------------------------------ * Thu Sep 13 2007 Eduardo Habkost - Rebase to 2.6.21.7 * Thu Sep 13 2007 Eduardo Habkost - Fix for bug #248398: HVM domain hangs during (F-7) install. Backported fix from xen-unstable: 15239:656b8175f4f2 * Thu Sep 13 2007 Eduardo Habkost - Make hypervisor patches relative to the xen HG tree, not only the hypervisor subdirectory. This makes easier to import patches from upstream. linuxwacom-0.7.8.3-3.fc8 ------------------------ * Thu Sep 13 2007 Aristeu Rozanski 0.7.8.3-3.fc8 - Adding ppc64 to list of architectures mlton-20070826-4.fc8 -------------------- * Thu Sep 13 2007 Adam Goode - 20070826-4 - Do not condition bootstrap source tag * Thu Sep 13 2007 Adam Goode - 20070826-3 - Bootstrap x86_64 nodoka-theme-gnome-0.3.2-1.fc8.1 -------------------------------- * Thu Sep 13 2007 Martin Sourada - 0.3.2-1.fc8.1 - fix dir name * Thu Sep 13 2007 Martin Sourada - 0.3.2-1 - new version, reworked gradients in metacity theme python-sqlalchemy-0.4.0-0.4.beta5.fc8 ------------------------------------- * Tue Sep 11 2007 Toshio Kuratomi - 0.4.0-0.4.beta5 - Update to 0.4beta5. * Thu Sep 06 2007 Toshio Kuratomi - 0.4.0-0.4.beta4 - setuptools has been fixed. qt4-4.3.1-7.fc8 --------------- * Thu Sep 13 2007 Rex Dieter 4.3.1-7 - include qt4-logo icon, used by qtdemo/qtconfig (#241452) - linguist.desktop: use new linguist4 icons - -devel,-x11: %post/%postun scriptlets (icons, mimetypes) * Thu Sep 13 2007 Than Ngo - 4.3.1-4 - fixed bz241452, add qtdemo/qtconfig icons - fixed bz249242, designer4 - segmentation fault on s390x * Thu Aug 23 2007 Rex Dieter 4.3.1-3 - ppc64 patch (#246324) remind-03.01.02-1.fc8 --------------------- * Thu Sep 13 2007 Ray Van Dolson - 03.01.02-1 - Updated to version 03.01.02 ruby-gnome2-0.16.0-12.fc8 ------------------------- * Thu Sep 13 2007 Allisson Azevedo 0.16.0-12 - Newpoppler.patch updated for poppler 0.6 * Sat Sep 08 2007 Allisson Azevedo 0.16.0-11 - Rebuild against new poppler - Changed license to LGPLv2+ ws-commons-util-1.0.1-6.fc8 --------------------------- * Thu Sep 13 2007 Andrew Overholt 1.0.1-6 - Add BR on maven surefire resources, eclipse, and install plugins. xchat-gnome-0.18-5.fc8 ---------------------- * Thu Sep 13 2007 Brian Pepple - 0.18-5 - Add patch to fix reconnect bug. (#225408) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From mike at miketc.com Fri Sep 14 10:23:54 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 14 Sep 2007 05:23:54 -0500 Subject: Volume control problems In-Reply-To: <61987.87.194.100.54.1189720654.squirrel@webmail.cream.org> References: <1189562460.15173.2.camel@scrappy.miketc.com> <1189601612.16561.1.camel@scrappy.miketc.com> <20070912150131.GA6177@tango.0pointer.de> <1189634314.2993.2.camel@scrappy.miketc.com> <20070912221924.GA20538@tango.0pointer.de> <1189656884.4095.6.camel@scrappy.miketc.com> <1189660132.21101.2.camel@jndwidescreen.lesbg.loc> <1189684732.2635.2.camel@scrappy.miketc.com> <61987.87.194.100.54.1189720654.squirrel@webmail.cream.org> Message-ID: <1189765434.4771.0.camel@scrappy.miketc.com> On Thu, 2007-09-13 at 22:57 +0100, bloch at verdurin.com wrote: > I have what seems to be a fairly similar problem, listed in > > https://bugzilla.redhat.com/show_bug.cgi?id=290151 Looks like same problem, not sure. I have cc'd myself on the list as well as posted my pulseaudio -vv output. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From rjones at redhat.com Fri Sep 14 10:51:01 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 14 Sep 2007 11:51:01 +0100 Subject: Review swapsies Message-ID: <46EA6795.6040404@redhat.com> Dear fedora developers, I've got a number of reviews outstanding: https://bugzilla.redhat.com/show_bug.cgi?id=253564 https://bugzilla.redhat.com/show_bug.cgi?id=253570 https://bugzilla.redhat.com/show_bug.cgi?id=253571 https://bugzilla.redhat.com/show_bug.cgi?id=253588 https://bugzilla.redhat.com/show_bug.cgi?id=275491 (the following 3 are assigned, but owing to laziness on my part they were only buildable from yesterday: https://bugzilla.redhat.com/show_bug.cgi?id=241472 https://bugzilla.redhat.com/show_bug.cgi?id=241476 https://bugzilla.redhat.com/show_bug.cgi?id=241487 ) I think I'm allowed to review other packages now, so I'll swap anyone a review for a review. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From bernie at codewiz.org Fri Sep 14 11:10:49 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Fri, 14 Sep 2007 07:10:49 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189698714.3570.158.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <1189695196.10318.19.camel@localhost6.localdomain6> <1189698714.3570.158.camel@shinybook.infradead.org> Message-ID: <46EA6C39.4010204@codewiz.org> David Woodhouse wrote: >> At the very least, make disabling it a one-step process (and free up >> ALL >> resources related to IPv6). Right now, I can't even figure out how to >> disable it entirely. There's online documentation on doing this by >> editing /etc/sysctl.conf flags, editing files in /etc/sysconfig/ and >> removing kernel modules from configuration. > > It _is_ one step: > > echo blacklist ipv6 > /etc/modprobe.d/luddite ROTFL :-))) (sorry for the OT, couldn't resist) -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ From nicu_fedora at nicubunu.ro Fri Sep 14 12:05:05 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 14 Sep 2007 15:05:05 +0300 Subject: [Long] Do we need a font SIG ? In-Reply-To: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> Message-ID: <46EA78F1.4090203@nicubunu.ro> Nicolas Mailhot wrote: > > 3. I don't believe our font selection is optimal for every locale. It > took a near-revolt by our Greek users to get their situation fixed in > Fedora Core 6, and there are probably many other problem locales, > where users just pass on Fedora or bear their pain silently instead of > telling us about problems. Please note that the fonts wanted by the art team don't need large locale coverage, they are not intended for documents or graphic interfaces, but mostly for fancy graphics, like a logo made with GIMP or such, so I don't think that should be a blocker for adding a font (in a non-default package). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nphilipp at redhat.com Fri Sep 14 12:18:11 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 14 Sep 2007 14:18:11 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070913224154.GT6066@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <20070913103042.86853409.dcantrell@redhat.com> <200709132212.44798.opensource@till.name> <1189723084.3241.10.camel@shinybook.infradead.org> <20070913224154.GT6066@angus.ind.WPI.EDU> Message-ID: <1189772291.8849.21.camel@wombat.tiptoe.de> On Thu, 2007-09-13 at 18:41 -0400, Chuck Anderson wrote: > On Fri, Sep 14, 2007 at 12:38:04AM +0200, David Woodhouse wrote: > > On Thu, 2007-09-13 at 22:12 +0200, Till Maas wrote: > > > It circumenvents iptables rules. > > > > IPv6 doesn't 'circumvent' iptables rules any more than IPv4 > > 'circumvents' ip6tables rules. > > > > Besides, http://www.advogato.org/person/dwmw2/diary/164.html > > +1. Firewalls just break connectivity and are a handicap that enables > people to be lazy about system security. And don't get me started on > NAT :-) -1. Firewalls are a mandatory access control system like SELinux. Their purpose is to prevent (certain kinds of) connectivity outside of the services they are shielding. You can easily log blocked connection attempts. Following your argument, one could say that "SELinux just breaks functionality and is a handicap that enables developers to be lazy about system security". Which it isn't. Both are additional lines of defense. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From panemade at gmail.com Fri Sep 14 12:20:52 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Sep 2007 17:50:52 +0530 Subject: [Long] Do we need a font SIG ? In-Reply-To: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> Message-ID: Hi, On 9/14/07, Nicolas Mailhot wrote: > Hi all > > [I wanted to prepare a bit more before writing this, but it seems > everyone is asking about the same things at once, so this will have to > do] > Thanks for your mail. > I'd like know what people think of setting up a font SIG, and if there > are enough would-be contributors for such a SIG to be viable. Fonts > are a very transversal subject in Fedora, and the initial To: list > reflects this. Please take care to reply on fedora-devel only however. > > The situation right now is: > > 1. we have several font packages in Fedora, but are only scratching > what could be packaged. > http://mihmo.livejournal.com/45152.html > > 2. In particular the art team wants a lot more fonts in for its Art spin > http://fedoraproject.org/wiki/Artwork/ArtTeamProjects/FedoraArtStudio > > 3. I don't believe our font selection is optimal for every locale. It > took a near-revolt by our Greek users to get their situation fixed in > Fedora Core 6, and there are probably many other problem locales, > where users just pass on Fedora or bear their pain silently instead of > telling us about problems. > > 4. The i18n team is nominally in charge of selecting the best fonts > for each locale, but does not always have the right local contacts to > do so. So far i18n has focused on technical problems : if your locale > needs complex IM methods you have i18n visibility, if your locale > poses no technical challenge but your default fonts are suboptimal the > i18n team may not notice you. > > 4. The l10n team has local contacts and could provide useful feedback > on font choices, currently packaged font problems, local > foundries/font designers that could be contacted to contribute to the > FLOSS font pool, etc but has mostly focused on translation so far. > > 5. The desktop team handles our font infrastructure and takes the heat > when a font is badly rendered (since we can not use the patented > freetype autohinter many fonts that work fine under windows do not > under Fedora) > > 6. We already have some font-related material disseminated on our wiki: > - packaging rules, > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 > - licensing rules > http://fedoraproject.org/wiki/Licensing#head-63f9d798a33b23a752e5a3b22a0888046d4cb8d8 > - other > http://fedoraproject.org/wiki/Fonts/DejaVu > Yes. But still I think good to have a single page say http://fedoraproject.org/wiki/Packaging/Fonts > 7. The font situation is bad enough we have a font exception to our > FLOSS rules > http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac > [for example we ship Luxi even though its licensing forbids > modification, making it non-free > http://www.xfree86.org/current/LICENSE11.html] > > 8. There are efforts to drain the font licensing swamp and promote > FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with > Fedora general objectives yet Fedora has totally ignored them so far > (cf Liberation licensing choices) > I18n and more importantly l10n team should check those fonts and provide which fonts are rendering fine in fedora so that we can see them packaged for fedora. > This is a stark contrast with the very active debian font team : > http://wiki.debian.org/DebianInstaller/GUIFonts > The main part of the OLPC font page is the Debian font list! > http://wiki.laptop.org/go/Fonts We should also have all fonts packages for fedora be listed in Font Matrix. > > I believe there is enough interest in the various Fedora groups to > improve the current situation through a font SIG. > > This SIG would be tasked with: > A. providing a single point of entry for Fedora people interested in > fonts, centralizing all our packaging rules or at least indexing them > in a single place > B. completing the existing font packaging documentation > C. helping the i18n team maintain the font install list for each locale > D. identifying fonts worthy of packaging for l10n or art reasons > E. identifying problems in existing font packages and helping relay > the info upstream > F. identifying problems in our font infrastructure, packaging > necessary font tools > G. coordinating and effectively packaging new fonts > > As the current maintainer of dejavu, and a co-maintainer of charis and > dejavu-lgc, I am ready to write a commented font spec example (B) > (without legacy core font bits, which IMHO should be optional nowadays > ; however I'm sure there are people ready and willing to write this > part as an extension), and package a few fonts (G). > > The l10n and i18n groups are naturals for (C). We just have to steal > the Debian receipe of having a font-by-locale table in our wiki. yes. we should have that list. > > I think it's pretty obvious the art team is motivated by (E). IMHO the > l10n team should have a role there too. Note that doing the legal > analysis of a potential font is far from easy as font licensing > practices are far less clean than software licensing practices. Also > we should try to build font from sources whenever possible, but font > building is often a mess. > > G will demand packagers and reviewers. By nature most of them will be > active in other Fedora forums, so we're not talking of a few full-time > SIG members but a lot of part-time contributors. > > I created a mockup wiki page to try to make all this clear > http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix > It's far from complete, but I hope it's complete enough to give > everyone an idea of the potential SIG scope. Thanks for that. > > So, who wants to play? Is Fedora ready for a font SIG or should I ask > again next year? +1 to have font SIG. Regards, Parag. From nicolas.mailhot at laposte.net Fri Sep 14 12:21:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Sep 2007 14:21:58 +0200 (CEST) Subject: [Long] Do we need a font SIG ? In-Reply-To: <46EA78F1.4090203@nicubunu.ro> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> Message-ID: <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> Le Ven 14 septembre 2007 14:05, Nicu Buculei a ?crit : > Nicolas Mailhot wrote: >> >> 3. I don't believe our font selection is optimal for every locale. >> It >> took a near-revolt by our Greek users to get their situation fixed >> in >> Fedora Core 6, and there are probably many other problem locales, >> where users just pass on Fedora or bear their pain silently instead >> of >> telling us about problems. > > Please note that the fonts wanted by the art team don't need large > locale coverage, I believe there are also artists in non-latin countries that'd like to create logos and other fancy graphics for their language. Anyway: this was not an argument against packaging fonts with limited coverage for art reasons (as long as they are not default). This was an argument to also package fonts art has little interest in. Regards, -- Nicolas Mailhot From petersen at redhat.com Fri Sep 14 12:52:27 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 14 Sep 2007 22:52:27 +1000 Subject: [Long] Do we need a font SIG ? In-Reply-To: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> Message-ID: <46EA840B.9010706@redhat.com> Nicolas Mailhot wrote: > I'd like know what people think of setting up a font SIG I think it is a great idea! > 3. I don't believe our font selection is optimal for every locale. It > took a near-revolt by our Greek users to get their situation fixed in > Fedora Core 6, and there are probably many other problem locales, > where users just pass on Fedora or bear their pain silently instead of > telling us about problems. True. > 4. The i18n team is nominally in charge of selecting the best fonts > for each locale, but does not always have the right local contacts to > do so. So far i18n has focused on technical problems : if your locale > needs complex IM methods you have i18n visibility, if your locale > poses no technical challenge but your default fonts are suboptimal the > i18n team may not notice you. Right and we are currently working hard moving all the fonts in our generic fonts-* to separate packages with their upstream names. > I believe there is enough interest in the various Fedora groups to > improve the current situation through a font SIG. Yes. > This SIG would be tasked with: > A. providing a single point of entry for Fedora people interested in > fonts, centralizing all our packaging rules or at least indexing them > in a single place > B. completing the existing font packaging documentation > C. helping the i18n team maintain the font install list for each locale > D. identifying fonts worthy of packaging for l10n or art reasons > E. identifying problems in existing font packages and helping relay > the info upstream > F. identifying problems in our font infrastructure, packaging > necessary font tools > G. coordinating and effectively packaging new fonts Looks good to me. > The l10n and i18n groups are naturals for (C). We just have to steal > the Debian receipe of having a font-by-locale table in our wiki. Yes > Note that doing the legal > analysis of a potential font is far from easy as font licensing > practices are far less clean than software licensing practices. Also > we should try to build font from sources whenever possible, but font > building is often a mess. That is right - the legal side is more often harder than the packaging and reviewing. > G will demand packagers and reviewers. By nature most of them will be > active in other Fedora forums, so we're not talking of a few full-time > SIG members but a lot of part-time contributors. Right, I guess this will be the main visible fruit of the SIG's efforts, which will provide good font packaging standards, guidelines and examples as you say. > I created a mockup wiki page to try to make all this clear > http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix Cool > So, who wants to play? Is Fedora ready for a font SIG or should I ask > again next year? I'm in. :) I think we need this sonner rather than later. Probably a bit late to make an impact on F8 but certainly we can start preparing now for F9. Thanks for the initiative! Jens From cra at WPI.EDU Fri Sep 14 13:06:52 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 14 Sep 2007 09:06:52 -0400 Subject: Disable IPv6 by default. In-Reply-To: <200709141025.31848@rineau.tsetse> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> Message-ID: <20070914130652.GO8380@angus.ind.WPI.EDU> On Fri, Sep 14, 2007 at 10:25:31AM +0200, Laurent Rineau wrote: > On Thursday 13 September 2007 21:12:54 Chris Adams wrote: > > My main problem is that I configure IPv4 and I explicitly have IPv6 > > turned off (or so it appears in the interface), yet I still have IPv6 > > loaded and used. This causes annoying warnings from programs trying to > > use an unconfigured IPv6 interface. > > > > If I don't configure IPv4, the interface isn't configured; why is it > > that way with IPv6? If I don't configure anything for IPv6, it is still > > loaded. > > It is the way of doing for a end-user machin, in IPv6: you do not need to > configure your IPv6 parameters. If an IPv6-enabled router exists in your > local network, it will broadcast the needed configuration. In a sens IPv6 is > more "plug and play" than IPv4. For that mecanism to work, IPv6 interfaces > are always up. Recent OSes including Fedora do configure IPv4 automatically too. You'll see 169.254.x.x addresses appear if there is no DHCP server response. From michel.sylvan at gmail.com Fri Sep 14 13:48:18 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 14 Sep 2007 09:48:18 -0400 Subject: Review swapsies In-Reply-To: <46EA6795.6040404@redhat.com> References: <46EA6795.6040404@redhat.com> Message-ID: Hi Richard, On 14/09/2007, Richard W.M. Jones wrote: > Dear fedora developers, > > I've got a number of reviews outstanding: > > https://bugzilla.redhat.com/show_bug.cgi?id=253564 > https://bugzilla.redhat.com/show_bug.cgi?id=253570 > https://bugzilla.redhat.com/show_bug.cgi?id=253571 > https://bugzilla.redhat.com/show_bug.cgi?id=253588 > https://bugzilla.redhat.com/show_bug.cgi?id=275491 > Would be nice to include some information on what these reviews are for -- I ended up clicking on all of them, and then noticing that they are all OCamL related. Regards, -- Michel From billcrawford1970 at gmail.com Fri Sep 14 14:36:02 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 15:36:02 +0100 Subject: Announcing rpmfusion In-Reply-To: <1189619895.23953.3.camel@kennedy> References: <46E637DB.6060102@hhs.nl> <20070911140616.61fc2799@localhost.localdomain> <1189546003.13590.38.camel@localhost6.localdomain6> <1189557422.4727.11.camel@localhost.localdomain> <1189563360.20578.4.camel@localhost6.localdomain6> <46E79D10.6060902@hhs.nl> <1189604270.7051.7.camel@localhost6.localdomain6> <544eb990709120717h43eab1b8qf5893276c37b2be7@mail.gmail.com> <604aa7910709120927m4471cc0ewede4441f97de9806@mail.gmail.com> <1189619895.23953.3.camel@kennedy> Message-ID: <544eb990709140736u2bb9204fx601cded8d20ff789@mail.gmail.com> On 12/09/2007, Brian Pepple wrote: > On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote: ... > > The discussion on how gstreamer's source codebase needs to be > > happening with gstreamer upstream. > > +1. This should be worked out upstream. Source packaging != binary packaging ... glibc comes as several packages (glibc-common, glibc, glibc-headers, nscd, glibc-devel) which are all built from a single source package (glibc). If we're going to argue that upstream packaging should reflect this ... From billcrawford1970 at gmail.com Fri Sep 14 14:38:28 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 15:38:28 +0100 Subject: Announcing rpmfusion In-Reply-To: <604aa7910709120948s439cfb98jfe0fb006a7e09cb9@mail.gmail.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <46E81607.40504@gmail.com> <604aa7910709120948s439cfb98jfe0fb006a7e09cb9@mail.gmail.com> Message-ID: <544eb990709140738u3fb2163ci2e1e099221e206ac@mail.gmail.com> On 12/09/2007, Jeff Spaleta wrote: ... > -jef"Anyone happen to have a C implementation of the generalized Lomb > periodogram for quadrature signals with Lagrangian amplitude envelope > decay functions just sitting around collecting dust that I could > mooch?"spaleta If you can transform them to runge-kutta form there's an old IOCCC entry that might do it for you ... ;) From billcrawford1970 at gmail.com Fri Sep 14 14:42:18 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 15:42:18 +0100 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> Message-ID: <544eb990709140742w76ac36a4q464f109f2420e821@mail.gmail.com> On 13/09/2007, Ago wrote: > nested filesystem => forget about the journal in the nested fs Host the journal as a separate "device" (= file on the external fs) and fsync() or equivalent that before the data file? I'm sure the journal is sync'd when transactions are committed anyway ... See mke2fs(8), option -J device= From billcrawford1970 at gmail.com Fri Sep 14 14:42:18 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 15:42:18 +0100 Subject: Windows based installation of Fedora Linux? In-Reply-To: References: <46E7D57B.8020902@filteredperception.org> <46E891EB.8010408@filteredperception.org> Message-ID: <544eb990709140742w76ac36a4q464f109f2420e821@mail.gmail.com> On 13/09/2007, Ago wrote: > nested filesystem => forget about the journal in the nested fs Host the journal as a separate "device" (= file on the external fs) and fsync() or equivalent that before the data file? I'm sure the journal is sync'd when transactions are committed anyway ... See mke2fs(8), option -J device= From rjones at redhat.com Fri Sep 14 14:57:30 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 14 Sep 2007 15:57:30 +0100 Subject: Review swapsies In-Reply-To: References: <46EA6795.6040404@redhat.com> Message-ID: <46EAA15A.3090505@redhat.com> Michel Salim wrote: > Would be nice to include some information on what these reviews are > for -- I ended up clicking on all of them, and then noticing that they > are all OCamL related. A fair point. I've put the package descriptions below. However even if you're not that interested in OCaml, perhaps people would consider reviewing them? ----- https://bugzilla.redhat.com/show_bug.cgi?id=253564 Camomile is the main Unicode library for OCaml. https://bugzilla.redhat.com/show_bug.cgi?id=253570 Camlp5 is a preprocessor-pretty-printer of OCaml. It is the continuation of the classical camlp4 with new features. OCaml 3.10 and above have an official camlp4 which is incompatible with classical (<= 3.09) versions. You can find that in the ocaml-camlp4 package. https://bugzilla.redhat.com/show_bug.cgi?id=253571 This library is intended to provide a basic interface to the most common file and filename operation. It provides different filename function : reduce, make_absolute, make_relative... It also enables to manipulate real file : cp, mv, rm, touch... It is separated in two modules : SysUtil and SysPath. The first one manipulate files ( real one ), the second one is made for manipulating abstract filename. https://bugzilla.redhat.com/show_bug.cgi?id=253588 CIL (C Intermediate Language) is a high-level representation along with a set of tools that permit easy analysis and source-to-source transformation of C programs. CIL is both lower-level than abstract-syntax trees, by clarifying ambiguous constructs and removing redundant ones, and also higher-level than typical intermediate languages designed for compilation, by maintaining types and a close relationship with the source program. The main advantage of CIL is that it compiles all valid C programs into a few core constructs with a very clean semantics. Also CIL has a syntax-directed type system that makes it easy to analyze and manipulate C programs. Furthermore, the CIL front-end is able to process not only ANSI-C programs but also those using Microsoft C or GNU C extensions. If you do not use CIL and want instead to use just a C parser and analyze programs expressed as abstract-syntax trees then your analysis will have to handle a lot of ugly corners of the language (let alone the fact that parsing C itself is not a trivial task). In essence, CIL is a highly-structured, "clean" subset of C. CIL features a reduced number of syntactic and conceptual forms. For example, all looping constructs are reduced to a single form, all function bodies are given explicit return statements, syntactic sugar like "->" is eliminated and function arguments with array types become pointers. https://bugzilla.redhat.com/show_bug.cgi?id=275491 PG'OCaml is a type-safe, simple interface to PostgreSQL from OCaml. It lets you embed SQL statements directly into OCaml code. ----- Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jochen.schlick at comsoft.de Fri Sep 14 15:27:22 2007 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Fri, 14 Sep 2007 17:27:22 +0200 Subject: Disable IPv6 by default. In-Reply-To: <20070914130652.GO8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> Message-ID: <46EAA85A.2080704@comsoft.de> Chuck Anderson wrote: > On Fri, Sep 14, 2007 at 10:25:31AM +0200, Laurent Rineau wrote: >> On Thursday 13 September 2007 21:12:54 Chris Adams wrote: >>> My main problem is that I configure IPv4 and I explicitly have IPv6 >>> turned off (or so it appears in the interface), yet I still have IPv6 >>> loaded and used. This causes annoying warnings from programs trying to >>> use an unconfigured IPv6 interface. >>> >>> If I don't configure IPv4, the interface isn't configured; why is it >>> that way with IPv6? If I don't configure anything for IPv6, it is still >>> loaded. >> It is the way of doing for a end-user machin, in IPv6: you do not need to >> configure your IPv6 parameters. If an IPv6-enabled router exists in your >> local network, it will broadcast the needed configuration. In a sens IPv6 is >> more "plug and play" than IPv4. For that mecanism to work, IPv6 interfaces >> are always up. > > Recent OSes including Fedora do configure IPv4 automatically too. > You'll see 169.254.x.x addresses appear if there is no DHCP server > response. > And the first step after every Fedora installation is always to disable this microsoft feature and potential security hole. /etc/sysconfig/network NOZEROCONF=yes -- --------------------------------------------------------------------------- Jochen Schlick From billcrawford1970 at gmail.com Fri Sep 14 15:29:07 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 16:29:07 +0100 Subject: rawhide report: 20070912 changes In-Reply-To: References: <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> Message-ID: <544eb990709140829j48d37625t19cd49726ab87f81@mail.gmail.com> On 13/09/2007, Kevin Kofler wrote: > Nalin Dahyabhai redhat.com> writes: > > Forgive me for wading in here, but upstream *has* to be where .pc files > > show up, and if they don't show up there, we absolutely shouldn't be > > adding them to binary packages. I believe this very strongly. > > But there are actually cases where .pc files are being added in Fedora > packages, for reasons such as the upstream foo-config script not being > multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper > foo-config script which just calls pkgconfig). There are also other reasons for > adding .pc files in the distribution. I think Nalin nailed the salient point: if the upstream doesn't ship a .pc, then packages building against it shouldn't be relying on there being one. I'll agree it's a PITA that upstream won't but that's a completely different issue. In the meantime, Ralf's right, whether anyone thinks he is being brusque or not. From kwhiskerz at yahoo.ca Fri Sep 14 15:50:37 2007 From: kwhiskerz at yahoo.ca (kwhiskerz) Date: Fri, 14 Sep 2007 09:50:37 -0600 Subject: CD burning faulty Message-ID: <200709140950.37854.kwhiskerz@yahoo.ca> Does anyone know what is wrong? The Cd is opened, the cue sheet is sent, then it is closed and the burning fails, but nothing is ever written to the CD and the CD is destroyed. Here is the output: System ----------------------- K3b Version: 1.0.3 KDE Version: 3.5.7-22.fc8 Fedora QT Version: 3.3.8 Kernel: 2.6.23-0.171.rc5.git1.fc8 Devices ----------------------- TSSTcorp CD/DVDW SH-S183L SB01 (/dev/sr0, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL] [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] Used versions ----------------------- cdrecord: 1.1.6 cdrecord ----------------------- scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.6 SCSI buffer size: 64512 Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. TOC Type: 1 = CD-ROM Driveropts: 'burnfree' Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identification : 'CD/DVDW SH-S183L' Revision : 'SB01' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: 0x0009 (CD-R) Profile: 0x0015 (DVD-R/DL sequential recording) Profile: 0x0016 (DVD-R/DL layer jump recording) Profile: 0x002B (DVD+R/DL) Profile: 0x001B (DVD+R) Profile: 0x001A (DVD+RW) Profile: 0x0014 (DVD-RW sequential recording) Profile: 0x0013 (DVD-RW restricted overwrite) Profile: 0x0012 (DVD-RAM) Profile: 0x0011 (DVD-R sequential recording) Profile: 0x0010 (DVD-ROM) Profile: 0x000A (CD-RW) Profile: 0x0009 (CD-R) (current) Profile: 0x0008 (CD-ROM) Profile: 0x0002 (Removable disk) Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1058816 = 1034 KB FIFO size : 4194304 = 4096 KB Track 01: data 163 MB Total size: 187 MB (18:33.25) = 83494 sectors Lout start: 187 MB (18:35/19) = 83494 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11634 (97:26/66) ATIP start of lead out: 359848 (79:59/73) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 359848 Blocks current: 359848 Blocks remaining: 276354 Starting to write CD/DVD at speed 48.0 in real SAO mode for single session. Last chance to quit, starting real write in 2 seconds. Speed set to 8468 KB/s 1 seconds. 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Sending CUE sheet... Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 FF FF FF 6A 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0A 00 00 00 00 08 03 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x08 Qual 0x03 (logical unit communication crc error (ultra-dma/32)) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.847s timeout 200s Writing pregap for track 1 at -150 write track pad data: error after 0 bytes BFree: 1025 K BSize: 1034 K Starting new track at sector: 0 Track 01: 0 of 163 MB written. Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0A 00 00 00 00 08 03 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x08 Qual 0x03 (logical unit communication crc error (ultra-dma/32)) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.312s timeout 200s /usr/bin/wodim: A write error occured. /usr/bin/wodim: Please properly read the error message above. write track data: error after 0 bytes Writing time: 18.354s Average write speed 180.7x. Fixating... Fixating time: 18.417s BURN-Free was never needed. /usr/bin/wodim: fifo had 64 puts and 1 gets. /usr/bin/wodim: fifo was 0 times empty and 0 times full, min fill was 100%. cdrecord command: ----------------------- /usr/bin/wodim -v gracetime=2 dev=/dev/sr0 speed=48 -dao driveropts=burnfree -eject -data -tsize=83494s - -- This happens with K3B and with XCDRoast. From harald at redhat.com Fri Sep 14 16:00:39 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 14 Sep 2007 18:00:39 +0200 Subject: udev performance In-Reply-To: <46E69B37.3000604@redhat.com> References: <46E69B37.3000604@redhat.com> Message-ID: <46EAB027.60806@redhat.com> Harald Hoyer schrieb: > For all of you who are bothered by the performance of udev: > > I did some profiling, where udev spents its time... so here are the > numbers: > > Out of 3.63s of measured activity udev spent: > > 44.1% (1,6s) with /sbin/modprobe > 13.3% (0,48s) with persistent-storage (mostly vol_id) > 12% (0.44s) with 60-net.rules > 10.5% (0.38s) with 90-alsa.rules > 7% (0.25s) with pam_console (which will go away anyway) > > Your numbers may vary because of different hardware. > *sigh*.. this is what I am talking about... https://bugzilla.redhat.com/show_bug.cgi?id=291071 Summary: udev is too slow Product: Fedora Version: f8test2 Description: udev takes too long (>5 seconds) at boot. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From cra at WPI.EDU Fri Sep 14 16:02:29 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 14 Sep 2007 12:02:29 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46EAA85A.2080704@comsoft.de> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> Message-ID: <20070914160229.GQ8380@angus.ind.WPI.EDU> On Fri, Sep 14, 2007 at 05:27:22PM +0200, Jochen Schlick wrote: > >Recent OSes including Fedora do configure IPv4 automatically too. > >You'll see 169.254.x.x addresses appear if there is no DHCP server > >response. > > > > And the first step after every Fedora installation is always to disable > this microsoft feature and potential security hole. > > /etc/sysconfig/network > NOZEROCONF=yes Why don't you just go full-out and remove the network card from your computer? From myfedora at richip.dhs.org Fri Sep 14 16:13:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:13:19 -0600 Subject: Disable IPv6 by default. In-Reply-To: <1189772291.8849.21.camel@wombat.tiptoe.de> References: <46E9447E.9080105@hi.is> <20070913103042.86853409.dcantrell@redhat.com> <200709132212.44798.opensource@till.name> <1189723084.3241.10.camel@shinybook.infradead.org> <20070913224154.GT6066@angus.ind.WPI.EDU> <1189772291.8849.21.camel@wombat.tiptoe.de> Message-ID: <1189786399.14868.7.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 14:18 +0200, Nils Philippsen wrote: > -1. Firewalls are a mandatory access control system like SELinux. Their > purpose is to prevent (certain kinds of) connectivity outside of the > services they are shielding. You can easily log blocked connection > attempts. Think laterally, gentlepeople. Firewalls have their uses that go beyond protecting poorly written software. On my system, I have a dynamic firewall management system that DROPs packets from known spam sites. I would rather not have the bandwidth I'm paying for wasted. Thank you very much. As well, I use firewalls to limit the repeated number of SSH connections from IPs on the Internet. Those are the unwelcome packets I can safely surmise. I don't use IPv6 and I'm certainly thankful that with it disabled, I don't have to set up an ip6tables to drop all packets since I'm not sure where they're going, and I am definitely sure I'm not expecting any IPv6 traffic. -- Richi Plana From lesmikesell at gmail.com Fri Sep 14 16:15:23 2007 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 14 Sep 2007 11:15:23 -0500 Subject: rawhide report: 20070912 changes In-Reply-To: <544eb990709140829j48d37625t19cd49726ab87f81@mail.gmail.com> References: <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <544eb990709140829j48d37625t19cd49726ab87f81@mail.gmail.com> Message-ID: <46EAB39B.1030602@gmail.com> Bill Crawford wrote: > On 13/09/2007, Kevin Kofler wrote: >> Nalin Dahyabhai redhat.com> writes: >>> Forgive me for wading in here, but upstream *has* to be where .pc files >>> show up, and if they don't show up there, we absolutely shouldn't be >>> adding them to binary packages. I believe this very strongly. >> But there are actually cases where .pc files are being added in Fedora >> packages, for reasons such as the upstream foo-config script not being >> multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper >> foo-config script which just calls pkgconfig). There are also other reasons for >> adding .pc files in the distribution. > > I think Nalin nailed the salient point: if the upstream doesn't ship a > .pc, then packages building against it shouldn't be relying on there > being one. I'll agree it's a PITA that upstream won't but that's a > completely different issue. In the meantime, Ralf's right, whether > anyone thinks he is being brusque or not. But this was never a case where "upstream won't", it was that "upstream hasn't done it yet" and apparently wasn't informed by the packager who should know the most about the distro's needs that it was needed. -- Les Mikesell lesmikesell at gmail.com From myfedora at richip.dhs.org Fri Sep 14 16:15:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:15:10 -0600 Subject: Disable IPv6 by default. In-Reply-To: <20070914160229.GQ8380@angus.ind.WPI.EDU> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> <20070914160229.GQ8380@angus.ind.WPI.EDU> Message-ID: <1189786510.14868.9.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 12:02 -0400, Chuck Anderson wrote: > On Fri, Sep 14, 2007 at 05:27:22PM +0200, Jochen Schlick wrote: > > >Recent OSes including Fedora do configure IPv4 automatically too. > > >You'll see 169.254.x.x addresses appear if there is no DHCP server > > >response. > > > > > > > And the first step after every Fedora installation is always to disable > > this microsoft feature and potential security hole. > > > > /etc/sysconfig/network > > NOZEROCONF=yes > > Why don't you just go full-out and remove the network card from your > computer? I'm guessing he wants welcome traffic in and unwelcome traffic out. -- Richi Plana From myfedora at richip.dhs.org Fri Sep 14 16:18:14 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:18:14 -0600 Subject: rawhide report: 20070912 changes In-Reply-To: <46EAB39B.1030602@gmail.com> References: <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <544eb990709140829j48d37625t19cd49726ab87f81@mail.gmail.com> <46EAB39B.1030602@gmail.com> Message-ID: <1189786694.14868.12.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 11:15 -0500, Les Mikesell wrote: > Bill Crawford wrote: > > On 13/09/2007, Kevin Kofler wrote: > >> Nalin Dahyabhai redhat.com> writes: > >>> Forgive me for wading in here, but upstream *has* to be where .pc files > >>> show up, and if they don't show up there, we absolutely shouldn't be > >>> adding them to binary packages. I believe this very strongly. > >> But there are actually cases where .pc files are being added in Fedora > >> packages, for reasons such as the upstream foo-config script not being > >> multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper > >> foo-config script which just calls pkgconfig). There are also other reasons for > >> adding .pc files in the distribution. > > > > I think Nalin nailed the salient point: if the upstream doesn't ship a > > .pc, then packages building against it shouldn't be relying on there > > being one. I'll agree it's a PITA that upstream won't but that's a > > completely different issue. In the meantime, Ralf's right, whether > > anyone thinks he is being brusque or not. > > But this was never a case where "upstream won't", it was that "upstream > hasn't done it yet" and apparently wasn't informed by the packager who > should know the most about the distro's needs that it was needed. Yes. And all it took was for some smart person to inform them they were missing a crucial file. Thank goodness the communication lines are open are people are handling the responsibilities properly. -- Richi Plana From billcrawford1970 at gmail.com Fri Sep 14 16:21:09 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 17:21:09 +0100 Subject: Disable IPv6 by default. In-Reply-To: <1189698471.10318.56.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> Message-ID: <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> On 13/09/2007, Richi Plana wrote: > One thing I've noticed is that people have this tendency to shove down > people's throats their own brand of doing things. Such as, uh, insisting that people don't have IPv6 enabled? From jkeating at redhat.com Fri Sep 14 16:21:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 12:21:50 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189786510.14868.9.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> <20070914160229.GQ8380@angus.ind.WPI.EDU> <1189786510.14868.9.camel@localhost6.localdomain6> Message-ID: <20070914122150.47b7a6ad@lumos.localdomain> On Fri, 14 Sep 2007 10:15:10 -0600 Richi Plana wrote: > > Why don't you just go full-out and remove the network card from > > your computer? > > I'm guessing he wants welcome traffic in and unwelcome traffic out. Just use NetworkManager and disable the interface when it's not plugged in to anything working. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alain.portal at free.fr Fri Sep 14 16:29:06 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Fri, 14 Sep 2007 18:29:06 +0200 Subject: Please, make lftp orphaned!!! Message-ID: <200709141829.07383.alain.portal@free.fr> Hi, I ask for orphaning lftp because package maintainer doesn't maintain this package since a long time. I asked for an updated in june, the 1st, for the 3.5.11 version, released on 2007-04-11 :-( https://bugzilla.redhat.com/show_bug.cgi?id=242112 http://lftp.yar.ru/events.html There is now a 3.5.14 release since 2 weeks. All these releases fix bugs. Regards, An angry lftp user -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 myfedora at richip.dhs.org Fri Sep 14 16:29:23 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:29:23 -0600 Subject: Disable IPv6 by default. In-Reply-To: <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> Message-ID: <1189787363.14868.18.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 17:21 +0100, Bill Crawford wrote: > On 13/09/2007, Richi Plana wrote: > > > One thing I've noticed is that people have this tendency to shove down > > people's throats their own brand of doing things. > > Such as, uh, insisting that people don't have IPv6 enabled? Who's insisting that IPv6 be disabled in anyone else's system aside from their own? If you noticed, the only time it was SUGGESTED that IPv6 be disabled after installation was the first poster. Everyone else after that was simply asking to make it easier for THEM to disable IPv6 on their systems. Anyway, I'm working on adding such an option to s-c-n. I just needed the Fedora-sanctioned way of disabling it. So far, it seems to be a combination of adding a modprobe entry and modifying /etc/sysconfig/network, but no one really seems sure. Please read the posts again. No one is insisting other people disable their IPv6 subsystems. Argue for it, perhaps, but respect other people's decisions to differ. -- Richi Plana From billcrawford1970 at gmail.com Fri Sep 14 16:32:59 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 17:32:59 +0100 Subject: Disable IPv6 by default. In-Reply-To: <1189787363.14868.18.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> Message-ID: <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> On 14/09/2007, Richi Plana wrote: > Who's insisting that IPv6 be disabled in anyone else's system aside from > their own? If you noticed, the only time it was SUGGESTED that IPv6 be > disabled after installation was the first poster. Everyone else after > that was simply asking to make it easier for THEM to disable IPv6 on > their systems. Well, that seemed to be the general tone (disable *by default*). But I forgot the winky, sorry. > Anyway, I'm working on adding such an option to s-c-n. I just needed the > Fedora-sanctioned way of disabling it. So far, it seems to be a > combination of adding a modprobe entry and > modifying /etc/sysconfig/network, but no one really seems sure. Adding an option to disable it would be good. I'd use it myself, until IPv6 is actually supported by the network I'm on (it isn't). I just wouldn't have argued for "by default" by any means. If it's enabled, then when ISPs (and hardware, corporate networks ...) actually support it en masse, Fedora installs are, well, ready. :) From myfedora at richip.dhs.org Fri Sep 14 16:33:57 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:33:57 -0600 Subject: Disable IPv6 by default. In-Reply-To: <20070914122150.47b7a6ad@lumos.localdomain> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> <20070914160229.GQ8380@angus.ind.WPI.EDU> <1189786510.14868.9.camel@localhost6.localdomain6> <20070914122150.47b7a6ad@lumos.localdomain> Message-ID: <1189787637.14868.22.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 12:21 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 10:15:10 -0600 > Richi Plana wrote: > > > > Why don't you just go full-out and remove the network card from > > > your computer? > > > > I'm guessing he wants welcome traffic in and unwelcome traffic out. > > Just use NetworkManager and disable the interface when it's not plugged > in to anything working. :) Anyway, I wasn't even aware that NM had IPv6-specific bits. That's good to hear. I can't wait for s-c-n to finally switch to using NM (and I'm wondering who's working on that and what the current status is). Is there a mailing list, bugzilla entry or wiki that's keeping track of the transition of system-wide network configuration to NM? -- Richi Plana From billcrawford1970 at gmail.com Fri Sep 14 16:35:25 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 14 Sep 2007 17:35:25 +0100 Subject: CD burning faulty In-Reply-To: <200709140950.37854.kwhiskerz@yahoo.ca> References: <200709140950.37854.kwhiskerz@yahoo.ca> Message-ID: <544eb990709140935y74056ff8h5d9411f13031a9e0@mail.gmail.com> On 14/09/2007, kwhiskerz wrote: > Does anyone know what is wrong? The Cd is opened, the cue sheet is sent, then > it is closed and the burning fails, but nothing is ever written to the CD and > the CD is destroyed. The output mentions a "crc error" communicating with the drive. It's possible you have a damaged cable, or something. From sundaram at fedoraproject.org Fri Sep 14 16:32:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 14 Sep 2007 22:02:34 +0530 Subject: Disable IPv6 by default. In-Reply-To: <1189787637.14868.22.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> <20070914160229.GQ8380@angus.ind.WPI.EDU> <1189786510.14868.9.camel@localhost6.localdomain6> <20070914122150.47b7a6ad@lumos.localdomain> <1189787637.14868.22.camel@localhost6.localdomain6> Message-ID: <46EAB7A2.2000509@fedoraproject.org> Richi Plana wrote: Is > there a mailing list, bugzilla entry or wiki that's keeping track of the > transition of system-wide network configuration to NM? http://fedoraproject.org/wiki/Releases/8/FeatureList Rahul From myfedora at richip.dhs.org Fri Sep 14 16:37:23 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:37:23 -0600 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141829.07383.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> Message-ID: <1189787843.14868.26.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 18:29 +0200, Alain PORTAL wrote: > I ask for orphaning lftp because package maintainer doesn't maintain this > package since a long time. How are packages orphaned? And where does one go to adopt orphan packages? I'd love to get my hands dirty by maintaining a package. Might be better than adding a new package (though I'd love to include add gnome-hearts for which I already have a package of 0.2 for). -- Richi Plana From sundaram at fedoraproject.org Fri Sep 14 16:36:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 14 Sep 2007 22:06:06 +0530 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141829.07383.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> Message-ID: <46EAB876.1090600@fedoraproject.org> Alain PORTAL wrote: > Hi, > > I ask for orphaning lftp because package maintainer doesn't maintain this > package since a long time. > > I asked for an updated in june, the 1st, for the 3.5.11 version, released on > 2007-04-11 :-( > https://bugzilla.redhat.com/show_bug.cgi?id=242112 > http://lftp.yar.ru/events.html > > There is now a 3.5.14 release since 2 weeks. > All these releases fix bugs. Follow the AWOL policy http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Rahul From myfedora at richip.dhs.org Fri Sep 14 16:42:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:42:10 -0600 Subject: Disable IPv6 by default. In-Reply-To: <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> Message-ID: <1189788130.14868.32.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 17:32 +0100, Bill Crawford wrote: > Adding an option to disable it would be good. I'd use it myself, until > IPv6 is actually supported by the network I'm on (it isn't). I just > wouldn't have argued for "by default" by any means. If it's enabled, > then when ISPs (and hardware, corporate networks ...) actually support > it en masse, Fedora installs are, well, ready. :) Actually, even though I don't use IPv6, I'd still argue for it to be on "by default". Because the only people who'd care to have it on or off should have the capacity to wade in to the System menus and switch it off. The rest can just be pleasantly surprised when IPv6 gets supported in their infrastructure. I'm just getting tired of manually doing things by hand (though I should really try kickstart one of these days. I understand a lot of preconfiguration can be done before installation these days ... both in low-level subsystems as well as user session ones). -- Richi Plana From jkeating at redhat.com Fri Sep 14 16:42:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 12:42:47 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189787637.14868.22.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189708870.18288.9.camel@localhost.localdomain> <20070913191253.GF1410972@hiwaay.net> <200709141025.31848@rineau.tsetse> <20070914130652.GO8380@angus.ind.WPI.EDU> <46EAA85A.2080704@comsoft.de> <20070914160229.GQ8380@angus.ind.WPI.EDU> <1189786510.14868.9.camel@localhost6.localdomain6> <20070914122150.47b7a6ad@lumos.localdomain> <1189787637.14868.22.camel@localhost6.localdomain6> Message-ID: <20070914124247.011a83e8@lumos.localdomain> On Fri, 14 Sep 2007 10:33:57 -0600 Richi Plana wrote: > Anyway, I wasn't even aware that NM had IPv6-specific bits. That's > good to hear. I can't wait for s-c-n to finally switch to using NM > (and I'm wondering who's working on that and what the current status > is). Is there a mailing list, bugzilla entry or wiki that's keeping > track of the transition of system-wide network configuration to NM? Hrm, I'm not sure if NM actually has anything ipv6 specific, I was just commenting toward disabling the zeroconf stuff. There is the Feature page in the wiki, and right now we're waiting on the progress of the rewrite so that it will actually work with say wireless devices and we can start getting wide spread testing. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Sep 14 16:38:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 14 Sep 2007 22:08:45 +0530 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189787843.14868.26.camel@localhost6.localdomain6> References: <200709141829.07383.alain.portal@free.fr> <1189787843.14868.26.camel@localhost6.localdomain6> Message-ID: <46EAB915.3070703@fedoraproject.org> Richi Plana wrote: > On Fri, 2007-09-14 at 18:29 +0200, Alain PORTAL wrote: >> I ask for orphaning lftp because package maintainer doesn't maintain this >> package since a long time. > > How are packages orphaned? Package maintainers themselves announce that they are orphaning a package and use the package database to abandon it or a package becomes orphaned after someone else uses the AWOL policy. And where does one go to adopt orphan > packages? http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages Rahul From notting at redhat.com Fri Sep 14 16:51:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Sep 2007 12:51:03 -0400 Subject: making config tools use system icons Message-ID: <20070914165103.GA15780@nostromo.devel.redhat.com> Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme. See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools. Do other people think this is worth fixing across the board? Bill From jkeating at redhat.com Fri Sep 14 16:58:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 12:58:11 -0400 Subject: making config tools use system icons In-Reply-To: <20070914165103.GA15780@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> Message-ID: <20070914125811.583b088e@lumos.localdomain> On Fri, 14 Sep 2007 12:51:03 -0400 Bill Nottingham wrote: > Do other people think this is worth fixing across the board? Yes, reduce the size of packages! Make it easy to swap in non-trademarked branding! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Fri Sep 14 16:59:15 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 10:59:15 -0600 Subject: making config tools use system icons In-Reply-To: <20070914165103.GA15780@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> Message-ID: <1189789155.14868.39.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > Most of the python config tools (system-config-*, anaconda) include > their own copies of bluecurve icons. It makes sense to me that they > should use system icons whenever possible, to match the current theme. > > See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example > patch for one of the tools. > > Do other people think this is worth fixing across the board? My personal opinion is yes since this not only will make Fedora look consistent, it will benefit distro spinners who wish to change themes overall, as well. The problem is they have to be filed as bugs against each package (with maybe one bugzilla entry depending on the resolution of all those bugs), and it would probably be marked with a lower priority. -- Richi Plana From johannbg at hi.is Fri Sep 14 17:03:36 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 14 Sep 2007 17:03:36 +0000 Subject: Disable IPv6 by default. In-Reply-To: <1189788130.14868.32.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> Message-ID: <46EABEE8.4080102@hi.is> Richi Plana wrote: > On Fri, 2007-09-14 at 17:32 +0100, Bill Crawford wrote: > >> Adding an option to disable it would be good. I'd use it myself, until >> IPv6 is actually supported by the network I'm on (it isn't). I just >> wouldn't have argued for "by default" by any means. If it's enabled, >> then when ISPs (and hardware, corporate networks ...) actually support >> it en masse, Fedora installs are, well, ready. :) >> > > Actually, even though I don't use IPv6, I'd still argue for it to be on > "by default". Because the only people who'd care to have it on or off > should have the capacity to wade in to the System menus and switch it > off. The rest can just be pleasantly surprised when IPv6 gets supported > in their infrastructure. I'm just getting tired of manually doing things > by hand (though I should really try kickstart one of these days. I > understand a lot of preconfiguration can be done before installation > these days ... both in low-level subsystems as well as user session > ones). > -- > > Richi Plana > > Reminder on the Topic.. Should we or should we not disable IPv6 during installation/Anaconda Should we or should we not allow the user to decide during installation ( Anaconda or after installation S-C-N ). * Default left as is support both * User can choose whether he wants to use either IPv6 or IPv4 * If users decides to choose either one the other one is properly turned off! * If user choose either one and service explicitly depend on either one the system could notify the user like.. Service A could not be started because it relies on IPv6 and IPv6 is currently disabled! To use this service ( service A ) please enabled it in system-config-network and then restart the service ( Service A ) If we decided not to allow the user to choose, where are we gonna draw the line on how *smarter* then the user is the system is supposed to be??? Look at M$ it takes all the intellect user decisions for the users and then questions everything else the user does ( are you sure you want to do this and that )!!!! When user is given option to turn something on ( enable/disable/start/stop ) the "program" is started and everything that relies on it as well or on demand and when that "program" is stopped then it and everything related should stop as well, ( programs should be notified and that option in them should be turned off so they can stop waiting and wondering if they receiving instruction regarding something that has been turned off). If not were just wasting resources... Best regards Johann B. Ps. For all you IPv6 Fan boys out there how well is it working when implemented??? How well is it working out site your LAN/WAN and communicating with the rest off the world??? How well is strictly use of IPv6 working in communicating out site LAN/WAN deployment.. How well are ( M$ ) clients handling falling to IPv4 when there is no IPv6 AAAA records in DNS servers. For a fact company's aren't gonna switch unless ( forced or business wize ) they have to I vote turn it of by default. Best regards.. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From jkeating at redhat.com Fri Sep 14 17:07:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 13:07:10 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46EABEE8.4080102@hi.is> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> Message-ID: <20070914130710.0c1921eb@lumos.localdomain> On Fri, 14 Sep 2007 17:03:36 +0000 ""J?hann B. Gu?mundsson"" wrote: > Should we or should we not disable IPv6 during installation/Anaconda No, it should stay enabled by default. > Should we or should we not allow the user to decide during > installation ( Anaconda or after installation S-C-N ). post-install yes, perhaps through s-c-n, or NetworkManager. And we should still fix any bugs that show up due to having it enabled but not actively used. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alain.portal at free.fr Fri Sep 14 17:09:07 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Fri, 14 Sep 2007 19:09:07 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAB876.1090600@fedoraproject.org> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> Message-ID: <200709141909.08387.alain.portal@free.fr> Le vendredi 14 septembre 2007, Rahul Sundaram a ?crit : > Follow the AWOL policy > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Thanks for the pointer! Do I have to follow the full policy or can I short some steps? I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=242112 on 2007-06-01 for a 3.5.11 release, updated that bug on 2007-08-19 for a 3.5.12 release without any answer from maintainer who commited an updated spec file to answer to the mass rebuild request. Unfortunately, I'm not sure to be able to maintain this package (I didn't try), but if nobody take it, I'll try. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 alex at tvtransilvania.ro Fri Sep 14 17:15:20 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Fri, 14 Sep 2007 20:15:20 +0300 Subject: gnomebaker 0.6.1-4 oddity Message-ID: <46EAC1A8.3090005@tvtransilvania.ro> Hello, Since last update gnomebaker doest not start. I don't know how to make a proper BZ entry since I don't have any errors other than: ** (gnomebaker:8039): WARNING **: Add decoder bethsoftvid (107) please ** (gnomebaker:8039): WARNING **: Add decoder c93 (106) please ** (gnomebaker:8039): WARNING **: Add decoder dnxhd (103) please ** (gnomebaker:8039): WARNING **: Add decoder dsicinvideo (97) please ** (gnomebaker:8039): WARNING **: Add decoder dxa (102) please ** (gnomebaker:8039): WARNING **: Add decoder gif (100) please ** (gnomebaker:8039): WARNING **: Add decoder kmvc (88) please ** (gnomebaker:8039): WARNING **: Add decoder nuv (87) please ** (gnomebaker:8039): WARNING **: Add decoder ptx (108) please ** (gnomebaker:8039): WARNING **: Add decoder sgi (105) please ** (gnomebaker:8039): WARNING **: Add decoder smackvid (86) please ** (gnomebaker:8039): WARNING **: Add decoder targa (96) please ** (gnomebaker:8039): WARNING **: Add decoder thp (104) please ** (gnomebaker:8039): WARNING **: Add decoder tiertexseqvideo (98) please ** (gnomebaker:8039): WARNING **: Add decoder tiff (99) please ** (gnomebaker:8039): WARNING **: Add decoder VMware video (92) please ** (gnomebaker:8039): WARNING **: Add decoder atrac 3 (86050) please ** (gnomebaker:8039): WARNING **: Add decoder dsicinaudio (86045) please ** (gnomebaker:8039): WARNING **: Add decoder imc (86046) please ** (gnomebaker:8039): WARNING **: Add decoder gsm (86037) please ** (gnomebaker:8039): WARNING **: Add decoder gsm_ms (86049) please ** (gnomebaker:8039): WARNING **: Add decoder mpc sv7 (86047) please ** (gnomebaker:8039): WARNING **: Add decoder smackaud (86042) please ** (gnomebaker:8039): WARNING **: Add decoder wavpack (86044) please ** (gnomebaker:8039): WARNING **: Add decoder adpcm_thp (69650) please I'm running latest rawhide (20070914) and I could really use some pointers. TIA, Alex From j.w.r.degoede at hhs.nl Fri Sep 14 17:17:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 14 Sep 2007 19:17:55 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141909.08387.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> Message-ID: <46EAC243.1030704@hhs.nl> Alain PORTAL wrote: > Le vendredi 14 septembre 2007, Rahul Sundaram a ?crit : > >> Follow the AWOL policy >> >> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > Thanks for the pointer! > > Do I have to follow the full policy or can I short some steps? > I opened the bug > https://bugzilla.redhat.com/show_bug.cgi?id=242112 > on 2007-06-01 for a 3.5.11 release, updated that bug on 2007-08-19 for a > 3.5.12 release without any answer from maintainer who commited an updated > spec file to answer to the mass rebuild request. > > Unfortunately, I'm not sure to be able to maintain this package (I didn't > try), but if nobody take it, I'll try. > Please, Adopt it, as anyone should know, if a package is written in C and a bug can be reproduced by someone other then the reporter, I'm always willing to help out and fix it. I wonder if we need to have a wiki entry for package maintainers which says: "I have a bug I cannot fix even though I'm an excellent packager as I'm unfortunately not a programming guru" With as answers: 1) Ask for help on fedora-devel-list 2) If the app is written in C ask Hans. And I'm _not_ joking, various packagers already know to find me, and I don't mind if others find out about this too. Ofcourse there will be a point when we need a Hans version 2 / a backup Hans, volunteers? Regards, Hans From johannbg at hi.is Fri Sep 14 17:21:27 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 14 Sep 2007 17:21:27 +0000 Subject: Disable IPv6 by default. In-Reply-To: <20070914130710.0c1921eb@lumos.localdomain> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> <20070914130710.0c1921eb@lumos.localdomain> Message-ID: <46EAC317.2060803@hi.is> Jesse Keating wrote: > On Fri, 14 Sep 2007 17:03:36 +0000 > ""J?hann B. Gu?mundsson"" wrote: > > >> Should we or should we not disable IPv6 during installation/Anaconda >> > > No, it should stay enabled by default. > > >> Should we or should we not allow the user to decide during >> installation ( Anaconda or after installation S-C-N ). >> > > post-install yes, perhaps through s-c-n, or NetworkManager. And we > should still fix any bugs that show up due to having it enabled but not > actively used. > > Then *manually* disabled, module should be blacklisted and any services that are IPv6 dependent or use IPv6 ( for example ip6tables ) should then be disabled or that *feature in them. If user turns something off that something stay turned off ( and thing related/depend on it IPv6 or otherwize ). Let's not waste cpu/ram/space/power on something that is not in use no matter how small the % of cpu/ram/space/power is. Best regard Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From ivazqueznet at gmail.com Fri Sep 14 17:22:29 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 14 Sep 2007 13:22:29 -0400 Subject: making config tools use system icons In-Reply-To: <20070914165103.GA15780@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> Message-ID: <1189790550.3130.14.camel@ignacio.lan> On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > Most of the python config tools (system-config-*, anaconda) include > their own copies of bluecurve icons. It makes sense to me that they > should use system icons whenever possible, to match the current theme. +1 to making it match/use the current theme, but -1 to using generic system icons. Pulling the individual icons out of the packages and into redhat-artwork (or perhaps system-config-artwork?) is fine, but I still think the distinctiveness of their icons versus the generic control panel icons is a good thing. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 Fri Sep 14 17:29:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Sep 2007 09:29:48 -0800 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC243.1030704@hhs.nl> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> Message-ID: <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> On 9/14/07, Hans de Goede wrote: > With as answers: > 1) Ask for help on fedora-devel-list > 2) If the app is written in C ask Hans. I think a broken code response group is a good idea. Generalize it a bit so we can gather a group of people who have skillz in a number of different programming subareas.. not just C. -jef"Such a group would need a kickass acronym and t-shirts"spaleta From myfedora at richip.dhs.org Fri Sep 14 17:30:07 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 11:30:07 -0600 Subject: Disable IPv6 by default. In-Reply-To: <20070914130710.0c1921eb@lumos.localdomain> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> <20070914130710.0c1921eb@lumos.localdomain> Message-ID: <1189791007.14868.58.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 13:07 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 17:03:36 +0000 > ""J?hann B. Gu?mundsson"" wrote: > > > Should we or should we not disable IPv6 during installation/Anaconda > > No, it should stay enabled by default. Agree. Until someone somehow adds a "smart" system for determining whether IPv6 is active or not on-the-fly on the network and loading or releasing resources as needed, then I suggest it remain on for now. If someone is willing to work on that "smart" system, perhaps then the decision to default should be re-evaluated. > > Should we or should we not allow the user to decide during > > installation ( Anaconda or after installation S-C-N ). > > post-install yes, perhaps through s-c-n, or NetworkManager. And we > should still fix any bugs that show up due to having it enabled but not > actively used. Agree. J?hann raised two issues regarding post-install: "allow/disallow" and "make it easy". I'm for freedom so of course I would say that that option should always be made available. I'm also for making it easy if someone would step up to the plate and and add that option to system-config-network-cmd (and maybe even -tui and -gui). -- Richi Plana From denis at poolshark.org Fri Sep 14 17:27:40 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 14 Sep 2007 19:27:40 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> Message-ID: <46EAC48C.9040909@poolshark.org> Jeff Spaleta wrote: > On 9/14/07, Hans de Goede wrote: >> With as answers: >> 1) Ask for help on fedora-devel-list >> 2) If the app is written in C ask Hans. > > I think a broken code response group is a good idea. > > Generalize it a bit so we can gather a group of people who have skillz > in a number of different programming subareas.. not just C. > > -jef"Such a group would need a kickass acronym and t-shirts"spaleta I've also helped out a C/C++ related stuff on a few occasions. So there is a Bug Squad reponse team :-) From jameshubbard at gmail.com Fri Sep 14 17:33:22 2007 From: jameshubbard at gmail.com (James Hubbard) Date: Fri, 14 Sep 2007 13:33:22 -0400 Subject: Disable IPv6 by default. In-Reply-To: <46EABEE8.4080102@hi.is> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> Message-ID: On 9/14/07, "J?hann B. Gu?mundsson" wrote: > Ps. > For all you IPv6 Fan boys out there how well is it working when > implemented??? > How well is it working out site your LAN/WAN and communicating > with the rest off the world??? > How well is strictly use of IPv6 working in communicating out > site LAN/WAN deployment.. > How well are ( M$ ) clients handling falling to IPv4 when there > is no IPv6 AAAA records in DNS servers. > > For a fact company's aren't gonna switch unless ( forced or > business wize ) they have to > > I vote turn it of by default. IPV6 is coming and it's not far away. Some will not update their fedora systems for a long time even if they can't get support. (I know of several FC 2, 3, 4 installations.) It's important for systems that can support ipv6 to just work when it does become popular. I suggest that you search for some information. I used google with the terms "ipv6 comcast". Here are some links: http://www.nanog.org/mtg-0606/durand.html http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_management.pdf http://www.redhat.com/promo/summit/2007/innovate/winners/comcast.html Already enabled on some US wireless networks. http://blogs.technet.com/ipv6/archive/2007/05/06/mythbusters-1-no-one-is-using-ipv6.aspx From tmz at pobox.com Fri Sep 14 17:34:32 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 14 Sep 2007 13:34:32 -0400 Subject: Calling Paul F. Johnson Message-ID: <20070914173432.GH19611@psilocybe.teonanacatl.org> Are you out there Paul? Anyone else know how to contact Paul? https://bugzilla.redhat.com/237286 has been open for many months without any comment. I pinged and attached a potential fix for it when I ran into it last month. I sent a private email 2 weeks ago asking for comment on the bug. No reply as of yet. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Many people lose their tempers merely by seeing you keep yours. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tmz at pobox.com Fri Sep 14 17:38:24 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 14 Sep 2007 13:38:24 -0400 Subject: AWOL policy (was Re: Please, make lftp orphaned!!!) In-Reply-To: <46EAB876.1090600@fedoraproject.org> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> Message-ID: <20070914173824.GI19611@psilocybe.teonanacatl.org> Rahul Sundaram wrote: > Follow the AWOL policy > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers I updated the page to change a few more references to the maintainers list to this list. I also changed references to owners.list to the CVSAdminprocedure. The latter change may well already be outdated as well, now that the PackageDB is open. Anyone that knows the current procedures well may want to double check that the page is accurate. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I just want revenge. Is that so wrong? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jima at beer.tclug.org Fri Sep 14 17:42:06 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 14 Sep 2007 12:42:06 -0500 (CDT) Subject: Calling Paul F. Johnson In-Reply-To: <20070914173432.GH19611@psilocybe.teonanacatl.org> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> Message-ID: On Fri, 14 Sep 2007, Todd Zullinger wrote: > Are you out there Paul? Anyone else know how to contact Paul? I've had him CC'd on a bug (BZ#253050) since 2007-08-17 with no response, and tried emailing him directly on 2007-08-28. Nada. I hope nothing bad happened to him. :-( Jima From limb at jcomserv.net Fri Sep 14 17:14:57 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 14 Sep 2007 12:14:57 -0500 (CDT) Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC243.1030704@hhs.nl> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> Message-ID: <53917.63.85.68.164.1189790097.squirrel@mail.jcomserv.net> > Alain PORTAL wrote: >> Le vendredi 14 septembre 2007, Rahul Sundaram a ?crit : >> >>> Follow the AWOL policy >>> >>> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers >> >> Thanks for the pointer! >> >> Do I have to follow the full policy or can I short some steps? >> I opened the bug >> https://bugzilla.redhat.com/show_bug.cgi?id=242112 >> on 2007-06-01 for a 3.5.11 release, updated that bug on 2007-08-19 for a >> 3.5.12 release without any answer from maintainer who commited an >> updated >> spec file to answer to the mass rebuild request. >> >> Unfortunately, I'm not sure to be able to maintain this package (I >> didn't >> try), but if nobody take it, I'll try. >> > > > Please, > > Adopt it, as anyone should know, if a package is written in C and a bug > can be > reproduced by someone other then the reporter, I'm always willing to help > out > and fix it. > > I wonder if we need to have a wiki entry for package maintainers which > says: > "I have a bug I cannot fix even though I'm an excellent packager as I'm > unfortunately not a programming guru" > > With as answers: > 1) Ask for help on fedora-devel-list > 2) If the app is written in C ask Hans. > > > And I'm _not_ joking, various packagers already know to find me, and I > don't > mind if others find out about this too. Ofcourse there will be a point > when we > need a Hans version 2 / a backup Hans, volunteers? No, but I could be the PHP Hans. For C, I'm jsut a Hans user. :) > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Fri Sep 14 17:41:26 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 14 Sep 2007 19:41:26 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC48C.9040909@poolshark.org> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> Message-ID: <46EAC7C6.1030802@hhs.nl> Denis Leroy wrote: > Jeff Spaleta wrote: >> On 9/14/07, Hans de Goede wrote: >>> With as answers: >>> 1) Ask for help on fedora-devel-list >>> 2) If the app is written in C ask Hans. >> >> I think a broken code response group is a good idea. >> >> Generalize it a bit so we can gather a group of people who have skillz >> in a number of different programming subareas.. not just C. >> >> -jef"Such a group would need a kickass acronym and t-shirts"spaleta > > I've also helped out a C/C++ related stuff on a few occasions. So there > is a Bug Squad reponse team :-) > Okay, so we have 2 c / c++ people for routing help request too (my C is better then my C++ though), what about other languages? I think that just using the list for help requests probably is best, last time there was an issue I was planning on fixing it and Dennis beat me to it (before I even started looking) so just sending things to the list seems to work well, otherwise we will need some complicated dispatch mechanism for help requests to reach the proper persons. I think that we just need to stimulate sending out help requests more. Every now and then I go on a bug hunt in bugzilla and find many bugs which are usually fixable within the hour for someone with the necessary skills and willing to do the job. If this encouraging of asking for help leads to too much noise on this list then we can start a fedora-devel-help list where people prepared to help others like me and Dennis can subscribe too. Regards, Hans From limb at jcomserv.net Fri Sep 14 17:19:48 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 14 Sep 2007 12:19:48 -0500 (CDT) Subject: Please, make lftp orphaned!!! In-Reply-To: <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> Message-ID: <58762.63.85.68.164.1189790388.squirrel@mail.jcomserv.net> > On 9/14/07, Hans de Goede wrote: >> With as answers: >> 1) Ask for help on fedora-devel-list >> 2) If the app is written in C ask Hans. > > I think a broken code response group is a good idea. > > Generalize it a bit so we can gather a group of people who have skillz > in a number of different programming subareas.. not just C. Fedora Repeatably Irregular Code Killers? I like the t-shirts idea. Then, if someone has a problem, they just look around, and find someone wearing. . .never mind. > -jef"Such a group would need a kickass acronym and t-shirts"spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From alain.portal at free.fr Fri Sep 14 17:49:26 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Fri, 14 Sep 2007 19:49:26 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC243.1030704@hhs.nl> References: <200709141829.07383.alain.portal@free.fr> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> Message-ID: <200709141949.26744.alain.portal@free.fr> Le vendredi 14 septembre 2007, Hans de Goede a ?crit : > Alain PORTAL wrote: > > Le vendredi 14 septembre 2007, Rahul Sundaram a ?crit : > >> Follow the AWOL policy > >> > >> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > > > Thanks for the pointer! > > > > Do I have to follow the full policy or can I short some steps? > > I opened the bug > > https://bugzilla.redhat.com/show_bug.cgi?id=242112 > > on 2007-06-01 for a 3.5.11 release, updated that bug on 2007-08-19 for a > > 3.5.12 release without any answer from maintainer who commited an updated > > spec file to answer to the mass rebuild request. > > > > Unfortunately, I'm not sure to be able to maintain this package (I didn't > > try), but if nobody take it, I'll try. > > Please, > > Adopt it, as anyone should know, if a package is written in C and a bug can > be reproduced by someone other then the reporter, I'm always willing to > help out and fix it. > > I wonder if we need to have a wiki entry for package maintainers which > says: "I have a bug I cannot fix even though I'm an excellent packager as > I'm unfortunately not a programming guru" > > With as answers: > 1) Ask for help on fedora-devel-list > 2) If the app is written in C ask Hans. > > > And I'm _not_ joking, various packagers already know to find me, and I > don't mind if others find out about this too. Ofcourse there will be a > point when we need a Hans version 2 / a backup Hans, volunteers? OK, if noboby ask for maintaining this package during the next 72h, I'll take it. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 johannbg at hi.is Fri Sep 14 17:52:47 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 14 Sep 2007 17:52:47 +0000 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> Message-ID: <46EACA6F.9080203@hi.is> James Hubbard wrote: > On 9/14/07, "J?hann B. Gu?mundsson" wrote: > >> Ps. >> For all you IPv6 Fan boys out there how well is it working when >> implemented??? >> How well is it working out site your LAN/WAN and communicating >> with the rest off the world??? >> How well is strictly use of IPv6 working in communicating out >> site LAN/WAN deployment.. >> How well are ( M$ ) clients handling falling to IPv4 when there >> is no IPv6 AAAA records in DNS servers. >> >> For a fact company's aren't gonna switch unless ( forced or >> business wize ) they have to >> >> I vote turn it of by default. >> > > IPV6 is coming and it's not far away. Some will not update their > fedora systems for a long time even if they can't get support. (I > know of several FC 2, 3, 4 installations.) It's important for systems > that can support ipv6 to just work when it does become popular. > > Wanted to know from real setups how the clients are handling failing to IPv4 when for example and an IPv6 AAAA dns record isn't available and the client has to fall back to IPv4. As in is it all working in the IPv6 Promised land.... IPv6 only LAN/WAN ( site to site ) setups work like charm everbody knows that. The real *f* happens when you have deal with using anything outsite your LAN/WAN. And company's cant be forced to switch or support both IPv4 and IPv6..... > I suggest that you search for some information. I used google with > the terms "ipv6 comcast". Here are some links: > http://www.nanog.org/mtg-0606/durand.html > http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_management.pdf > http://www.redhat.com/promo/summit/2007/innovate/winners/comcast.html > > Already enabled on some US wireless networks. > http://blogs.technet.com/ipv6/archive/2007/05/06/mythbusters-1-no-one-is-using-ipv6.aspx > > Dont need google start here http://www.icann.org http://www.iana.org http://www.lacnic.net http://www.arin.net http://www.root-servers.org Best regards Johann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From myfedora at richip.dhs.org Fri Sep 14 17:55:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 11:55:06 -0600 Subject: Disable IPv6 by default. In-Reply-To: <46EAC317.2060803@hi.is> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> <20070914130710.0c1921eb@lumos.localdomain> <46EAC317.2060803@hi.is> Message-ID: <1189792506.14868.67.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 17:21 +0000, "J?hann B. Gu?mundsson" wrote: > Then *manually* disabled, module should be blacklisted and any services > that are IPv6 > dependent or use IPv6 ( for example ip6tables ) should then be disabled > or that *feature in them. Well, if we can agree that the process for switching it off is: # echo blacklist ipv6 >> /etc/modprobe.d/blacklist # sed -ie /NETWORKING_IPV6=/s/yes/no/ /etc/sysconfig/network || echo NETWORKING_IPV6=no >> /etc/sysconfig/network # chkconfig ip6tables off (note that the commands above aren't supposed to work but is just my way of stating what needs to be done) then perhaps I can work on adding those options to s-c-n. I'm not sure what is required of NM, for now. -- Richi Plana From jkeating at redhat.com Fri Sep 14 17:55:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 13:55:24 -0400 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC7C6.1030802@hhs.nl> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> Message-ID: <20070914135524.197d7d02@lumos.localdomain> On Fri, 14 Sep 2007 19:41:26 +0200 Hans de Goede wrote: > Okay, so we have 2 c / c++ people for routing help request too (my C > is better then my C++ though), what about other languages? We definitely need a Python Squad. I can't offer a whole lot to it, but I'd love to watch the traffic and learn a thing or to along the way. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrewparker at bigfoot.com Fri Sep 14 17:54:39 2007 From: andrewparker at bigfoot.com (Andrew Parker) Date: Fri, 14 Sep 2007 13:54:39 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46E959F5.4010804@fedoraproject.org> References: <46E959F5.4010804@fedoraproject.org> Message-ID: <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> On 9/13/07, Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/F8Test2/ReleaseNotes > > I have updated the release notes with information on changes new to test > 2. If there is anything important I have missed, please edit the wiki or > let me know. Correct me if I'm wrong, but IIRC the inclusion of PulseAudio breaks audio in Adobe Flash? Would it be worth adding this so that we have something to point people to instead of explaining it every time it comes up? From nicolas.mailhot at laposte.net Fri Sep 14 17:57:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Sep 2007 19:57:30 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAC7C6.1030802@hhs.nl> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> Message-ID: <1189792650.369.5.camel@rousalka.dyndns.org> Le vendredi 14 septembre 2007 ? 19:41 +0200, Hans de Goede a ?crit : > I think that just using the list for help requests probably is best, last time > there was an issue I was planning on fixing it and Dennis beat me to it (before > I even started looking) so just sending things to the list seems to work well, > otherwise we will need some complicated dispatch mechanism for help requests to > reach the proper persons. IMHO fedora-devel traffic is big enough without this, but there's no need for a complicated dispatch mechanism : just create a fedora-coderescue-list with no language differentiation, and have would-be helpers subscribe to it. -- 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 limb at jcomserv.net Fri Sep 14 17:30:37 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 14 Sep 2007 12:30:37 -0500 (CDT) Subject: Please, make lftp orphaned!!! In-Reply-To: <1189792650.369.5.camel@rousalka.dyndns.org> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <1189792650.369.5.camel@rousalka.dyndns.org> Message-ID: <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> > > Le vendredi 14 septembre 2007 ? 19:41 +0200, Hans de Goede a ??crit : > >> I think that just using the list for help requests probably is best, >> last time >> there was an issue I was planning on fixing it and Dennis beat me to it >> (before >> I even started looking) so just sending things to the list seems to work >> well, >> otherwise we will need some complicated dispatch mechanism for help >> requests to >> reach the proper persons. > > IMHO fedora-devel traffic is big enough without this, but there's no > need for a complicated dispatch mechanism : just create a > fedora-coderescue-list with no language differentiation, and have > would-be helpers subscribe to it. +1 > -- > Nicolas Mailhot > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From mtasaka at ioa.s.u-tokyo.ac.jp Fri Sep 14 17:59:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 15 Sep 2007 02:59:42 +0900 Subject: Calling Paul F. Johnson In-Reply-To: <20070914173432.GH19611@psilocybe.teonanacatl.org> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> Message-ID: <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> Todd Zullinger wrote, at 09/15/2007 02:34 AM +9:00: > Are you out there Paul? Anyone else know how to contact Paul? > Umm.. Actually Paul does not seem to react to any bugzilla reports for months, however it seems that he is reading fedora-list. For example: https://www.redhat.com/archives/fedora-list/2007-August/msg03839.html Regards, Mamoru From jspaleta at gmail.com Fri Sep 14 18:06:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Sep 2007 10:06:16 -0800 Subject: Please, make lftp orphaned!!! In-Reply-To: <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <1189792650.369.5.camel@rousalka.dyndns.org> <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> Message-ID: <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> On 9/14/07, Jon Ciesla wrote: > +1 Is there a potential bugzilla enhancement idea here as well? Like a settable flag that the bug owner can use to send the bat signal up into the air for the code squad to see? -jef From limb at jcomserv.net Fri Sep 14 17:43:05 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 14 Sep 2007 12:43:05 -0500 (CDT) Subject: Please, make lftp orphaned!!! In-Reply-To: <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <1189792650.369.5.camel@rousalka.dyndns.org> <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> Message-ID: <20773.63.85.68.164.1189791785.squirrel@mail.jcomserv.net> > On 9/14/07, Jon Ciesla wrote: >> +1 > > Is there a potential bugzilla enhancement idea here as well? > Like a settable flag that the bug owner can use to send the bat signal > up into the air for the code squad to see? +1 Can we have cars, like a certain other Squad? Maybe something a bit cooler though, like a Prius, or the Tumbler(?) from Batman Begins. Or maybe just open the bugzilla report in a new tab, instead of via a crosstown chase leaving a wake of devastation. Yeah, that makes more sense. > -jef > -- novus ordo absurdum From notting at redhat.com Fri Sep 14 18:13:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Sep 2007 14:13:54 -0400 Subject: making config tools use system icons In-Reply-To: <1189790550.3130.14.camel@ignacio.lan> References: <20070914165103.GA15780@nostromo.devel.redhat.com> <1189790550.3130.14.camel@ignacio.lan> Message-ID: <20070914181354.GA15896@nostromo.devel.redhat.com> Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: > On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > > Most of the python config tools (system-config-*, anaconda) include > > their own copies of bluecurve icons. It makes sense to me that they > > should use system icons whenever possible, to match the current theme. > > +1 to making it match/use the current theme, but -1 to using generic > system icons. > > Pulling the individual icons out of the packages and into redhat-artwork > (or perhaps system-config-artwork?) is fine, but I still think the > distinctiveness of their icons versus the generic control panel icons is > a good thing. The problem is that doesn't actually help - you'd need to do a version of the icon for each theme, which is something I'd like to avoid. Right now, you boot up a *stock* desktop, and you have the gnome icons (in the GNOME style), the config tool icons (in the bluecurve style), and the puplet icons (in the echo style). That's *ugly*. Bill From ivazqueznet at gmail.com Fri Sep 14 18:17:53 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 14 Sep 2007 14:17:53 -0400 Subject: rpms/gstreamer-python/devel gstreamer-python-0.10.8-exit.patch, NONE, 1.1 gstreamer-python.spec, 1.18, 1.19 In-Reply-To: <200709141811.l8EIBC7v021072@cvs-int.fedora.redhat.com> References: <200709141811.l8EIBC7v021072@cvs-int.fedora.redhat.com> Message-ID: <1189793873.3130.16.camel@ignacio.lan> On Fri, 2007-09-14 at 14:11 -0400, Denis Leroy wrote: > Log Message: > Added patch to avoid crash on exit > > gstreamer-python-0.10.8-exit.patch: > > --- NEW FILE gstreamer-python-0.10.8-exit.patch --- > --- gst-python-0.10.8/gst/gstmodule.c 2007/07/28 14:26:54 1.46 > +++ gst-python-0.10.8/gst/gstmodule.c 2007/09/11 11:49:50 1.47 > @@ -266,8 +266,6 @@ > > g_timeout_add_full (0, 100, python_do_pending_calls, NULL, NULL); > > - atexit(gst_deinit); > - > if (PyErr_Occurred ()) { > Py_FatalError ("can't initialize module gst"); > } Yow. Where is the information on this crash, and why is removing the shutdown procedure the "correct" fix? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 myfedora at richip.dhs.org Fri Sep 14 18:14:28 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 12:14:28 -0600 Subject: Please, make lftp orphaned!!! In-Reply-To: <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <1189792650.369.5.camel@rousalka.dyndns.org> <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> Message-ID: <1189793668.14868.71.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 10:06 -0800, Jeff Spaleta wrote: > On 9/14/07, Jon Ciesla wrote: > > +1 > > Is there a potential bugzilla enhancement idea here as well? > Like a settable flag that the bug owner can use to send the bat signal > up into the air for the code squad to see? Good idea. Maybe just change Bugzilla status to "NEEDSHELP" and bugzilla can send an email with the proper link back to the bugzilla page to the proper mailing list. -- Richi Plana From myfedora at richip.dhs.org Fri Sep 14 18:18:34 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 12:18:34 -0600 Subject: making config tools use system icons In-Reply-To: <20070914165103.GA15780@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> Message-ID: <1189793914.14868.75.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example > patch for one of the tools. Good approach, but I would suggest that instead of falling back to the bluecurve icon, it should fall back to some generic icon in the icon theme. Thereby reducing the dependency on bluecurve. We can't expect all theme-makers to create icons for the various applets, apps, etc. and a fallback default icon is a good remind of what's missing that still looks okay. -- Richi Plana From denis at poolshark.org Fri Sep 14 18:17:48 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 14 Sep 2007 20:17:48 +0200 Subject: rpms/gstreamer-python/devel gstreamer-python-0.10.8-exit.patch, NONE, 1.1 gstreamer-python.spec, 1.18, 1.19 In-Reply-To: <1189793873.3130.16.camel@ignacio.lan> References: <200709141811.l8EIBC7v021072@cvs-int.fedora.redhat.com> <1189793873.3130.16.camel@ignacio.lan> Message-ID: <46EAD04C.5060707@poolshark.org> Ignacio Vazquez-Abrams wrote: > On Fri, 2007-09-14 at 14:11 -0400, Denis Leroy wrote: >> Log Message: >> Added patch to avoid crash on exit >> >> gstreamer-python-0.10.8-exit.patch: >> >> --- NEW FILE gstreamer-python-0.10.8-exit.patch --- >> --- gst-python-0.10.8/gst/gstmodule.c 2007/07/28 14:26:54 1.46 >> +++ gst-python-0.10.8/gst/gstmodule.c 2007/09/11 11:49:50 1.47 >> @@ -266,8 +266,6 @@ >> >> g_timeout_add_full (0, 100, python_do_pending_calls, NULL, NULL); >> >> - atexit(gst_deinit); >> - >> if (PyErr_Occurred ()) { >> Py_FatalError ("can't initialize module gst"); >> } > > Yow. Where is the information on this crash, and why is removing the > shutdown procedure the "correct" fix? Sorry, I forgot to mention the bugzilla entry in the log: https://bugzilla.redhat.com/show_bug.cgi?id=287851 From rc040203 at freenet.de Fri Sep 14 17:00:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 14 Sep 2007 19:00:59 +0200 Subject: rawhide report: 20070912 changes In-Reply-To: <46EAB39B.1030602@gmail.com> References: <1189675566.3157.365.camel@mccallum.corsepiu.local> <1189694553.10318.8.camel@localhost6.localdomain6> <1189696132.3157.462.camel@mccallum.corsepiu.local> <1189697140.10318.35.camel@localhost6.localdomain6> <1189697829.3157.469.camel@mccallum.corsepiu.local> <20070913162806.GA1318@redhat.com> <544eb990709140829j48d37625t19cd49726ab87f81@mail.gmail.com> <46EAB39B.1030602@gmail.com> Message-ID: <1189789259.3157.629.camel@mccallum.corsepiu.local> On Fri, 2007-09-14 at 11:15 -0500, Les Mikesell wrote: > Bill Crawford wrote: > > On 13/09/2007, Kevin Kofler wrote: > >> Nalin Dahyabhai redhat.com> writes: > >>> Forgive me for wading in here, but upstream *has* to be where .pc files > >>> show up, and if they don't show up there, we absolutely shouldn't be > >>> adding them to binary packages. I believe this very strongly. > >> But there are actually cases where .pc files are being added in Fedora > >> packages, for reasons such as the upstream foo-config script not being > >> multilib-safe (so it gets replaced with multilibbed .pc files and a wrapper > >> foo-config script which just calls pkgconfig). There are also other reasons for > >> adding .pc files in the distribution. > > > > I think Nalin nailed the salient point: if the upstream doesn't ship a > > .pc, then packages building against it shouldn't be relying on there > > being one. I'll agree it's a PITA that upstream won't but that's a > > completely different issue. In the meantime, Ralf's right, whether > > anyone thinks he is being brusque or not. > > But this was never a case where "upstream won't", it was that "upstream > hasn't done it yet" and apparently wasn't informed by the packager who > should know the most about the distro's needs that it was needed. Facts are: * Upstream shipped *.pc's with OSG-1 * Upstream does not ship *.pc's with their OSG-2 tarballs * Upstream has not yet added *.pc's to their (bleeding edge) SVN. Ralf From notting at redhat.com Fri Sep 14 18:29:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Sep 2007 14:29:38 -0400 Subject: making config tools use system icons In-Reply-To: <1189793914.14868.75.camel@localhost6.localdomain6> References: <20070914165103.GA15780@nostromo.devel.redhat.com> <1189793914.14868.75.camel@localhost6.localdomain6> Message-ID: <20070914182937.GB15896@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > > See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example > > patch for one of the tools. > > Good approach, but I would suggest that instead of falling back to the > bluecurve icon, it should fall back to some generic icon in the icon > theme. Thereby reducing the dependency on bluecurve. We can't expect all > theme-makers to create icons for the various applets, apps, etc. and a > fallback default icon is a good remind of what's missing that still > looks okay. The bluecurve icon in this case is in the package itself. Bill From katzj at redhat.com Fri Sep 14 18:37:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 14 Sep 2007 14:37:42 -0400 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141949.26744.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <200709141949.26744.alain.portal@free.fr> Message-ID: <1189795062.14591.32.camel@localhost.localdomain> On Fri, 2007-09-14 at 19:49 +0200, Alain PORTAL wrote: > OK, if noboby ask for maintaining this package during the next 72h, I'll take > it. FWIW, 72 hours on a Friday afternoon is somewhat short as far as time is concerned. I've done a side channel ping to try to get the maintainer's attention Jeremy From katzj at redhat.com Fri Sep 14 18:40:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 14 Sep 2007 14:40:48 -0400 Subject: making config tools use system icons In-Reply-To: <20070914165103.GA15780@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> Message-ID: <1189795248.14591.36.camel@localhost.localdomain> On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > Most of the python config tools (system-config-*, anaconda) include > their own copies of bluecurve icons. It makes sense to me that they > should use system icons whenever possible, to match the current theme. > > See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example > patch for one of the tools. > > Do other people think this is worth fixing across the board? Yeah, it's probably worth doing. And at the same time, switching to using the fdo standard icon names[1] is also worthwhile where doable. And as an added benefit, it makes the code quite a bit simpler. Jeremy [1] http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html -- most of system-config-* are from before the existence of the spec, so the fact that they don't follow it is hardly surprising From alain.portal at free.fr Fri Sep 14 19:10:36 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Fri, 14 Sep 2007 21:10:36 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189795062.14591.32.camel@localhost.localdomain> References: <200709141829.07383.alain.portal@free.fr> <200709141949.26744.alain.portal@free.fr> <1189795062.14591.32.camel@localhost.localdomain> Message-ID: <200709142110.36489.alain.portal@free.fr> Le vendredi 14 septembre 2007, Jeremy Katz a ?crit : > On Fri, 2007-09-14 at 19:49 +0200, Alain PORTAL wrote: > > OK, if noboby ask for maintaining this package during the next 72h, I'll > > take it. > > FWIW, 72 hours on a Friday afternoon is somewhat short as far as time is > concerned. I've done a side channel ping to try to get the maintainer's > attention I said 72H because I didn't want to try to package in the weekend ;-) I agree to wait some days more if you're able to find someboby to take it, but you have to know that I need a FC-6 branch, a branch that I'll request if I take it because I'm still on this release on two boxes. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 drago01 at gmail.com Fri Sep 14 19:15:47 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 14 Sep 2007 21:15:47 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> Message-ID: <46EADDE3.3090809@gmail.com> Andrew Parker wrote: > On 9/13/07, Rahul Sundaram wrote: > >> Hi >> >> http://fedoraproject.org/wiki/F8Test2/ReleaseNotes >> >> I have updated the release notes with information on changes new to test >> 2. If there is anything important I have missed, please edit the wiki or >> let me know. >> > > Correct me if I'm wrong, but IIRC the inclusion of PulseAudio breaks > audio in Adobe Flash? Would it be worth adding this so that we have > something to point people to instead of explaining it every time it > comes up? > > nope that should have been fixed in the current builds (and the ones in test2). From mclasen at redhat.com Fri Sep 14 19:15:12 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 14 Sep 2007 15:15:12 -0400 Subject: making config tools use system icons In-Reply-To: <20070914181354.GA15896@nostromo.devel.redhat.com> References: <20070914165103.GA15780@nostromo.devel.redhat.com> <1189790550.3130.14.camel@ignacio.lan> <20070914181354.GA15896@nostromo.devel.redhat.com> Message-ID: <1189797312.4181.0.camel@localhost.localdomain> On Fri, 2007-09-14 at 14:13 -0400, Bill Nottingham wrote: > Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: > > On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote: > > > Most of the python config tools (system-config-*, anaconda) include > > > their own copies of bluecurve icons. It makes sense to me that they > > > should use system icons whenever possible, to match the current theme. > > > > +1 to making it match/use the current theme, but -1 to using generic > > system icons. > > > > Pulling the individual icons out of the packages and into redhat-artwork > > (or perhaps system-config-artwork?) is fine, but I still think the > > distinctiveness of their icons versus the generic control panel icons is > > a good thing. > > The problem is that doesn't actually help - you'd need to do a version > of the icon for each theme, which is something I'd like to avoid. > > Right now, you boot up a *stock* desktop, and you have the gnome icons > (in the GNOME style), the config tool icons (in the bluecurve style), > and the puplet icons (in the echo style). That's *ugly*. A lot of these tools have larger interface issues than non-matching icons, though... From redhat at olen.net Fri Sep 14 19:30:20 2007 From: redhat at olen.net (Ola Thoresen) Date: Fri, 14 Sep 2007 21:30:20 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46EACA6F.9080203@hi.is> References: <46E9447E.9080105@hi.is> <1189695736.10318.25.camel@localhost6.localdomain6> <20070913152211.GM8380@angus.ind.WPI.EDU> <1189698471.10318.56.camel@localhost6.localdomain6> <544eb990709140921x50b9bda2j256cb82c06421d52@mail.gmail.com> <1189787363.14868.18.camel@localhost6.localdomain6> <544eb990709140932w107e00f5vaf4a2bf3ffaa233d@mail.gmail.com> <1189788130.14868.32.camel@localhost6.localdomain6> <46EABEE8.4080102@hi.is> <46EACA6F.9080203@hi.is> Message-ID: <46EAE14C.30309@olen.net> J?hann B. Gu?mundsson wrote: > James Hubbard wrote: >> On 9/14/07, "J?hann B. Gu?mundsson" wrote: >> >>> Ps. >>> For all you IPv6 Fan boys out there how well is it working when >>> implemented??? It works like a charm. I have real IPv6 both at home and at work. It does not cause any problems - actually I don't even notice when I am connected with what protocol. But when I run a tcpdump I see from time to time that it actually is IPv6 that is used when I connect to a webserver or send an email. >>> How well is it working out site your LAN/WAN and communicating >>> with the rest off the world??? No problem. >>> How well is strictly use of IPv6 working in communicating out >>> site LAN/WAN deployment.. Today it is not possible to live without IPv4. But when I ssh or browse servers with both IPv6 and IPv4, IPv6 is used. Both internally and externally. Also, when I tail the logs on the webservers I can see a growing number of clients connecting with IPv6. Welcome to the future - it's now. Rgds. Ola Thoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From jkeating at redhat.com Fri Sep 14 19:31:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 15:31:10 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46EADDE3.3090809@gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> Message-ID: <20070914153110.6e83dc52@lumos.localdomain> On Fri, 14 Sep 2007 21:15:47 +0200 dragoran wrote: > nope that should have been fixed in the current builds (and the ones > in test2). You sure about that? I get no audio from flash here. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Sep 14 19:36:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 14 Sep 2007 21:36:18 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141829.07383.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> Message-ID: <20070914193618.GB2511@free.fr> On Fri, Sep 14, 2007 at 06:29:06PM +0200, Alain PORTAL wrote: > Hi, > > I ask for orphaning lftp because package maintainer doesn't maintain this > package since a long time. > > I asked for an updated in june, the 1st, for the 3.5.11 version, released on > 2007-04-11 :-( > https://bugzilla.redhat.com/show_bug.cgi?id=242112 > http://lftp.yar.ru/events.html There is also https://bugzilla.redhat.com/show_bug.cgi?id=203574 and the merge review isn't ini better shape. I could maintain lftp. Hans already takes care of my bugs ;-). -- Pat From drago01 at gmail.com Fri Sep 14 19:50:49 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 14 Sep 2007 21:50:49 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914153110.6e83dc52@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> Message-ID: <46EAE619.8020300@gmail.com> Jesse Keating wrote: > On Fri, 14 Sep 2007 21:15:47 +0200 > dragoran wrote: > > >> nope that should have been fixed in the current builds (and the ones >> in test2). >> > > You sure about that? I get no audio from flash here. > > I havn't tested it yet that why I said it _should_ be fixed ... tested it and it seems that it still broken.... :( From pertusus at free.fr Fri Sep 14 19:51:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 14 Sep 2007 21:51:35 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <200709141829.07383.alain.portal@free.fr> References: <200709141829.07383.alain.portal@free.fr> Message-ID: <20070914195135.GD2511@free.fr> On Fri, Sep 14, 2007 at 06:29:06PM +0200, Alain PORTAL wrote: > Hi, > > I ask for orphaning lftp because package maintainer doesn't maintain this > package since a long time. I contacted the maintainer, as per the AWOL procedure. We'll see. -- Pat From mclasen at redhat.com Fri Sep 14 19:54:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 14 Sep 2007 15:54:15 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46EAE619.8020300@gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> Message-ID: <1189799656.4181.2.camel@localhost.localdomain> On Fri, 2007-09-14 at 21:50 +0200, dragoran wrote: > Jesse Keating wrote: > > On Fri, 14 Sep 2007 21:15:47 +0200 > > dragoran wrote: > > > > > >> nope that should have been fixed in the current builds (and the ones > >> in test2). > >> > > > > You sure about that? I get no audio from flash here. > > > > > I havn't tested it yet that why I said it _should_ be fixed ... > tested it and it seems that it still broken.... :( > It works fine here. From packages at amiga-hardware.com Fri Sep 14 19:56:25 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Fri, 14 Sep 2007 20:56:25 +0100 Subject: Announcing rpmfusion In-Reply-To: <1189557606.4727.14.camel@localhost.localdomain> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> Message-ID: <46EAE769.6010301@amiga-hardware.com> Rodd Clarkson wrote: > Oh and could this be used for setting my paper preference to A4 by > default instead of having to change this each time I set up a printer? +1 - love it! :-) -- Ian Chapman. From mattdm at mattdm.org Fri Sep 14 19:56:41 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 14 Sep 2007 15:56:41 -0400 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189795062.14591.32.camel@localhost.localdomain> References: <200709141829.07383.alain.portal@free.fr> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <200709141949.26744.alain.portal@free.fr> <1189795062.14591.32.camel@localhost.localdomain> Message-ID: <20070914195641.GA2525@jadzia.bu.edu> On Fri, Sep 14, 2007 at 02:37:42PM -0400, Jeremy Katz wrote: > > OK, if noboby ask for maintaining this package during the next 72h, I'll take > > it. > FWIW, 72 hours on a Friday afternoon is somewhat short as far as time is Yeah, seriously. And here's the changes we're talking about, from the web site: 2007-08-31: lftp-3.5.14 released. A bug fixed. 2007-08-23: lftp-3.5.13 released. Some bugs fixed. 2007-07-26: lftp-3.5.12 released. Minor improvements. 2007-04-11: lftp-3.5.11 released. Some minor bugs fixed. None of that really looks earth-shattering -- and with sometimes only a few weeks between updates, seems like waiting for an important release is a reasonably maintenance strategy. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Fri Sep 14 20:04:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Sep 2007 16:04:20 -0400 Subject: making config tools use system icons In-Reply-To: <1189797312.4181.0.camel@localhost.localdomain> References: <20070914165103.GA15780@nostromo.devel.redhat.com> <1189790550.3130.14.camel@ignacio.lan> <20070914181354.GA15896@nostromo.devel.redhat.com> <1189797312.4181.0.camel@localhost.localdomain> Message-ID: <20070914200420.GA13037@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > > Right now, you boot up a *stock* desktop, and you have the gnome icons > > (in the GNOME style), the config tool icons (in the bluecurve style), > > and the puplet icons (in the echo style). That's *ugly*. > > A lot of these tools have larger interface issues than non-matching > icons, though... That's a much large patch. Unless you're talking just blocking the packages from the distro entirely. Which I'm not averse to. Bill From opensource at till.name Fri Sep 14 20:07:38 2007 From: opensource at till.name (Till Maas) Date: Fri, 14 Sep 2007 22:07:38 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189792506.14868.67.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46EAC317.2060803@hi.is> <1189792506.14868.67.camel@localhost6.localdomain6> Message-ID: <200709142207.43817.opensource@till.name> On Fr September 14 2007, Richi Plana wrote: > # sed -ie /NETWORKING_IPV6=/s/yes/no/ /etc/sysconfig/network || echo > NETWORKING_IPV6=no >> /etc/sysconfig/network I don't think, that this is correct, afaik NETWORKING (without the IPV6 suffix) only states, that the network was configured somehow. I guess it is the same for the ipv6 pendant. It does not indicate, whether network is enabled or available. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From yabraham2 at gmail.com Fri Sep 14 20:19:38 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Fri, 14 Sep 2007 16:19:38 -0400 Subject: no menu entry for bigboard? Message-ID: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> hi, where did the menu entry for bigboard related disappeared? I installed for rahawide system and couldn't find how to run it. There used to be a menu entry some where on system-->preferences if I run bigboard from terminal, I get a warning that says, i didn't started online desktop ....? man bigboard return none. http://fedoraproject.org/wiki/Releases/FeatureBigboard claim it is 100% done for F8. The usage section says "See the upstream web page". I don't know what that is. /yonas From dmc.fedora at filteredperception.org Fri Sep 14 20:25:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 14 Sep 2007 15:25:53 -0500 Subject: no menu entry for bigboard? In-Reply-To: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> References: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> Message-ID: <46EAEE51.40104@filteredperception.org> yonas Abraham wrote: > hi, > > where did the menu entry for bigboard related disappeared? I > installed for rahawide system and couldn't find how to run it. There > used to be a menu entry some where on system-->preferences I was kind of hoping to see it in f8t2 as I don't run rawhide. Is it there? -dmc > > if I run bigboard from terminal, I get a warning that says, i didn't > started online desktop ....? man bigboard return none. > http://fedoraproject.org/wiki/Releases/FeatureBigboard claim it is > 100% done for F8. The usage section says "See the upstream web page". > I don't know what that is. > > /yonas > From johan at x-tnd.be Fri Sep 14 20:32:36 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Fri, 14 Sep 2007 22:32:36 +0200 Subject: SELinux for BackupPC Message-ID: <46EAEFE4.1080403@x-tnd.be> Hi, I'm currently re-packaging BackupPC[1], a perl backup software server. As BackupPC need to use, for example, rsync or tar to backup itself, wich cause SELinux denies. There also is a CGI interface to manage backups/restore and config. As I'm not at all a SELinux guru, I've used 'audit2allow' to create a selinux policy module included in my specfile, but I don't know if this is the good way, and even if my policy module should causes issues... I'd like you to have advices related to SELinux integration in this RPM file. I'll put online actual policy file[2], as I use it in the specfile[3] I'd also like opinions on the best way to include an SELinux policy for this software. Regards, Johan [1] http://backuppc.sourceforge.net [2] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te [3] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From walters at redhat.com Fri Sep 14 20:35:46 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 14 Sep 2007 16:35:46 -0400 Subject: no menu entry for bigboard? In-Reply-To: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> References: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> Message-ID: On 9/14/07, yonas Abraham wrote: > hi, > > where did the menu entry for bigboard related disappeared? The wiki page on this was a bit unclear, I've updated it now: http://live.gnome.org/OnlineDesktop Here is the relevant quote: If you've installed the Online Desktop packages for Fedora or other systems look for the "Online Desktop" session in your GDM sessions. That will allow you to login to the Online Desktop, without changing your existing system configurations. I'm also cleaning up the Fedora feature wiki for this work now. From yabraham2 at gmail.com Fri Sep 14 20:46:54 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Fri, 14 Sep 2007 16:46:54 -0400 Subject: no menu entry for bigboard? In-Reply-To: References: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> Message-ID: <47324ed80709141346y50ae967y269ba3742b7732ec@mail.gmail.com> On 9/14/07, Colin Walters wrote: > On 9/14/07, yonas Abraham wrote: > > hi, > > > > where did the menu entry for bigboard related disappeared? > > The wiki page on this was a bit unclear, I've updated it now: > > http://live.gnome.org/OnlineDesktop > > Here is the relevant quote: > > If you've installed the Online Desktop packages for Fedora or other > systems look for the "Online Desktop" session in your GDM sessions. > That will allow you to login to the Online Desktop, without changing > your existing system configurations. > > I'm also cleaning up the Fedora feature wiki for this work now. Thanks Colin, this makes sense choosing from GDM Session. Previously, when i tried, I can't go back to the old panel. I will give it a try. thanks /Yonas From snecklifter at gmail.com Fri Sep 14 20:51:32 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 14 Sep 2007 21:51:32 +0100 Subject: Please, make lftp orphaned!!! In-Reply-To: <20070914195641.GA2525@jadzia.bu.edu> References: <200709141829.07383.alain.portal@free.fr> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <200709141949.26744.alain.portal@free.fr> <1189795062.14591.32.camel@localhost.localdomain> <20070914195641.GA2525@jadzia.bu.edu> Message-ID: <364d303b0709141351g42335a24t78e38e69f9b6e474@mail.gmail.com> On 14/09/2007, Matthew Miller wrote: > > On Fri, Sep 14, 2007 at 02:37:42PM -0400, Jeremy Katz wrote: > > > OK, if noboby ask for maintaining this package during the next 72h, > I'll take > > > it. > > FWIW, 72 hours on a Friday afternoon is somewhat short as far as time is > > Yeah, seriously. And here's the changes we're talking about, from the web > site: > > 2007-08-31: lftp-3.5.14 released. A bug fixed. > 2007-08-23: lftp-3.5.13 released. Some bugs fixed. > 2007-07-26: lftp-3.5.12 released. Minor improvements. > 2007-04-11: lftp-3.5.11 released. Some minor bugs fixed. > > None of that really looks earth-shattering -- and with sometimes only a > few > weeks between updates, seems like waiting for an important release is a > reasonably maintenance strategy. > I agree but bugs are bugs and this hasn't been updated for Fedora 7 or following the update request. Not great. Plus the maintainer's email address is waving a red flag in my head somewhere - I think someone was chasing another of his packages for an update on IRC recently... Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Fri Sep 14 21:01:29 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 14 Sep 2007 15:01:29 -0600 Subject: Announcing rpmfusion In-Reply-To: <46EAE769.6010301@amiga-hardware.com> References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <1189557606.4727.14.camel@localhost.localdomain> <46EAE769.6010301@amiga-hardware.com> Message-ID: <80d7e4090709141401t595873c6m6fb7ff93ac1dc479@mail.gmail.com> On 9/14/07, Ian Chapman wrote: > Rodd Clarkson wrote: > > > Oh and could this be used for setting my paper preference to A4 by > > default instead of having to change this each time I set up a printer? > > +1 - love it! :-) > Hmmm for some reason I have to change my paper to Letter from A4 every time I setup a printer in various applications.. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From ibmalone at gmail.com Fri Sep 14 21:15:14 2007 From: ibmalone at gmail.com (Ian Malone) Date: Fri, 14 Sep 2007 22:15:14 +0100 Subject: vorbis-tools in 7.90 In-Reply-To: <364d303b0709111453l78677e89h4e52f699128020c6@mail.gmail.com> References: <124299980709110705j6b4e86b0pb2b8acd10b89e88d@mail.gmail.com> <364d303b0709111453l78677e89h4e52f699128020c6@mail.gmail.com> Message-ID: <46EAF9E2.5030203@gmail.com> Christopher Brown wrote: > On 11/09/2007, Ian Malone wrote: >> >> I notice that Fedora 7.90 still has vorbis-tools-1.1.1.svn20070412-2. >> A newer version of svn would fix bug 244757[1]. > > Hmm, looks like no response from the maintainer for a while. Try contacting > them directly and give it a week or so. If still no response you might want > to consider orphaning it: > Thanks. It turns out the maintainer is still alive, if quite busy. I was just slightly perturbed by the suspicion that this package was going to be broken in 2 consecutive Fedora releases. -- imalone From buildsys at fedoraproject.org Fri Sep 14 21:24:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 14 Sep 2007 17:24:52 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-14 Message-ID: <20070914212452.8FD0C152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 8 bacula-2.0.3-10.fc6 em8300-kmod-0.16.3-1.2.6.22.5_49.fc6 latexmk-3.20-1.fc6 mod_security-2.1.3-1.fc6 NEW perl-Geo-IP-1.28-3.fc6 : Efficient Perl bindings for the GeoIP location database NEW php-pear-HTML-QuickForm-advmultiselect-1.4.0-1.fc6 : Element for HTML_QuickForm that emulate a multi-select python-setuptools-0.6c7-1.fc6 sysprof-kmod-1.0.8-1.2.6.22.5_49.fc6 Changes in Fedora Extras 6: bacula-2.0.3-10.fc6 ------------------- * Thu Sep 13 2007 Andreas Thienemann 2.0.3-10 - Applied restore fix to sd. #288981 em8300-kmod-0.16.3-1.2.6.22.5_49.fc6 ------------------------------------ * Thu Sep 13 2007 Ville Skytt? - Rebuild for kernel 2.6.22.5-49.fc6. latexmk-3.20-1.fc6 ------------------ * Fri Aug 31 2007 Jerry James - 3.20-1 - New version 3.20. - Texlive isn't as near as I thought; require the tetex packages for now. * Tue Aug 21 2007 Jerry James - 3.08n-5 - Update license tag mod_security-2.1.3-1.fc6 ------------------------ * Thu Sep 13 2007 Michael Fleming 2.1.3-1 - New upstream release - Update License tag per guidelines perl-Geo-IP-1.28-3.fc6 ---------------------- * Mon Sep 03 2007 Michael Fleming 1.28-4 - Fix %patch invocation to help avoid a bogus interpreter issue - First build for Extras * Sun Aug 26 2007 Michael Fleming 1.28-3 - Actually apply the patch :-) - Apply consistency in macro usage - Remove explicit GeoIP dependency as it should be pulled in automagically - Patch to example/netspeed to avoid bogus interpreter - Update License to match current Fedora guidelines. php-pear-HTML-QuickForm-advmultiselect-1.4.0-1.fc6 -------------------------------------------------- * Tue Aug 21 2007 Remi Collet 1.4.0-1 - Take ownership for this, update to 1.4.0 - Change licence from PHP to BSD python-setuptools-0.6c7-1.fc6 ----------------------------- * Fri Sep 14 2007 Konstantin Ryabitsev - 0.6c7-1 - Upstream 0.6c7 - Provide python-setuptools-devel to make packagers' lives easier sysprof-kmod-1.0.8-1.2.6.22.5_49.fc6 ------------------------------------ * Tue Aug 21 2007 Gianluca Sforna - Update License field From myfedora at richip.dhs.org Fri Sep 14 21:50:22 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 15:50:22 -0600 Subject: Disable IPv6 by default. In-Reply-To: <200709142207.43817.opensource@till.name> References: <46E9447E.9080105@hi.is> <46EAC317.2060803@hi.is> <1189792506.14868.67.camel@localhost6.localdomain6> <200709142207.43817.opensource@till.name> Message-ID: <1189806622.24350.3.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 22:07 +0200, Till Maas wrote: > On Fr September 14 2007, Richi Plana wrote: > > > # sed -ie /NETWORKING_IPV6=/s/yes/no/ /etc/sysconfig/network || echo > > NETWORKING_IPV6=no >> /etc/sysconfig/network > > I don't think, that this is correct, afaik NETWORKING (without the IPV6 > suffix) only states, that the network was configured somehow. I guess it is > the same for the ipv6 pendant. It does not indicate, whether network is > enabled or available. *sigh* I wish I wrote down where I got that piece of information from. Thanks. -- Richi Plana From myfedora at richip.dhs.org Fri Sep 14 21:52:53 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 15:52:53 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189799656.4181.2.camel@localhost.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> Message-ID: <1189806773.24350.6.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 15:54 -0400, Matthias Clasen wrote: > On Fri, 2007-09-14 at 21:50 +0200, dragoran wrote: > > Jesse Keating wrote: > > > On Fri, 14 Sep 2007 21:15:47 +0200 > > > dragoran wrote: > > > > > > > > >> nope that should have been fixed in the current builds (and the ones > > >> in test2). > > >> > > > > > > You sure about that? I get no audio from flash here. > > > > > > > > I havn't tested it yet that why I said it _should_ be fixed ... > > tested it and it seems that it still broken.... :( > > > > It works fine here. Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What was the proposed fix to make it work with PulseAudio enabled? -- Richi Plana From jkeating at redhat.com Fri Sep 14 21:53:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 17:53:54 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189806773.24350.6.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> Message-ID: <20070914175354.0c97972e@lumos.localdomain> On Fri, 14 Sep 2007 15:52:53 -0600 Richi Plana wrote: > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > was the proposed fix to make it work with PulseAudio enabled? What I had to do to get it working for me was install the pulseaudio-lib.i386 package. I'm on x86_64 and using flash via nspluginwrapper.i386, and thus I needed the i386 pulse libs. Now it's working just fine. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mzerqung at 0pointer.de Fri Sep 14 22:00:44 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 15 Sep 2007 00:00:44 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189806773.24350.6.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> Message-ID: <20070914220043.GA5018@tango.0pointer.de> On Fri, 14.09.07 15:52, Richi Plana (myfedora at richip.dhs.org) wrote: > > > I havn't tested it yet that why I said it _should_ be fixed ... > > > tested it and it seems that it still broken.... :( > > > > > > > It works fine here. > > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > was the proposed fix to make it work with PulseAudio enabled? Flash uses its own (crappy) audio abstraction called libflashsupport.so. pulseaudio-libs installs an implementation of that file which connects to PA for audio playback. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From myfedora at richip.dhs.org Fri Sep 14 22:00:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 16:00:16 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914175354.0c97972e@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> Message-ID: <1189807216.24350.15.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 17:53 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 15:52:53 -0600 > Richi Plana wrote: > > > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > > was the proposed fix to make it work with PulseAudio enabled? > > What I had to do to get it working for me was install the > pulseaudio-lib.i386 package. I'm on x86_64 and using flash via > nspluginwrapper.i386, and thus I needed the i386 pulse libs. Now it's > working just fine. Ah, makes sense. I use nspluginwrapper on my machine, as well, and I have to install alsa-oss-libs.i386 to make Flash work on F7 without PulseAudio. (Speaking of which, somebody should inform Adobe to make certain libs Require'd in their RPM packages). Does anyone know who maintains their package? -- Richi Plana From myfedora at richip.dhs.org Fri Sep 14 22:09:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 16:09:58 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914220043.GA5018@tango.0pointer.de> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> Message-ID: <1189807798.24350.19.camel@localhost6.localdomain6> On Sat, 2007-09-15 at 00:00 +0200, Lennart Poettering wrote: > On Fri, 14.09.07 15:52, Richi Plana (myfedora at richip.dhs.org) wrote: > > > > > I havn't tested it yet that why I said it _should_ be fixed ... > > > > tested it and it seems that it still broken.... :( > > > > > > > > > > It works fine here. > > > > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > > was the proposed fix to make it work with PulseAudio enabled? > > Flash uses its own (crappy) audio abstraction called > libflashsupport.so. pulseaudio-libs installs an implementation of > that file which connects to PA for audio playback. Thanks. I was about to ask what pulseaudio-libs had that Flash would use. So what did pulseaudio-libs have to implement to get Flash working? Are there talk with the Penguin.SWF folks on making their stuff use PulseAudio? Or do we have to live with layers-upon-layers of abstractions? ;) -- Richi Plana From myfedora at richip.dhs.org Fri Sep 14 22:12:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 16:12:10 -0600 Subject: Please, make lftp orphaned!!! In-Reply-To: <46EAB915.3070703@fedoraproject.org> References: <200709141829.07383.alain.portal@free.fr> <1189787843.14868.26.camel@localhost6.localdomain6> <46EAB915.3070703@fedoraproject.org> Message-ID: <1189807930.24350.22.camel@localhost6.localdomain6> So let's say I wanted to grab some experiencing managing a package on Fedora and I wanted to start with an orphaned package (say brightside, though its upstream appears dead), what do I do first? How do I get an account for Fedora PackageDB? On Fri, 2007-09-14 at 22:08 +0530, Rahul Sundaram wrote: > Richi Plana wrote: > > On Fri, 2007-09-14 at 18:29 +0200, Alain PORTAL wrote: > >> I ask for orphaning lftp because package maintainer doesn't maintain this > >> package since a long time. > > > > How are packages orphaned? > > Package maintainers themselves announce that they are orphaning a > package and use the package database to abandon it or a package becomes > orphaned after someone else uses the AWOL policy. > > And where does one go to adopt orphan > > packages? > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > Rahul > From a.badger at gmail.com Fri Sep 14 22:30:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 14 Sep 2007 15:30:31 -0700 Subject: PackageDB 0.3.1 open for business In-Reply-To: <1189757530.8849.10.camel@wombat.tiptoe.de> References: <46E9F26C.1080407@gmail.com> <1189757530.8849.10.camel@wombat.tiptoe.de> Message-ID: <46EB0B87.8040706@gmail.com> Nils Philippsen wrote: > On Thu, 2007-09-13 at 19:31 -0700, Toshio Kuratomi wrote: > [ no way to find PackageDB ] > > I think the PackageDB lives at: > > https://admin.fedoraproject.org/pkgdb/ > Thanks Nils! Much to my chagrin, Jef Spaleta, pointed out on IRC that my announcement failed to say anything about how to use the packagedb at all, including where it lives. https://admin.fedoraproject.org/pkgdb/ is indeed the correct location. If anyone is interested, I've also written a brief walkthrough of using the Package DB here:: https://hosted.fedoraproject.org/projects/packagedb/wiki/HowTo -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Sep 14 22:34:37 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Sep 2007 14:34:37 -0800 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189807930.24350.22.camel@localhost6.localdomain6> References: <200709141829.07383.alain.portal@free.fr> <1189787843.14868.26.camel@localhost6.localdomain6> <46EAB915.3070703@fedoraproject.org> <1189807930.24350.22.camel@localhost6.localdomain6> Message-ID: <604aa7910709141534o128f060veec8559e96cafef4@mail.gmail.com> On 9/14/07, Richi Plana wrote: > So let's say I wanted to grab some experiencing managing a package on > Fedora and I wanted to start with an orphaned package (say brightside, > though its upstream appears dead), what do I do first? How do I get an > account for Fedora PackageDB? Read: http://fedoraproject.org/wiki/PackageMaintainers/Join Read: http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored As linked from: http://fedoraproject.org/wiki/PackageMaintainers As linked from: http://fedoraproject.org/wiki/ Or as link from: http://fedoraproject.org/wiki/Join -jef From nphilipp at redhat.com Fri Sep 14 22:55:34 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 15 Sep 2007 00:55:34 +0200 Subject: source file audit - 2007-08-26 In-Reply-To: <20070827134237.5cde7f33@ghistelwchlohm.scrye.com> References: <20070827134237.5cde7f33@ghistelwchlohm.scrye.com> Message-ID: <1189810534.14893.31.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-08-27 at 13:42 -0600, Kevin Fenzi wrote: > nphilipp:BADSOURCE:dcraw-8.77.tar.gz:dcraw I'm not really sure about this one, it seems upstream updated the tarball without changing the version. I've built a new package with the new version. > nphilipp:BADURL:rss-glx_0.8.1.p.tar.bz2:rss-glx As we ship a tarball with one questionable hack removed, I've removed the URL from Source0. The fixed version is building right now. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From stickster at gmail.com Fri Sep 14 23:15:54 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 14 Sep 2007 19:15:54 -0400 Subject: Please, make lftp orphaned!!! In-Reply-To: <20070914135524.197d7d02@lumos.localdomain> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <20070914135524.197d7d02@lumos.localdomain> Message-ID: <1189811754.3712.2.camel@localhost.localdomain> On Fri, 2007-09-14 at 13:55 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 19:41:26 +0200 > Hans de Goede wrote: > > > Okay, so we have 2 c / c++ people for routing help request too (my C > > is better then my C++ though), what about other languages? > > We definitely need a Python Squad. I can't offer a whole lot to it, > but I'd love to watch the traffic and learn a thing or to along the way. +1 that. I can help a little with C stuff, but probably not at the level of someone like Hans or other full-time developers, at least not if you want it fast. :-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 stickster at gmail.com Fri Sep 14 23:21:00 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 14 Sep 2007 19:21:00 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914175354.0c97972e@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> Message-ID: <1189812060.3712.4.camel@localhost.localdomain> On Fri, 2007-09-14 at 17:53 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 15:52:53 -0600 > Richi Plana wrote: > > > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > > was the proposed fix to make it work with PulseAudio enabled? > > What I had to do to get it working for me was install the > pulseaudio-lib.i386 package. I'm on x86_64 and using flash via > nspluginwrapper.i386, and thus I needed the i386 pulse libs. Now it's > working just fine. So *that* seems like something that should be in the test2 Release Notes, then. Care to pop it in there? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 nphilipp at redhat.com Fri Sep 14 23:38:58 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 15 Sep 2007 01:38:58 +0200 Subject: Redesigning System Services (Re: My 2 cents on the whole Fedora to succeed as global wide deployed desktop are...) In-Reply-To: <1188942818.9729.143.camel@pc-notebook> References: <46DBFD50.5020505@hi.is> <1188824313.9729.25.camel@pc-notebook> <20070903090019.1f746ae4@ender> <1188825506.9729.41.camel@pc-notebook> <1188917146.4464.41.camel@localhost.localdomain> <1188939947.10471.10.camel@Diffingo.localdomain> <1188942818.9729.143.camel@pc-notebook> Message-ID: <1189813138.14893.42.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-09-04 at 23:53 +0200, Martin Sourada wrote: > 3. Improve the system-config-services. Its great tool and has great > potential but its confusing at first look. We need to provide to each > service such a description *AND* name that everyone (well, I exaggerate > here a little...) will understand it. See my posting "plans for system-config-services, was: early-gdm redux" on fedora-desktop-list. Basically: yes, s-c-services is confusing to users right now, one thing to make it easier is remove the visual distinction between SysVinit and xinetd based services by way of tabs. I don't think anybody wants to tell s-c-services which type of service shall be configured ;-). That's one thing I want to change for Fedora 9, I've planned more and will hopefully get around to it all. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From johannbg at hi.is Sat Sep 15 00:11:18 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Sat, 15 Sep 2007 00:11:18 -0000 (GMT) Subject: User enhancement feature's request for Fedora Core 9'ish Message-ID: <16870.88.149.97.225.1189815078.squirrel@webmail.hi.is> While we cant agree on what should be and should not be loaded and during install adding an new advanced user feature to Anaconda/kickstart where advanced user can choose IPv4 or IPv6 and which services will start after installation should address these issues until concrete solution is formed.. ***** System-Config-Services-Gui ***** 1. Allow user to bind the service to certain interface or IP # New / not discussed.. ( Advanced user feature maybe ).... 2. Check if firewall has been opened for service ( when enabled or started ) if not notify the user ( and possible fail to start ) which port to open and open System-Config-Security, Ask the user to re-enable the service. ( check again until he gets it right or just one time if we don't want to *spam* the user with messages ) For this to work more user predefined port options need to be added to System-Config-Security # already have filed an RFE for that Advanced user need to be able to disable this both in System-Config-Services ( Advanced user maybe want to be just notified or disable this feature )and System-Config-Security ( not to mess with custom firewall rules ). 3. Notify the user about SElinux issues maybe to? # New / Not discussed.. There is also the question if other apps should notify user the same way.. ( Bittorrent, NetworkManager ( vpn ) etc.. ) # New / Not discussed 4. Notify the user of possible chain reaction if he disabled a service, let's say user decides to disable service A and service b and c strictly depended on # Somewhat discussed ( IPv6, ipv6iptables would fit in here ) service A, the user receives warning and those services ( b and c ) are turned off, or user just notified, or even yet those services just are turned off as well. ( User receives no message ) Warning the following suggestion may cause sun burn so put on your sunblock to protect you from the heat... :) 5. Renaming some services to more *user friendly* names. ( cups to printer service for example ). # Somewhat discussed I personally stay neutral on this issue, ( I see both sites on this one... ) * All together rename a service . ( suggest a new name for service --> name sent upstream --> upstream approves ( unlikely ) --> package(s) renamed --> service renamed ) * Alias in System-Config-Services. ( Could cause some confusion if user ever had to deal with it outside X ).. * Info given to user when the mouse pointer is over the service. * Put this one under the rug... To achieve the user notifier we need to use something that we already have ( ideas any one ) or create a new *x-to-system-to-x-to-user msg*. I think regarding S-C-S point 2 we can all agree that that's the best way to do it security/user friendly wise.. Best regards. Johann B. Ps. Good summarization from Martin Sourada regarding some of those issues in previously threads.. <-- snip --> 1. redefine the default set of services. Should be runlevel dependent and it should include only the services that are crucial to non-problematic run on every machine and that provide good user experience as well (like automounting CD's) 2. add support for automatically turning on services dependant on hardware. If you plug in bluetooth, HAL detects it and turn on the bluetooth services. Should be however handled in a way where user can have control over the service if (s)he want. That would mean that we would need three states for such a service: turned off by default, turned on by default, automatic. 3. Improve the system-config-services. Its great tool and has great potential but its confusing at first look. We need to provide to each service such a description *AND* name that everyone (well, I exaggerate here a little...) will understand it. 4. Some services that require a change of firewall rules to run correctly should offer such a change (but not do the change automatically, sometimes you want to have specific rules for the firewall, like opening ports only to specific IPs). These are mostly server services like sendmail, postfix, vsftpd, ... 5. Would be good if we provide gui utilities for easy (and only basic) configuration of services that has configuration capabilities. Should be accessible from system-config-services. I hope this list makes sense, I think I learned a lot in this particular thread... We could maybe, if the changes are desirable and sane, add this on the F9 feature list. Thanks, Martin <-- snip ---> From buildsys at fedoraproject.org Sat Sep 15 00:27:49 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 14 Sep 2007 20:27:49 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-14 Message-ID: <20070915002749.CA4A5152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 3 cacti-0.8.6j-8.fc6 duplicity-0.4.3-1.fc6 NEW python-GnuPGInterface-0.3.2-2.fc6 : A Python module to interface with GnuPG Changes in Fedora Extras 6: cacti-0.8.6j-8.fc6 ------------------ * Fri Sep 14 2007 Mike McGrath - 0.8.6j-8 - Fix for CVE-2007-3112 bz#243592 * Sat Sep 08 2007 Mike McGrath - 0.8.6j-6 - rebuild duplicity-0.4.3-1.fc6 --------------------- * Sat Sep 15 2007 Robert Scheck 0.4.3-1 - Upgrade to 0.4.3 (#265701) - Updated the license tag according to the guidelines python-GnuPGInterface-0.3.2-2.fc6 --------------------------------- * Mon Sep 03 2007 Robert Scheck 0.3.2-2 - Updated source URL to match with the guidelines (#265381) - Use get_python_lib() macro according to the policy (#265381) * Wed Aug 29 2007 Robert Scheck 0.3.2-1 - Upgrade to 0.3.2 - Initial spec file for Fedora and Red Hat Enterprise Linux From jkeating at redhat.com Sat Sep 15 00:39:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 20:39:21 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189807216.24350.15.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> Message-ID: <20070914203921.3278dfde@lumos.localdomain> On Fri, 14 Sep 2007 16:00:16 -0600 Richi Plana wrote: > (Speaking of which, somebody should inform Adobe to make > certain libs Require'd in their RPM packages). Does anyone know who > maintains their package? Warren Togami helps them a lot with their packages, but I'm not sure that's right to require it. Maybe if they have Fedora specific packages they can require pulseaudio-libs, but I'm not sure they're really fully pulse right now, it may be working through some compat layer. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Sat Sep 15 00:44:42 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Sep 2007 16:44:42 -0800 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914203921.3278dfde@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> Message-ID: <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> On 9/14/07, Jesse Keating wrote: > Warren Togami helps them a lot with their packages, but I'm not sure > that's right to require it. Maybe if they have Fedora specific > packages they can require pulseaudio-libs, but I'm not sure they're > really fully pulse right now, it may be working through some compat > layer. should nspluginwrapper drag it in? -jef From jkeating at redhat.com Sat Sep 15 01:06:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 21:06:10 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> Message-ID: <20070914210610.31fdaf59@lumos.localdomain> On Fri, 14 Sep 2007 16:44:42 -0800 "Jeff Spaleta" wrote: > should nspluginwrapper drag it in? Not sure that makes sense. The problem is it needs to be a library specific Require, so that the correct arch package will get dragged in. A requirement on "pulseaudio-lib" just won't cut it as that would be satisfied by "pulseaudio-lib.x86_64". I know there is some work going on in rpm5 that will do arch specific provides, maybe even requires to, but that is future land that we may pull into rpm.org. Until then we need something of a solution for Fedora 8. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Sat Sep 15 01:10:28 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 19:10:28 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> Message-ID: <1189818628.27148.3.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 16:44 -0800, Jeff Spaleta wrote: > On 9/14/07, Jesse Keating wrote: > > Warren Togami helps them a lot with their packages, but I'm not sure > > that's right to require it. Maybe if they have Fedora specific > > packages they can require pulseaudio-libs, but I'm not sure they're > > really fully pulse right now, it may be working through some compat > > layer. > > should nspluginwrapper drag it in? Jesse: I was actually thinking of alsa-oss-libs.i386, at first. Jeff: I thought the same thing, but nspluginwrapper doesn't directly depend on either of the audio libs (I think). That's why I wanted to find out exactly what the flash-plugin used for audio output to determine exactly what it should require. It might even be another virtual package or virtual device file like /dev/dsp At any rate, flash-plugin will not work properly (no audio) without either of those packages. -- Richi Plana From myfedora at richip.dhs.org Sat Sep 15 01:17:49 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 19:17:49 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914210610.31fdaf59@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> <20070914210610.31fdaf59@lumos.localdomain> Message-ID: <1189819069.27148.10.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 21:06 -0400, Jesse Keating wrote: > Not sure that makes sense. The problem is it needs to be a library > specific Require, so that the correct arch package will get dragged > in. A requirement on "pulseaudio-lib" just won't cut it as that would > be satisfied by "pulseaudio-lib.x86_64". I know there is some work > going on in rpm5 that will do arch specific provides, maybe even > requires to, but that is future land that we may pull into rpm.org. > Until then we need something of a solution for Fedora 8. Lennart or a flash-plugin guy can tell us for certain what flash-plugin needs (I've no idea what's in pulseaudio-lib). It's most likely a library file that it dlopen(3)'s. Perhaps flash-plugin can do a: Requires: %{_libdir}/libaoss.so.0 or some new virtual package name. BTW, since flash-plugin is an i386 package, wouldn't a Require: pulseaudio-lib be enough for it to require the .i386 version? -- Richi Plana From kwhiskerz at yahoo.ca Sat Sep 15 01:23:25 2007 From: kwhiskerz at yahoo.ca (kwhiskerz) Date: Fri, 14 Sep 2007 19:23:25 -0600 Subject: CD burning faulty Message-ID: <200709141923.25150.kwhiskerz@yahoo.ca> Thanks, I will check into it. The drive is still under warranty, so the dealer said they will see whether it can be replace dor repaired. Otherwise it would likely be a cable or even the controller on the mobo. I guess I should have had the cable tested first, but I had ripped out the drive and didn't want to pack it back home again. From nphilipp at redhat.com Sat Sep 15 01:25:26 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 15 Sep 2007 03:25:26 +0200 Subject: User enhancement feature's request for Fedora Core 9'ish In-Reply-To: <16870.88.149.97.225.1189815078.squirrel@webmail.hi.is> References: <16870.88.149.97.225.1189815078.squirrel@webmail.hi.is> Message-ID: <1189819526.14893.92.camel@gibraltar.stuttgart.redhat.com> On Sat, 2007-09-15 at 00:11 +0000, J?hann B. Gu?mundsson wrote: > While we cant agree on what should be and should not be loaded and during > install adding an new advanced user feature to Anaconda/kickstart where > advanced user can choose IPv4 or IPv6 and which services will start after > installation should address these issues until concrete solution is > formed.. > > ***** System-Config-Services-Gui ***** > > 1. Allow user to bind the service to certain interface or IP > # New / not discussed.. ( Advanced user feature maybe ).... That's something for configuration tool of the specific service, not system-config-services. > 2. Check if firewall has been opened for service ( when enabled or started ) > if not notify the user ( and possible fail to start ) which port to open > and open System-Config-Security, Ask the user to re-enable the service. > ( check again until he gets it right or just one time if we don't want > to *spam* the user with messages ) > > For this to work more user predefined port options need to be added to > System-Config-Security # already have filed an RFE for that > Advanced user need to be able to disable this both in > System-Config-Services ( Advanced user maybe want to be just notified > or disable this feature )and System-Config-Security > ( not to mess with custom firewall rules ). Please let's not get this overboard. The system-config-services tool is to start/stop services and to specify under which circumstances they should be started/stopped automatically. System-config-securitylevel (or in the future system-config-firewall) is the tool to change firewall rules. System-config- is for configuring , among that which IPs/ports it should bind (if that's configurable anyway). > 3. Notify the user about SElinux issues maybe to? # New / Not discussed.. > > There is also the question if other apps should notify user the same > way.. ( Bittorrent, NetworkManager ( vpn ) etc.. ) # New / Not discussed setroubleshoot anyone? > 4. Notify the user of possible chain reaction if he disabled a service, > let's say user decides to disable service A and service b and c strictly > depended on # Somewhat discussed > ( IPv6, ipv6iptables would fit in here ) > > service A, the user receives warning and those services ( b and c ) > are turned off, or user just notified, or even yet those services just > are turned off as well. ( User receives no message ) That's pretty much dependent on that services define on which other services they depend on, possibly in the course of a revamped init scheme. > Warning the following suggestion may cause sun burn so put on your > sunblock to protect you from the heat... :) > > 5. Renaming some services to more *user friendly* names. > ( cups to printer service for example ). # Somewhat discussed > > I personally stay neutral on this issue, ( I see both sites on this > one... ) > > * All together rename a service . ( suggest a new name for > service --> name sent upstream --> upstream approves ( unlikely ) > --> package(s) renamed --> service renamed ) > * Alias in System-Config-Services. ( Could cause some confusion if > user ever had to deal with it outside X ).. > * Info given to user when the mouse pointer is over the service. > * Put this one under the rug... If services use a uniform way to announce their generic name, I'm game for adding tooltips for that. > To achieve the user notifier we need to use something that we already have > ( ideas any one ) or create a new *x-to-system-to-x-to-user msg*. If the services file in e.g. /etc/init.d contains the generic name, we could do with something less complicated ;-). > I think regarding S-C-S point 2 we can all agree that that's the best > way to do it security/user friendly wise.. No :-P. Firewalls -- like SELinux -- are mandatory access control systems and tools like system-config-services are NOT the place to second-guess them. I'll point back to my description of s-c-services' purpose above. > Best regards. > Johann B. > > Ps. Good summarization from Martin Sourada regarding some of those > issues > in previously threads.. > > <-- snip --> > > 1. redefine the default set of services. Should be runlevel dependent > and it should include only the services that are crucial to > non-problematic run on every machine and that provide good user > experience as well (like automounting CD's) > > 2. add support for automatically turning on services dependant on > hardware. If you plug in bluetooth, HAL detects it and turn on the > bluetooth services. Should be however handled in a way where user can > have control over the service if (s)he want. That would mean that we > would need three states for such a service: turned off by default, > turned on by default, automatic. Services activated by DBUS events. I've already heard that somewhere ;-). > 3. Improve the system-config-services. Its great tool and has great > potential but its confusing at first look. We need to provide to each > service such a description *AND* name that everyone (well, I exaggerate > here a little...) will understand it. The most confusing thing at the moment is the tabbed distinction between long-running daemons and xinetd-started services. That's on my list of things to change. > 4. Some services that require a change of firewall rules to run > correctly should offer such a change (but not do the change > automatically, sometimes you want to have specific rules for the > firewall, like opening ports only to specific IPs). These are mostly > server services like sendmail, postfix, vsftpd, ... This could be put in the config tool of the respective service, s-c-firewall could offer widgets/modules that other config tools could use for that. Just as well as s-c-services should offer widgets/modules to enable/disable/start/stop a service from its own config tool. Plan++. > 5. Would be good if we provide gui utilities for easy (and only basic) > configuration of services that has configuration capabilities. Should be > accessible from system-config-services. If there's an easy way to map service -> config tool, I could let s-c-services offer a "Configure ..." button rather easily. > I hope this list makes sense, I think I learned a lot in this particular > thread... We could maybe, if the changes are desirable and sane, add > this on the F9 feature list. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jkeating at redhat.com Sat Sep 15 01:54:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 14 Sep 2007 21:54:47 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189819069.27148.10.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> <20070914210610.31fdaf59@lumos.localdomain> <1189819069.27148.10.camel@localhost6.localdomain6> Message-ID: <20070914215447.2597c58b@lumos.localdomain> On Fri, 14 Sep 2007 19:17:49 -0600 Richi Plana wrote: > BTW, since flash-plugin is an i386 package, wouldn't a Require: > pulseaudio-lib be enough for it to require the .i386 version? No, that's not the way our rpm works. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sat Sep 15 04:04:45 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 15 Sep 2007 00:04:45 -0400 Subject: Errata Message-ID: <1189829085.6750.36.camel@localhost.localdomain> The Java beat for the official F8 release notes needs a lot of good lovin', and fast. (And no, these two requirements need not be mutually exclusive in this case.) Could knowledgeable souls please update this page to include advances in Iced Tea and other goodies? I've already updated the Eclipse page in the DevelTools beat with the latest morsels but would welcome additional eyeballs. We need to get these beats out to translators ASAP so they have plenty of time to translate before F8 GA. Thanks all! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sat Sep 15 05:33:50 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 15 Sep 2007 07:33:50 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189811754.3712.2.camel@localhost.localdomain> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <20070914135524.197d7d02@lumos.localdomain> <1189811754.3712.2.camel@localhost.localdomain> Message-ID: <46EB6EBE.2090202@hhs.nl> Paul W. Frields wrote: > On Fri, 2007-09-14 at 13:55 -0400, Jesse Keating wrote: >> On Fri, 14 Sep 2007 19:41:26 +0200 >> Hans de Goede wrote: >> >>> Okay, so we have 2 c / c++ people for routing help request too (my C >>> is better then my C++ though), what about other languages? >> We definitely need a Python Squad. I can't offer a whole lot to it, >> but I'd love to watch the traffic and learn a thing or to along the way. > > +1 that. I can help a little with C stuff, but probably not at the > level of someone like Hans or other full-time developers, at least not > if you want it fast. :-) > Hey, I'm _not_ a fulltime developer. Regards, Hans From myfedora at richip.dhs.org Sat Sep 15 05:50:01 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 14 Sep 2007 23:50:01 -0600 Subject: Please, make lftp orphaned!!! In-Reply-To: <20070914135524.197d7d02@lumos.localdomain> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <20070914135524.197d7d02@lumos.localdomain> Message-ID: <1189835401.3661.2.camel@localhost6.localdomain6> On Fri, 2007-09-14 at 13:55 -0400, Jesse Keating wrote: > On Fri, 14 Sep 2007 19:41:26 +0200 > Hans de Goede wrote: > > > Okay, so we have 2 c / c++ people for routing help request too (my C > > is better then my C++ though), what about other languages? > > We definitely need a Python Squad. I can't offer a whole lot to it, > but I'd love to watch the traffic and learn a thing or to along the way. Count me in on C/C++, python, php and perl, I guess. If there's going to be a list, that is. And java, if anyone needs help. -- Richi Plana From paul at all-the-johnsons.co.uk Fri Sep 14 21:39:36 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 14 Sep 2007 22:39:36 +0100 Subject: Calling Paul F. Johnson In-Reply-To: <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> Message-ID: <1189805976.3463.1.camel@localhost.localdomain> Hi, On Sat, 2007-09-15 at 02:59 +0900, Mamoru Tasaka wrote: > > Are you out there Paul? Anyone else know how to contact Paul? > > > > Umm.. Actually Paul does not seem to react to any bugzilla reports > for months, however it seems that he is reading fedora-list. I am still here, although after this last 6 months, I've left the wife, lost a job, started another and am currently running around like an idiot trying to catch my own shadow! I will get back to people as soon as I can... TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 Sep 15 06:32:52 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 15 Sep 2007 01:32:52 -0500 Subject: Calling Paul F. Johnson In-Reply-To: <1189805976.3463.1.camel@localhost.localdomain> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> <1189805976.3463.1.camel@localhost.localdomain> Message-ID: <16de708d0709142332j552ee3d1sb775cae7123d43@mail.gmail.com> On 9/14/07, Paul wrote: > Hi, > On Sat, 2007-09-15 at 02:59 +0900, Mamoru Tasaka wrote: > > > > Are you out there Paul? Anyone else know how to contact Paul? > > > > > > > Umm.. Actually Paul does not seem to react to any bugzilla reports > > for months, however it seems that he is reading fedora-list. > > I am still here, although after this last 6 months, I've left the wife, > lost a job, started another and am currently running around like an > idiot trying to catch my own shadow! > > I will get back to people as soon as I can... Best of luck dude. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From Lam at Lam.pl Sat Sep 15 07:24:33 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 15 Sep 2007 09:24:33 +0200 Subject: Please, make lftp orphaned!!! In-Reply-To: <1189835401.3661.2.camel@localhost6.localdomain6> References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <20070914135524.197d7d02@lumos.localdomain> <1189835401.3661.2.camel@localhost6.localdomain6> Message-ID: <20070915092433.65a87287@pensja.lam.pl> Dnia 2007-09-14, o godz. 23:50:01 Richi Plana napisa?(a): > Count me in on C/C++, python, php and perl, I guess. If there's going to > be a list, that is. Yeah, please create a list and when you do so, don't forget to post to f-d-announce, so I don't miss it here, thanks :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Sat Sep 15 08:36:34 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 15 Sep 2007 10:36:34 +0200 Subject: Mirrors page Message-ID: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> Hello all, The fullsearch link at http://fedoraproject.org/wiki/Mirrors does not make a lot of sense (just look at the result page if you let this run through all pages). Who has access to this page? regards, Florian La Roche From drago01 at gmail.com Sat Sep 15 10:10:43 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 15 Sep 2007 12:10:43 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914175354.0c97972e@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> Message-ID: <46EBAFA3.7090005@gmail.com> Jesse Keating wrote: > On Fri, 14 Sep 2007 15:52:53 -0600 > Richi Plana wrote: > > >> Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What >> was the proposed fix to make it work with PulseAudio enabled? >> > > What I had to do to get it working for me was install the > pulseaudio-lib.i386 package. I'm on x86_64 and using flash via > nspluginwrapper.i386, and thus I needed the i386 pulse libs. Now it's > working just fine. > > ... works now too ;) From drago01 at gmail.com Sat Sep 15 10:13:07 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 15 Sep 2007 12:13:07 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070914215447.2597c58b@lumos.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914175354.0c97972e@lumos.localdomain> <1189807216.24350.15.camel@localhost6.localdomain6> <20070914203921.3278dfde@lumos.localdomain> <604aa7910709141744u1d73bb17g439e83a422b9ab8a@mail.gmail.com> <20070914210610.31fdaf59@lumos.localdomain> <1189819069.27148.10.camel@localhost6.localdomain6> <20070914215447.2597c58b@lumos.localdomain> Message-ID: <46EBB033.6070709@gmail.com> Jesse Keating wrote: > On Fri, 14 Sep 2007 19:17:49 -0600 > Richi Plana wrote: > > >> BTW, since flash-plugin is an i386 package, wouldn't a Require: >> pulseaudio-lib be enough for it to require the .i386 version? >> > > No, that's not the way our rpm works. > > but since there are no x86_64 flash what about not shipping the lib in the x86_64 packages? (useless for now) From tmus at tmus.dk Sat Sep 15 10:32:15 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 15 Sep 2007 08:32:15 -0200 Subject: Announcing rpmfusion In-Reply-To: <46E637DB.6060102@hhs.nl> References: <46E637DB.6060102@hhs.nl> Message-ID: Hans de Goede wrote: > > We don't have a repository ready for end users yet, but we are actively > working on merging the following ones: > > * http://dribble.org.uk/ > * http://freshrpms.net/ > * http://rpm.livna.org/ > Cool... Have you spoken to the guys over at RPMforge too? They have a load of high-quality packages and perhaps they would be a good partner in this as well... Even if it's just by agreeing now to step on each other. :) Cheers! /Thomas From tmus at tmus.dk Sat Sep 15 10:36:57 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 15 Sep 2007 08:36:57 -0200 Subject: Disable IPv6 by default. In-Reply-To: <46E94BD2.5080506@BitWagon.com> References: <46E9447E.9080105@hi.is> <20070913141757.GJ8380@angus.ind.WPI.EDU> <200709130923.47235.dennis@ausil.us> <46E94BD2.5080506@BitWagon.com> Message-ID: John Reiser wrote: >> I use ipv6 daily. why should i go through extra steps when having both >> enabled does not hurt people with ipv4 only connections? > > Perhaps you've heard of the recommended policy "turn off all unused services"? > Enabling IPv6 wastes RAM (several dozen pages) and is a security risk > when the only connections used are IPv4. > > Just publicize the easy OFF switch: > ----- /etc/modprobe.conf > alias net-pf-10 off > ----- > Actually... That is no longer as useful as it used to be. On F7, IPv6 will still be enabled on boot, even if this config is in place (in my experience)... Try putting this in modprobe.conf instead: ----- install ipv6 /bin/true ----- /Thomas From tmus at tmus.dk Sat Sep 15 10:45:17 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 15 Sep 2007 08:45:17 -0200 Subject: Disable IPv6 by default. In-Reply-To: <46E95966.9030604@hi.is> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> Message-ID: J?hann B. Gu?mundsson wrote: > Dennis Gilmore wrote: >> Please provide proof of your claims. where is the security risk? >> Johann. why exactly do you want ipv6 disabled? >> > > Majority of user are not using it, it's wasting time and resources, > faster boot time. > > When I turn things "off" or disable them programs should not be wasting > time and resources > to be running an constantly listening or checking and wondering if they > are gonna receive "instruction" to process and further instruct > a program that I have already disabled. > In all fairness... put "install ipv6 /bin/true" in modprobe.conf, then run "chkconfig ip6tables off" and that's it - after a reboot, you're IPv6 free... This is just not worth changing defaults over. IPv6 is the future (whether you like it or not), so lets just leave it there to be as ready as possible when the ship sails. I haven't swithced to IPv6 either, but it takes less that 30 secs to disable it on a newly installed system. 30 secs that I can easily spare on this. If you do mass installations. Letting kickstart implement these changes will add 0 seconds to the install time. /Thomas From buildsys at redhat.com Sat Sep 15 10:51:57 2007 From: buildsys at redhat.com (Build System) Date: Sat, 15 Sep 2007 06:51:57 -0400 Subject: rawhide report: 20070915 changes Message-ID: <200709151051.l8FApvfm018502@porkchop.devel.redhat.com> New package eclipse-egit Eclipse Git plug-in New package python-GnuPGInterface A Python module to interface with GnuPG Updated Packages: bigboard-0.5.16-1.fc8 --------------------- * Wed Sep 12 2007 Colin Walters - 0.5.16-1 - new upstream cacti-0.8.6j-8.fc8 ------------------ * Fri Sep 14 2007 Mike McGrath - 0.8.6j-8 - Fix for CVE-2007-3112 bz#243592 compat-wxGTK26-2.6.3-8 ---------------------- * Fri Sep 14 2007 Michael Schwendt - 2.6.3-8 - Patch some dangerous pointer dereferences in src/common/strconv.cpp. compiz-0.5.2-11.0ec3ec.fc8 -------------------------- * Fri Sep 14 2007 Warren Togami - 0.5.2-11 - compiz-gnome: install core schema so it actually works - remove unnecessary gconf stuff from %install dbus-1.1.2-6.fc8 ---------------- * Fri Sep 14 2007 Bill Nottingham - 1.1.2-6.fc8 - fix daemon abort when SELinux denies passing on a message (#283231) * Fri Sep 14 2007 Dan Walsh - 1.1.2-5.fc8 - Reverse we_were_root check to setpcap if we were root. Also only init audit if we were root. So error dbus message will not show up when policy reload happens. dbus -session will no longer try to send audit message, only system will. * Tue Aug 28 2007 David Zeuthen - 1.1.2-4.fc8 - Make dbus require dbus-libs (#261721) dcraw-8.77-2.fc8 ---------------- * Mon Feb 05 2007 Nils Philippsen - 8.77-2 - rebuild with pristine source tarball duplicity-0.4.3-1.fc8 --------------------- * Sat Sep 15 2007 Robert Scheck 0.4.3-1 - Upgrade to 0.4.3 (#265701) - Updated the license tag according to the guidelines fedora-logos-7.92.1-2.fc8 ------------------------- * Fri Sep 14 2007 Bill Nottingham - 7.92.1-2- - regen tarball fedora-release-7.91-2 --------------------- * Fri Sep 14 2007 Jesse Keating - 7.91-2 - Use failovermethod=priority in yum configs (243698) gamin-0.1.9-4.fc8 ----------------- * Fri Sep 14 2007 Matthias Clasen - 0.1.9-4 - Fix a memory leak * Fri Sep 14 2007 Ray Strode - 0.1.9-3 - don't poll for non-existant watched files (bug 240385) gcc-4.1.2-24 ------------ * Fri Sep 14 2007 Jakub Jelinek 4.1.2-24 - backport __builtin_va_arg_pack_len () support - fix Fortran error recovery with DATA (Jerry DeLisle, #281331, PR fortran/27954) gconf-editor-2.19.92-1.fc8 -------------------------- * Fri Sep 14 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gedit-1:2.19.92-1.fc8 --------------------- * Fri Sep 14 2007 Matthias Clasen - 1:2.19.92-1 - Update to 2.19.92 geomview-1.9.4-3.fc8 -------------------- * Fri Sep 14 2007 Rex Dieter 1.9.4-3 - use model/vrml,object/x-oogl(register) mimetypes gettext-0.16.1-11.fc8 --------------------- * Fri Sep 14 2007 Nils Philippsen - 0.16.1-11 - remove gettext-xglade-include-expat-285701.patch, add gettext-xglade-define-xml-major-version-285701.patch to determine XML_MAJOR_VERSION from expat.h and define it in config.h (#285701) ginac-1.4.0-2.fc8 ----------------- * Thu Sep 13 2007 Quentin Spencer 1.4.0-2 - Add pkgconfig as a dependency of -devel. * Wed Sep 12 2007 Quentin Spencer 1.4.0-1 - New release. Changes file lists to reflect the removal of some files previously in the devel package. glibmm24-2.14.0-1.fc8 --------------------- * Fri Sep 14 2007 Denis Leroy - 2.14.0-1 - Update to new stable tree 2.14.0 glpk-4.21-1.fc8 --------------- * Fri Sep 14 2007 Quentin Spencer 4.21-1 - New release. Update license tag to GPLv3. gnome-keyring-manager-2.19.92-1.fc8 ----------------------------------- * Fri Sep 14 2007 Matthias Clasen 2.19.92-1 - Update to 2.19.92 gnome-mag-0.14.9-1.fc8 ---------------------- * Fri Sep 14 2007 Matthias Clasen - 0.14.9-1 - Update to 0.14.9 gok-1.3.3-1.fc8 --------------- * Fri Sep 14 2007 Matthias Clasen - 1.3.3-1 - Update to 1.3.3 gstreamer-python-0.10.8-2.fc8 ----------------------------- * Fri Sep 14 2007 Denis Leroy - 0.10.8-2 - Added patch to avoid crash on exit gtk-vnc-0.2.0-1.fc8 ------------------- * Thu Sep 13 2007 Daniel P. Berrange - 0.2.0-1.fc8 - Update to 0.2.0 release gtk2-2.12.0-1.fc8 ----------------- * Fri Sep 14 2007 Matthias Clasen - 2.12.0-1 - Update to 2.12.0 hal-cups-utils-0.6.13-1.fc8 --------------------------- * Fri Sep 14 2007 Tim Waugh 0.6.13-1 - 0.6.13: - Enable/disable fix. - Speed improvements. hwbrowser-0.36-1.fc8 -------------------- * Fri Sep 14 2007 Nils Philippsen - 0.36-1 - make "hwbrowser" executable (#285171) * Mon Sep 10 2007 Nils Philippsen - 0.35-1 - make use of force tagging (since mercurial 0.9.4) * Fri Aug 03 2007 Nils Philippsen - fix licensing and author blurbs - tag as GPLv2+ im-chooser-0.5.1-2.fc8 ---------------------- * Fri Sep 14 2007 Akira TAGOH - 0.5.1-2 - Add README into the package. international-time-0.0.2-4.fc8 ------------------------------ * Fri Sep 14 2007 Tim Waugh 0.0.2-4 - Use the current time (bug #291151). iputils-20070202-5.fc8 ---------------------- * Fri Sep 14 2007 Martin Bacovsky - 20070202-5 - rebuild jd-1.9.6-0.4.svn1335.fc8 ------------------------ * Sat Sep 15 2007 Mamoru Tasaka - 1.9.6-0.4.svn1335 - svn 1335 * Sun Aug 05 2007 Mamoru Tasaka - 1.9.6-0.2.beta070804 - 1.9.6 beta 070804 release 2 * Sat Aug 04 2007 Mamoru Tasaka - 1.9.6-0.1.beta070804 - 1.9.6 beta 070804 keepalived-1.1.14-2.fc8 ----------------------- * Fri Sep 14 2007 Matthias Saou 1.1.14-2 - Include patch from Shinji Tanaka to fix conf include from inside some directives like vrrp_instance. * Thu Sep 13 2007 Matthias Saou 1.1.14-1 - Update to 1.1.14. - Remove all upstreamed patches. - Remove our init script and sysconfig files, use the same now provided by the upstream package (will need to patch for LSB stuff soonish). - Include new goodies/arpreset.pl in %doc. - Add missing scriplet requirements. kernel-2.6.23-0.184.rc6.git4.fc8 -------------------------------- * Fri Sep 14 2007 Chuck Ebbert - leave boot option as "libata.pata_dma" for now * Fri Sep 14 2007 Chuck Ebbert - x86 setup: limit number of EDD devices scanned - x86 setup: print number of EDD device during scan - libata: change boot option name to "libata.dma" (still only affects PATA drives) * Thu Sep 13 2007 Chuck Ebbert - Linux 2.6.23-rc6-git4 libgsf-1.14.7-1.fc8 ------------------- * Fri Sep 14 2007 Matthias Clasen 1.14.7-1 - Update to 1.14.7 libsigc++20-2.0.18-1 -------------------- * Fri Sep 14 2007 Denis Leroy - 2.0.18-1 - Update to 2.0.18 libtheora-0:1.0alpha8-0.3.svn13393.fc8 -------------------------------------- * Fri Sep 14 2007 Hans de Goede 1.0alpha8-0.3.svn13393 - Fix textrelocations on i386 (bz 253591) maxima-5.13.0-6.fc8 ------------------- * Fri Sep 14 2007 Rex Dieter 5.13.0-6 - xmaxima.desktop: Categories=Development,Math nsd-3.0.6-2.fc8 --------------- * Fri Sep 14 2007 Paul Wouters 3.0.6-2 - Change locations of ixfr.db and xfrd.state to /var/lib/nsd - Enable NSEC3 - Delay running nsdc update until after nsd has started - Delete xfrd.state on nsd stop - Run nsdc notify in the background, since it can take a very long time when remote servers are unavailable. policycoreutils-2.0.25-14.fc8 ----------------------------- * Fri Sep 14 2007 Dan Walsh 2.0.25-14 - Fix calls to _admin interfaces python-2.5.1-11.fc8 ------------------- * Fri Sep 14 2007 Jeremy Katz - 2.5.1-11 - fix encoding of sqlite .py files to work around weird encoding problem in Turkish (#283331) qt4-4.3.1-8.fc8 --------------- * Fri Sep 14 2007 Rex Dieter 4.3.1-8 - -x11: Req: redhat-rpm-config rpm, app-wrapper/multilib fun (#277581) * Thu Sep 13 2007 Rex Dieter 4.3.1-7 - include qt4-logo icon, used by qtdemo/qtconfig (#241452) - linguist.desktop: use new linguist4 icons - -devel,-x11: %post/%postun scriptlets (icons, mimetypes) * Thu Sep 13 2007 Than Ngo - 4.3.1-4 - fixed bz241452, add qtdemo/qtconfig icons - fixed bz249242, designer4 - segmentation fault on s390x quagga-0:0.99.8-1.1.fc8 ----------------------- * Fri Sep 14 2007 Martin Bacovsky - 0.99.8-1.1 - rebuild redhat-artwork-7.0.0-11.fc8.1 ----------------------------- * Fri Sep 14 2007 Than Ngo - 7.0.0-11.1 - fix bz276731, KWin theme shows pixel noise for "sticky" icon rss-glx-0.8.1.p-10.fc8 ---------------------- * Fri Sep 14 2007 Nils Philippsen 0.8.1.p-10 - replace requirement on /usr/bin/kxsconfig by kdeartwork-kxe (Fedora >= 7, RHEL >= 6), kdeartwork-extras (<= Fedora 6, RHEL 5) - license is GPLv2 - run /usr/sbin/update-xscreensaver-hacks in %post, %postun, require xscreensaver-base >= 5.03-3 for that - don't reference upstream URL for source tarball as we ship a modified one * Mon Sep 03 2007 Nils Philippsen - implement revamped modular xscreensaver configuration (#200881) - require post/preun xscreensaver-base min/max EVR - don't let %preun fail rubygems-0.9.4-1.fc8 -------------------- * Fri Jul 27 2007 David Lutterkort - 0.9.4-1 - Conditionalize so it builds on RHEL4 squid-7:2.6.STABLE16-1.fc8 -------------------------- * Fri Sep 14 2007 Martin Bacovsky - 7:2.6.STABLE16-1 - upgrade to latest upstream 2.6.STABLE16 tomboy-0.7.8-1.fc8 ------------------ * Fri Sep 14 2007 Matthias Clasen - 0.7.8-1 - Update to 0.7.8 verbiste-0.1.21-1.fc8 --------------------- * Fri Sep 14 2007 Konstantin Ryabitsev - 0.1.21-1 - Upstream 0.1.21 - Adjust license to match expected standard - Make sure docs are utf-8 wxMaxima-0.7.2-4.fc8 -------------------- * Fri Sep 14 2007 Rex Dieter 0.7.3-4 - wxmaxima.desktop: Categories=Development,Math xscreensaver-1:5.03-5.fc8 ------------------------- * Sat Sep 15 2007 Mamoru Tasaka - 1:5.03-5 - Add some comments on update script. Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070826.fc8.i386 requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) eclipse-egit - 0.2.2-0.git20070826.fc8.x86_64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070826.fc8.ppc requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 eclipse-egit - 0.2.2-0.git20070826.fc8.ppc64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From skvidal at fedoraproject.org Sat Sep 15 11:51:08 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 15 Sep 2007 07:51:08 -0400 Subject: Mirrors page In-Reply-To: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> References: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> Message-ID: <1189857068.2602.0.camel@cutter> On Sat, 2007-09-15 at 10:36 +0200, Florian La Roche wrote: > Hello all, > > The fullsearch link at http://fedoraproject.org/wiki/Mirrors > does not make a lot of sense (just look at the result page if you > let this run through all pages). > > Who has access to this page? > What fullsearch link at that page? -sv From dwmw2 at infradead.org Sat Sep 15 11:59:21 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 15 Sep 2007 13:59:21 +0200 Subject: Disable IPv6 by default. In-Reply-To: References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> Message-ID: <1189857561.4460.44.camel@shinybook.infradead.org> On Sat, 2007-09-15 at 08:45 -0200, Thomas M Steenholdt wrote: > This is just not worth changing defaults over. IPv6 is the future > (whether you like it or not), so lets just leave it there to be as ready > as possible when the ship sails. I haven't swithced to IPv6 either, but > it takes less that 30 secs to disable it on a newly installed system. 30 > secs that I can easily spare on this. A whole 30 seconds? You can actually get proper IPv6 connectivity in that amount of time, if you have a public IPv4 address: echo IPV6_DEFAULTDEV=tun6to4 >> /etc/sysconfig/network echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 More details, and how to set it up to route for a whole subnet of machines so that all you have to do is plug them in, at http://linux.yyz.us/ipv6-fc2-howto.html -- dwmw2 From jonathan.roberts.uk at googlemail.com Sat Sep 15 12:18:02 2007 From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts) Date: Sat, 15 Sep 2007 13:18:02 +0100 Subject: Fwd: Graphical Shutdown In-Reply-To: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> Message-ID: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> I sent the below message to the Fedora-art-list and it was suggested I ask here... ---------- Forwarded message ---------- From: Jonathan Roberts Date: 15 Sep 2007 12:25 Subject: Graphical Shutdown To: "Discussions about the artwork included with Fedora, including icons, themes, and wallpapers." Not sure if this is the relevant list, but...is there any possibility of F8 having a graphical shutdown? Perhaps even just a non-verbose shutdown mode? It's just my humble opinion, but I find it looks ugly and breaks the experience a bit... Jon From ich at frank-schmitt.net Fri Sep 14 21:53:38 2007 From: ich at frank-schmitt.net (Frank Schmitt) Date: Fri, 14 Sep 2007 23:53:38 +0200 Subject: Please, make lftp orphaned!!! References: <200709141829.07383.alain.portal@free.fr> <46EAB876.1090600@fedoraproject.org> <200709141909.08387.alain.portal@free.fr> <46EAC243.1030704@hhs.nl> <604aa7910709141029n1e37e95ewe6170bfeed4e17f1@mail.gmail.com> <46EAC48C.9040909@poolshark.org> <46EAC7C6.1030802@hhs.nl> <1189792650.369.5.camel@rousalka.dyndns.org> <6482.63.85.68.164.1189791037.squirrel@mail.jcomserv.net> <604aa7910709141106k2df11ae9tc2eeb8bc96ddf14c@mail.gmail.com> Message-ID: "Jeff Spaleta" writes: > On 9/14/07, Jon Ciesla wrote: >> +1 > > Is there a potential bugzilla enhancement idea here as well? > Like a settable flag that the bug owner can use to send the bat signal > up into the air for the code squad to see? Very nice ideas. -- 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 Matt_Domsch at dell.com Sat Sep 15 13:22:49 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 15 Sep 2007 08:22:49 -0500 Subject: Mirrors page In-Reply-To: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> References: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> Message-ID: <20070915132249.GA25308@auslistsprd01.us.dell.com> On Sat, Sep 15, 2007 at 10:36:34AM +0200, Florian La Roche wrote: > Hello all, > > The fullsearch link at http://fedoraproject.org/wiki/Mirrors > does not make a lot of sense (just look at the result page if you > let this run through all pages). > > Who has access to this page? Where would you like it to point to instead? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat Sep 15 13:25:03 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 15 Sep 2007 08:25:03 -0500 Subject: Mirrors page In-Reply-To: <20070915132249.GA25308@auslistsprd01.us.dell.com> References: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> <20070915132249.GA25308@auslistsprd01.us.dell.com> Message-ID: <20070915132503.GB25308@auslistsprd01.us.dell.com> On Sat, Sep 15, 2007 at 08:22:49AM -0500, Matt Domsch wrote: > On Sat, Sep 15, 2007 at 10:36:34AM +0200, Florian La Roche wrote: > > Hello all, > > > > The fullsearch link at http://fedoraproject.org/wiki/Mirrors > > does not make a lot of sense (just look at the result page if you > > let this run through all pages). > > > > Who has access to this page? > > Where would you like it to point to instead? I pointed it at http://mirrors.fedoraproject.org//mirrorlists/publiclist//Fedora/7/ instead. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From icon at fedoraproject.org Sat Sep 15 13:59:13 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sat, 15 Sep 2007 09:59:13 -0400 Subject: USB audio takes over other devices on boot Message-ID: Hello, all: Since there isn't a mic input jack on Mac Mini, I have to use a USB headset. If I leave it plugged in when booting, the HDA Intel onboard device doesn't even show up any more in my ALSA device selector -- only USB audio devices are present. So, I have to remember to unplug the headset before booting, in order for the onboard audio to still show up and work (we like music). I don't think this is desired behaviour -- both devices appear to work correctly when I plug in the USB headset after the boot. I'm not sure if this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms do seem similar. Can anyone confirm with other devices? This is on F7. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From choeger at cs.tu-berlin.de Sat Sep 15 15:40:22 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sat, 15 Sep 2007 17:40:22 +0200 Subject: empty dns information from openvpn servers Message-ID: <1189870822.24399.13.camel@choeger5> hi, I have some proposals to handle this bug: https://bugzilla.redhat.com/show_bug.cgi?id=244274 (in short, if an openvpn server does not push dns informations to the client, the networkmanager-openvpn plugin sends empty addresses and networkmanager creates an empty /etc/resolv.conf resulting in loss of comfort using the plugin) I would prefer to have an "ignore pushed dns information" option in the plugin, as seen in the attached glade file. The simplest method would be to patch the plugin to parse the old resolv.conf and ask NM to use the old data. This would only require to patch the plugin. A better way would be to inform NM, that there is no valid new information available and to use the old file. This would require patches for both packages. (The patch mentioned in the ubuntu bug report seems to already do exactly this for NM by jumping out if there is an obvious wrong nameserver ip returned) I would do it myself, but im rather new in gnome propgramming in common and dbus in special. It would be nice if someone could give me a hint on how to use the value of the checkbox, and if this is even the right direction to solve the problem. regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: nm-openvpn-dialog.glade Type: application/x-glade Size: 81253 bytes Desc: not available URL: From ngompa13 at gmail.com Sat Sep 15 16:24:43 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Sat, 15 Sep 2007 11:24:43 -0500 Subject: Announcing rpmfusion In-Reply-To: References: <46E637DB.6060102@hhs.nl> Message-ID: <8278b1b0709150924v3308613cx94d0af4c1d170b17@mail.gmail.com> Umm, freshrpms.net is part of RPMForge last I checked, but, also last I checked, RPMForge was mostly RHEL packages.... On 9/15/07, Thomas M Steenholdt wrote: > > Hans de Goede wrote: > > > > We don't have a repository ready for end users yet, but we are actively > > working on merging the following ones: > > > > * http://dribble.org.uk/ > > * http://freshrpms.net/ > > * http://rpm.livna.org/ > > > > Cool... > > Have you spoken to the guys over at RPMforge too? They have a load of > high-quality packages and perhaps they would be a good partner in this > as well... Even if it's just by agreeing now to step on each other. :) > > Cheers! > > /Thomas > > -- > 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 ssorce at redhat.com Sat Sep 15 16:40:38 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 15 Sep 2007 12:40:38 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189857561.4460.44.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> Message-ID: <1189874439.32250.29.camel@willson> On Sat, 2007-09-15 at 13:59 +0200, David Woodhouse wrote: > On Sat, 2007-09-15 at 08:45 -0200, Thomas M Steenholdt wrote: > > This is just not worth changing defaults over. IPv6 is the future > > (whether you like it or not), so lets just leave it there to be as ready > > as possible when the ship sails. I haven't swithced to IPv6 either, but > > it takes less that 30 secs to disable it on a newly installed system. 30 > > secs that I can easily spare on this. > > A whole 30 seconds? You can actually get proper IPv6 connectivity in > that amount of time, if you have a public IPv4 address: > > echo IPV6_DEFAULTDEV=tun6to4 >> /etc/sysconfig/network > echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 > echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 > > More details, and how to set it up to route for a whole subnet of > machines so that all you have to do is plug them in, at > http://linux.yyz.us/ipv6-fc2-howto.html Ok, I tried out this one, and it works as long as you manually usef ifup/ifdown, but as soon as NetworkManager gets in the equation nothing works. Is there a way to configure NetworkManager to do 6-to-4 ? I use NM to quickly activate the VPN and to easily jump on WiFi Nnetworks, so if I have to choose between IPV6 and NM, right now I have to choose NM. Simo. From myfedora at richip.dhs.org Sat Sep 15 16:55:02 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 15 Sep 2007 10:55:02 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> Message-ID: <1189875302.18290.13.camel@localhost6.localdomain6> On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > Not sure if this is the relevant list, but...is there any possibility > of F8 having a graphical shutdown? Perhaps even just a non-verbose > shutdown mode? It's just my humble opinion, but I find it looks ugly > and breaks the experience a bit... If I were to guess at people's responses ... The crowd who wanted an all-text startup complete with kernel messages for debugging purposes would probably say "breaks what experience? It's a shutdown. By definition, the experience should be over" People who believe in symmetry or consistency would probably argue for a similar setup to the graphical start-up procedure (since services shutting down also give out similar status results). My questions: 1) What would it take to use rhgb for shutdown? Is it just a matter of executing /usr/bin/rhgb as in /etc/rc.d/rc.sysinit upon shutting down? The messages in rhgb startup seem generic enough (no mention of "Starting up..") 2) How exactly does /sbin/shutdown work, anyway? I'm familiar with how the startup scripts get called by init on startup (via sysinit -> /etc/rc.d/rc.sysinit), but I've never figured out how it gets started on shutdown. Slightly related topic ... well, alright, off-topic. 3) Is there going to be a move by Fedora to something other/better than SysVInit? -- Richi Plana From myfedora at richip.dhs.org Sat Sep 15 17:11:44 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 15 Sep 2007 11:11:44 -0600 Subject: Disable IPv6 by default. In-Reply-To: <1189857561.4460.44.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> Message-ID: <1189876304.18290.18.camel@localhost6.localdomain6> On Sat, 2007-09-15 at 13:59 +0200, David Woodhouse wrote: > A whole 30 seconds? You can actually get proper IPv6 connectivity in > that amount of time, if you have a public IPv4 address: > > echo IPV6_DEFAULTDEV=tun6to4 >> /etc/sysconfig/network > echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 > echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 > > More details, and how to set it up to route for a whole subnet of > machines so that all you have to do is plug them in, at > http://linux.yyz.us/ipv6-fc2-howto.html I have to ask people who IPv6 this: What are the advantages of using IPv6 right now? Specially tunneling. Is there anything I can get with using IPv6 at this point that I can't while using IPv4? There's been mention of wireless. Does that have anything to do with it? Last I read up on IPv6, it's sole purpose (and I could be wrong) was just to address the dwindling address space of IPv4. Currently, are there any public machines accessible on the Internet that are only addressable via IPv6? (It just dawned on me that I may be missing out on a lot of things because I'm not using IPv6 right now). BTW ... to Cisco engineers out there. How are the core routers coping? I understand that when the time comes, it'll take a LOT of processing power to handle the 128-bit address space and the number of smaller subnets. -- Richi Plana From ssorce at redhat.com Sat Sep 15 17:18:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 15 Sep 2007 13:18:10 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189876304.18290.18.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> Message-ID: <1189876690.32250.34.camel@willson> On Sat, 2007-09-15 at 11:11 -0600, Richi Plana wrote: > I have to ask people who IPv6 this: What are the advantages of using > IPv6 right now? Specially tunneling. Is there anything I can get with > using IPv6 at this point that I can't while using IPv4? There's been > mention of wireless. Does that have anything to do with it? Afaik nothing specific to wireless, one GOOD thing is that you have a full public address, and you can have a public address on each machine in your home/small shop/whatever and get rid of NAT and all the problems it causes. > Last I read up on IPv6, it's sole purpose (and I could be wrong) was > just to address the dwindling address space of IPv4. Currently, are > there any public machines accessible on the Internet that are only > addressable via IPv6? (It just dawned on me that I may be missing out > on > a lot of things because I'm not using IPv6 right now). Yes there are some sites that are IPv6 only. You can get some info on www.sixxs.net > BTW ... to Cisco engineers out there. How are the core routers coping? > I > understand that when the time comes, it'll take a LOT of processing > power to handle the 128-bit address space and the number of smaller > subnets. AFAIK, unless changed recently Cisco keep dragging feets and their routers are *much* slower when dealing with IPv6, other vendors seem to do better. But I have not looked in the area for a couple of years, so, maybe, Cisco has released something better now. (Afaik this was also one of the reason ISPs refrained to deploy IPv6 back then as the network performances were definitely affected). Simo. From myfedora at richip.dhs.org Sat Sep 15 17:32:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 15 Sep 2007 11:32:29 -0600 Subject: Disable IPv6 by default. In-Reply-To: <1189876690.32250.34.camel@willson> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> <1189876690.32250.34.camel@willson> Message-ID: <1189877549.21491.8.camel@localhost6.localdomain6> On Sat, 2007-09-15 at 13:18 -0400, Simo Sorce wrote: > On Sat, 2007-09-15 at 11:11 -0600, Richi Plana wrote: > > I have to ask people who IPv6 this: What are the advantages of using > > IPv6 right now? Specially tunneling. Is there anything I can get with > > using IPv6 at this point that I can't while using IPv4? There's been > > mention of wireless. Does that have anything to do with it? > > Afaik nothing specific to wireless, one GOOD thing is that you have a > full public address, and you can have a public address on each machine > in your home/small shop/whatever and get rid of NAT and all the problems > it causes. Kind of like NAT, then. Is there an IPv6 address registry? Can I acquire a publiv IPv6 address space (even if it isn't routeable right now)? I'm assuming that IPv6 isn't being routed right now and most people just tunnel. (I'll have to ask my ISP). I seriously didn't know that IPv6 is actively being routed now (without tunneling). -- Richi Plana From Lam at Lam.pl Sat Sep 15 17:35:08 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 15 Sep 2007 19:35:08 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189876304.18290.18.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> Message-ID: <20070915193508.48774882@pensja.lam.pl> Dnia 2007-09-15, o godz. 11:11:44 Richi Plana napisa?(a): > Last I read up on IPv6, it's sole purpose (and I could be wrong) was > just to address the dwindling address space of IPv4 Start from http://en.wikipedia.org/wiki/IPv6#Features_of_IPv6, then enter discussion :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Sat Sep 15 18:54:09 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 15 Sep 2007 14:54:09 -0400 Subject: Disable IPv6 by default. In-Reply-To: <1189877549.21491.8.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> <1189876690.32250.34.camel@willson> <1189877549.21491.8.camel@localhost6.localdomain6> Message-ID: <20070915185409.GR8380@angus.ind.WPI.EDU> On Sat, Sep 15, 2007 at 11:32:29AM -0600, Richi Plana wrote: > Kind of like NAT, then. Is there an IPv6 address registry? Can I acquire > a publiv IPv6 address space (even if it isn't routeable right now)? I'm > assuming that IPv6 isn't being routed right now and most people just > tunnel. (I'll have to ask my ISP). > I seriously didn't know that IPv6 is actively being routed now (without > tunneling). Yes, it has been actively routed for years. It's there on RENs (Research and Education Networks) like Internet2, as well as commercial ISPs like MCI, Sprint, British Telecom, Global Crossing, Teleglobe, NTT/Verio, and Cable & Wireless. Even if tunnels are used in some cases, the tunnles still need to be routed. However, tunnelling is becoming less and less common as infrastructure is upgraded to allow native transport. From redhat at olen.net Sat Sep 15 20:37:14 2007 From: redhat at olen.net (Ola Thoresen) Date: Sat, 15 Sep 2007 22:37:14 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189877549.21491.8.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> <1189876690.32250.34.camel@willson> <1189877549.21491.8.camel@localhost6.localdomain6> Message-ID: <46EC427A.60108@olen.net> Richi Plana wrote: > On Sat, 2007-09-15 at 13:18 -0400, Simo Sorce wrote: >> On Sat, 2007-09-15 at 11:11 -0600, Richi Plana wrote: >>> I have to ask people who IPv6 this: What are the advantages of using >>> IPv6 right now? Specially tunneling. Is there anything I can get with >>> using IPv6 at this point that I can't while using IPv4? There's been >>> mention of wireless. Does that have anything to do with it? >> Afaik nothing specific to wireless, one GOOD thing is that you have a >> full public address, and you can have a public address on each machine >> in your home/small shop/whatever and get rid of NAT and all the problems >> it causes. > > Kind of like NAT, then. Is there an IPv6 address registry? Can I acquire > a publiv IPv6 address space (even if it isn't routeable right now)? I'm > assuming that IPv6 isn't being routed right now and most people just > tunnel. (I'll have to ask my ISP). traceroute to www.freebsd.org (2001:4f8:fff6::21), 30 hops max, 40 byte packets 1 2001:840:101a:ffff::1 0.320 ms 0.201 ms 0.173 ms 2 2001:840:0:f000::a 39.593 ms 43.471 ms 44.600 ms 3 2001:840::1 64.704 ms 66.456 ms 68.157 ms 4 2001:840:0:88::81 69.777 ms 79.340 ms 82.366 ms 5 2001:2000:3080:5::1 88.880 ms 93.157 ms 95.838 ms 6 2001:728:0:4000::1 96.919 ms 99.085 ms 101.449 ms 7 2001:728:0:7001::1 103.101 ms 95.157 ms 93.461 ms 8 2001:728:0:2000::59 93.872 ms 98.011 ms 97.881 ms 9 2001:418:0:2000::10d 172.262 ms 173.862 ms 166.285 ms 10 2001:418:0:2000::bd 186.359 ms 191.858 ms 189.147 ms 11 2001:418:0:2000::36 189.348 ms 190.107 ms 189.071 ms 12 2001:418:0:2000::1b9 237.950 ms 237.712 ms 220.769 ms 13 2001:418:0:2000::1a1 224.523 ms 219.251 ms 216.616 ms 14 2001:418:0:2000::15a 217.473 ms 217.222 ms 216.515 ms 15 2001:418:0:5000::1e 218.824 ms 228.069 ms 220.305 ms 16 2001:4f8:0:1::3e:2 220.787 ms 225.144 ms 228.025 ms 17 2001:4f8:fff6::21 228.348 ms 223.070 ms 223.667 ms No tunnels here... And firefox uses ipv6 automatically if I browse that site. The normal registies are maintaining it: % This is the RIPE Whois query server #2. % The objects are in RPSL format. % (...) % Information related to '2001:840::/32' inet6num: 2001:840::/32 netname: NO-POWERTECH-20020725 descr: PowerTech Information Systems AS Rgds. Ola Thoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From ruben at rubenkerkhof.com Sat Sep 15 22:44:02 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sun, 16 Sep 2007 00:44:02 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1189877549.21491.8.camel@localhost6.localdomain6> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> <1189876304.18290.18.camel@localhost6.localdomain6> <1189876690.32250.34.camel@willson> <1189877549.21491.8.camel@localhost6.localdomain6> Message-ID: <5CB1A0DC-7B2D-45F4-8D73-71C7AF17FB64@rubenkerkhof.com> On 15-sep-2007, at 19:32, Richi Plana wrote: > Kind of like NAT, then. Is there an IPv6 address registry? Can I > acquire > a publiv IPv6 address space (even if it isn't routeable right now)? > I'm > assuming that IPv6 isn't being routed right now and most people just > tunnel. (I'll have to ask my ISP). I got curious about this ipv6 thing, so I registered for an account at sixxs.net an hour ago. Just drop the username and password you get from them in /etc/ aiccu.conf, service aiccu start and that's all :-) Ruben From cjdahlin at ncsu.edu Sat Sep 15 23:53:21 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sat, 15 Sep 2007 19:53:21 -0400 Subject: USB audio takes over other devices on boot In-Reply-To: References: Message-ID: <46EC7071.8090102@ncsu.edu> I have similar issues on a Dell Latitude D810 laptop. Konstantin Ryabitsev wrote: > Hello, all: > > Since there isn't a mic input jack on Mac Mini, I have to use a USB > headset. If I leave it plugged in when booting, the HDA Intel onboard > device doesn't even show up any more in my ALSA device selector -- > only USB audio devices are present. So, I have to remember to unplug > the headset before booting, in order for the onboard audio to still > show up and work (we like music). > > I don't think this is desired behaviour -- both devices appear to work > correctly when I plug in the USB headset after the boot. > > I'm not sure if this is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms > do seem similar. > > Can anyone confirm with other devices? This is on F7. > > Cheers, > From cjdahlin at ncsu.edu Sat Sep 15 23:57:27 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sat, 15 Sep 2007 19:57:27 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1189875302.18290.13.camel@localhost6.localdomain6> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1189875302.18290.13.camel@localhost6.localdomain6> Message-ID: <46EC7167.205@ncsu.edu> Richi Plana wrote: > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > >> Not sure if this is the relevant list, but...is there any possibility >> of F8 having a graphical shutdown? Perhaps even just a non-verbose >> shutdown mode? It's just my humble opinion, but I find it looks ugly >> and breaks the experience a bit... >> > > If I were to guess at people's responses ... > > The crowd who wanted an all-text startup complete with kernel messages > for debugging purposes would probably say "breaks what experience? It's > a shutdown. By definition, the experience should be over" > > People who believe in symmetry or consistency would probably argue for a > similar setup to the graphical start-up procedure (since services > shutting down also give out similar status results). > > My questions: 1) What would it take to use rhgb for shutdown? Is it just > a matter of executing /usr/bin/rhgb as in /etc/rc.d/rc.sysinit upon > shutting down? The messages in rhgb startup seem generic enough (no > mention of "Starting up..") > I believe that some of the cleanup for the bootup sequence mentioned getting rid of rhgb in favor of a new solution > 2) How exactly does /sbin/shutdown work, anyway? I'm familiar with how > the startup scripts get called by init on startup (via sysinit > -> /etc/rc.d/rc.sysinit), but I've never figured out how it gets started > on shutdown. > I believe it signals init to drop into runlevel zero (halted) via dbus. > Slightly related topic ... well, alright, off-topic. 3) Is there going > to be a move by Fedora to something other/better than SysVInit? > -- > > This was discussed some time back. There was somewhat of a decision to stick with SysV and focus on improving its functionality (though I would prefer a new system) > Richi Plana > > From naheemzaffar at gmail.com Sun Sep 16 00:34:54 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 16 Sep 2007 01:34:54 +0100 Subject: no menu entry for bigboard? In-Reply-To: <47324ed80709141346y50ae967y269ba3742b7732ec@mail.gmail.com> References: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> <47324ed80709141346y50ae967y269ba3742b7732ec@mail.gmail.com> Message-ID: <3adc77210709151734r2c12b0dcm9d789c2692515f78@mail.gmail.com> The BigBoard wiki links to the wrong page. (should be wiki/releases/FeatureOnlineDesktop, not wiki/FeatureOnlineDesktop) http://fedoraproject.org/wiki/Releases/FeatureBigboard From ibmalone at gmail.com Sun Sep 16 01:39:40 2007 From: ibmalone at gmail.com (Ian Malone) Date: Sun, 16 Sep 2007 02:39:40 +0100 Subject: USB audio takes over other devices on boot In-Reply-To: References: Message-ID: <46EC895C.5090407@gmail.com> Konstantin Ryabitsev wrote: > Hello, all: > > Since there isn't a mic input jack on Mac Mini, I have to use a USB > headset. If I leave it plugged in when booting, the HDA Intel onboard > device doesn't even show up any more in my ALSA device selector -- > only USB audio devices are present. So, I have to remember to unplug > the headset before booting, in order for the onboard audio to still > show up and work (we like music). > > I don't think this is desired behaviour -- both devices appear to work > correctly when I plug in the USB headset after the boot. > > I'm not sure if this is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms > do seem similar. > > Can anyone confirm with other devices? This is on F7. > Exactly the issue I see on FC6 with a USB VOIP handset: boot with the handset plugged in and it's the only available sound device. No obvious way to force a re-detect even after unplugging said device. -- imalone From sean.bruno at dsl-only.net Sun Sep 16 03:35:47 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sat, 15 Sep 2007 20:35:47 -0700 Subject: USB audio takes over other devices on boot In-Reply-To: <46EC7071.8090102@ncsu.edu> References: <46EC7071.8090102@ncsu.edu> Message-ID: <1189913747.10076.96.camel@home-desk> On Sat, 2007-09-15 at 19:53 -0400, Casey Dahlin wrote: > I have similar issues on a Dell Latitude D810 laptop. > > Konstantin Ryabitsev wrote: > > Hello, all: > > > > Since there isn't a mic input jack on Mac Mini, I have to use a USB > > headset. If I leave it plugged in when booting, the HDA Intel onboard > > device doesn't even show up any more in my ALSA device selector -- > > only USB audio devices are present. So, I have to remember to unplug > > the headset before booting, in order for the onboard audio to still > > show up and work (we like music). > > > > I don't think this is desired behaviour -- both devices appear to work > > correctly when I plug in the USB headset after the boot. > > > > I'm not sure if this is the same as > > https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms > > do seem similar. > > > > Can anyone confirm with other devices? This is on F7. > > > > Cheers, > > > Yeah, this is a pernicious and long lasting issue. I implemented a work around in a previous thread: https://www.redhat.com/archives/fedora-list/2007-July/msg05028.html Sean From michel.sylvan at gmail.com Sun Sep 16 04:11:30 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 16 Sep 2007 00:11:30 -0400 Subject: Review swapsies In-Reply-To: <46EAA15A.3090505@redhat.com> References: <46EA6795.6040404@redhat.com> <46EAA15A.3090505@redhat.com> Message-ID: On 14/09/2007, Richard W.M. Jones wrote: > Michel Salim wrote: > > Would be nice to include some information on what these reviews are > > for -- I ended up clicking on all of them, and then noticing that they > > are all OCamL related. > > A fair point. I've put the package descriptions below. However even if > you're not that interested in OCaml, perhaps people would consider > reviewing them? Indeed! > https://bugzilla.redhat.com/show_bug.cgi?id=253588 > > CIL (C Intermediate Language) is a high-level representation along > with a set of tools that permit easy analysis and source-to-source > transformation of C programs. > Taking this one -- for some reason I cannot assign the bug to myself though, weird. I just changed my e-mail address a while ago, not sure if that's causing problems. FWIW, I did go to the Fedora Accounts System page and update the e-mail address there, so I'm not sure what's wrong. Could someone in charge of Bugzilla have a look? Thanks. -- Michel From greno at verizon.net Sun Sep 16 04:37:04 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 00:37:04 -0400 Subject: F6->F7 upgrade dependency errors Message-ID: <46ECB2F0.1000306@verizon.net> Today while I'm trying to upgrade an F6 machine to F7 I get these error which kills the upgrade: Error: Missing Dependency: libgcj.so.8rh is needed by package libgtk-java Error: Missing Dependency: libgcj.so.8rh is needed by package libgnome-java Error: Missing Dependency: libgcj.so.8rh is needed by package cairo-java Error: Missing Dependency: libgcj.so.8rh is needed by package frysk Error: Missing Dependency: libsnmp.so.10 is needed by package freeradius Error: Missing Dependency: libgcj.so.8rh is needed by package libglade-java Error: Missing Dependency: libgcj.so.8rh is needed by package glib-java Error: Missing Dependency: libgcj.so.8rh is needed by package libgconf-java Error: Missing Dependency: libgcj.so.8rh is needed by package libvte-java How can I satisfy these dependencies during the upgrade? From greno at verizon.net Sun Sep 16 04:50:27 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 00:50:27 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ECB2F0.1000306@verizon.net> References: <46ECB2F0.1000306@verizon.net> Message-ID: <46ECB613.7010906@verizon.net> Gerry Reno wrote: > Today while I'm trying to upgrade an F6 machine to F7 I get these > error which kills the upgrade: > > Error: Missing Dependency: libgcj.so.8rh is needed by package libgtk-java > Error: Missing Dependency: libgcj.so.8rh is needed by package > libgnome-java > Error: Missing Dependency: libgcj.so.8rh is needed by package cairo-java > Error: Missing Dependency: libgcj.so.8rh is needed by package frysk > Error: Missing Dependency: libsnmp.so.10 is needed by package freeradius > Error: Missing Dependency: libgcj.so.8rh is needed by package > libglade-java > Error: Missing Dependency: libgcj.so.8rh is needed by package glib-java > Error: Missing Dependency: libgcj.so.8rh is needed by package > libgconf-java > Error: Missing Dependency: libgcj.so.8rh is needed by package libvte-java > > How can I satisfy these dependencies during the upgrade? > Ok, libsnmp.so.10 is in net-snmp-libs 1:5.3.1-15.fc6 which is the package which is currently installed. So why can't it figure it out? And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this machine has libgcj-4.1.2-13-fc6 installed. So is that a downgrade???? How do I get yum to do a downgrade? From gilboad at gmail.com Sun Sep 16 04:50:24 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 16 Sep 2007 06:50:24 +0200 Subject: USB audio takes over other devices on boot In-Reply-To: References: Message-ID: <1189918224.18191.97.camel@gilboa-home-dev.localdomain> On Sat, 2007-09-15 at 09:59 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > Since there isn't a mic input jack on Mac Mini, I have to use a USB > headset. If I leave it plugged in when booting, the HDA Intel onboard > device doesn't even show up any more in my ALSA device selector -- > only USB audio devices are present. So, I have to remember to unplug > the headset before booting, in order for the onboard audio to still > show up and work (we like music). > > I don't think this is desired behaviour -- both devices appear to work > correctly when I plug in the USB headset after the boot. > > I'm not sure if this is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms > do seem similar. > > Can anyone confirm with other devices? This is on F7. > I've had the same problem with FC6 and F7 with the USB mick on my Webcam. (Plus I have two sound cards on my machine) There's an annoying solution to this problem: Manually edit the modprobe.conf file and set the primary sound card while keeping them all plugged in during boot. E.g. alias snd-card-0 snd-emu10k1 options snd-card-0 index=0 options snd-emu10k1 index=0 alias snd-card-1 snd-intel8x0 options snd-card-1 index=1 options snd-intel8x0 index=1 alias snd-card-2 snd-usb-audio options snd-card-2 index=2 options snd-usb-audio index=2 - Gilboa From greno at verizon.net Sun Sep 16 05:27:03 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 01:27:03 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ECB613.7010906@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> Message-ID: <46ECBEA7.3060502@verizon.net> Gerry Reno wrote: > Gerry Reno wrote: >> Today while I'm trying to upgrade an F6 machine to F7 I get these >> error which kills the upgrade: >> >> Error: Missing Dependency: libgcj.so.8rh is needed by package >> libgtk-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package >> libgnome-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package cairo-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package frysk >> Error: Missing Dependency: libsnmp.so.10 is needed by package freeradius >> Error: Missing Dependency: libgcj.so.8rh is needed by package >> libglade-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package glib-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package >> libgconf-java >> Error: Missing Dependency: libgcj.so.8rh is needed by package >> libvte-java >> >> How can I satisfy these dependencies during the upgrade? >> > Ok, libsnmp.so.10 is in net-snmp-libs 1:5.3.1-15.fc6 which is the > package which is currently installed. So why can't it figure it out? > > And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this > machine has libgcj-4.1.2-13-fc6 installed. So is that a > downgrade???? How do I get yum to do a downgrade? > I tried to update just libgcj but it says: No Packages marked for Update/Obsoletion From sertac.liste at gmail.com Sun Sep 16 05:51:04 2007 From: sertac.liste at gmail.com (=?utf-8?B?U2VydGHDpyDDli4gWcSxbGTEsXo=?=) Date: Sun, 16 Sep 2007 08:51:04 +0300 Subject: Trusting repositories (was: Re: Announcing rpmfusion) In-Reply-To: <20070912223657.GA3613@kerouac> References: <46E63E21.8020305@fedoraproject.org> <20070911160537.696c6a25@localhost.localdomain> <46E6F59B.7010506@fedoraproject.org> <46E7DE8C.7020508@kanarip.com> <46E7EBC2.5070400@gmail.com> <604aa7910709120917i156f3b80tcf10fb5e98b5674f@mail.gmail.com> <1189626133.3999.5.camel@rousalka.dyndns.org> <1189626190.6704.106.camel@cutter> <20070912223657.GA3613@kerouac> Message-ID: <20070916055104.GA3781@kerouac> [13.Eyl.07 01:36 +0300] Serta? ?. Y?ld?z: > [12.Eyl.07 15:43 -0400] seth vidal: >> On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote: >>> I hope yum has a check somewhere to forbid installation of unknown >>> default-on repositories. >> >> how on earth would yum know? Do you want yum to have special behavior if it >> detects a .repo file? > > Not for .repo files, but it would be nice to check for GPG keys it installs. On a second thought, I realized that yum cannot do anything about trust at the moment. And my mindset about trust here (based on public keys being installed or not) was completely flawed. I?ve seen a package executing ?rpm --import? from postinstall scriptlet and maybe it?s possible even from preinstall. If I cannot express my distrust on a repository (or specifically a public key) I cannot express my trust either. And probably this must be solved at the rpm level. Rpm apparently has some (undocumented) code about this: | $ rpm --trust | --trust: missing argument But IIUC at the moment it handles the situation similar to what I?d thought: NOTTRUSTED is similar to NOKEY. As it is, GPG signature verification reduces to a mere integrity check if one wants to use external repositories. -- ~serta? From ville.skytta at iki.fi Sun Sep 16 08:16:30 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 16 Sep 2007 11:16:30 +0300 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ECB613.7010906@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> Message-ID: <200709161116.30610.ville.skytta@iki.fi> On Sunday 16 September 2007, Gerry Reno wrote: > And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this > machine has libgcj-4.1.2-13-fc6 installed. So is that a downgrade???? Yes. Looks like libgcj-4.1.2-18.fc7 which would fix the versioning problem is in the updates/testing/7 repository, it might not hurt to ask its maintainer what's up. From buildsys at redhat.com Sun Sep 16 09:19:10 2007 From: buildsys at redhat.com (Build System) Date: Sun, 16 Sep 2007 05:19:10 -0400 Subject: rawhide report: 20070916 changes Message-ID: <200709160919.l8G9JAeJ007298@porkchop.devel.redhat.com> Updated Packages: chess-1.0-9.fc8 --------------- * Sat Sep 15 2007 Hans de Goede 1.0-9 - Rebuild for new ogre dbus-glib-0.73-3.fc8 -------------------- * Sat Sep 15 2007 Matthias Clasen - 0.73-3 - Rebuild against new expat eclipse-egit-0.2.2-0.git20070911.fc8 ------------------------------------ evolution-2.11.92-4.fc8 ----------------------- * Sat Sep 15 2007 Matthew Barnes - 2.11.92-4.fc8 - Add patch for GNOME bug #477045 (use standard icon names). * Tue Sep 11 2007 Matthew Barnes - 2.11.92-3.fc8 - Add patch for GNOME bug #476040 (fix attachment icon). * Sat Sep 08 2007 Matthias Clasen - 2.11.92-2.fc8 - Split off an evolution-help package glob2-0.9.1-2.fc8 ----------------- * Sun Sep 16 2007 Rafa?? Psota - 0.9.1-2 - new install method * Tue Sep 04 2007 Rafa?? Psota - 0.9.1-1 - update to 0.9.1 librtas-1.3.2-1.fc8 ------------------- * Mon Sep 10 2007 David Cantrell - 1.3.2-1 - Upgraded to librtas-1.3.2 - Cleaned up spec file to conform to Fedora packaging guidelines mod_fcgid-2.2-1.fc8 ------------------- * Fri Sep 14 2007 Paul Howarth 2.2-1 - Update to version 2.2 - Make sure docs are encoded as UTF-8 ogre-1.4.4-1.fc8 ---------------- * Fri Sep 14 2007 Hans de Goede 1.4.4-1 - New upstream release 1.4.4 (bz 291481) pdfcube-0.0.2-6.fc8 ------------------- * Sat Sep 15 2007 Mads Villadsen - 0.0.2-6 - Messed up tagging - trying again. * Sat Sep 15 2007 Mads Villadsen - 0.0.2-5 - Rebuild because of new poppler library ppc64-utils-0.12-1.fc8 ---------------------- * Sat Sep 15 2007 David Cantrell - 0.12-1 - Upgraded to powerpc-utils-1.0.6 and powerpc-utils-papr-1.0.4 - Updated license tag to reflect licenses of all included components pv-1.1.0-1.fc8 -------------- rss-glx-0.8.1.p-11.fc8 ---------------------- * Sat Sep 15 2007 Nils Philippsen 0.8.1.p-11 - enable modular xscreensaver support for Fedora 7 and later (#200881) - include %post/%postun scripts only with modular xscreensaver support system-config-date-1.9.9-1.fc8 ------------------------------ * Sun Sep 16 2007 Nils Philippsen 1.9.9 - pick up updated translations * Sat Sep 15 2007 Nils Philippsen 1.9.8 - pick up updated translations * Mon Sep 10 2007 Nils Philippsen - make use of force tagging (since mercurial 0.9.4) system-config-samba-1.2.52-1.fc8 -------------------------------- * Sat Sep 15 2007 Nils Philippsen - 1.2.52 - pick up updated translations system-config-users-1.2.67-1.fc8 -------------------------------- * Sun Sep 16 2007 Nils Philippsen - 1.2.67 - pick up updated translations * Sat Sep 15 2007 Nils Philippsen - 1.2.66 - pick up updated translations * Mon Sep 10 2007 Nils Philippsen - make use of force tagging (since mercurial 0.9.4) xscreensaver-1:5.03-6.fc8 ------------------------- * Sat Sep 15 2007 Mamoru Tasaka - 1:5.03-6 - Fix update script to treat the ending character of conf file correctly. Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070911.fc8.i386 requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) eclipse-egit - 0.2.2-0.git20070911.fc8.x86_64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070911.fc8.ppc requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 eclipse-egit - 0.2.2-0.git20070911.fc8.ppc64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From dominik at greysector.net Sun Sep 16 11:30:03 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 16 Sep 2007 13:30:03 +0200 Subject: F6->F7 upgrade dependency errors In-Reply-To: <200709161116.30610.ville.skytta@iki.fi> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> Message-ID: <20070916113003.GA5027@ryvius.pekin.waw.pl> On Sunday, 16 September 2007 at 10:16, Ville Skytt? wrote: > On Sunday 16 September 2007, Gerry Reno wrote: > > > And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this > > machine has libgcj-4.1.2-13-fc6 installed. So is that a downgrade???? > > Yes. Looks like libgcj-4.1.2-18.fc7 which would fix the versioning problem is > in the updates/testing/7 repository, it might not hurt to ask its maintainer > what's up. The maintainer has been aware of this for a few weeks now. See bug 251035: https://bugzilla.redhat.com/show_bug.cgi?id=251035 Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From sdl.web at gmail.com Sun Sep 16 11:53:10 2007 From: sdl.web at gmail.com (Leo) Date: Sun, 16 Sep 2007 12:53:10 +0100 Subject: Why use an old GNUTLS? Message-ID: Hi there, I found some problems with gnutls-1.4.5-2.fc7. One of them has caused an Emacs package Gnus to fail to retrieve emails via pop. I don't know if the bug has been fixed in latest GNUTLS 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is there a reason to stick to an old GNUTLS? Any plan to fix the bug? ---- " trace of POP session to pop.gmail.com" ---- Resolving 'pop.gmail.com'... Connecting to '72.14.205.109:995'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'pop.gmail.com'. # valid since: Tue Nov 15 21:22:44 GMT 2005 # expires at: Fri Nov 16 21:22:44 GMT 2007 # fingerprint: 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4 # Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc.,CN=pop.gmail.com # Issuer's DN: C=US,O=Equifax,OU=Equifax Secure Certificate Authority - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: 3DES 168 CBC - MAC: SHA - Compression: NULL - Handshake was completed - Simple Client Mode: +OK Gpop ready for requests from 131.111.223.122 e10pf2134124qbe *** Fatal error: A TLS packet with unexpected length was received. *** Server has terminated the connection abnormally. Process POP finished ---- end ---- Best wishes, -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. I use GNU Emacs <= http://www.gnu.org/software/emacs/ <= From alexl at users.sourceforge.net Sun Sep 16 12:26:54 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 16 Sep 2007 05:26:54 -0700 Subject: Why use an old GNUTLS? In-Reply-To: (Leo's message of "Sun\, 16 Sep 2007 12\:53\:10 +0100") References: Message-ID: <0m642a4wz5.fsf@allele2.localdomain> >>>>> "L" == Leo writes: L> Hi there, I found some problems with gnutls-1.4.5-2.fc7. One of L> them has caused an Emacs package Gnus to fail to retrieve emails L> via pop. I don't know if the bug has been fixed in latest GNUTLS L> 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is L> there a reason to stick to an old GNUTLS? Any plan to fix the bug? Leo, I don't know why it hasn't been updated, probably the maintainer hasn't gotten around to it yet, but there has been a bug filed about it: http://bugzilla.redhat.com/218184 For the reasons you state, I agree it would be bad to have to wait around until F9 to get gnutls updated. I have been having problems with gnutls-1.4.5, not with POP, but with outgoing SMTP traffic to my university's SMTP server with Emacs/Gnus. Alex From alexl at users.sourceforge.net Sun Sep 16 12:37:31 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 16 Sep 2007 05:37:31 -0700 Subject: Why use an old GNUTLS? In-Reply-To: <0m642a4wz5.fsf@allele2.localdomain> (Alex Lancaster's message of "Sun\, 16 Sep 2007 05\:26\:54 -0700") References: <0m642a4wz5.fsf@allele2.localdomain> Message-ID: >>>>> "L" == Leo writes: L> Hi there, I found some problems with gnutls-1.4.5-2.fc7. One of L> them has caused an Emacs package Gnus to fail to retrieve emails L> via pop. I don't know if the bug has been fixed in latest GNUTLS L> 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is L> there a reason to stick to an old GNUTLS? Any plan to fix the bug? [...] >>>>> "AL" == Alex Lancaster writes: AL> http://bugzilla.redhat.com/218184 AL> For the reasons you state, I agree it would be bad to have to wait AL> around until F9 to get gnutls updated. I have been having AL> problems with gnutls-1.4.5, not with POP, but with outgoing SMTP AL> traffic to my university's SMTP server with Emacs/Gnus. Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds. $ rpm -q gnutls --provides libgnutls-extra.so.13 libgnutls-extra.so.13(GNUTLS_1_2) libgnutls-openssl.so.13 libgnutls.so.13 libgnutls.so.13(GNUTLS_1_3) gnutls = 1.4.5-2.fc7 $ rpm -q --whatrequires libgnutls.so.13 gnutls-devel-1.4.5-2.fc7 bug-buddy-2.18.0-2.fc7 loudmouth-1.2.2-3.fc7 gnutls-1.4.5-2.fc7 wireshark-0.99.6-1.fc7 libsoup-2.2.100-1.fc7 evolution-webcal-2.10.0-1.fc7 gnutls-utils-1.4.5-2.fc7 libtranslate-0.99-9.fc6 mutt-1.5.14-4.fc7 wireshark-gnome-0.99.6-1.fc7 ntfsprogs-1.13.1-6.fc7 liferea-1.2.19-3.fc7 evolution-data-server-1.10.3.1-2.fc7 gtk-gnutella-0.96.4-1.fc7 seahorse-1.0.1-6.fc7 cups-libs-1.2.12-4.fc7 cups-1.2.12-4.fc7 vlc-0.8.6c-4.lvn7 evolution-2.10.3-4.fc7 I wonder what .so version gnutls will provide and if it is source-compatible with applications that have been compiled in the past with gnutls <= 1.4.5. Alex From greno at verizon.net Sun Sep 16 13:33:46 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 09:33:46 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <20070916113003.GA5027@ryvius.pekin.waw.pl> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> Message-ID: <46ED30BA.9020202@verizon.net> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 16 September 2007 at 10:16, Ville Skytt? wrote: > >> On Sunday 16 September 2007, Gerry Reno wrote: >> >> >>> And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this >>> machine has libgcj-4.1.2-13-fc6 installed. So is that a downgrade???? >>> >> Yes. Looks like libgcj-4.1.2-18.fc7 which would fix the versioning problem is >> in the updates/testing/7 repository, it might not hurt to ask its maintainer >> what's up. >> > > The maintainer has been aware of this for a few weeks now. See bug 251035: > https://bugzilla.redhat.com/show_bug.cgi?id=251035 > > Regards, > R. > > Ok, the following workaround gets past the libgcj dependency problem: # yum update libgcj --enablerepo=updates-testing ... Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: libgcj i386 4.1.2-18.fc7 updates-testing 19 M Updating for dependencies: cairo-java i386 1.0.5-7.fc7 fedora 134 k cpp i386 4.1.2-18.fc7 updates-testing 2.7 M frysk i686 0.0.1.2007.03.13.rh1-1.fc7 fedora 12 M gcc i386 4.1.2-18.fc7 updates-testing 5.2 M gcc-c++ i386 4.1.2-18.fc7 updates-testing 3.4 M gcc-gfortran i386 4.1.2-18.fc7 updates-testing 3.1 M gcc-gnat i386 4.1.2-18.fc7 updates-testing 11 M gcc-java i386 4.1.2-18.fc7 updates-testing 2.7 M gcc-objc i386 4.1.2-18.fc7 updates-testing 2.5 M glib-java i386 0.2.6-8.fc7 fedora 41 k libgcc i386 4.1.2-18.fc7 updates-testing 90 k libgcj-devel i386 4.1.2-18.fc7 updates-testing 1.5 M libgcj-src i386 4.1.2-18.fc7 updates-testing 12 M libgconf-java i386 2.12.4-8.fc7 fedora 72 k libgfortran i386 4.1.2-18.fc7 updates-testing 228 k libglade-java i386 2.12.5-6.fc7 fedora 78 k libgnat i386 4.1.2-18.fc7 updates-testing 985 k libgnome-java i386 2.12.4-6.fc7 fedora 328 k libgomp i386 4.1.2-18.fc7 updates-testing 79 k libgtk-java i386 2.8.7-4.fc7 fedora 2.1 M libobjc i386 4.1.2-18.fc7 updates-testing 98 k libstdc++ i386 4.1.2-18.fc7 updates-testing 357 k libstdc++-devel i386 4.1.2-18.fc7 updates-testing 2.9 M libvte-java i386 0.12.1-7.fc7 fedora 71 k Transaction Summary ============================================================================= Install 0 Package(s) Update 25 Package(s) Remove 0 Package(s) ============================================================================= However, I still have the libsnmp problem: # yum whatprovides libsnmp.so.10 Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Finished Importing additional filelist information net-snmp-libs.i386 1:5.3.1-15.fc6 installed Matched from: /usr/lib/libsnmp.so.10 /usr/lib/libsnmp.so.10.0.1 libsnmp.so.10 What can I do about this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web at gmail.com Sun Sep 16 13:12:54 2007 From: sdl.web at gmail.com (Leo) Date: Sun, 16 Sep 2007 14:12:54 +0100 Subject: Why use an old GNUTLS? References: <0m642a4wz5.fsf@allele2.localdomain> Message-ID: On 2007-09-16 13:37 +0100, Alex Lancaster wrote: > Hmm, I notice that gnutls is used as a shared library in many > applications that it might be non-trivial to update if the .so version > is bumped because it will require a lot of rebuilds. That's why it is difficult for users to upgrade this package. I try to remove Gnutls and that will remove 299 packages that depend on it as well. -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. I use GNU Emacs <= http://www.gnu.org/software/emacs/ <= From greno at verizon.net Sun Sep 16 13:54:02 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 09:54:02 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ED30BA.9020202@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> Message-ID: <46ED357A.80801@verizon.net> Gerry Reno wrote: > Dominik 'Rathann' Mierzejewski wrote: >> On Sunday, 16 September 2007 at 10:16, Ville Skytt? wrote: >> >>> On Sunday 16 September 2007, Gerry Reno wrote: >>> >>> >>>> And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this >>>> machine has libgcj-4.1.2-13-fc6 installed. So is that a downgrade???? >>>> >>> Yes. Looks like libgcj-4.1.2-18.fc7 which would fix the versioning problem is >>> in the updates/testing/7 repository, it might not hurt to ask its maintainer >>> what's up. >>> >> >> The maintainer has been aware of this for a few weeks now. See bug 251035: >> https://bugzilla.redhat.com/show_bug.cgi?id=251035 >> >> Regards, >> R. >> >> > Ok, the following workaround gets past the libgcj dependency problem: > > # yum update libgcj --enablerepo=updates-testing > > ... > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > Updating: > libgcj i386 4.1.2-18.fc7 > updates-testing 19 M > Updating for dependencies: > cairo-java i386 1.0.5-7.fc7 fedora > 134 k > cpp i386 4.1.2-18.fc7 updates-testing > 2.7 M > frysk i686 0.0.1.2007.03.13.rh1-1.fc7 > fedora 12 M > gcc i386 4.1.2-18.fc7 updates-testing > 5.2 M > gcc-c++ i386 4.1.2-18.fc7 updates-testing > 3.4 M > gcc-gfortran i386 4.1.2-18.fc7 updates-testing > 3.1 M > gcc-gnat i386 4.1.2-18.fc7 > updates-testing 11 M > gcc-java i386 4.1.2-18.fc7 updates-testing > 2.7 M > gcc-objc i386 4.1.2-18.fc7 updates-testing > 2.5 M > glib-java i386 0.2.6-8.fc7 > fedora 41 k > libgcc i386 4.1.2-18.fc7 > updates-testing 90 k > libgcj-devel i386 4.1.2-18.fc7 updates-testing > 1.5 M > libgcj-src i386 4.1.2-18.fc7 > updates-testing 12 M > libgconf-java i386 2.12.4-8.fc7 > fedora 72 k > libgfortran i386 4.1.2-18.fc7 updates-testing > 228 k > libglade-java i386 2.12.5-6.fc7 > fedora 78 k > libgnat i386 4.1.2-18.fc7 updates-testing > 985 k > libgnome-java i386 2.12.4-6.fc7 fedora > 328 k > libgomp i386 4.1.2-18.fc7 > updates-testing 79 k > libgtk-java i386 2.8.7-4.fc7 fedora > 2.1 M > libobjc i386 4.1.2-18.fc7 > updates-testing 98 k > libstdc++ i386 4.1.2-18.fc7 updates-testing > 357 k > libstdc++-devel i386 4.1.2-18.fc7 updates-testing > 2.9 M > libvte-java i386 0.12.1-7.fc7 > fedora 71 k > > Transaction Summary > ============================================================================= > Install 0 Package(s) > Update 25 Package(s) > Remove 0 Package(s) > > > > ============================================================================= > However, I still have the libsnmp problem: > > # yum whatprovides libsnmp.so.10 > Loading "installonlyn" plugin > Setting up repositories > Reading repository metadata in from local files > Finished > Importing additional filelist information > > > > net-snmp-libs.i386 1:5.3.1-15.fc6 > installed > Matched from: > /usr/lib/libsnmp.so.10 > /usr/lib/libsnmp.so.10.0.1 > libsnmp.so.10 > > > What can I do about this? > > # yum list freeradius Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Livna for Fedora Core 7 - i386 - Base Finished Installed Packages freeradius.i386 1.1.7-2.fc6 installed Available Packages freeradius.i386 1.1.6-2.fc7 updates # yum list freeradius --enablerepo=updates-testing Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Livna for Fedora Core 7 - i386 - Base Finished Installed Packages freeradius.i386 1.1.7-2.fc6 installed Available Packages freeradius.i386 1.1.7-2.fc7 updates-testing # yum update freeradius --enablerepo=updates-testing ... Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: compat-db i386 4.3.29-2.fc7 fedora 1.9 M replacing db4-devel.i386 4.3.29-9.fc6 java-1.5.0-gcj-devel i386 1.5.0.0-14.fc7 fedora 43 k replacing java-1.4.2-gcj-compat-devel.i386 1.4.2.0-40jpp.110 nautilus-sendto i386 0.10-4.fc7 fedora 80 k replacing nautilus-sendto-bluetooth.i386 0.7-5.fc6 postgresql-pltcl i386 8.2.4-1.fc7 updates 30 k replacing postgresql-pl.i386 8.1.9-1.fc6 Updating: freeradius i386 1.1.7-2.fc7 updates-testing 1.2 M Installing for dependencies: akode i386 2.0.1-6.fc7 fedora 100 k akode-pulseaudio i386 2.0.1-6.fc7 fedora 7.6 k checkpolicy i386 2.0.3-1.fc7 updates 256 k dbus-qt i386 0.70-1.fc7 fedora 33 k dnsmasq i386 2.38-1.fc7 fedora 147 k enchant i386 1:1.3.0-1.fc6 fedora 128 k fast-user-switch-applet i386 2.17.4-4.fc7 fedora 640 k glib i386 1:1.2.10-26.fc7 fedora 138 k gnucash-docs noarch 2.2.0-1.fc7 updates 9.4 M gnutls-devel i386 1.4.5-2.fc7 fedora 920 k goffice04 i386 0.4.2-1.fc7 updates 1.5 M gtk+ i386 1:1.2.10-57.fc7 fedora 923 k hunspell i386 1.1.5-2.fc7 fedora 145 k hunspell-en noarch 0.20040623-1.fc7 fedora 499 k java-1.5.0-gcj i386 1.5.0.0-14.fc7 fedora 104 k kdebindings-dcopperl i386 3.5.7-1.fc7.1 updates 43 k kdemultimedia-extras i386 6:3.5.7-2.fc7 updates 3.4 M kdeutils-extras i386 6:3.5.7-1.fc7.1 updates 950 k libcdio i386 0.78.2-2.fc7 updates 268 k libgnomekbd i386 2.18.0-1.fc7 fedora 79 k libmodplug i386 1:0.8.4-1.fc7 fedora 170 k libsamplerate i386 0.1.2-6.fc6 fedora 153 k libsexy i386 0.1.11-1.fc7 fedora 42 k libshout i386 2.2.2-1.fc6 fedora 43 k libsndfile i386 1.0.17-1.fc6 fedora 230 k libsoup-devel i386 2.2.100-1.fc7 fedora 126 k perl-CPAN i386 1.76_02-23.fc7 updates 127 k perl-ExtUtils-Embed i386 1.26-23.fc7 updates 33 k perl-ExtUtils-MakeMaker i386 6.30-23.fc7 updates 292 k perl-Finance-Quote noarch 1.13-1.fc7 fedora 189 k perl-HTML-TableExtract noarch 2.10-1.fc7 fedora 32 k perl-Test-Harness i386 2.56-23.fc7 updates 77 k perl-Test-Simple i386 0.62-23.fc7 updates 108 k perl-devel i386 4:5.8.8-23.fc7 updates 388 k perl-libs i386 4:5.8.8-23.fc7 updates 573 k pulseaudio-lib i386 0.9.6-2.fc7 updates 122 k python-libs i386 2.5-12.fc7 fedora 568 k qbanking i386 2.3.2-1.fc7 updates 744 k sinjdoc i386 0.5-4.fc7 fedora 822 k taglib i386 1.4-5.fc7 fedora 142 k wavpack i386 4.41-1.fc7 fedora 120 k xine-lib i386 1.1.7-1.fc7 updates 2.5 M xmms-libs i386 1:1.2.10-36.fc7 fedora 243 k Updating for dependencies: MySQL-python i386 1.2.2-3.fc7 updates 88 k PyQt i386 3.17.1-1.fc7 fedora 2.0 M PyQt-devel i386 3.17.1-1.fc7 fedora 221 k PyXML i386 0.8.4-6 fedora 1.2 M alacarte noarch 0.11.3-3.fc7 fedora 141 k alchemist i386 1.0.37-1 fedora 115 k apr-util i386 1.2.8-7 fedora 77 k aqbanking i386 2.3.2-1.fc7 updates 3.0 M audit i386 1.5.6-2.fc7 updates 247 k audit-libs i386 1.5.6-2.fc7 updates 64 k audit-libs-python i386 1.5.6-2.fc7 updates 72 k authconfig i386 5.3.15-1.fc7 updates 392 k authconfig-gtk i386 5.3.15-1.fc7 updates 44 k avahi i386 0.6.17-1.fc7 fedora 252 k avahi-compat-howl i386 0.6.17-1.fc7 fedora 29 k avahi-devel i386 0.6.17-1.fc7 fedora 39 k avahi-glib i386 0.6.17-1.fc7 fedora 14 k avahi-qt3 i386 0.6.17-1.fc7 fedora 17 k avahi-tools i386 0.6.17-1.fc7 fedora 60 k bug-buddy i386 1:2.18.0-2.fc7 fedora 443 k control-center i386 1:2.18.0-20.fc7 updates 2.8 M cracklib i386 2.8.9-10 fedora 46 k curl i386 7.16.2-1.fc7 fedora 256 k curl-devel i386 7.16.2-1.fc7 fedora 189 k db4 i386 4.5.20-5.fc7 fedora 1.1 M dbus-python i386 0.82.0-2.fc7 updates-testing 199 k desktop-file-utils i386 0.12-4.fc7 fedora 51 k dovecot i386 1.0.3-14.fc7 updates 1.7 M ekiga i386 2.0.9-1.fc7 fedora 6.6 M evolution i386 2.10.3-4.fc7 updates 37 M evolution-connector i386 2.10.3-1.fc7 updates 643 k evolution-data-server i386 1.10.3.1-2.fc7 updates 3.6 M evolution-data-server-devel i386 1.10.3.1-2.fc7 updates 603 k evolution-sharp i386 0.12.2-2.fc7 fedora 117 k evolution-webcal i386 2.10.0-1.fc7 fedora 93 k flac i386 1.1.4-4.fc7 fedora 343 k gnome-applets i386 1:2.18.0-7.fc7 fedora 10 M gnome-bluetooth i386 0.9.1-1.fc7 updates 264 k gnome-bluetooth-libs i386 0.9.1-1.fc7 updates 52 k gnome-desktop i386 2.18.3-1.fc7 updates 890 k gnome-desktop-devel i386 2.18.3-1.fc7 updates 36 k gnome-menus i386 2.19.4-2.fc7 updates 179 k gnome-panel i386 2.18.3-1.fc7 updates 3.4 M gnome-panel-devel i386 2.18.3-1.fc7 updates 56 k gnome-pilot i386 2.0.15-5.fc7 fedora 599 k gnome-python2 i386 2.18.1-1.fc7 fedora 129 k gnome-python2-applet i386 2.18.0-1.fc7 fedora 13 k gnome-python2-bonobo i386 2.18.1-1.fc7 fedora 65 k gnome-python2-canvas i386 2.18.1-1.fc7 fedora 26 k gnome-python2-desktop i386 2.18.0-1.fc7 fedora 46 k gnome-python2-extras i386 2.14.3-4.fc7 updates 25 k gnome-python2-gconf i386 2.18.1-1.fc7 fedora 34 k gnome-python2-gnomekeyring i386 2.18.0-1.fc7 fedora 18 k gnome-python2-gnomeprint i386 2.18.0-1.fc7 fedora 78 k gnome-python2-gnomevfs i386 2.18.1-1.fc7 fedora 65 k gnome-python2-gtksourceview i386 2.18.0-1.fc7 fedora 58 k gnome-python2-libegg i386 2.14.3-4.fc7 updates 54 k gnucash i386 2.2.1-2.fc7 updates 5.6 M gnupg i386 1.4.7-6 fedora 1.9 M gnutls i386 1.4.5-2.fc7 fedora 372 k gnutls-utils i386 1.4.5-2.fc7 fedora 115 k gstreamer-plugins-good i386 0.10.6-1.fc7 updates 827 k gtkhtml3 i386 3.14.3-1.fc7 updates 920 k gucharmap i386 1.10.0-1.fc7 fedora 2.5 M hpijs i386 1:1.7.4a-4.fc7 updates 294 k hplip i386 1.7.4a-4.fc7 updates 9.8 M httpd i386 2.2.4-4.1.fc7 updates 987 k httpd-manual i386 2.2.4-4.1.fc7 updates 833 k iproute i386 2.6.20-2.fc7 fedora 812 k isdn4k-utils i386 3.2-54.fc7 fedora 3.9 M jpilot i386 0.99.9-3.fc7 fedora 975 k k3b i386 1.0.3-2.fc7 updates 13 M kbd i386 1.12-22.fc7 updates 1.0 M kdeaddons i386 3.5.7-1.fc7 updates 2.6 M kdebindings i386 3.5.7-1.fc7.1 updates 5.7 M kdeedu i386 3.5.7-1.fc7 updates 31 M kdemultimedia i386 6:3.5.7-2.fc7 updates 5.0 M kdesdk i386 3.5.7-7.fc7 updates 6.8 M kdeutils i386 6:3.5.7-1.fc7.1 updates 2.9 M kdeutils-devel i386 6:3.5.7-1.fc7.1 updates 29 k kdevelop i386 9:3.4.1-1.fc7 updates 16 M kudzu i386 1.2.71.1-1 updates 223 k libbtctl i386 0.9.0-1.fc7 updates 43 k libdbi-dbd-mysql i386 0.8.1a-2.fc7 fedora 17 k libdbi-dbd-pgsql i386 0.8.1a-2.fc7 fedora 21 k libdbi-drivers i386 0.8.1a-2.fc7 fedora 14 k libpcap i386 14:0.9.7-1.fc7 updates 102 k libpurple i386 2.1.1-1.fc7 updates 6.6 M libsane-hpaio i386 1.7.4a-4.fc7 updates 63 k libselinux i386 2.0.14-4.fc7 updates 98 k libselinux-devel i386 2.0.14-4.fc7 updates 139 k libselinux-python i386 2.0.14-4.fc7 updates 60 k libsemanage i386 2.0.3-4.fc7 updates 137 k libsepol i386 2.0.3-1.fc7 fedora 130 k libsepol-devel i386 2.0.3-1.fc7 fedora 190 k libsoup i386 2.2.100-1.fc7 fedora 150 k libuser i386 0.56.2-1 fedora 437 k libuser-devel i386 0.56.2-1 fedora 54 k libvirt i386 0.3.2-1.fc7 updates 820 k libvirt-python i386 0.3.2-1.fc7 updates 69 k libxml2-python i386 2.6.29-1.fc7 updates 702 k libxslt-python i386 1.1.21-1.fc7 updates 150 k livna-config-display noarch 0.0.17-1.lvn7 livna 58 k mod_auth_pgsql i386 2.0.3-3 fedora 22 k mod_perl i386 2.0.3-9.1.fc7 updates 3.8 M mod_python i386 3.3.1-3 fedora 334 k mod_ssl i386 1:2.2.4-4.1.fc7 updates 85 k mx i386 2.0.6-3 fedora 4.5 M ncurses i386 5.6-6.20070303.fc7 fedora 1.0 M ncurses-devel i386 5.6-6.20070303.fc7 fedora 642 k net-snmp i386 1:5.4-14.fc7 updates 727 k net-snmp-libs i386 1:5.4-14.fc7 updates 1.1 M net-snmp-utils i386 1:5.4-14.fc7 updates 185 k netatalk i386 4:2.0.3-9.fc7 fedora 1.3 M newt i386 0.52.7-1.fc7 updates 131 k newt-devel i386 0.52.7-1.fc7 updates 40 k notify-python i386 0.1.0-4.fc7 fedora 12 k nss_ldap i386 257-3.fc7 updates-testing 148 k opal i386 2.2.8-5.fc7 updates 2.9 M openoffice.org-base i386 1:2.2.1-18.1.fc7 updates-testing 884 k openoffice.org-calc i386 1:2.2.1-18.1.fc7 updates-testing 6.9 M openoffice.org-core i386 1:2.2.1-18.1.fc7 updates-testing 74 M openoffice.org-draw i386 1:2.2.1-18.1.fc7 updates-testing 1.1 M openoffice.org-emailmerge i386 1:2.2.1-18.1.fc7 updates-testing 75 k openoffice.org-graphicfilter i386 1:2.2.1-18.1.fc7 updates-testing 197 k openoffice.org-impress i386 1:2.2.1-18.1.fc7 updates-testing 1.6 M openoffice.org-javafilter i386 1:2.2.1-18.1.fc7 updates-testing 160 k openoffice.org-math i386 1:2.2.1-18.1.fc7 updates-testing 1.3 M openoffice.org-pyuno i386 1:2.2.1-18.1.fc7 updates-testing 191 k openoffice.org-testtools i386 1:2.2.1-18.1.fc7 updates-testing 413 k openoffice.org-writer i386 1:2.2.1-18.1.fc7 updates-testing 2.9 M openoffice.org-xsltfilter i386 1:2.2.1-18.1.fc7 updates-testing 109 k orca i386 2.18.0-1.fc7 fedora 1.4 M pam i386 0.99.7.1-5.1.fc7 updates 1.0 M pam-devel i386 0.99.7.1-5.1.fc7 updates 188 k pam_ccreds i386 4-2.fc7 fedora 19 k perl i386 4:5.8.8-23.fc7 updates 10 M perl-DBD-Pg i386 1.49-3.fc7 fedora 114 k php i386 5.2.3-1.fc7 updates-testing 1.3 M php-cli i386 5.2.3-1.fc7 updates-testing 2.5 M php-common i386 5.2.3-1.fc7 updates-testing 218 k php-ldap i386 5.2.3-1.fc7 updates-testing 29 k php-mbstring i386 5.2.3-1.fc7 updates-testing 1.0 M php-mysql i386 5.2.3-1.fc7 updates-testing 79 k php-odbc i386 5.2.3-1.fc7 updates-testing 46 k php-pdo i386 5.2.3-1.fc7 updates-testing 58 k php-pgsql i386 5.2.3-1.fc7 updates-testing 63 k pidgin i386 2.1.1-1.fc7 updates 1.1 M pilot-link i386 2:0.12.2-4.fc7 updates 561 k pilot-link-devel i386 2:0.12.2-4.fc7 updates 169 k pirut noarch 1.3.9-1.fc7 updates 285 k planner i386 0.14.2-4.fc7 fedora 3.5 M policycoreutils i386 2.0.16-11.fc7 updates 617 k postfix i386 2:2.4.3-2.fc7 updates 3.7 M postgresql i386 8.2.4-1.fc7 updates 3.0 M postgresql-contrib i386 8.2.4-1.fc7 updates 511 k postgresql-docs i386 8.2.4-1.fc7 updates 6.2 M postgresql-libs i386 8.2.4-1.fc7 updates 197 k postgresql-odbc i386 08.01.0200-4.fc7 fedora 202 k postgresql-python i386 8.2.4-1.fc7 updates 66 k postgresql-server i386 8.2.4-1.fc7 updates 4.2 M postgresql-tcl i386 8.2.4-1.fc7 updates 86 k postgresql-test i386 8.2.4-1.fc7 updates 1.2 M ppp i386 2.4.4-2 fedora 383 k pwlib i386 1.10.7-1.fc7 fedora 823 k pycairo i386 1.4.0-1.fc7 fedora 71 k pycairo-devel i386 1.4.0-1.fc7 fedora 5.9 k pygobject2 i386 2.12.3-3.fc7 fedora 98 k pygtk2 i386 2.10.6-1.fc7 updates 1.1 M pygtk2-codegen i386 2.10.6-1.fc7 updates 166 k pygtk2-devel i386 2.10.6-1.fc7 updates 1.1 M pygtk2-libglade i386 2.10.6-1.fc7 updates 18 k pykickstart noarch 1.1.1-1.fc7 updates 182 k pyorbit i386 2.14.2-2.fc7 fedora 48 k python i386 2.5-12.fc7 fedora 5.5 M python-devel i386 2.5-12.fc7 fedora 3.5 M python-ldap i386 2.3-1.fc7 updates 127 k python-numeric i386 24.2-4.fc7 fedora 771 k python-urlgrabber noarch 2.9.9-5.fc7 fedora 122 k python-virtinst noarch 0.200.0-3.fc7 updates-testing 105 k pyxf86config i386 0.3.33-1.fc7 fedora 66 k redhat-menus noarch 8.9.10-3.fc7 updates 204 k rhpl i386 0.208-1 fedora 244 k rhpxl i386 0.47-1.fc7 fedora 106 k rhythmbox i386 0.10.1-1.fc7 updates 4.1 M rpm i386 4.4.2.1-1.fc7 updates 1.1 M rpm-build i386 4.4.2.1-1.fc7 updates 661 k rpm-devel i386 4.4.2.1-1.fc7 updates 5.4 M rpm-libs i386 4.4.2.1-1.fc7 updates 930 k rpm-python i386 4.4.2.1-1.fc7 updates 56 k ruby i386 1.8.6.36-3.fc7 updates 520 k ruby-devel i386 1.8.6.36-3.fc7 updates 559 k ruby-libs i386 1.8.6.36-3.fc7 updates 1.7 M sendmail i386 8.14.1-4.1.fc7 updates-testing 832 k sendmail-cf i386 8.14.1-4.1.fc7 updates-testing 311 k sip i386 4.6-1.fc7 fedora 234 k sip-devel i386 4.6-1.fc7 fedora 16 k subversion i386 1.4.3-4 fedora 2.3 M system-config-printer i386 0.7.63.3-1.fc7 updates 175 k system-config-printer-libs i386 0.7.63.3-1.fc7 updates 341 k vim-X11 i386 2:7.1.12-1.fc7 updates 1.0 M vim-common i386 2:7.1.12-1.fc7 updates 6.6 M vim-enhanced i386 2:7.1.12-1.fc7 updates 868 k virt-manager i386 0.4.0-2.fc7 fedora 1.3 M vorbis-tools i386 1:1.1.1.svn20070412-2.fc7 fedora 190 k vte i386 0.16.8-1.fc7 updates 483 k webalizer i386 2.01_10-32 fedora 106 k wireshark i386 0.99.6-1.fc7 updates 9.0 M wireshark-gnome i386 0.99.6-1.fc7 updates 572 k xchat i386 1:2.8.4-2.fc7 updates 1.3 M xen i386 3.1.0-2.fc7 updates 2.2 M xen-libs i386 3.1.0-2.fc7 updates 132 k yum noarch 3.2.5-1.fc7 updates-testing 543 k yum-metadata-parser i386 1.1.0-2.fc7 fedora 25 k yum-updatesd noarch 3.2.5-1.fc7 updates-testing 23 k Transaction Summary ============================================================================= Install 47 Package(s) Update 216 Package(s) Remove 0 Package(s) Total download size: 441 M Is this ok [y/N]: I don't know about this one. It brings in a lot of updates-testing packages. Would this be safe to do? From sundaram at fedoraproject.org Sun Sep 16 15:19:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Sep 2007 20:49:26 +0530 Subject: no menu entry for bigboard? In-Reply-To: <3adc77210709151734r2c12b0dcm9d789c2692515f78@mail.gmail.com> References: <47324ed80709141319n1496690eufae8dffda5cf5f47@mail.gmail.com> <47324ed80709141346y50ae967y269ba3742b7732ec@mail.gmail.com> <3adc77210709151734r2c12b0dcm9d789c2692515f78@mail.gmail.com> Message-ID: <46ED497E.9070508@fedoraproject.org> Naheem Zaffar wrote: > The BigBoard wiki links to the wrong page. (should be > wiki/releases/FeatureOnlineDesktop, not wiki/FeatureOnlineDesktop) > > http://fedoraproject.org/wiki/Releases/FeatureBigboard I have setup a redirect now. Thanks for notifying. Rahul From greno at verizon.net Sun Sep 16 20:48:58 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 16:48:58 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ED357A.80801@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> Message-ID: <46ED96BA.2010808@verizon.net> Gerry Reno wrote: > Gerry Reno wrote: >> Dominik 'Rathann' Mierzejewski wrote: >>> On Sunday, 16 September 2007 at 10:16, Ville Skytt? wrote: >>> >>>> On Sunday 16 September 2007, Gerry Reno wrote: >>>> >>>> >>>>> And it looks like libgcj.so.8rh is only in libgcj-4.1.2-12 and this >>>>> machine has libgcj-4.1.2-13-fc6 installed. So is that a >>>>> downgrade???? >>>>> >>>> Yes. Looks like libgcj-4.1.2-18.fc7 which would fix the versioning >>>> problem is in the updates/testing/7 repository, it might not hurt >>>> to ask its maintainer what's up. >>>> >>> >>> The maintainer has been aware of this for a few weeks now. See bug >>> 251035: >>> https://bugzilla.redhat.com/show_bug.cgi?id=251035 >>> >>> Regards, >>> R. >>> >>> >> Ok, the following workaround gets past the libgcj dependency problem: >> >> # yum update libgcj --enablerepo=updates-testing >> >> ... >> >> Dependencies Resolved >> >> ============================================================================= >> >> Package Arch Version >> Repository Size >> ============================================================================= >> >> Updating: >> libgcj i386 4.1.2-18.fc7 >> updates-testing 19 M >> Updating for dependencies: >> cairo-java i386 1.0.5-7.fc7 >> fedora 134 k >> cpp i386 4.1.2-18.fc7 >> updates-testing 2.7 M >> frysk i686 0.0.1.2007.03.13.rh1-1.fc7 >> fedora 12 M >> gcc i386 4.1.2-18.fc7 >> updates-testing 5.2 M >> gcc-c++ i386 4.1.2-18.fc7 >> updates-testing 3.4 M >> gcc-gfortran i386 4.1.2-18.fc7 >> updates-testing 3.1 M >> gcc-gnat i386 4.1.2-18.fc7 >> updates-testing 11 M >> gcc-java i386 4.1.2-18.fc7 >> updates-testing 2.7 M >> gcc-objc i386 4.1.2-18.fc7 >> updates-testing 2.5 M >> glib-java i386 0.2.6-8.fc7 >> fedora 41 k >> libgcc i386 4.1.2-18.fc7 >> updates-testing 90 k >> libgcj-devel i386 4.1.2-18.fc7 >> updates-testing 1.5 M >> libgcj-src i386 4.1.2-18.fc7 >> updates-testing 12 M >> libgconf-java i386 2.12.4-8.fc7 >> fedora 72 k >> libgfortran i386 4.1.2-18.fc7 >> updates-testing 228 k >> libglade-java i386 2.12.5-6.fc7 >> fedora 78 k >> libgnat i386 4.1.2-18.fc7 >> updates-testing 985 k >> libgnome-java i386 2.12.4-6.fc7 >> fedora 328 k >> libgomp i386 4.1.2-18.fc7 >> updates-testing 79 k >> libgtk-java i386 2.8.7-4.fc7 >> fedora 2.1 M >> libobjc i386 4.1.2-18.fc7 >> updates-testing 98 k >> libstdc++ i386 4.1.2-18.fc7 >> updates-testing 357 k >> libstdc++-devel i386 4.1.2-18.fc7 >> updates-testing 2.9 M >> libvte-java i386 0.12.1-7.fc7 >> fedora 71 k >> >> Transaction Summary >> ============================================================================= >> >> Install 0 Package(s) Update 25 Package(s) >> Remove 0 Package(s) >> >> >> ============================================================================= >> >> However, I still have the libsnmp problem: >> >> # yum whatprovides libsnmp.so.10 >> Loading "installonlyn" plugin >> Setting up repositories >> Reading repository metadata in from local files >> Finished >> Importing additional filelist information >> >> >> >> net-snmp-libs.i386 1:5.3.1-15.fc6 >> installed Matched from: >> /usr/lib/libsnmp.so.10 >> /usr/lib/libsnmp.so.10.0.1 >> libsnmp.so.10 >> >> >> What can I do about this? >> >> > # yum list freeradius > Loading "installonlyn" plugin > Setting up repositories > Reading repository metadata in from local files > Excluding Packages from Livna for Fedora Core 7 - i386 - Base > Finished > Installed Packages > freeradius.i386 1.1.7-2.fc6 > installed Available Packages > freeradius.i386 1.1.6-2.fc7 > updates > # yum list freeradius --enablerepo=updates-testing > Loading "installonlyn" plugin > Setting up repositories > Reading repository metadata in from local files > Excluding Packages from Livna for Fedora Core 7 - i386 - Base > Finished > Installed Packages > freeradius.i386 1.1.7-2.fc6 > installed Available Packages > freeradius.i386 1.1.7-2.fc7 > updates-testing > > > # yum update freeradius --enablerepo=updates-testing > > ... > > Dependencies Resolved > > ============================================================================= > > Package Arch Version Repository > Size > ============================================================================= > > Installing: > compat-db i386 4.3.29-2.fc7 fedora > 1.9 M > replacing db4-devel.i386 4.3.29-9.fc6 > > java-1.5.0-gcj-devel i386 1.5.0.0-14.fc7 fedora > 43 k > replacing java-1.4.2-gcj-compat-devel.i386 1.4.2.0-40jpp.110 > > nautilus-sendto i386 0.10-4.fc7 fedora > 80 k > replacing nautilus-sendto-bluetooth.i386 0.7-5.fc6 > > postgresql-pltcl i386 8.2.4-1.fc7 updates > 30 k > replacing postgresql-pl.i386 8.1.9-1.fc6 > > Updating: > freeradius i386 1.1.7-2.fc7 updates-testing > 1.2 M > Installing for dependencies: > akode i386 2.0.1-6.fc7 fedora > 100 k > akode-pulseaudio i386 2.0.1-6.fc7 fedora > 7.6 k > checkpolicy i386 2.0.3-1.fc7 updates > 256 k > dbus-qt i386 0.70-1.fc7 fedora > 33 k > dnsmasq i386 2.38-1.fc7 fedora > 147 k > enchant i386 1:1.3.0-1.fc6 fedora > 128 k > fast-user-switch-applet i386 2.17.4-4.fc7 fedora > 640 k > glib i386 1:1.2.10-26.fc7 fedora > 138 k > gnucash-docs noarch 2.2.0-1.fc7 updates > 9.4 M > gnutls-devel i386 1.4.5-2.fc7 fedora > 920 k > goffice04 i386 0.4.2-1.fc7 updates > 1.5 M > gtk+ i386 1:1.2.10-57.fc7 fedora > 923 k > hunspell i386 1.1.5-2.fc7 fedora > 145 k > hunspell-en noarch 0.20040623-1.fc7 fedora > 499 k > java-1.5.0-gcj i386 1.5.0.0-14.fc7 fedora > 104 k > kdebindings-dcopperl i386 3.5.7-1.fc7.1 updates > 43 k > kdemultimedia-extras i386 6:3.5.7-2.fc7 updates > 3.4 M > kdeutils-extras i386 6:3.5.7-1.fc7.1 updates > 950 k > libcdio i386 0.78.2-2.fc7 updates > 268 k > libgnomekbd i386 2.18.0-1.fc7 fedora > 79 k > libmodplug i386 1:0.8.4-1.fc7 fedora > 170 k > libsamplerate i386 0.1.2-6.fc6 fedora > 153 k > libsexy i386 0.1.11-1.fc7 fedora > 42 k > libshout i386 2.2.2-1.fc6 fedora > 43 k > libsndfile i386 1.0.17-1.fc6 fedora > 230 k > libsoup-devel i386 2.2.100-1.fc7 fedora > 126 k > perl-CPAN i386 1.76_02-23.fc7 updates > 127 k > perl-ExtUtils-Embed i386 1.26-23.fc7 updates > 33 k > perl-ExtUtils-MakeMaker i386 6.30-23.fc7 updates > 292 k > perl-Finance-Quote noarch 1.13-1.fc7 fedora > 189 k > perl-HTML-TableExtract noarch 2.10-1.fc7 fedora > 32 k > perl-Test-Harness i386 2.56-23.fc7 updates > 77 k > perl-Test-Simple i386 0.62-23.fc7 updates > 108 k > perl-devel i386 4:5.8.8-23.fc7 updates > 388 k > perl-libs i386 4:5.8.8-23.fc7 updates > 573 k > pulseaudio-lib i386 0.9.6-2.fc7 updates > 122 k > python-libs i386 2.5-12.fc7 fedora > 568 k > qbanking i386 2.3.2-1.fc7 updates > 744 k > sinjdoc i386 0.5-4.fc7 fedora > 822 k > taglib i386 1.4-5.fc7 fedora > 142 k > wavpack i386 4.41-1.fc7 fedora > 120 k > xine-lib i386 1.1.7-1.fc7 updates > 2.5 M > xmms-libs i386 1:1.2.10-36.fc7 fedora > 243 k > Updating for dependencies: > MySQL-python i386 1.2.2-3.fc7 updates > 88 k > PyQt i386 3.17.1-1.fc7 fedora > 2.0 M > PyQt-devel i386 3.17.1-1.fc7 fedora > 221 k > PyXML i386 0.8.4-6 fedora > 1.2 M > alacarte noarch 0.11.3-3.fc7 fedora > 141 k > alchemist i386 1.0.37-1 fedora > 115 k > apr-util i386 1.2.8-7 fedora > 77 k > aqbanking i386 2.3.2-1.fc7 updates > 3.0 M > audit i386 1.5.6-2.fc7 updates > 247 k > audit-libs i386 1.5.6-2.fc7 updates > 64 k > audit-libs-python i386 1.5.6-2.fc7 updates > 72 k > authconfig i386 5.3.15-1.fc7 updates > 392 k > authconfig-gtk i386 5.3.15-1.fc7 updates > 44 k > avahi i386 0.6.17-1.fc7 fedora > 252 k > avahi-compat-howl i386 0.6.17-1.fc7 fedora > 29 k > avahi-devel i386 0.6.17-1.fc7 fedora > 39 k > avahi-glib i386 0.6.17-1.fc7 fedora > 14 k > avahi-qt3 i386 0.6.17-1.fc7 fedora > 17 k > avahi-tools i386 0.6.17-1.fc7 fedora > 60 k > bug-buddy i386 1:2.18.0-2.fc7 fedora > 443 k > control-center i386 1:2.18.0-20.fc7 updates > 2.8 M > cracklib i386 2.8.9-10 fedora > 46 k > curl i386 7.16.2-1.fc7 fedora > 256 k > curl-devel i386 7.16.2-1.fc7 fedora > 189 k > db4 i386 4.5.20-5.fc7 fedora > 1.1 M > dbus-python i386 0.82.0-2.fc7 updates-testing > 199 k > desktop-file-utils i386 0.12-4.fc7 fedora > 51 k > dovecot i386 1.0.3-14.fc7 updates > 1.7 M > ekiga i386 2.0.9-1.fc7 fedora > 6.6 M > evolution i386 2.10.3-4.fc7 updates > 37 M > evolution-connector i386 2.10.3-1.fc7 updates > 643 k > evolution-data-server i386 1.10.3.1-2.fc7 updates > 3.6 M > evolution-data-server-devel i386 1.10.3.1-2.fc7 > updates 603 k > evolution-sharp i386 0.12.2-2.fc7 fedora > 117 k > evolution-webcal i386 2.10.0-1.fc7 fedora > 93 k > flac i386 1.1.4-4.fc7 fedora > 343 k > gnome-applets i386 1:2.18.0-7.fc7 fedora > 10 M > gnome-bluetooth i386 0.9.1-1.fc7 updates > 264 k > gnome-bluetooth-libs i386 0.9.1-1.fc7 updates > 52 k > gnome-desktop i386 2.18.3-1.fc7 updates > 890 k > gnome-desktop-devel i386 2.18.3-1.fc7 updates > 36 k > gnome-menus i386 2.19.4-2.fc7 updates > 179 k > gnome-panel i386 2.18.3-1.fc7 updates > 3.4 M > gnome-panel-devel i386 2.18.3-1.fc7 updates > 56 k > gnome-pilot i386 2.0.15-5.fc7 fedora > 599 k > gnome-python2 i386 2.18.1-1.fc7 fedora > 129 k > gnome-python2-applet i386 2.18.0-1.fc7 fedora > 13 k > gnome-python2-bonobo i386 2.18.1-1.fc7 fedora > 65 k > gnome-python2-canvas i386 2.18.1-1.fc7 fedora > 26 k > gnome-python2-desktop i386 2.18.0-1.fc7 fedora > 46 k > gnome-python2-extras i386 2.14.3-4.fc7 updates > 25 k > gnome-python2-gconf i386 2.18.1-1.fc7 fedora > 34 k > gnome-python2-gnomekeyring i386 2.18.0-1.fc7 > fedora 18 k > gnome-python2-gnomeprint i386 2.18.0-1.fc7 > fedora 78 k > gnome-python2-gnomevfs i386 2.18.1-1.fc7 fedora > 65 k > gnome-python2-gtksourceview i386 2.18.0-1.fc7 > fedora 58 k > gnome-python2-libegg i386 2.14.3-4.fc7 updates > 54 k > gnucash i386 2.2.1-2.fc7 updates > 5.6 M > gnupg i386 1.4.7-6 fedora > 1.9 M > gnutls i386 1.4.5-2.fc7 fedora > 372 k > gnutls-utils i386 1.4.5-2.fc7 fedora > 115 k > gstreamer-plugins-good i386 0.10.6-1.fc7 updates > 827 k > gtkhtml3 i386 3.14.3-1.fc7 updates > 920 k > gucharmap i386 1.10.0-1.fc7 fedora > 2.5 M > hpijs i386 1:1.7.4a-4.fc7 updates > 294 k > hplip i386 1.7.4a-4.fc7 updates > 9.8 M > httpd i386 2.2.4-4.1.fc7 updates > 987 k > httpd-manual i386 2.2.4-4.1.fc7 updates > 833 k > iproute i386 2.6.20-2.fc7 fedora > 812 k > isdn4k-utils i386 3.2-54.fc7 fedora > 3.9 M > jpilot i386 0.99.9-3.fc7 fedora > 975 k > k3b i386 1.0.3-2.fc7 updates > 13 M > kbd i386 1.12-22.fc7 updates > 1.0 M > kdeaddons i386 3.5.7-1.fc7 updates > 2.6 M > kdebindings i386 3.5.7-1.fc7.1 updates > 5.7 M > kdeedu i386 3.5.7-1.fc7 updates > 31 M > kdemultimedia i386 6:3.5.7-2.fc7 updates > 5.0 M > kdesdk i386 3.5.7-7.fc7 updates > 6.8 M > kdeutils i386 6:3.5.7-1.fc7.1 updates > 2.9 M > kdeutils-devel i386 6:3.5.7-1.fc7.1 updates > 29 k > kdevelop i386 9:3.4.1-1.fc7 updates > 16 M > kudzu i386 1.2.71.1-1 updates > 223 k > libbtctl i386 0.9.0-1.fc7 updates > 43 k > libdbi-dbd-mysql i386 0.8.1a-2.fc7 fedora > 17 k > libdbi-dbd-pgsql i386 0.8.1a-2.fc7 fedora > 21 k > libdbi-drivers i386 0.8.1a-2.fc7 fedora > 14 k > libpcap i386 14:0.9.7-1.fc7 updates > 102 k > libpurple i386 2.1.1-1.fc7 updates > 6.6 M > libsane-hpaio i386 1.7.4a-4.fc7 updates > 63 k > libselinux i386 2.0.14-4.fc7 updates > 98 k > libselinux-devel i386 2.0.14-4.fc7 updates > 139 k > libselinux-python i386 2.0.14-4.fc7 updates > 60 k > libsemanage i386 2.0.3-4.fc7 updates > 137 k > libsepol i386 2.0.3-1.fc7 fedora > 130 k > libsepol-devel i386 2.0.3-1.fc7 fedora > 190 k > libsoup i386 2.2.100-1.fc7 fedora > 150 k > libuser i386 0.56.2-1 fedora > 437 k > libuser-devel i386 0.56.2-1 fedora > 54 k > libvirt i386 0.3.2-1.fc7 updates > 820 k > libvirt-python i386 0.3.2-1.fc7 updates > 69 k > libxml2-python i386 2.6.29-1.fc7 updates > 702 k > libxslt-python i386 1.1.21-1.fc7 updates > 150 k > livna-config-display noarch 0.0.17-1.lvn7 livna > 58 k > mod_auth_pgsql i386 2.0.3-3 fedora > 22 k > mod_perl i386 2.0.3-9.1.fc7 updates > 3.8 M > mod_python i386 3.3.1-3 fedora > 334 k > mod_ssl i386 1:2.2.4-4.1.fc7 updates > 85 k > mx i386 2.0.6-3 fedora > 4.5 M > ncurses i386 5.6-6.20070303.fc7 > fedora 1.0 M > ncurses-devel i386 5.6-6.20070303.fc7 > fedora 642 k > net-snmp i386 1:5.4-14.fc7 updates > 727 k > net-snmp-libs i386 1:5.4-14.fc7 updates > 1.1 M > net-snmp-utils i386 1:5.4-14.fc7 updates > 185 k > netatalk i386 4:2.0.3-9.fc7 fedora > 1.3 M > newt i386 0.52.7-1.fc7 updates > 131 k > newt-devel i386 0.52.7-1.fc7 updates > 40 k > notify-python i386 0.1.0-4.fc7 fedora > 12 k > nss_ldap i386 257-3.fc7 updates-testing > 148 k > opal i386 2.2.8-5.fc7 updates > 2.9 M > openoffice.org-base i386 1:2.2.1-18.1.fc7 updates-testing > 884 k > openoffice.org-calc i386 1:2.2.1-18.1.fc7 updates-testing > 6.9 M > openoffice.org-core i386 1:2.2.1-18.1.fc7 > updates-testing 74 M > openoffice.org-draw i386 1:2.2.1-18.1.fc7 updates-testing > 1.1 M > openoffice.org-emailmerge i386 1:2.2.1-18.1.fc7 > updates-testing 75 k > openoffice.org-graphicfilter i386 1:2.2.1-18.1.fc7 > updates-testing 197 k > openoffice.org-impress i386 1:2.2.1-18.1.fc7 updates-testing > 1.6 M > openoffice.org-javafilter i386 1:2.2.1-18.1.fc7 > updates-testing 160 k > openoffice.org-math i386 1:2.2.1-18.1.fc7 updates-testing > 1.3 M > openoffice.org-pyuno i386 1:2.2.1-18.1.fc7 updates-testing > 191 k > openoffice.org-testtools i386 1:2.2.1-18.1.fc7 > updates-testing 413 k > openoffice.org-writer i386 1:2.2.1-18.1.fc7 updates-testing > 2.9 M > openoffice.org-xsltfilter i386 1:2.2.1-18.1.fc7 > updates-testing 109 k > orca i386 2.18.0-1.fc7 fedora > 1.4 M > pam i386 0.99.7.1-5.1.fc7 updates > 1.0 M > pam-devel i386 0.99.7.1-5.1.fc7 updates > 188 k > pam_ccreds i386 4-2.fc7 fedora > 19 k > perl i386 4:5.8.8-23.fc7 updates > 10 M > perl-DBD-Pg i386 1.49-3.fc7 fedora > 114 k > php i386 5.2.3-1.fc7 updates-testing > 1.3 M > php-cli i386 5.2.3-1.fc7 updates-testing > 2.5 M > php-common i386 5.2.3-1.fc7 updates-testing > 218 k > php-ldap i386 5.2.3-1.fc7 updates-testing > 29 k > php-mbstring i386 5.2.3-1.fc7 updates-testing > 1.0 M > php-mysql i386 5.2.3-1.fc7 updates-testing > 79 k > php-odbc i386 5.2.3-1.fc7 updates-testing > 46 k > php-pdo i386 5.2.3-1.fc7 updates-testing > 58 k > php-pgsql i386 5.2.3-1.fc7 updates-testing > 63 k > pidgin i386 2.1.1-1.fc7 updates > 1.1 M > pilot-link i386 2:0.12.2-4.fc7 updates > 561 k > pilot-link-devel i386 2:0.12.2-4.fc7 updates > 169 k > pirut noarch 1.3.9-1.fc7 updates > 285 k > planner i386 0.14.2-4.fc7 fedora > 3.5 M > policycoreutils i386 2.0.16-11.fc7 updates > 617 k > postfix i386 2:2.4.3-2.fc7 updates > 3.7 M > postgresql i386 8.2.4-1.fc7 updates > 3.0 M > postgresql-contrib i386 8.2.4-1.fc7 updates > 511 k > postgresql-docs i386 8.2.4-1.fc7 updates > 6.2 M > postgresql-libs i386 8.2.4-1.fc7 updates > 197 k > postgresql-odbc i386 08.01.0200-4.fc7 fedora > 202 k > postgresql-python i386 8.2.4-1.fc7 updates > 66 k > postgresql-server i386 8.2.4-1.fc7 updates > 4.2 M > postgresql-tcl i386 8.2.4-1.fc7 updates > 86 k > postgresql-test i386 8.2.4-1.fc7 updates > 1.2 M > ppp i386 2.4.4-2 fedora > 383 k > pwlib i386 1.10.7-1.fc7 fedora > 823 k > pycairo i386 1.4.0-1.fc7 fedora > 71 k > pycairo-devel i386 1.4.0-1.fc7 fedora > 5.9 k > pygobject2 i386 2.12.3-3.fc7 fedora > 98 k > pygtk2 i386 2.10.6-1.fc7 updates > 1.1 M > pygtk2-codegen i386 2.10.6-1.fc7 updates > 166 k > pygtk2-devel i386 2.10.6-1.fc7 updates > 1.1 M > pygtk2-libglade i386 2.10.6-1.fc7 updates > 18 k > pykickstart noarch 1.1.1-1.fc7 updates > 182 k > pyorbit i386 2.14.2-2.fc7 fedora > 48 k > python i386 2.5-12.fc7 fedora > 5.5 M > python-devel i386 2.5-12.fc7 fedora > 3.5 M > python-ldap i386 2.3-1.fc7 updates > 127 k > python-numeric i386 24.2-4.fc7 fedora > 771 k > python-urlgrabber noarch 2.9.9-5.fc7 fedora > 122 k > python-virtinst noarch 0.200.0-3.fc7 updates-testing > 105 k > pyxf86config i386 0.3.33-1.fc7 fedora > 66 k > redhat-menus noarch 8.9.10-3.fc7 updates > 204 k > rhpl i386 0.208-1 fedora > 244 k > rhpxl i386 0.47-1.fc7 fedora > 106 k > rhythmbox i386 0.10.1-1.fc7 updates > 4.1 M > rpm i386 4.4.2.1-1.fc7 updates > 1.1 M > rpm-build i386 4.4.2.1-1.fc7 updates > 661 k > rpm-devel i386 4.4.2.1-1.fc7 updates > 5.4 M > rpm-libs i386 4.4.2.1-1.fc7 updates > 930 k > rpm-python i386 4.4.2.1-1.fc7 updates > 56 k > ruby i386 1.8.6.36-3.fc7 updates > 520 k > ruby-devel i386 1.8.6.36-3.fc7 updates > 559 k > ruby-libs i386 1.8.6.36-3.fc7 updates > 1.7 M > sendmail i386 8.14.1-4.1.fc7 updates-testing > 832 k > sendmail-cf i386 8.14.1-4.1.fc7 updates-testing > 311 k > sip i386 4.6-1.fc7 fedora > 234 k > sip-devel i386 4.6-1.fc7 fedora > 16 k > subversion i386 1.4.3-4 fedora > 2.3 M > system-config-printer i386 0.7.63.3-1.fc7 updates > 175 k > system-config-printer-libs i386 0.7.63.3-1.fc7 > updates 341 k > vim-X11 i386 2:7.1.12-1.fc7 updates > 1.0 M > vim-common i386 2:7.1.12-1.fc7 updates > 6.6 M > vim-enhanced i386 2:7.1.12-1.fc7 updates > 868 k > virt-manager i386 0.4.0-2.fc7 fedora > 1.3 M > vorbis-tools i386 1:1.1.1.svn20070412-2.fc7 > fedora 190 k > vte i386 0.16.8-1.fc7 updates > 483 k > webalizer i386 2.01_10-32 fedora > 106 k > wireshark i386 0.99.6-1.fc7 updates > 9.0 M > wireshark-gnome i386 0.99.6-1.fc7 updates > 572 k > xchat i386 1:2.8.4-2.fc7 updates > 1.3 M > xen i386 3.1.0-2.fc7 updates > 2.2 M > xen-libs i386 3.1.0-2.fc7 updates > 132 k > yum noarch 3.2.5-1.fc7 updates-testing > 543 k > yum-metadata-parser i386 1.1.0-2.fc7 fedora > 25 k > yum-updatesd noarch 3.2.5-1.fc7 updates-testing > 23 k > > Transaction Summary > ============================================================================= > > Install 47 Package(s) Update 216 Package(s) > Remove 0 Package(s) > Total download size: 441 M > Is this ok [y/N]: > > > I don't know about this one. It brings in a lot of updates-testing > packages. > > Would this be safe to do? > > > Ok, with fingers crossed, I ran this freeradius upgrade against updates-testing. I seemed to update without problem. So I reran the full upgrade: yum -y upgrade and everything goes along except I see some errors: Updating : caching-nameserver [ 595/2006]warning: /etc/named.caching-nameserver.conf saved as /etc/named.caching-nameserver.conf.rpmsave warning: /etc/named.rfc1912.zones saved as /etc/named.rfc1912.zones.rpmsave Updating : caching-nameserver ################## [ 595/2006]warning: /var/named/named.ca saved as /var/named/named.ca.rpmsave Updating : livna-release ############### [ 718/2006]warning: /etc/yum.repos.d/livna.repo saved as /etc/yum.repos.d/livna.repo.rpmsave No theme index file in '/usr/share/icons/Fedora'. If you really want to create an icon cache here, use --ignore-theme-index. I/O warning : failed to load external entity "glchess.schemas" Failed to open `glchess.schemas': No such file or directory Updating : kdebase ################### [ 966/2006] `/etc/kde/kdm/kdmrc' -> `/etc/kde/kdm/kdmrc.rpmorig' Installing: kde-settings-kdm ################## [ 967/2006]warning: /etc/kde/kdm/kdmrc created as /etc/kde/kdm/kdmrc.rpmnew No problem with these, I just have to merge some files. But here is a big problem that I know from past experience. None of the cleanups are performed due to some kind of indexing-off-by-one problem: ... Cleanup : irda-utils ################### [1416/2006] ts_done name in te is oprofile-gui should be irda-utils Cleanup : antlr ################### [1417/2006] ts_done name in te is irda-utils should be antlr Cleanup : system-config-httpd ################### [1418/2006] ts_done name in te is antlr should be system-config-httpd Cleanup : dialog ################### [1419/2006] ts_done name in te is system-config-httpd should be dialog Cleanup : sox ################### [1420/2006] ts_done name in te is dialog should be sox Cleanup : openssh-clients ################### [1421/2006] ts_done name in te is sox should be openssh-clients Cleanup : sysreport ################### [1422/2006] ts_done name in te is openssh-clients should be sysreport Cleanup : cyrus-sasl-md5 ################### [1423/2006] ts_done name in te is sysreport should be cyrus-sasl-md5 Cleanup : openldap-servers ################### [1424/2006] ts_done name in te is cyrus-sasl-md5 should be openldap-servers Cleanup : libwnck ################### [1425/2006] ts_done name in te is openldap-servers should be libwnck Cleanup : libXft ################### [1426/2006] ts_done name in te is libwnck should be libXft ... No cleanup was done because of this index problem. So how can I fix this cleanup problem on a huge number of packages???? From skvidal at fedoraproject.org Sun Sep 16 21:15:59 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 16 Sep 2007 17:15:59 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46ED96BA.2010808@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> <46ED96BA.2010808@verizon.net> Message-ID: <1189977359.2602.10.camel@cutter> On Sun, 2007-09-16 at 16:48 -0400, Gerry Reno wrote: > ts_done name in te is cyrus-sasl-md5 should be openldap-servers > Cleanup : libwnck ################### [1425/2006] > ts_done name in te is openldap-servers should be libwnck > Cleanup : libXft ################### [1426/2006] > ts_done name in te is libwnck should be libXft > ... > > No cleanup was done because of this index problem. What makes you say the clean up was not done. The ts_done message is just about the journalling not about the actual function that's occurring > So how can I fix this cleanup problem on a huge number of packages???? First, you need to know that is what's actually happened. -sv From lamont at gurulabs.com Sun Sep 16 21:24:36 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 16 Sep 2007 15:24:36 -0600 Subject: Where is Alexander Larsson (Nautilus bug)? Message-ID: <20070916152436.200557d1@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Where in the World is Alexander Larson? #243309 [ https://bugzilla.redhat.com/show_bug.cgi?id=243309 ] (Nautilus folder icons get stuck in open state) is assigned to him, but he isn't responding to it. The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and added my +1 to it on 2007-08-29. Is Alexander missing? Is there a co-maintainer who should be available? I would think that this bug would be very easy to fix (seems like a regression, but what would I know about it), and that we would want it fixed for F8. I have not tried this in F8t2 (haven't downloaded or installed it yet, as I've been traveling since before its release). If anyone who has F8 test 2 handy would mind checking on this bug and reporting results, that would be great. If not, I may get one up in the next couple of days. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG7Z8V+YBsl9wN1AkRAk9UAKCCXaa5Mkj8PgSNTplqat0UEkarjgCfRlK2 A0bWz2sb0WIqSytFu17AWTE= =z273 -----END PGP SIGNATURE----- From bojan at rexursive.com Sun Sep 16 21:26:16 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 17 Sep 2007 07:26:16 +1000 Subject: F7 updates hosed? Message-ID: <1189977977.2983.33.camel@shrek.rexursive.com> Am I dreaming or did all F7 updates get hosed (i386, x86_64, SRPMS, including testing)? I'm getting no packages on these URLs (just some examples): http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/ http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/ http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/x86_64/ Did I miss an announcement of a location change or something? -- Bojan From greno at verizon.net Sun Sep 16 21:33:26 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 17:33:26 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <1189977359.2602.10.camel@cutter> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> <46ED96BA.2010808@verizon.net> <1189977359.2602.10.camel@cutter> Message-ID: <46EDA126.5070907@verizon.net> seth vidal wrote: > On Sun, 2007-09-16 at 16:48 -0400, Gerry Reno wrote: > >> ts_done name in te is cyrus-sasl-md5 should be openldap-servers >> Cleanup : libwnck ################### [1425/2006] >> ts_done name in te is openldap-servers should be libwnck >> Cleanup : libXft ################### [1426/2006] >> ts_done name in te is libwnck should be libXft >> ... >> >> No cleanup was done because of this index problem. >> > > What makes you say the clean up was not done. The ts_done message is > just about the journalling not about the actual function that's > occurring > > > >> So how can I fix this cleanup problem on a huge number of packages???? >> > > First, you need to know that is what's actually happened. > > -sv > > > Ok, I check kernel listing and I see both f7 and f6 kernels, but I then check firefox, thunderbird, mysql, php and I only see f7 packages so maybe things are ok. How can I be sure though with so many packages? From skvidal at fedoraproject.org Sun Sep 16 21:36:07 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 16 Sep 2007 17:36:07 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46EDA126.5070907@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> <46ED96BA.2010808@verizon.net> <1189977359.2602.10.camel@cutter> <46EDA126.5070907@verizon.net> Message-ID: <1189978567.2602.12.camel@cutter> On Sun, 2007-09-16 at 17:33 -0400, Gerry Reno wrote: > > > > > Ok, I check kernel listing and I see both f7 and f6 kernels, but I then > check firefox, thunderbird, mysql, php and I only see f7 packages so > maybe things are ok. How can I be sure though with so many packages? Kernels are supposed to be multi-installed. if you have yum-utils installed run: package-cleanup --dupes that will tell you. -sv From greno at verizon.net Sun Sep 16 21:50:22 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 16 Sep 2007 17:50:22 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <1189978567.2602.12.camel@cutter> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> <46ED96BA.2010808@verizon.net> <1189977359.2602.10.camel@cutter> <46EDA126.5070907@verizon.net> <1189978567.2602.12.camel@cutter> Message-ID: <46EDA51E.1090709@verizon.net> seth vidal wrote: > On Sun, 2007-09-16 at 17:33 -0400, Gerry Reno wrote: > >>> >>> >> Ok, I check kernel listing and I see both f7 and f6 kernels, but I then >> check firefox, thunderbird, mysql, php and I only see f7 packages so >> maybe things are ok. How can I be sure though with so many packages? >> > > Kernels are supposed to be multi-installed. > > if you have yum-utils installed run: > > package-cleanup --dupes > > > that will tell you. > -sv > > > # package-cleanup --dupes Setting up yum No Repositories Available to Set Up kmod-nvidia-100.14.11-1.2.6.22.5_49.fc6.i686 kmod-nvidia-100.14.11-1.2.6.22.5_76.fc7.i686 Is this normal? It said no repositories. From vonbrand at inf.utfsm.cl Sun Sep 16 21:42:46 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 16 Sep 2007 17:42:46 -0400 Subject: rawhide report: 20070916 changes In-Reply-To: <200709160919.l8G9JAeJ007298@porkchop.devel.redhat.com> References: <200709160919.l8G9JAeJ007298@porkchop.devel.redhat.com> Message-ID: <200709162142.l8GLgkK4005929@laptop13.inf.utfsm.cl> Build System wrote: > Updated Packages: [...] > eclipse-egit-0.2.2-0.git20070911.fc8 I'm getting: Error: Missing Dependency: eclipse-platform > 1:3.3.0 is needed by package eclipse-egit -- 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 karlikt at gmail.com Sun Sep 16 21:56:38 2007 From: karlikt at gmail.com (Karlik) Date: Sun, 16 Sep 2007 23:56:38 +0200 Subject: Problem with updating widelands - rpm error: rename failed Message-ID: I have a problem with package widelands, because in previous version, there were directories, but now there are files with the same names. rpm -Uvh .... returns: error: unpacking of archive failed on file /usr/share/widelands/maps/Checkmate.wmf: cpio: rename failed - Is a directory How can I fix it? From skvidal at fedoraproject.org Sun Sep 16 21:53:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 16 Sep 2007 17:53:31 -0400 Subject: F6->F7 upgrade dependency errors In-Reply-To: <46EDA51E.1090709@verizon.net> References: <46ECB2F0.1000306@verizon.net> <46ECB613.7010906@verizon.net> <200709161116.30610.ville.skytta@iki.fi> <20070916113003.GA5027@ryvius.pekin.waw.pl> <46ED30BA.9020202@verizon.net> <46ED357A.80801@verizon.net> <46ED96BA.2010808@verizon.net> <1189977359.2602.10.camel@cutter> <46EDA126.5070907@verizon.net> <1189978567.2602.12.camel@cutter> <46EDA51E.1090709@verizon.net> Message-ID: <1189979611.2602.15.camel@cutter> On Sun, 2007-09-16 at 17:50 -0400, Gerry Reno wrote: > seth vidal wrote: > > On Sun, 2007-09-16 at 17:33 -0400, Gerry Reno wrote: > > > >>> > >>> > >> Ok, I check kernel listing and I see both f7 and f6 kernels, but I then > >> check firefox, thunderbird, mysql, php and I only see f7 packages so > >> maybe things are ok. How can I be sure though with so many packages? > >> > > > > Kernels are supposed to be multi-installed. > > > > if you have yum-utils installed run: > > > > package-cleanup --dupes > > > > > > that will tell you. > > -sv > > > > > > > > # package-cleanup --dupes > Setting up yum > No Repositories Available to Set Up > kmod-nvidia-100.14.11-1.2.6.22.5_49.fc6.i686 > kmod-nvidia-100.14.11-1.2.6.22.5_76.fc7.i686 > > > > Is this normal? It said no repositories. yes, the no repositories is normal and having multiple kernel modules is not abnormal. However, using the nvidia modules is always a bad idea. -sv From kevin at scrye.com Sun Sep 16 22:10:18 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 16 Sep 2007 16:10:18 -0600 Subject: source file audit - 2007-08-26 In-Reply-To: <1189810534.14893.31.camel@gibraltar.stuttgart.redhat.com> References: <20070827134237.5cde7f33@ghistelwchlohm.scrye.com> <1189810534.14893.31.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070916161018.553ce8b9@ghistelwchlohm.scrye.com> On Sat, 15 Sep 2007 00:55:34 +0200 nphilipp at redhat.com (Nils Philippsen) wrote: > On Mon, 2007-08-27 at 13:42 -0600, Kevin Fenzi wrote: > > > nphilipp:BADSOURCE:dcraw-8.77.tar.gz:dcraw > > I'm not really sure about this one, it seems upstream updated the > tarball without changing the version. I've built a new package with > the new version. Yeah. ;( You might also drop a note to upstream and ask them not to do that again if they can avoid it. > > nphilipp:BADURL:rss-glx_0.8.1.p.tar.bz2:rss-glx > > As we ship a tarball with one questionable hack removed, I've removed > the URL from Source0. The fixed version is building right now. Excellent. Thanks for taking a look. FYI, I just started another run. Will post the results possibly tomorrow. > Nils kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Sep 16 23:03:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 16 Sep 2007 19:03:02 -0400 Subject: F7 updates hosed? In-Reply-To: <1189977977.2983.33.camel@shrek.rexursive.com> References: <1189977977.2983.33.camel@shrek.rexursive.com> Message-ID: <20070916190302.2916aaa9@localhost.localdomain> On Mon, 17 Sep 2007 07:26:16 +1000 Bojan Smojver wrote: > Am I dreaming or did all F7 updates get hosed (i386, x86_64, SRPMS, > including testing)? I'm getting no packages on these URLs (just some > examples): > > http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/ > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/ > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/x86_64/ > > Did I miss an announcement of a location change or something? Something seems to have gone horribly wrong. I'm resyncing all the data from the buildsystem, but that will take a while. I've disabled the cron job while this happens and I won't be pushing any more updates until we figure out what went wrong. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Sep 16 23:39:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 16 Sep 2007 19:39:42 -0400 Subject: Fedora 7 update data not valid, do not sync. Message-ID: <20070916193942.6d45afa7@localhost.localdomain> Due to a configuration error, the content in the Fedora 7 updates directory got removed. If you have any automated processes that would sync Fedora 7 updates, it is advised that you turn them off for the time being. We are re-populating the content from the build system but this will take some time (hours). I will respond to this when it finishes (if I'm still awake) and it is safe to sync updates once more. No new updates will be processed until this is fixed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lmacken at redhat.com Sun Sep 16 23:37:26 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 16 Sep 2007 19:37:26 -0400 Subject: F7 updates hosed? In-Reply-To: <20070916190302.2916aaa9@localhost.localdomain> References: <1189977977.2983.33.camel@shrek.rexursive.com> <20070916190302.2916aaa9@localhost.localdomain> Message-ID: <20070916233726.GC3602@crow.myhome.westell.com> On Sun, Sep 16, 2007 at 07:03:02PM -0400, Jesse Keating wrote: > On Mon, 17 Sep 2007 07:26:16 +1000 > Bojan Smojver wrote: > > > Am I dreaming or did all F7 updates get hosed (i386, x86_64, SRPMS, > > including testing)? I'm getting no packages on these URLs (just some > > examples): > > > > http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/ > > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > > http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/ > > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/x86_64/ > > > > Did I miss an announcement of a location change or something? > > Something seems to have gone horribly wrong. I'm resyncing all the > data from the buildsystem, but that will take a while. I've disabled > the cron job while this happens and I won't be pushing any more updates > until we figure out what went wrong. Bodhi composed the last two repositories with 'symlink=True' in its mash.conf. I have since changed the f7-updates{,-testing} symlinks to point to back to the last good repository, and have queued up mashes with a fixed mash.conf. Jesse has kicked off an rsync as well. This is definitely a good reason to create a bodhi-production branch -- so "little" changes like this don't slip through the cracks ;) luke From seg at haxxed.com Mon Sep 17 00:14:15 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 16 Sep 2007 19:14:15 -0500 Subject: Disable IPv6 by default. In-Reply-To: <1189857561.4460.44.camel@shinybook.infradead.org> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E95966.9030604@hi.is> <1189857561.4460.44.camel@shinybook.infradead.org> Message-ID: <1189988055.20962.77.camel@localhost> On Sat, 2007-09-15 at 13:59 +0200, David Woodhouse wrote: > On Sat, 2007-09-15 at 08:45 -0200, Thomas M Steenholdt wrote: > > This is just not worth changing defaults over. IPv6 is the future > > (whether you like it or not), so lets just leave it there to be as ready > > as possible when the ship sails. I haven't swithced to IPv6 either, but > > it takes less that 30 secs to disable it on a newly installed system. 30 > > secs that I can easily spare on this. > > A whole 30 seconds? You can actually get proper IPv6 connectivity in > that amount of time, if you have a public IPv4 address: > > echo IPV6_DEFAULTDEV=tun6to4 >> /etc/sysconfig/network > echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 > echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0 This worked beautifully until Charter cable got into bed with Microsoft, in which case I suddenly found 6to4 being quietly dropped into the bitbucket and non-existent DNS entries redirecting to their search engine. http://slashdot.org/articles/07/02/15/0432259.shtml Fucking bastards. (Yes, I fixed the DNS problem using dnsmasq's bogus-nxdomain option. IPv6 can still be had with Miredo but it doesn't let me route a native subnet at the router like 6to4. Miredo should be in Fedora, if possible. :) -------------- 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 mjc at avtechpulse.com Mon Sep 17 00:22:32 2007 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Sun, 16 Sep 2007 20:22:32 -0400 Subject: Where is Alexander Larsson (Nautilus bug)? In-Reply-To: <20070916152436.200557d1@reaver.lamontpeterson.net> References: <20070916152436.200557d1@reaver.lamontpeterson.net> Message-ID: <46EDC8C8.6040105@avtechpulse.com> Lamont Peterson wrote: > > Where in the World is Alexander Larson? #243309 > [ https://bugzilla.redhat.com/show_bug.cgi?id=243309 ] (Nautilus folder > icons get stuck in open state) is assigned to him, but he isn't > responding to it. I imagine he has a million high-priority bugs and new features to deal with... > The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and > added my +1 to it on 2007-08-29. If it's not fixed in 30 days, it's free... Seriously, though, try investigating the bug upstream. For instance: http://bugzilla.gnome.org/show_bug.cgi?id=314137 looks similar. I can not reproduce the problem on my F7 system. Are you using the default theme? - Mike From jkeating at redhat.com Mon Sep 17 00:47:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 16 Sep 2007 20:47:59 -0400 Subject: Fedora 7 update data not valid, do not sync. In-Reply-To: <20070916193942.6d45afa7@localhost.localdomain> References: <20070916193942.6d45afa7@localhost.localdomain> Message-ID: <20070916204759.575d546a@localhost.localdomain> On Sun, 16 Sep 2007 19:39:42 -0400 Jesse Keating wrote: > We are re-populating the content from the build system but > this will take some time (hours). Just to clarify. We aren't rebuilding things, we're just rsyncing the content from the buildserver to the mirror masters. This is what is taking time. The content will be the same once restored. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tmz at pobox.com Mon Sep 17 04:16:35 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 17 Sep 2007 00:16:35 -0400 Subject: Calling Paul F. Johnson In-Reply-To: <1189805976.3463.1.camel@localhost.localdomain> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> <1189805976.3463.1.camel@localhost.localdomain> Message-ID: <20070917041635.GC17209@psilocybe.teonanacatl.org> Paul wrote: > I am still here, although after this last 6 months, I've left the > wife, lost a job, started another and am currently running around > like an idiot trying to catch my own shadow! Eek. Sorry to hear things have been so "interesting" for you. Would you mind if fellow maintainers fixed up bugs or helped out with some of your packages in the meantime? I'm more than happy to work on an update for the gonvert bug I mentioned previously. Some other folks may also be willing to help out with other issues that they notice if they know you've been kept real busy lately. :) Good luck with things, -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...more people are driven insane through religious hysteria than by drinking alcohol. -- W.C. Fields -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Mon Sep 17 08:51:27 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 17 Sep 2007 08:51:27 +0000 Subject: Calling Paul F. Johnson In-Reply-To: <20070917041635.GC17209@psilocybe.teonanacatl.org> References: <20070914173432.GH19611@psilocybe.teonanacatl.org> <46EACC0E.7000207@ioa.s.u-tokyo.ac.jp> <1189805976.3463.1.camel@localhost.localdomain> <20070917041635.GC17209@psilocybe.teonanacatl.org> Message-ID: <20070917085127.M27445@all-the-johnsons.co.uk> Hi, > Paul wrote: > > I am still here, although after this last 6 months, I've left the > > wife, lost a job, started another and am currently running around > > like an idiot trying to catch my own shadow! > > Eek. Sorry to hear things have been so "interesting" for you. > > Would you mind if fellow maintainers fixed up bugs or helped out with > some of your packages in the meantime? No problems with that at all! I'd appreciate the help while things settle down. TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From buildsys at redhat.com Mon Sep 17 09:37:13 2007 From: buildsys at redhat.com (Build System) Date: Mon, 17 Sep 2007 05:37:13 -0400 Subject: rawhide report: 20070917 changes Message-ID: <200709170937.l8H9bDqf009909@porkchop.devel.redhat.com> Updated Packages: blobwars-1.07-1.fc8 ------------------- * Sun Sep 16 2007 Hans de Goede 1.07-1 - New upstream version 1.07 (bz 292391) bluez-libs-3.19-1.fc8 --------------------- * Sun Sep 16 2007 David Woodhouse - 3.19-1 - Update to bluez-libs 3.19 bluez-utils-3.19-1.fc8 ---------------------- * Sun Sep 16 2007 David Woodhouse 3.19-1 - Update to bluez-utils 3.19 bochs-2.3.5-1.fc8 ----------------- * Sun Sep 16 2007 Hans de Goede 2.3.5-1 - New upstream release 2.3.5 crossvc-1.5.2-1.fc8 ------------------- * Sun Sep 16 2007 Jochen Schmitt 1.5.2-1 - New upstream release ekg2-0.1-2.fc8 -------------- * Sun Sep 16 2007 Dominik Mierzejewski 0.1-2 - filter bad Provides: (fixes bug 278181) farsight-0.1.25-1.fc8 --------------------- * Sun Sep 16 2007 Brian Pepple - 0.1.25-1 - Update to 0.1.25. flac-1.2.1-1.fc8 ---------------- * Mon Sep 17 2007 - Bastien Nocera - 1.2.1-1 - Update to 1.2.1 freeciv-2.0.9-4.fc8 ------------------- * Sun Sep 16 2007 Brian Pepple - 2.0.9-4 - Add patch to fix open function build bug. * Tue Aug 21 2007 Brian Pepple - 2.0.9-3 - Rebuild. * Thu Aug 02 2007 Brian Pepple - 2.0.9-2 - Update license tag. freedroidrpg-0.10.3-1.fc8 ------------------------- * Sun Sep 16 2007 Wart - 0.10.3-1 - Update to 0.10.3 gdb-6.6-27.fc8 -------------- * Sun Sep 16 2007 Jan Kratochvil - 6.6-27 - Fix attaching to stopped processes and/or pending signals. glib2-2.14.1-1.fc8 ------------------ * Sun Sep 16 2007 Matthias Clasen - 2.14.1-1 - Update to 2.14.1 gnome-applets-1:2.20.0-1.fc8 ---------------------------- * Sun Sep 16 2007 Matthias Clasen - 1:2.20.0-1 - Update to 2.20.0 gnome-python2-2.20.0-1.fc8 -------------------------- * Sun Sep 16 2007 Matthew Barnes - 2.20.0-1.fc8 - Update to 2.20.0 * Wed Aug 29 2007 Fedora Release Engineering - 2.19.2-3 - Rebuild for selinux ppc32 issue. * Tue Aug 07 2007 Matthias Clasen - 2.19.2-2 - Update the license field gnome-python2-desktop-2.20.0-1.fc8 ---------------------------------- * Sun Sep 16 2007 Matthew Barnes - 2.20.0-1.fc8 - Update to 2.20.0 highlight-2.6.4-1.fc8 --------------------- * Sun Sep 16 2007 Jochen Schmitt 2.6.4-1 - New upstream release intltool-0.36.2-1.fc8 --------------------- * Sun Sep 16 2007 Matthias Clasen - 0.36.2-1 - Update to 0.36.2 lesstif-0.95.0-20.fc8 --------------------- * Sun Sep 16 2007 Patrice Dumas 0.95.0-20 - Correct patch XxxxProperty-64bit based on E. Sheldrake input (bz 284431) libgtop2-2.20.0-1.fc8 --------------------- * Sun Sep 16 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 metacity-2.20.0-1.fc8 --------------------- * Sun Sep 16 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 orca-2.20.0-1.fc8 ----------------- * Sun Sep 16 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 pygobject2-2.14.0-1.fc8 ----------------------- * Sun Sep 16 2007 Matthew Barnes - 2.14.0-1.fc8 - Update to 2.14.0 pygtk2-2.12.0-1.fc8 ------------------- * Sun Sep 16 2007 Matthew Barnes - 2.12.0-1.fc8 - Update to 2.12.0 system-config-lvm-1.1.1-2.0.fc8 ------------------------------- * Sun Sep 16 2007 Matthias Clasen 1.1.1-2.0 - Use desktop-file-install to install the desktop file - Move the application to the right spot in the menus totem-2.20.0-1.fc8 ------------------ * Sun Sep 16 2007 - Bastien Nocera - 2.20.0-1 - Update for 2.20.0 wine-0.9.45-1.fc8 ----------------- * Sun Sep 16 2007 Andreas Bierfert - 0.9.45-1 - version upgrade xfce4-places-plugin-0.9.992-1.fc8 --------------------------------- * Sat Aug 25 2007 Christoph Wickert - 0.9.992-1 - Update to 0.9.992 Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070911.fc8.i386 requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) eclipse-egit - 0.2.2-0.git20070911.fc8.x86_64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 eclipse-egit - 0.2.2-0.git20070911.fc8.ppc requires eclipse-platform > 1:3.3.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 eclipse-egit - 0.2.2-0.git20070911.fc8.ppc64 requires eclipse-platform > 1:3.3.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From rjones at redhat.com Mon Sep 17 11:19:11 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 17 Sep 2007 12:19:11 +0100 Subject: Why use an old GNUTLS? In-Reply-To: References: <0m642a4wz5.fsf@allele2.localdomain> Message-ID: <46EE62AF.5030507@redhat.com> Leo wrote: > On 2007-09-16 13:37 +0100, Alex Lancaster wrote: >> Hmm, I notice that gnutls is used as a shared library in many >> applications that it might be non-trivial to update if the .so version >> is bumped because it will require a lot of rebuilds. > > That's why it is difficult for users to upgrade this package. I try to > remove Gnutls and that will remove 299 packages that depend on it as > well. Does anyone know if this new GnuTLS is API and/or ABI compatible? I know that they broke a load of API functions between 1.0 and 1.4, which required a source patches and retesting for libvirt. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From tsmetana at redhat.com Mon Sep 17 11:28:53 2007 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Mon, 17 Sep 2007 13:28:53 +0200 Subject: gnomebaker 0.6.1-4 oddity In-Reply-To: <46EAC1A8.3090005@tvtransilvania.ro> References: <46EAC1A8.3090005@tvtransilvania.ro> Message-ID: <20070917132853.540696a5.tsmetana@redhat.com> On Fri, 14 Sep 2007 20:15:20 +0300 Alexandru Ciobanu wrote: > Hello, > > Since last update gnomebaker doest not start. I don't know how to make a > proper BZ entry since I don't have any errors other than: > > ** (gnomebaker:8039): WARNING **: Add decoder bethsoftvid (107) please ... > ** (gnomebaker:8039): WARNING **: Add decoder adpcm_thp (69650) please > > I'm running latest rawhide (20070914) and I could really use some pointers. This seems to be a problem in liboil that gstreamer uses, GnomeBaker is not the only one affected (see e.g., https://bugzilla.redhat.com/show_bug.cgi?id=242619). So please upgrade liboil and let me know (even off-list) whether it helps. -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os From dennis at ausil.us Mon Sep 17 03:36:02 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 16 Sep 2007 22:36:02 -0500 Subject: EPEL and Fedora Extras build system down Message-ID: <200709162236.16142.dennis@ausil.us> Hi All, The main build hub for the plague build system is currently down. It will remain down until we can get someone to look at it in the morning. Sorry for the short notice. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dcbw at redhat.com Mon Sep 17 11:58:15 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Sep 2007 07:58:15 -0400 Subject: EPEL and Fedora Extras build system down In-Reply-To: <200709162236.16142.dennis@ausil.us> References: <200709162236.16142.dennis@ausil.us> Message-ID: <1190030295.1148.16.camel@xo-3E-67-34.localdomain> On Sun, 2007-09-16 at 22:36 -0500, Dennis Gilmore wrote: > Hi All, > > The main build hub for the plague build system is currently down. It will > remain down until we can get someone to look at it in the morning. Sorry for > the short notice. Something with plague or a hardware/os fault? Dan From skvidal at fedoraproject.org Mon Sep 17 11:58:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Sep 2007 07:58:31 -0400 Subject: EPEL and Fedora Extras build system down In-Reply-To: <1190030295.1148.16.camel@xo-3E-67-34.localdomain> References: <200709162236.16142.dennis@ausil.us> <1190030295.1148.16.camel@xo-3E-67-34.localdomain> Message-ID: <1190030311.2602.40.camel@cutter> On Mon, 2007-09-17 at 07:58 -0400, Dan Williams wrote: > On Sun, 2007-09-16 at 22:36 -0500, Dennis Gilmore wrote: > > Hi All, > > > > The main build hub for the plague build system is currently down. It will > > remain down until we can get someone to look at it in the morning. Sorry for > > the short notice. > > Something with plague or a hardware/os fault? hardware/os. -sv From abartlet at samba.org Mon Sep 17 12:32:10 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 17 Sep 2007 22:32:10 +1000 Subject: Why use an old GNUTLS? In-Reply-To: <46EE62AF.5030507@redhat.com> References: <0m642a4wz5.fsf@allele2.localdomain> <46EE62AF.5030507@redhat.com> Message-ID: <1190032330.3512.48.camel@naomi> On Mon, 2007-09-17 at 12:19 +0100, Richard W.M. Jones wrote: > Leo wrote: > > On 2007-09-16 13:37 +0100, Alex Lancaster wrote: > >> Hmm, I notice that gnutls is used as a shared library in many > >> applications that it might be non-trivial to update if the .so version > >> is bumped because it will require a lot of rebuilds. > > > > That's why it is difficult for users to upgrade this package. I try to > > remove Gnutls and that will remove 299 packages that depend on it as > > well. > > Does anyone know if this new GnuTLS is API and/or ABI compatible? I > know that they broke a load of API functions between 1.0 and 1.4, which > required a source patches and retesting for libvirt. Are there any plans to feature GnuTLS in the crypto consolidation. I like (sort of...) the crypto consolidation idea, but for example Samba4 uses GnuTLS, as it's callback functions fits our IO modal well. This might also avoid issues with trying to keep one more crypto package up to date. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- 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 kwizart at gmail.com Mon Sep 17 12:37:36 2007 From: kwizart at gmail.com (KH KH) Date: Mon, 17 Sep 2007 14:37:36 +0200 Subject: Why use an old GNUTLS? In-Reply-To: <46EE62AF.5030507@redhat.com> References: <0m642a4wz5.fsf@allele2.localdomain> <46EE62AF.5030507@redhat.com> Message-ID: 2007/9/17, Richard W.M. Jones : > Leo wrote: > > On 2007-09-16 13:37 +0100, Alex Lancaster wrote: > >> Hmm, I notice that gnutls is used as a shared library in many > >> applications that it might be non-trivial to update if the .so version > >> is bumped because it will require a lot of rebuilds. > > > > That's why it is difficult for users to upgrade this package. I try to > > remove Gnutls and that will remove 299 packages that depend on it as > > well. > > Does anyone know if this new GnuTLS is API and/or ABI compatible? I > know that they broke a load of API functions between 1.0 and 1.4, which > required a source patches and retesting for libvirt. I don't know about gnutls 2.0 case, but updating from 1.4.1 to 1.6.3 is safe, meaning that there is no SONAME bump . So there isn't any "need" to rebuild... (as far as i know). That might be interesting to have it. Updating gnutls-devel >= 1.5.4 will allow filezilla 3.0.0 (final) to be available to the F-7 branch. So now, gntls 1.6.3 is only within the devel branch. But it just has been commited for the F-7 branch. I will request F-7 branch for filezilla and build for F-7 if released... Someone know if gnutls 2.0.0 is already BuildRequired by some apps ? Anyway Might be interesting to rebuild packages in devel now instead of having it updated later...(if possible) Nicolas (kwizart ) > Rich. > > -- > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > England and Wales under Company Registration No. 03798903 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From rdieter at math.unl.edu Mon Sep 17 14:05:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 09:05:16 -0500 Subject: Can Name=GenericName go away now, please? Message-ID: <46EE899C.8070908@math.unl.edu> I posted similarly to fedora-desktop list, but I thought it may be worth spreading this discussion to a wider audience. In particular, can we/fedora consider using better menu names now, so users know which apps are really behind some generic (and mysterious?) items in menus(1). I'm aware of the history that brought us to this point, and using the generic items, but I think it's time to re-evaluate the decision, especially in the context of fedora's various spins. -- Rex (1) For example, Internet->Contacts (evolution) Internet->Email (evolution) Internet->Internet Messenger (pidgin) Internet->IRC (xchat) Office->Calendar (evolution) Office->Word Processor (oowriter) Office->Spreadsheet (oocalc) From ajackson at redhat.com Mon Sep 17 13:50:53 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 17 Sep 2007 09:50:53 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> Message-ID: <1190037053.7686.149.camel@localhost.localdomain> On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > Not sure if this is the relevant list, but...is there any possibility > of F8 having a graphical shutdown? Perhaps even just a non-verbose > shutdown mode? It's just my humble opinion, but I find it looks ugly > and breaks the experience a bit... We (Red Hat) haven't looked into that yet. It's certainly a fine idea though. My mental model of this is that the X session just stays up until the computer actually halts, since it's not like the X server maintains any state that needs to get flushed to disk. You might terminate all the other clients besides the session leader, and then throw up some animation so the user knows things are happening. But that's just a guess. It would take some design first to make sure we think through the interactions. At this stage of F8 it might be too late to fold this in before release, but that doesn't mean we shouldn't work on it. - ajax From jkeating at redhat.com Mon Sep 17 14:15:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Sep 2007 10:15:57 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <46EE899C.8070908@math.unl.edu> References: <46EE899C.8070908@math.unl.edu> Message-ID: <20070917101557.29d52f23@localhost.localdomain> On Mon, 17 Sep 2007 09:05:16 -0500 Rex Dieter wrote: > I posted similarly to fedora-desktop list, but I thought it may be > worth spreading this discussion to a wider audience. > > In particular, can we/fedora consider using better menu names now, so > users know which apps are really behind some generic (and > mysterious?) items in menus(1). > > I'm aware of the history that brought us to this point, and using the > generic items, but I think it's time to re-evaluate the decision, > especially in the context of fedora's various spins. Is a tooltip popup with what the application name actually is not enough? We have to satisfy two groups here, those that are looking for an "email client" and those that are looking for "thunderbird". I would think being helpful to those just looking for a task to do would slightly outweigh somebody looking for a specific application and could hover for a second to see if this is the application they are looking for that does the task listed? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Sep 17 14:19:41 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 17 Sep 2007 15:19:41 +0100 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190037053.7686.149.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> Message-ID: <1190038781.6779.7.camel@pmac.infradead.org> On Mon, 2007-09-17 at 09:50 -0400, Adam Jackson wrote: > My mental model of this is that the X session just stays up until the > computer actually halts, since it's not like the X server maintains > any state that needs to get flushed to disk. It's not like anything _else_ maintains state which needs to be flushed to disk either. If they do, and they can't recover after an unclean shutdown, then they're mostly broken anyway. The only things we should really be doing on shutdown are closing network sockets where appropriate, and the relatively few optimisations which allow a more optimal startup (like properly unmounting the fs so that the journal doesn't have to be replayed, etc.). TBH I've mostly taken to using 'sync; reboot -f', or SysRq-S-U-B to reboot machines these days; what we do on shutdown is mostly a pointless waste of time. -- dwmw2 From wolfy at nobugconsulting.ro Mon Sep 17 14:34:48 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 17 Sep 2007 17:34:48 +0300 Subject: problems writing cd/dvd Message-ID: <46EE9088.6010507@nobugconsulting.ro> I've been hit by a problem which I _think_ is due to a bug in growisofs, but I am not sure. Basically, the disks written (either directly with growisofs or via k3b) sometimes are OK but most often then not, they are not recognized as being ISO9660. For instance: [wolfy at wolfy64 ~]$ isoinfo -i /tmp/test.iso -d CD-ROM is in ISO 9660 format System id: LINUX Volume id: test Volume set id: Publisher id: Data preparer id: Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 12060 NO Joliet present Rock Ridge signatures version 1 found [wolfy at wolfy64 ~]$ growisofs -Z /dev/dvdwriter=/tmp/test.iso Executing 'builtin_dd if=/tmp/test.iso of=/dev/dvdwriter obs=32k seek=0' /dev/dvdwriter: "Current Write Speed" is 4.1x1352KBps. 0/24698880 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0% 0/24698880 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0% 0/24698880 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0% 1048576/24698880 ( 4.2%) @0.2x, remaining 5:38 RBU 100.0% UBU 3.1% 17825792/24698880 (72.2%) @3.6x, remaining 0:07 RBU 41.0% UBU 99.8% builtin_dd: 12064*2KB out @ average 0.9x1352KBps /dev/dvdwriter: flushing cache /dev/dvdwriter: stopping de-icing /dev/dvdwriter: writing lead-out /dev/dvdwriter: reloading tray [wolfy at wolfy64 ~]$ isoinfo dev=/dev/dvdwriter -debug CD-ROM is NOT in ISO 9660 format The problem can be reduced sometimes to the following sequence: [wolfy at wolfy64 tmp]$ for i in `seq 1 5`; do growisofs -Z /dev/dvdwriter=/home/wolfy/cd_space/ghost.iso ; isoinfo dev=/dev/dvdwriter -debug;done --> exhibited no error. Trying again, 1 min later with absolutely no change in the system: [wolfy at wolfy64 tmp]$ growisofs -Z /dev/dvdwriter=/home/wolfy/cd_space/ghost.iso WARNING: /dev/dvdwriter already carries isofs! About to execute 'builtin_dd if=/home/wolfy/cd_space/ghost.iso of=/dev/dvdwriter obs=32k seek=0' /dev/dvdwriter: "Current Write Speed" is 4.1x1352KBps. builtin_dd: 1344*2KB out @ average 1.0x1352KBps /dev/dvdwriter: flushing cache /dev/dvdwriter: stopping de-icing /dev/dvdwriter: writing lead-out [wolfy at wolfy64 tmp]$ sudo mount /dev/dvdwriter /mnt/dvd mount: you must specify the filesystem type I've tried (but failed) to finalize the disk manually, using: [wolfy at wolfy64 tmp]$ growisofs -M /dev/dvdwriter=/dev/zero :-( /dev/dvdwriter doesn't look like isofs... Now, I do admit that I might be plain dumb, but I've tested dozens of times and - about 15 of the DVDs written for the Freemedia project during the last month (that is, roughly half of them) are non functional. All of them have been created using the option "write dvd to disk" from k3b - other .iso images (see above) are sometimes written OK, sometimes (most of the times) not - disks created using genisoimage with the option "-udf" (in whatever combination) seem to fail always - the problem was first spotted while using an ASUS 804P (ATA) which is now used by a colleague without problems; meanwhile I have replaced it with a SATA unit, DRW-1814BLT. - I have replaced the power supply - I have used several types of media(DVD-R, DVD+R, lately DVD+RW, from different manufacturer[s] lots) but I have found no correlation - I have tried to disable udev (udevcontrol stop_exec_queue)/dbus (service messagebus stop) but to no avail. For a period of time I had the impression that writing a dis and allowing the system to automount it would lead to defective subsequent written disks. However the problem appears even if I explicitely umount the first disk , or if I do not mount it at all. I emphasize that I have absolutely no other problems with the system It looks to me like a bug in finalizing the disks, but I do not know how to test (no other machine with DVD-ROM and anything else but linux around). Any ideas, before filing a bug? From jkeating at redhat.com Mon Sep 17 14:34:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Sep 2007 10:34:48 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190038781.6779.7.camel@pmac.infradead.org> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> Message-ID: <20070917103448.39e6762a@localhost.localdomain> On Mon, 17 Sep 2007 15:19:41 +0100 David Woodhouse wrote: > TBH I've mostly taken to using 'sync; reboot -f', or SysRq-S-U-B to > reboot machines these days; what we do on shutdown is mostly a > pointless waste of time. I was thinking about this over the weekend. We have "shutdown" sections in services so that you can restart a service while running, however we don't necessarily have to "shut down" the services when we shut down the system. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Sep 17 14:27:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 09:27:00 -0500 Subject: Can Name=GenericName go away now, please? References: <46EE899C.8070908@math.unl.edu> <20070917101557.29d52f23@localhost.localdomain> Message-ID: Jesse Keating wrote: > Is a tooltip popup with what the application name actually is not > enough? We have to satisfy two groups here, those that are looking for > an "email client" and those that are looking for "thunderbird". That's insufficient, imo, and besides, runs a bit counter to the desktop-entry-spec, which defines these relevant entities as: Name Specific name of the application, for example "Mozilla". GenericName Generic name of the application, for example "Web Browser". Comment Tooltip for the entry, for example "View sites on the Internet", should not be redundant with Name or GenericName. For the record, the spec handles this, where Name=Thunderbird GenericName=Email client Unfortunately, gnome doesn't support/implement the (optional) GenericName part yet, which is part of what led us to the point we are now. A compromise for now would be include GenericName in Name, e.g. Name=Thunderbird Email which is what some apps have already implemented (like thunderbird). -- Rex From nicu_fedora at nicubunu.ro Mon Sep 17 14:49:06 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 17 Sep 2007 17:49:06 +0300 Subject: problems writing cd/dvd In-Reply-To: <46EE9088.6010507@nobugconsulting.ro> References: <46EE9088.6010507@nobugconsulting.ro> Message-ID: <46EE93E2.1030308@nicubunu.ro> Manuel Wolfshant wrote: > I've been hit by a problem which I _think_ is due to a bug in growisofs, > but I am not sure. Basically, the disks written (either directly with > growisofs or via k3b) sometimes are OK but most often then not, they are > not recognized as being ISO9660. For instance: [...] > It looks to me like a bug in finalizing the disks, but I do not know > how to test (no other machine with DVD-ROM and anything else but linux > around). Any ideas, before filing a bug? I saw something similar and only when writing DVDs, not CDs and sometime the recorded disks will work on a Windows box but have not investigated the problem further (I used GNOME burning tools). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nicu_fedora at nicubunu.ro Mon Sep 17 14:52:43 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 17 Sep 2007 17:52:43 +0300 Subject: problems writing cd/dvd In-Reply-To: <46EE93E2.1030308@nicubunu.ro> References: <46EE9088.6010507@nobugconsulting.ro> <46EE93E2.1030308@nicubunu.ro> Message-ID: <46EE94BB.7040504@nicubunu.ro> Nicu Buculei wrote: > Manuel Wolfshant wrote: >> I've been hit by a problem which I _think_ is due to a bug in >> growisofs, but I am not sure. Basically, the disks written (either >> directly with growisofs or via k3b) sometimes are OK but most often >> then not, they are not recognized as being ISO9660. For instance: > > [...] >> It looks to me like a bug in finalizing the disks, but I do not >> know how to test (no other machine with DVD-ROM and anything else but >> linux around). Any ideas, before filing a bug? > > I saw something similar and only when writing DVDs, not CDs and sometime > the recorded disks will work on a Windows box but have not investigated > the problem further (I used GNOME burning tools). Oh, forgot to add: I saw this for the first time with FC6, it happened suddenly, probably after a package update (don't know which). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nicolas.mailhot at laposte.net Mon Sep 17 15:00:59 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 17 Sep 2007 17:00:59 +0200 (CEST) Subject: Can Name=GenericName go away now, please? In-Reply-To: <20070917101557.29d52f23@localhost.localdomain> References: <46EE899C.8070908@math.unl.edu> <20070917101557.29d52f23@localhost.localdomain> Message-ID: <27063.192.54.193.51.1190041259.squirrel@rousalka.dyndns.org> Le Lun 17 septembre 2007 16:15, Jesse Keating a ?crit : > On Mon, 17 Sep 2007 09:05:16 -0500 > Rex Dieter wrote: >> I'm aware of the history that brought us to this point, and using >> the >> generic items, but I think it's time to re-evaluate the decision, >> especially in the context of fedora's various spins. > > Is a tooltip popup with what the application name actually is not > enough? We have to satisfy two groups here, those that are looking > for > an "email client" and those that are looking for "thunderbird". And one could change the menu policy from one to the other or a combo of both if GNOME apps didn't hijack Name with what the spec says should go in genericname Even if we chose to retain the current behaviour as default it has no business being implemented through a gross f.d.o. spec violation. -- Nicolas Mailhot From mclasen at redhat.com Mon Sep 17 15:10:46 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 17 Sep 2007 11:10:46 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <27063.192.54.193.51.1190041259.squirrel@rousalka.dyndns.org> References: <46EE899C.8070908@math.unl.edu> <20070917101557.29d52f23@localhost.localdomain> <27063.192.54.193.51.1190041259.squirrel@rousalka.dyndns.org> Message-ID: <1190041846.4134.11.camel@localhost.localdomain> On Mon, 2007-09-17 at 17:00 +0200, Nicolas Mailhot wrote: > Le Lun 17 septembre 2007 16:15, Jesse Keating a ?crit : > > On Mon, 17 Sep 2007 09:05:16 -0500 > > Rex Dieter wrote: > > >> I'm aware of the history that brought us to this point, and using > >> the > >> generic items, but I think it's time to re-evaluate the decision, > >> especially in the context of fedora's various spins. How do Fedoras various spins change the circumstances that lead to the decision ? > > Is a tooltip popup with what the application name actually is not > > enough? We have to satisfy two groups here, those that are looking > > for > > an "email client" and those that are looking for "thunderbird". > > And one could change the menu policy from one to the other or a combo > of both if GNOME apps didn't hijack Name with what the spec says > should go in genericname No, thats just broken. If you change the combo, you suddenly get five "Email Client" entries in the menu. Combining name and genericname programmatically just doesn't work from an i18n perspective. From mattdm at mattdm.org Mon Sep 17 15:14:14 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Sep 2007 11:14:14 -0400 Subject: calc ready for package review, for real In-Reply-To: <20070906154921.GA5448@jadzia.bu.edu> References: <20070906154921.GA5448@jadzia.bu.edu> Message-ID: <20070917151414.GA11615@jadzia.bu.edu> On Thu, Sep 06, 2007 at 11:49:21AM -0400, Matthew Miller wrote: > This has been hanging out in bugzilla for some time pending some upstream > work. That's resolved, and I think the package is ready to go. > Anyone? Much work, a few good comments, no formal review.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From overholt at redhat.com Mon Sep 17 15:12:24 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 17 Sep 2007 11:12:24 -0400 Subject: rawhide report: 20070916 changes In-Reply-To: <200709162142.l8GLgkK4005929@laptop13.inf.utfsm.cl> References: <200709160919.l8G9JAeJ007298@porkchop.devel.redhat.com> <200709162142.l8GLgkK4005929@laptop13.inf.utfsm.cl> Message-ID: <20070917151223.GA7576@redhat.com> * Horst H. von Brand [2007-09-16 17:53]: > Build System wrote: > > Updated Packages: > > [...] > > > eclipse-egit-0.2.2-0.git20070911.fc8 > > I'm getting: > > Error: Missing Dependency: eclipse-platform > 1:3.3.0 is needed by package eclipse-egit I don't see how that's not being satisfied. I have: $ rpm -q eclipse-platform 1:eclipse-platform-3.3.0-19.fc8 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 Mon Sep 17 15:15:52 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 17 Sep 2007 11:15:52 -0400 Subject: rawhide report: 20070916 changes In-Reply-To: <20070917151223.GA7576@redhat.com> References: <200709160919.l8G9JAeJ007298@porkchop.devel.redhat.com> <200709162142.l8GLgkK4005929@laptop13.inf.utfsm.cl> <20070917151223.GA7576@redhat.com> Message-ID: <20070917151552.GB7576@redhat.com> * Andrew Overholt [2007-09-17 11:18]: > * Horst H. von Brand [2007-09-16 17:53]: > > Build System wrote: > > > Updated Packages: > > > > [...] > > > > > eclipse-egit-0.2.2-0.git20070911.fc8 > > > > I'm getting: > > > > Error: Missing Dependency: eclipse-platform > 1:3.3.0 is needed by package eclipse-egit > > I don't see how that's not being satisfied. I have: Nevermind, I see that Ben just fixed this in CVS. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Sep 17 15:26:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 10:26:20 -0500 Subject: Can Name=GenericName go away now, please? References: <46EE899C.8070908@math.unl.edu> <20070917101557.29d52f23@localhost.localdomain> <27063.192.54.193.51.1190041259.squirrel@rousalka.dyndns.org> <1190041846.4134.11.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: >> > On Mon, 17 Sep 2007 09:05:16 -0500 >> > Rex Dieter wrote: >> >> >> I'm aware of the history that brought us to this point, and using >> >> the >> >> generic items, but I think it's time to re-evaluate the decision, >> >> especially in the context of fedora's various spins. > > How do Fedoras various spins change the circumstances that lead to the > decision ? Say Fedora Spin X decided to start naming all their "default" apps similarly. More specifically, wow would you react if the KDE spin started calling kmail "Email client" or kword "Word Processor" in the menus too? Wouldn't you agree this is a bad path to follow and/or a bad precedent to set? -- Rex From walters at redhat.com Mon Sep 17 15:30:05 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Sep 2007 11:30:05 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <46EE899C.8070908@math.unl.edu> References: <46EE899C.8070908@math.unl.edu> Message-ID: On 9/17/07, Rex Dieter wrote: > I posted similarly to fedora-desktop list, but I thought it may be worth > spreading this discussion to a wider audience. > > In particular, can we/fedora consider using better menu names now, so > users know which apps are really behind some generic (and mysterious?) > items in menus(1). The last discussion on this was here: http://marc.info/?l=fedora-desktop-list&m=118530967420021&w=2 Owen's suggested solution was: "OK, back to the present: My advise for the X-Chat is to make it match how we do a lot of other .desktop files now: do "X-Chat IRC Client" like "Firefox Web Browser" and so forth." From nicolas.mailhot at laposte.net Mon Sep 17 16:07:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 17 Sep 2007 18:07:42 +0200 (CEST) Subject: Can Name=GenericName go away now, please? In-Reply-To: References: <46EE899C.8070908@math.unl.edu> Message-ID: <35378.192.54.193.51.1190045262.squirrel@rousalka.dyndns.org> Le Lun 17 septembre 2007 17:30, Colin Walters a ?crit : > Owen's suggested solution was: > > "OK, back to the present: My advise for the X-Chat is to make it match > how we > do a lot of other .desktop files now: do "X-Chat IRC Client" like > "Firefox Web Browser" > and so forth." However this is not name or genericname but something like descriptivename Can't the gnome folks agree with the kde folks on a spec both would implement? -- Nicolas Mailhot From mschwendt.tmp0701.nospam at arcor.de Mon Sep 17 16:13:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 17 Sep 2007 18:13:28 +0200 Subject: Useless OpenEXR split Message-ID: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> $ sudo rpm -e OpenEXR error: Failed dependencies: OpenEXR = 1.4.0a-5.fc8 is needed by (installed) OpenEXR-libs-1.4.0a-5.fc8.i386 $ sudo rpm -e OpenEXR-libs error: Failed dependencies: libHalf.so.4 is needed by (installed) kdelibs-3.5.7-22.fc8.i386 libHalf.so.4 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 libIex.so.4 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 libIlmImf.so.4 is needed by (installed) kdelibs-3.5.7-22.fc8.i386 libIlmImf.so.4 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 libIlmThread.so.4 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 libImath.so.4 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 OpenEXR-libs = 1.4.0a-5.fc8 is needed by (installed) OpenEXR-1.4.0a-5.fc8.i386 $ rpmls OpenEXR -rwxr-xr-x /usr/bin/exrenvmap -rwxr-xr-x /usr/bin/exrheader -rwxr-xr-x /usr/bin/exrmakepreview -rwxr-xr-x /usr/bin/exrmaketiled -rwxr-xr-x /usr/bin/exrstdattr drwxr-xr-x /usr/share/doc/OpenEXR-1.4.0a -rw-r--r-- /usr/share/doc/OpenEXR-1.4.0a/AUTHORS -rw-r--r-- /usr/share/doc/OpenEXR-1.4.0a/ChangeLog -rw-r--r-- /usr/share/doc/OpenEXR-1.4.0a/LICENSE -rw-r--r-- /usr/share/doc/OpenEXR-1.4.0a/NEWS -rw-r--r-- /usr/share/doc/OpenEXR-1.4.0a/README Why does the -libs package require these tools? The .spec doesn't answer that question. In the other direction, there's a hardcoded strict dependency in addition to the automatic soname deps, creating a circle: $ rpm -qR OpenEXR|grep EXR OpenEXR-libs = 1.4.0a-5.fc8 Conclusively, the split is useless. From mschwendt.tmp0701.nospam at arcor.de Mon Sep 17 16:13:36 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 17 Sep 2007 18:13:36 +0200 Subject: Useless jasper split Message-ID: <20070917181336.e9ce7c44.mschwendt.tmp0701.nospam@arcor.de> $ rpm -e jasper error: Failed dependencies: jasper = 1.900.1-4.fc8 is needed by (installed) jasper-libs-1.900.1-4.fc8.i386 $ sudo rpm -e jasper-libs error: Failed dependencies: libjasper.so.1 is needed by (installed) kdelibs-3.5.7-22.fc8.i386 libjasper.so.1 is needed by (installed) jasper-1.900.1-4.fc8.i386 jasper-libs = 1.900.1-4.fc8 is needed by (installed) jasper-1.900.1-4.fc8.i386 $ rpmls jasper -rwxr-xr-x /usr/bin/imgcmp -rwxr-xr-x /usr/bin/imginfo -rwxr-xr-x /usr/bin/jasper drwxr-xr-x /usr/share/doc/jasper-1.900.1 -rw-r--r-- /usr/share/doc/jasper-1.900.1/COPYRIGHT -rw-r--r-- /usr/share/doc/jasper-1.900.1/LICENSE -rw-r--r-- /usr/share/doc/jasper-1.900.1/NEWS -rw-r--r-- /usr/share/doc/jasper-1.900.1/README -rw-r--r-- /usr/share/man/man1/imgcmp.1.gz -rw-r--r-- /usr/share/man/man1/imginfo.1.gz -rw-r--r-- /usr/share/man/man1/jasper.1.gz Why does the -libs package require these tools? The .spec doesn't answer that question. In the other direction, there's a hardcoded strict dependency in addition to the automatic soname deps, creating a circle: $ rpm -qR jasper|grep jas jasper-libs = 1.900.1-4.fc8 libjasper.so.1 Conclusively, the split is useless. From orion at cora.nwra.com Mon Sep 17 16:09:46 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 17 Sep 2007 10:09:46 -0600 Subject: Install speed comparisons FC5 -> rawhide Message-ID: <46EEA6CA.2020704@cora.nwra.com> Since I commented on yum speed in rawhide, I thought I'd run some comparisons from Fedora Core 5 through current rawhide. We do PXE/http network installs using kickstart here and include extras/updates/local repositories in the install. I did the installs on a moderately old Pentium M 1.4GHz computer with 100MB ethernet. Here are the break downs (time is from the previous step to that line): FC5 (919 packages) (actually, this is a rebuilt FC5 repo with extras and updates merged in, and with NFS not HTTP) boot -> run anaconda 17s -> basepkgsel 30s -> postselection 41s + -> enablefilesystems 110s | -> installpackages 74s +- 225s -> copylogs 19:37 FC6 (984 packages) boot -> run anaconda 18s -> basepkgsel 30s -> postsel 238s + -> enablefilesys 212s | -> installpackages 69s +- 519s -> copylogs 20:12 F7 (1039 packages) boot -> anaconda 19s -> basepkgsel 24s -> postselection 99s + -> enablefilesystems 284s | -> installpackages 69s +- 452s -> copylogs 17:53 rawhide (1109 packages) boot -> anaconda 30s (10s to insert wireless ipw2100 driver) -> basepkgsel 27s -> postselection 70s + -> enablefilesystems 39s | -> installpackages 72s +- 181s -> copylogs 33:19 Observations: - FC5 was the best - FC6 was *slow* - F7 package install speed improved - F8 startup is looking good, packages are taking longer to install though. Debugging still in rawhide kernel? - Getting more and more packages each release. Hmm.. It would be nice to have a log of how long each package took to install. -- 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 kevin.kofler at chello.at Mon Sep 17 16:11:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 17 Sep 2007 16:11:55 +0000 (UTC) Subject: Can Name=GenericName go away now, please? Message-ID: > First of all, sorry for this message not being properly threaded, but followups are currently broken in the GMane web interface. :-( Rex Dieter wrote: > In particular, can we/fedora consider using better menu names now, so users > know which apps are really behind some generic (and mysterious?) items in > menus(1). +1 (In fact, I would have fixed XChat already if it hadn't been vetoed by the primary maintainer.) Jesse Keating wrote: > Is a tooltip popup with what the application name actually is not > enough? First of all, KDE doesn't show that tooltip. We're in a pretty unfortunate state where GNOME ignores GenericName and KDE ignores Comment. Still, IMHO the best (and most logical) workaround for this problem is to have GenericName == Comment as seen in several .desktop files already, or to have them contain the same information phrased differently (e.g. GenericName=E-Mail Client, Comment=Send and receive e-mail). That way, GNOME users will get the task the apps are solving as a tooltip, KDE users can choose to have it listed in the menu (KDE allows displaying only Name, only GenericName or both). Or of course we can fix the desktop environments to show all 3 items. :-) Nicolas Mailhot wrote: > Even if we chose to retain the current behaviour as default it has no > business being implemented through a gross f.d.o. spec violation. +1 to that too. Rex Dieter wrote: > Matthias Clasen wrote: [snip] > > How do Fedoras various spins change the circumstances that lead to the > > decision ? > > Say Fedora Spin X decided to start naming all their "default" apps > similarly. More specifically, wow would you react if the KDE spin started > calling kmail "Email client" or kword "Word Processor" in the menus too? > Wouldn't you agree this is a bad path to follow and/or a bad precedent to > set? Once again I fully agree with Rex. In fact, that would lead to exactly this situation you (Matthias Clasen) describe: > No, thats just broken. If you change the combo, you suddenly get five > "Email Client" entries in the menu. only you don't even get the option to fix it. Abusing Name that way only works if there's one default, but Fedora has outgrown this now that we have multiple spins and that the alternative applications formerly in Extras have been merged into the core distribution. Matthias Clasen wrote: > Combining name and genericname programmatically just doesn't work from an > i18n perspective. The format can be internationalized, for example some languages can use "Name GenericName", others "Name - GenericName" (which is what KDE is currently using, unless it's already locale-dependent), others "Name (GenericName)". Colin Walters wrote: > Owen's suggested solution was: > > "OK, back to the present: My advise for the X-Chat is to make it match how we > do a lot of other .desktop files now: do "X-Chat IRC Client" like > "Firefox Web Browser" and so forth." But we can have this without abusing the spec this way by just programmatically displaying "Name GenericName". Kevin Kofler From rdieter at math.unl.edu Mon Sep 17 16:20:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 11:20:47 -0500 Subject: Can Name=GenericName go away now, please? References: <46EE899C.8070908@math.unl.edu> Message-ID: Colin Walters wrote: > On 9/17/07, Rex Dieter wrote: >> I posted similarly to fedora-desktop list, but I thought it may be worth >> spreading this discussion to a wider audience. >> >> In particular, can we/fedora consider using better menu names now, so >> users know which apps are really behind some generic (and mysterious?) >> items in menus(1). > > The last discussion on this was here: > http://marc.info/?l=fedora-desktop-list&m=118530967420021&w=2 > > Owen's suggested solution was: > > "OK, back to the present: My advise for the X-Chat is to make it match how > we do a lot of other .desktop files now: do "X-Chat IRC Client" like > "Firefox Web Browser" > and so forth." I can live with that compromise (which is certainly better than the status quo). I'm wondering why maintainers of affected packages didn't follow the suggestion, but maybe not everybody had followed the discussion close enough. I'll get to work filing bugs against affected packages. -- Rex From rdieter at math.unl.edu Mon Sep 17 16:23:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 11:23:23 -0500 Subject: Useless OpenEXR split References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > Why does the -libs package require these tools? > The .spec doesn't answer that question. > > In the other direction, there's a hardcoded strict dependency in > addition to the automatic soname deps, creating a circle: > > $ rpm -qR OpenEXR|grep EXR > OpenEXR-libs = 1.4.0a-5.fc8 > > Conclusively, the split is useless. It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. (same goes for jasper). -- Rex From mschwendt.tmp0701.nospam at arcor.de Mon Sep 17 16:38:31 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 17 Sep 2007 18:38:31 +0200 Subject: Useless OpenEXR split In-Reply-To: References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> On Mon, 17 Sep 2007 11:23:23 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > Why does the -libs package require these tools? > > The .spec doesn't answer that question. > > > > In the other direction, there's a hardcoded strict dependency in > > addition to the automatic soname deps, creating a circle: > > > > $ rpm -qR OpenEXR|grep EXR > > OpenEXR-libs = 1.4.0a-5.fc8 > > > > Conclusively, the split is useless. > > It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. > > (same goes for jasper). You didn't answer the question. Why does the -libs package require the tools? Do the libraries need the tools?! I see that the OpenEXR-libs.i386 "Requires: OpenEXR = ..." is satisfied by OpenEXR.x86_64, but why the dependency? What do you find "clean" about it? WRT multi-lib, it would also work to have just -devel requires -libs and be done. Just because of the dependency on the main package, optional example programs are installed and cannot be removed. From kwizart at gmail.com Mon Sep 17 16:40:01 2007 From: kwizart at gmail.com (KH KH) Date: Mon, 17 Sep 2007 18:40:01 +0200 Subject: Useless OpenEXR split In-Reply-To: References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> Message-ID: 2007/9/17, Rex Dieter : > Michael Schwendt wrote: > > > Why does the -libs package require these tools? > > The .spec doesn't answer that question. > > > > In the other direction, there's a hardcoded strict dependency in > > addition to the automatic soname deps, creating a circle: > > > > $ rpm -qR OpenEXR|grep EXR > > OpenEXR-libs = 1.4.0a-5.fc8 > > > > Conclusively, the split is useless. > > It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. But there is a problem if OpenEXR-libs.i386 Requires main.i386 There is at least two solutions if we want multilibs compatibility : 1 - Use main and -devel (with bins and libs in main ), that's mean when a user install a package.i386 that requires OpenEXR.i386, then 2 - Disable libs to Requires main, then apps that links to OpenEXR will need to add Requires: OpenEXR (which will have only bins ). For now i don't know if app are requiring binaries to works... But is there any problem to uses .x86_64 binaries from a i386 program ? Actually when both arch for bin package are installed, preference goes to x86_64 version on x86_64 system... (unless i'm wrong ) Thought there is an 1.6 update of openexr... Rex, do you mind we can have an update ? Nicolas (kwizart ) > (same goes for jasper). > > -- Rex > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rdieter at math.unl.edu Mon Sep 17 16:40:24 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 11:40:24 -0500 Subject: Useless OpenEXR split References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > On Mon, 17 Sep 2007 11:23:23 -0500, Rex Dieter wrote: > >> Michael Schwendt wrote: >> >> > Why does the -libs package require these tools? >> > The .spec doesn't answer that question. >> > >> > In the other direction, there's a hardcoded strict dependency in >> > addition to the automatic soname deps, creating a circle: >> > >> > $ rpm -qR OpenEXR|grep EXR >> > OpenEXR-libs = 1.4.0a-5.fc8 >> > >> > Conclusively, the split is useless. >> >> It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. >> >> (same goes for jasper). > > You didn't answer the question. Why does the -libs package require the > tools? Do the libraries need the tools?! I addressed the assertion that the split was useless. :) > Just because of the dependency on the main package, optional example > programs are installed and cannot be removed. It's unclear (to me anyway) whether these truly are optional or not, ie, I have yet to determine here (or in the jasper case) whether apps assume the presence tools/binaries. In short, I'm playing it safe, and keeping the same behavior as when there wasn't a -libs split. -- Rex From jwboyer at jdub.homelinux.org Mon Sep 17 16:43:04 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 17 Sep 2007 11:43:04 -0500 Subject: Install speed comparisons FC5 -> rawhide In-Reply-To: <46EEA6CA.2020704@cora.nwra.com> References: <46EEA6CA.2020704@cora.nwra.com> Message-ID: <20070917114304.232902a2@weaponx.rchland.ibm.com> On Mon, 17 Sep 2007 10:09:46 -0600 Orion Poplawski wrote: > Observations: > > - FC5 was the best > - FC6 was *slow* > - F7 package install speed improved > - F8 startup is looking good, packages are taking longer to install > though. Debugging still in rawhide kernel? Yes, debugging is still enabled. > - Getting more and more packages each release. Hmm.. What, did you expect it to shrink? > It would be nice to have a log of how long each package took to install. You realize that generating that will just take more time overall right? josh From rdieter at math.unl.edu Mon Sep 17 16:45:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 11:45:00 -0500 Subject: Useless OpenEXR split References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> Message-ID: KH KH wrote: >> It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. > But there is a problem if OpenEXR-libs.i386 Requires main.i386 It only Requires: OpenEXR (not OpenEXR.i386) so OpenEXR.x86_64 can/will satisfy that. > Thought there is an 1.6 update of openexr... > Rex, do you mind we can have an update ? pending review of new dependency: http://bugzilla.redhat.com/251521 -- Rex From orion at cora.nwra.com Mon Sep 17 17:05:37 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 17 Sep 2007 11:05:37 -0600 Subject: Install speed comparisons FC5 -> rawhide In-Reply-To: <20070917114304.232902a2@weaponx.rchland.ibm.com> References: <46EEA6CA.2020704@cora.nwra.com> <20070917114304.232902a2@weaponx.rchland.ibm.com> Message-ID: <46EEB3E1.3080501@cora.nwra.com> Josh Boyer wrote: > On Mon, 17 Sep 2007 10:09:46 -0600 > Orion Poplawski wrote: > >> - Getting more and more packages each release. Hmm.. > > What, did you expect it to shrink? > No, more of a mental note to myself to see what packages I need to explicitly not install. >> It would be nice to have a log of how long each package took to install. > > You realize that generating that will just take more time overall right? Come on, a extra 1000 lines in a log file written to a ram filesystem? But probably should only be enabled with an explicit "verbose debug" option to anaconda. Off to bugzilla... -- 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 mschwendt.tmp0701.nospam at arcor.de Mon Sep 17 17:13:48 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 17 Sep 2007 19:13:48 +0200 Subject: Useless OpenEXR split In-Reply-To: References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070917191348.59d17631.mschwendt.tmp0701.nospam@arcor.de> On Mon, 17 Sep 2007 11:40:24 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > On Mon, 17 Sep 2007 11:23:23 -0500, Rex Dieter wrote: > > > >> Michael Schwendt wrote: > >> > >> > Why does the -libs package require these tools? > >> > The .spec doesn't answer that question. > >> > > >> > In the other direction, there's a hardcoded strict dependency in > >> > addition to the automatic soname deps, creating a circle: > >> > > >> > $ rpm -qR OpenEXR|grep EXR > >> > OpenEXR-libs = 1.4.0a-5.fc8 > >> > > >> > Conclusively, the split is useless. > >> > >> It's cleaner wrt multilib, ie no OpenEXR.i386 in x86_64 repo. > >> > >> (same goes for jasper). > > > > You didn't answer the question. Why does the -libs package require the > > tools? Do the libraries need the tools?! > > I addressed the assertion that the split was useless. :) > > > Just because of the dependency on the main package, optional example > > programs are installed and cannot be removed. > > It's unclear (to me anyway) whether these truly are optional or not, ie, I > have yet to determine here (or in the jasper case) whether apps assume the > presence tools/binaries. In short, I'm playing it safe, and keeping the > same behavior as when there wasn't a -libs split. For jasper, the executables are _example programs_. RTFM confirms that. For OpenEXR, they are referred to as additional utilities. The prefix "exr" in their names does not appear in any of the libs. $ rpm -ql OpenEXR-libs /usr/lib/libHalf.so.4 /usr/lib/libHalf.so.4.0.0 /usr/lib/libIex.so.4 /usr/lib/libIex.so.4.0.0 /usr/lib/libIlmImf.so.4 /usr/lib/libIlmImf.so.4.0.0 /usr/lib/libIlmThread.so.4 /usr/lib/libIlmThread.so.4.0.0 /usr/lib/libImath.so.4 /usr/lib/libImath.so.4.0.0 $ grep -i exr /usr/lib/libHalf.so.4 $ grep -i exr /usr/lib/libIex.so.4 $ grep -i exr /usr/lib/libIlmImf.so.4 Binary file /usr/lib/libIlmImf.so.4 matches $ grep -i exr /usr/lib/libIlmThread.so.4 $ grep -i exr /usr/lib/libImath.so.4 $ $ strings /usr/lib/libIlmImf.so.4|grep -i exr _ZN3Imf13isOpenExrFileEPKcRb _ZN3Imf18isTiledOpenExrFileEPKc _ZN3Imf13isOpenExrFileEPKc _ZN3Imf13isOpenExrFileERNS_7IStreamERb _ZN3Imf18isTiledOpenExrFileERNS_7IStreamE _ZN3Imf13isOpenExrFileERNS_7IStreamE From rdieter at math.unl.edu Mon Sep 17 17:18:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 17 Sep 2007 12:18:26 -0500 Subject: Useless OpenEXR split References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> <20070917191348.59d17631.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: >> It's unclear (to me anyway) whether these truly are optional or not, ie, >> I have yet to determine here (or in the jasper case) whether apps assume >> the >> presence tools/binaries. In short, I'm playing it safe, and keeping the >> same behavior as when there wasn't a -libs split. > > For jasper, the executables are _example programs_. RTFM confirms that. I've found at least one example (kopete?) where it assumes the presence of the jasper binary. > For OpenEXR, they are referred to as additional utilities. The prefix > "exr" in their names does not appear in any of the libs. OK, well, I guess we can take the "remove it and see if anything breaks" approach too. -- Rex From ondrejj at salstar.sk Mon Sep 17 17:24:10 2007 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Mon, 17 Sep 2007 19:24:10 +0200 Subject: Drop package micq (it's new name is climm) Message-ID: <20070917172410.GI4684@salstar.sk> Hello, please, drop package "micq", because it has been renamed to "climm". New package is waiting for CSV admin now. This package has been never pushed into stable updates, because name change has been done between testing to stable change. The new climm package will replace the old one. Thank you. Jan ONDREJ (SAL) From mschwendt.tmp0701.nospam at arcor.de Mon Sep 17 17:46:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 17 Sep 2007 19:46:33 +0200 Subject: Useless OpenEXR split In-Reply-To: References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> <20070917191348.59d17631.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070917194633.ee9a2ea6.mschwendt.tmp0701.nospam@arcor.de> On Mon, 17 Sep 2007 12:18:26 -0500, Rex Dieter wrote: > > For jasper, the executables are _example programs_. RTFM confirms that. > > I've found at least one example (kopete?) where it assumes the presence of > the jasper binary. As mentioned before, no comment in the spec file reflects that. :( The names of the jasper tools don't appear in libjasper.so.1, so perhaps you've found an external dependency on one of the tools (and that ought to be documented in the same place where there is the "Requires: /usr/bin/jasper" or similar). It would still be no reason to make libjasper require the examples. $ repoquery --whatrequires libjasper.so.1 jasper-debuginfo-0:1.900.1-4.fc8.i386 kdelibs-6:3.5.7-22.fc8.i386 jasper-0:1.900.1-4.fc8.i386 jasper-devel-0:1.900.1-4.fc8.i386 digikam-0:0.9.2-4.fc8.i386 LabPlot-0:1.5.1.6-4.fc8.i386 gdal-0:1.4.2-3.fc8.i386 jasper-utils-0:1.900.1-4.fc8.i386 jasper-libs-0:1.900.1-4.fc8.i386 Only four users. From notting at redhat.com Mon Sep 17 17:49:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Sep 2007 13:49:27 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917103448.39e6762a@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> Message-ID: <20070917174927.GF337@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I was thinking about this over the weekend. We have "shutdown" > sections in services so that you can restart a service while running, > however we don't necessarily have to "shut down" the services when we > shut down the system. Right, and not doing it cuts shutdown in half. However, since it's a change in interface, you'd have to tag each service that you don't care about shutting down separately. Which sucks. Bill From fedora at leemhuis.info Mon Sep 17 18:00:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 17 Sep 2007 20:00:26 +0200 Subject: EPEL report week 37 2007 Message-ID: <46EEC0BA.3040807@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week37 (/me still suffered from a cold/has a headache - I hope I didn't do even more typos then I usually do already when I wrote the report due to that...) = Weekly EPEL Summary = Week 37/2007 == Most important happenings == * push scripts improved (see below) == EPEL SIG Meeting == === Attending === * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) * f13 (Jesse Keating) * warren (Warren Togami) === Summary === * pushing * dglimore, nirik and mschwendt further improved and simplified pushing directly to stable and moving a package from testing to stable; thx guys, especially mschwendt! * nirik will test them * repo layout * the plan written at http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 was to have directories for each release (e.g. have 5.0 as main repo now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks or months later remove the 5.0 dir to save the space; 5.0 btw would not be maintained anymore, we just leave it around for some weeks/months). This would allow people still on EL5.0 (for example those using derivates that do not ship 5.1 some weeks after RH does) to use EPEL5.0 without running into dependency issues that might arise when a package from EPEL5.1 depends on something from EL5.1; * seems lots of people forgot about that plan never realized it full effects; do we still want that stuff? or in a modified way maybe? * RHEL 5.1 * will likely be out soon; we don't know exactly when; thus the estimated EPEL testing -> stable move that is pushed in parallel will likely be a week (or two?) after EL 5.1 is out * do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all * some discussion how to exactly do this; more discussions to follow the list * RH relations * warren: BTW, I inserted this rule into RH's processes for adding a new package to RHEL. Something like "Check EPEL to be sure your new package is newer" * Free discussion around EPEL * sticking with the alternate meeting time? we try another two or three weeks and decide afterwards === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-September/msg00006.html == Stats == === General === Number of EPEL Contributors 6 We welcome 6 new contributors: candyz joshuadf lkundrak ondrejj salimma sundaram === EPEL 5 === Number of source packages: 655 Number of binary packages: 1261 There are 18 new Packages: * abcde | A Better CD Encoder * aspell-sk | Slovak dictionaries for Aspell * cd-discid | Utility to get CDDB discid information * cvs2cl | Generate ChangeLogs from CVS working copies * dbench | Filesystem load benchmarking tool * directfb | Graphics abstraction library for the Linux Framebuffer Device * gcin | Input method for Traditional Chinese * gtk-qt-engine | A project allowing GTK to use Qt widget styles. * isync | Tool to synchronize IMAP4 and Maildir mailboxes * kasablanca | Graphical FTP client * lyx | WYSIWYM (What You See Is What You Mean) document processor * mach | Make a chroot * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system * rubygem-rake | Ruby based make-like utility * rubygems | The Ruby standard for packaging ruby libraries * svn2cl | Create a ChangeLog from a Subversion log * tomcat-native | Tomcat native library === EPEL 4 === Number of source packages: 418 Number of binary packages: 850 There are 3 new Packages: * isync | Tool to synchronize IMAP4 and Maildir mailboxes * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system ---- ["CategoryEPELReports"] From walters at redhat.com Mon Sep 17 18:05:16 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Sep 2007 14:05:16 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917174927.GF337@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> Message-ID: On 9/17/07, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I was thinking about this over the weekend. We have "shutdown" > > sections in services so that you can restart a service while running, > > however we don't necessarily have to "shut down" the services when we > > shut down the system. > > Right, and not doing it cuts shutdown in half. However, since it's a > change in interface, you'd have to tag each service that you don't care > about shutting down separately. Which sucks. Right, but there's very few things that actually need a special shutdown. And all of them are server services (thus not interesting for discussion of graphical shutdown). Ubuntu apparently went through their list: https://wiki.ubuntu.com/Teardown From jkeating at redhat.com Mon Sep 17 18:04:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Sep 2007 14:04:53 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917174927.GF337@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> Message-ID: <20070917140453.657eb83d@localhost.localdomain> On Mon, 17 Sep 2007 13:49:27 -0400 Bill Nottingham wrote: > Right, and not doing it cuts shutdown in half. However, since it's a > change in interface, you'd have to tag each service that you don't > care about shutting down separately. Which sucks. Yeah, I figured there would have to be some way to indicate "no really, I need to do some things at system shut down time". F9/10 feature maybe? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Mon Sep 17 18:04:40 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Sep 2007 14:04:40 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917174927.GF337@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> Message-ID: <1190052280.2602.63.camel@cutter> On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I was thinking about this over the weekend. We have "shutdown" > > sections in services so that you can restart a service while running, > > however we don't necessarily have to "shut down" the services when we > > shut down the system. > > Right, and not doing it cuts shutdown in half. However, since it's a > change in interface, you'd have to tag each service that you don't care > about shutting down separately. Which sucks. > would this be as a simple as modifying chkconfig so that if there isn't a 3rd field in the: # chkconfig: levels start_order stop_order line in an initscript that it just didn't make the stop symlink? -sv From myfedora at richip.dhs.org Mon Sep 17 18:12:05 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 12:12:05 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917103448.39e6762a@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> Message-ID: <1190052725.16960.13.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 10:34 -0400, Jesse Keating wrote: > I was thinking about this over the weekend. We have "shutdown" > sections in services so that you can restart a service while running, > however we don't necessarily have to "shut down" the services when we > shut down the system. I'm a little confused. I occasionally shut down running services on a running system without necessarily starting them up immediately or ever after (like NFS when I'm done sharing things or tomcat5 when I'm just debugging). I thought that there was also a "shutdown" option in services to allow people to script proper and clean shutdown sequences for services (like saving state for databases and ALSA sound system). If we don't necessarily have to "shut down" the service when shutting down, do you mean that services should just do the proper thing when sent the appropriate signal(7)? Like a uniform way of being signalled to shut down? (an analogy would be destructors in OOP) -- Richi Plana From ssorce at redhat.com Mon Sep 17 18:15:21 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Sep 2007 14:15:21 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190052280.2602.63.camel@cutter> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> Message-ID: <1190052921.8152.17.camel@localhost.localdomain> On Mon, 2007-09-17 at 14:04 -0400, seth vidal wrote: > On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote: > > Jesse Keating (jkeating at redhat.com) said: > > > I was thinking about this over the weekend. We have "shutdown" > > > sections in services so that you can restart a service while running, > > > however we don't necessarily have to "shut down" the services when we > > > shut down the system. > > > > Right, and not doing it cuts shutdown in half. However, since it's a > > change in interface, you'd have to tag each service that you don't care > > about shutting down separately. Which sucks. > > > > would this be as a simple as modifying chkconfig so that if there isn't > a 3rd field in the: > # chkconfig: levels start_order stop_order > > line in an initscript that it just didn't make the stop symlink? Doesn't this potentially interfere with un-mounting file systems? So we always kill -9 em? Simo. From skvidal at fedoraproject.org Mon Sep 17 18:17:44 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Sep 2007 14:17:44 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190052921.8152.17.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> <1190052921.8152.17.camel@localhost.localdomain> Message-ID: <1190053064.2602.68.camel@cutter> On Mon, 2007-09-17 at 14:15 -0400, Simo Sorce wrote: > On Mon, 2007-09-17 at 14:04 -0400, seth vidal wrote: > > On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote: > > > Jesse Keating (jkeating at redhat.com) said: > > > > I was thinking about this over the weekend. We have "shutdown" > > > > sections in services so that you can restart a service while running, > > > > however we don't necessarily have to "shut down" the services when we > > > > shut down the system. > > > > > > Right, and not doing it cuts shutdown in half. However, since it's a > > > change in interface, you'd have to tag each service that you don't care > > > about shutting down separately. Which sucks. > > > > > > > would this be as a simple as modifying chkconfig so that if there isn't > > a 3rd field in the: > > # chkconfig: levels start_order stop_order > > > > line in an initscript that it just didn't make the stop symlink? > > Doesn't this potentially interfere with un-mounting file systems? > So we always kill -9 em? I think we kill -term then we kill -9 them. But that's a lot lighter than running an init script for each. -sv From loupgaroublond at gmail.com Mon Sep 17 18:23:52 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 17 Sep 2007 14:23:52 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190037053.7686.149.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> Message-ID: <7f692fec0709171123n2d586f44j32a7ab6c6bfd6391@mail.gmail.com> On 9/17/07, Adam Jackson wrote: > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > > Not sure if this is the relevant list, but...is there any possibility > > of F8 having a graphical shutdown? Perhaps even just a non-verbose > > shutdown mode? It's just my humble opinion, but I find it looks ugly > > and breaks the experience a bit... > > We (Red Hat) haven't looked into that yet. It's certainly a fine idea > though. > > My mental model of this is that the X session just stays up until the > computer actually halts, since it's not like the X server maintains any > state that needs to get flushed to disk. You might terminate all the > other clients besides the session leader, and then throw up some > animation so the user knows things are happening. > > But that's just a guess. It would take some design first to make sure > we think through the interactions. At this stage of F8 it might be too > late to fold this in before release, but that doesn't mean we shouldn't > work on it. > > - ajax What about going down into and coming back from hibernate? -Yaakov From jkeating at redhat.com Mon Sep 17 18:29:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Sep 2007 14:29:25 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190052725.16960.13.camel@localhost6.localdomain6> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> Message-ID: <20070917142925.38636978@localhost.localdomain> On Mon, 17 Sep 2007 12:12:05 -0600 Richi Plana wrote: > If we don't necessarily have to "shut down" the service when shutting > down, do you mean that services should just do the proper thing when > sent the appropriate signal(7)? Like a uniform way of being signalled > to shut down? (an analogy would be destructors in OOP) Many of the services just simply kill the pid. The final part of a system shutdown would take care of that. The added time to run the service script and source all the functions and display words to the screen is just needless overhead. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Mon Sep 17 18:29:10 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Sep 2007 14:29:10 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917142925.38636978@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> Message-ID: <1190053750.2602.70.camel@cutter> On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote: > On Mon, 17 Sep 2007 12:12:05 -0600 > Richi Plana wrote: > > > If we don't necessarily have to "shut down" the service when shutting > > down, do you mean that services should just do the proper thing when > > sent the appropriate signal(7)? Like a uniform way of being signalled > > to shut down? (an analogy would be destructors in OOP) > > Many of the services just simply kill the pid. The final part of a > system shutdown would take care of that. The added time to run the > service script and source all the functions and display words to the > screen is just needless overhead. > As notting just pointed out to me - we do need to have the right thing happen for going to run level 1, though. -sv From ajackson at redhat.com Mon Sep 17 18:20:01 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 17 Sep 2007 14:20:01 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <7f692fec0709171123n2d586f44j32a7ab6c6bfd6391@mail.gmail.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <7f692fec0709171123n2d586f44j32a7ab6c6bfd6391@mail.gmail.com> Message-ID: <1190053201.7686.198.camel@localhost.localdomain> On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote: > On 9/17/07, Adam Jackson wrote: > > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > > > Not sure if this is the relevant list, but...is there any possibility > > > of F8 having a graphical shutdown? Perhaps even just a non-verbose > > > shutdown mode? It's just my humble opinion, but I find it looks ugly > > > and breaks the experience a bit... > > > > We (Red Hat) haven't looked into that yet. It's certainly a fine idea > > though. > > > > My mental model of this is that the X session just stays up until the > > computer actually halts, since it's not like the X server maintains any > > state that needs to get flushed to disk. You might terminate all the > > other clients besides the session leader, and then throw up some > > animation so the user knows things are happening. > > > > But that's just a guess. It would take some design first to make sure > > we think through the interactions. At this stage of F8 it might be too > > late to fold this in before release, but that doesn't mean we shouldn't > > work on it. > > What about going down into and coming back from hibernate? What about it? That's a different path. Hibernate doesn't terminate processes at all. If you mean "can we have a pretty hibernate too", then I suspect the answer is "that's hard to make X do until we have kernel modesetting". - ajax From notting at redhat.com Mon Sep 17 18:38:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Sep 2007 14:38:28 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190052280.2602.63.camel@cutter> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> Message-ID: <20070917183828.GB5018@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > would this be as a simple as modifying chkconfig so that if there isn't > a 3rd field in the: > # chkconfig: levels start_order stop_order > > line in an initscript that it just didn't make the stop symlink? Not quite that simple. S00killall will still stop started services on shutdown; moreover, you probably still want kill scripts in runlevel 1. Bill From loupgaroublond at gmail.com Mon Sep 17 18:39:47 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 17 Sep 2007 14:39:47 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190053201.7686.198.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <7f692fec0709171123n2d586f44j32a7ab6c6bfd6391@mail.gmail.com> <1190053201.7686.198.camel@localhost.localdomain> Message-ID: <7f692fec0709171139y6b451eccxf7ff3b490c004440@mail.gmail.com> On 9/17/07, Adam Jackson wrote: > On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote: > > On 9/17/07, Adam Jackson wrote: > > > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > > What about going down into and coming back from hibernate? > > What about it? That's a different path. Hibernate doesn't terminate > processes at all. > > If you mean "can we have a pretty hibernate too", then I suspect the > answer is "that's hard to make X do until we have kernel modesetting". > *cough*buntu does it. Would it be in our interests to get what ever patches they use pushed upstream? -Yaakov From myfedora at richip.dhs.org Mon Sep 17 18:52:44 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 12:52:44 -0600 Subject: Can Name=GenericName go away now, please? In-Reply-To: <46EE899C.8070908@math.unl.edu> References: <46EE899C.8070908@math.unl.edu> Message-ID: <1190055164.16960.28.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 09:05 -0500, Rex Dieter wrote: > In particular, can we/fedora consider using better menu names now, so > users know which apps are really behind some generic (and mysterious?) > items in menus(1). You know, I can't help but agreeing that the presented names need to be improved somehow. I keep stumbling over the ambiguity over and over again in various situations. The menus are one thing, but they're also presented in other things like right-clicking a nautilus icon and choosing an "Open With " option. On several occasions, I've accidentally or without thinking clicked on the wrong application option. Even though I've trained myself to "slow down" and try to find the right option because it's not readily presented, I inadvertently click on the wrong selection. Luckily it hasn't resulted in catastrophic results (clicking the wrong option doesn't result in deleted files or anything like that), but it's certainly irritating on slow machines to wait for a process to finish starting up before I can shut it down. And at that point in time when I feel irritated, I just can't help but wish that the menu option was clearer to begin with. In the course of a working day, I get up to speed and start doing things one after the other like it was second-nature to me (kind of like touch-typing) only to get tripped up by ambiguous options. For instance, looking at my Applications -> Sound & Video menu, it only takes me a fraction of a second to realize whether an application is relevant to my current context when I see the application name. Seeing two "Movie Player" options makes me pause and try to figure out which is which. Can't we do something like " " (ie. "Play Multimedia with Totem", "View Graphical Images with gimp", "Edit Graphical Images with gimp" or whatever the sequence is in other languages). Or perhaps " ()" like "Play Movies (Totem)" -- Richi Plana From myfedora at richip.dhs.org Mon Sep 17 18:58:41 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 12:58:41 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917183828.GB5018@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> <20070917183828.GB5018@nostromo.devel.redhat.com> Message-ID: <1190055521.16960.33.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote: > Not quite that simple. S00killall will still stop started services on shutdown; > moreover, you probably still want kill scripts in runlevel 1. How does the current flat setup handle possibly different shutdown-startup sequences for going to different runlevels? Do scripts go through the same shutdown sequence going from runlevel 5 to runlevel 6 as it does to runlevel 3 or 1? Sounds more like it should be handled by finite-state machine logic. -- Richi Plana From mclasen at redhat.com Mon Sep 17 19:05:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 17 Sep 2007 15:05:06 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <1190055164.16960.28.camel@localhost6.localdomain6> References: <46EE899C.8070908@math.unl.edu> <1190055164.16960.28.camel@localhost6.localdomain6> Message-ID: <1190055906.4134.21.camel@localhost.localdomain> On Mon, 2007-09-17 at 12:52 -0600, Richi Plana wrote: > > Can't we do something like " > " (ie. "Play Multimedia with Totem", "View Graphical Images > with gimp", "Edit Graphical Images with gimp" or whatever the sequence > is in other languages). Or perhaps " ()" like "Play > Movies (Totem)" Any such attempts are broken i18n-wise. The only thing that works for translation is complete strings. From myfedora at richip.dhs.org Mon Sep 17 19:04:00 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 13:04:00 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917142925.38636978@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> Message-ID: <1190055840.16960.39.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote: > On Mon, 17 Sep 2007 12:12:05 -0600 > Richi Plana wrote: > > > If we don't necessarily have to "shut down" the service when shutting > > down, do you mean that services should just do the proper thing when > > sent the appropriate signal(7)? Like a uniform way of being signalled > > to shut down? (an analogy would be destructors in OOP) > > Many of the services just simply kill the pid. The final part of a > system shutdown would take care of that. The added time to run the > service script and source all the functions and display words to the > screen is just needless overhead. Oh, so it's not the process by which services are shutdown that's at question but the implementation. Are there use-cases where feedback on service shutdown would be desired? It seems that if there were, a couple of lines of text would be minimalist. If sourcing shells and scripts has become a sticky point, then perhaps that functionality should be included in init. Which sort of brings up the topic of evaluating current init replacements (or, better yet, an init, changerunlevel, shutdown system). -- Richi Plana From notting at redhat.com Mon Sep 17 19:14:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Sep 2007 15:14:54 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190055521.16960.33.camel@localhost6.localdomain6> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> <20070917183828.GB5018@nostromo.devel.redhat.com> <1190055521.16960.33.camel@localhost6.localdomain6> Message-ID: <20070917191454.GB8848@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote: > > Not quite that simple. S00killall will still stop started services on shutdown; > > moreover, you probably still want kill scripts in runlevel 1. > > How does the current flat setup handle possibly different > shutdown-startup sequences for going to different runlevels? Not sure what you mean by this. It's pretty simple: - run all KXX scripts, in order - run all SXX scripts, in order > Do scripts > go through the same shutdown sequence going from runlevel 5 to runlevel > 6 as it does to runlevel 3 or 1? If they're set up to be killed in both, yes. Bill From notting at redhat.com Mon Sep 17 19:17:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Sep 2007 15:17:18 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190055840.16960.39.camel@localhost6.localdomain6> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> Message-ID: <20070917191718.GC8848@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > Are there use-cases where feedback on service shutdown would be desired? > It seems that if there were, a couple of lines of text would be > minimalist. > > If sourcing shells and scripts has become a sticky point, then perhaps > that functionality should be included in init. Which sort of brings up > the topic of evaluating current init replacements (or, better yet, an > init, changerunlevel, shutdown system). I'd need to benchmark some more, but I suspect the delay is because of a linear sequence of: - kill -TERM $pid - wait to see if it's dead - kill -KILL $pid for each service, as opposed to a global - kill -TERM $everything - wait a second - kill -KILL $everything Bill From myfedora at richip.dhs.org Mon Sep 17 19:25:18 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 13:25:18 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917191454.GB8848@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> <20070917183828.GB5018@nostromo.devel.redhat.com> <1190055521.16960.33.camel@localhost6.localdomain6> <20070917191454.GB8848@nostromo.devel.redhat.com> Message-ID: <1190057118.16960.49.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 15:14 -0400, Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: > > On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote: > > > Not quite that simple. S00killall will still stop started services on shutdown; > > > moreover, you probably still want kill scripts in runlevel 1. > > > > How does the current flat setup handle possibly different > > shutdown-startup sequences for going to different runlevels? > > Not sure what you mean by this. It's pretty simple: > > - run all KXX scripts, in order > - run all SXX scripts, in order > > > Do scripts > > go through the same shutdown sequence going from runlevel 5 to runlevel > > 6 as it does to runlevel 3 or 1? > > If they're set up to be killed in both, yes. Yes, that's what I wanted to know with both questions: if the current system is smart enough to know which services to shut down and what not to when changing runlevels. Just by looking at the contents of /etc/rc.d/, it just seems so flat (no hierarchy info) that it's possible to think that the system might actually be shutting down all services and restarting them in the new run-level. Which script handles this? I'm curious to know. I've only been able to trace the startup scripts but get lost when tracing init(8). -- Richi Plana From ssorce at redhat.com Mon Sep 17 19:31:17 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Sep 2007 15:31:17 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917191718.GC8848@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> Message-ID: <1190057477.8152.33.camel@localhost.localdomain> On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: > > Are there use-cases where feedback on service shutdown would be desired? > > It seems that if there were, a couple of lines of text would be > > minimalist. > > > > If sourcing shells and scripts has become a sticky point, then perhaps > > that functionality should be included in init. Which sort of brings up > > the topic of evaluating current init replacements (or, better yet, an > > init, changerunlevel, shutdown system). > > I'd need to benchmark some more, but I suspect the delay is because of > a linear sequence of: > > - kill -TERM $pid > - wait to see if it's dead > - kill -KILL $pid > > for each service, as opposed to a global > > - kill -TERM $everything > - wait a second > - kill -KILL $everything Do it with your services, don't try on mine :-) Maybe there is a way to say "me too", and " no, not me, I have to shut down cleanly", and group these process in 2 groups, for the second you wait the time it needs to. Simo. From j.w.r.degoede at hhs.nl Mon Sep 17 19:33:02 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Sep 2007 21:33:02 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort Message-ID: <46EED66E.8040009@hhs.nl> Hi All, I've been talking lately with Fernando Lopez-Lezcano from CCRMA about making Fedora a better distro for Audio Creation, mainly focusing on a plan for getting his excellent CCRMA packages integrated in to Fedora. Here is the plan we've come up with (quoting from the SIG's wiki page): "Since Fernando's time is almost fully occupied with maintaining CCRMA and keeping it up to date, the effort of the integration of CCRMA packages into Fedora will be mostly done by other Fedora Contributers. The plan is that Fedora contributers go through CCRMA packages spec files to make them fully match the Fedora Packaging Guidelines and then submit them for review and make any necessary changes to pass review. Fernando will be put in the CC of the review, and will be made co-maintainer of packages want the are imported into the Fedora Package Collection. This way the packaging expertise and manpower of the Fedora Community can be combined with the vast Audio Creation experience of Fernando. This effort will be spearheaded by Hans de Goede (me)." The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also interested in this and are willing to help out. There are a lot of CCRMA packages and we could use your help. Hence the creation of the Audio Creation SIG, where all interested contributers can join and help out. The Audio Creation SIG is further described here: http://fedoraproject.org/wiki/SIGs/AudioCreation Even more then help with checking and fixing the packages for guidelines compliance, we need people to review them, I've submitted the first 4 for review and many more will follow. So if you have some interest in Audio Creation under Fedora, please help with reviewing audio related packages, there is an continuously kept up2date list of packages needing review on the wiki page. As most of you know I'm a very experienced packager, so the reviews should go as smooth as a babies buttocks :) Thanks & Regards, Hans From myfedora at richip.dhs.org Mon Sep 17 19:37:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 13:37:06 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917191718.GC8848@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> Message-ID: <1190057827.16960.60.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote: > I'd need to benchmark some more, but I suspect the delay is because of > a linear sequence of: > > - kill -TERM $pid > - wait to see if it's dead > - kill -KILL $pid > > for each service, as opposed to a global > > - kill -TERM $everything > - wait a second > - kill -KILL $everything You're talking academically, right? Because the second scenario is never going to happen, right? The second scenario is a fixed-time scenario (1+ second) but is wrong in a couple of levels. I think we can assume that some services need to be shut down in a certain sequence if they're to be properly shut down at all. But even if we disregarded that and let the services shut down as best they can, killing all processes at the same time could result in the system thrashing at bottlenecks like harddisk access. What would the point be of comparing the two speeds, then if the "best case scenario" isn't actually useful? There are certain baseline needs that have to be satisfied before any time comparison are to be made, IMO. -- Richi Plana From nalin at redhat.com Mon Sep 17 19:42:24 2007 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 17 Sep 2007 15:42:24 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190057118.16960.49.camel@localhost6.localdomain6> References: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <20070917174927.GF337@nostromo.devel.redhat.com> <1190052280.2602.63.camel@cutter> <20070917183828.GB5018@nostromo.devel.redhat.com> <1190055521.16960.33.camel@localhost6.localdomain6> <20070917191454.GB8848@nostromo.devel.redhat.com> <1190057118.16960.49.camel@localhost6.localdomain6> Message-ID: <20070917194223.GA17266@redhat.com> On Mon, Sep 17, 2007 at 01:25:18PM -0600, Richi Plana wrote: > Yes, that's what I wanted to know with both questions: if the current > system is smart enough to know which services to shut down and what not > to when changing runlevels. Just by looking at the contents > of /etc/rc.d/, it just seems so flat (no hierarchy info) that it's > possible to think that the system might actually be shutting down all > services and restarting them in the new run-level. I think you're looking for /etc/rc, which additionally checks for the presence or absence of a /var/lock/subsys file which matches the script's name, in order to decide whether or not to skip stopping or starting the service. HTH, Nalin From myfedora at richip.dhs.org Mon Sep 17 19:46:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 13:46:26 -0600 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <46EED66E.8040009@hhs.nl> References: <46EED66E.8040009@hhs.nl> Message-ID: <1190058386.16960.67.camel@localhost6.localdomain6> How about some reference links to CCRMA on the SIG wiki, particularly the software-related ones? The SIG is called AudioCreation, but is it going to concentrate specifically on CCRMA for its lifecycle? I understand there are other audio-related Linux packaging attempts like AGNULA or any of the attempts at this page: http://linux-sound.org/distro.html On Mon, 2007-09-17 at 21:33 +0200, Hans de Goede wrote: > Hi All, > > I've been talking lately with Fernando Lopez-Lezcano from CCRMA about making > Fedora a better distro for Audio Creation, mainly focusing on a plan for > getting his excellent CCRMA packages integrated in to Fedora. > > Here is the plan we've come up with (quoting from the SIG's wiki page): > > "Since Fernando's time is almost fully occupied with maintaining CCRMA and > keeping it up to date, the effort of the integration of CCRMA packages into > Fedora will be mostly done by other Fedora Contributers. The plan is that > Fedora contributers go through CCRMA packages spec files to make them fully > match the Fedora Packaging Guidelines and then submit them for review and make > any necessary changes to pass review. Fernando will be put in the CC of the > review, and will be made co-maintainer of packages want the are imported into > the Fedora Package Collection. This way the packaging expertise and manpower of > the Fedora Community can be combined with the vast Audio Creation experience of > Fernando. This effort will be spearheaded by Hans de Goede (me)." > > The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also > interested in this and are willing to help out. There are a lot of CCRMA > packages and we could use your help. Hence the creation of the Audio Creation > SIG, where all interested contributers can join and help out. The Audio > Creation SIG is further described here: > http://fedoraproject.org/wiki/SIGs/AudioCreation > > Even more then help with checking and fixing the packages for guidelines > compliance, we need people to review them, I've submitted the first 4 for > review and many more will follow. So if you have some interest in Audio > Creation under Fedora, please help with reviewing audio related packages, there > is an continuously kept up2date list of packages needing review on the wiki > page. As most of you know I'm a very experienced packager, so the reviews > should go as smooth as a babies buttocks :) > > Thanks & Regards, > > Hans > From j.w.r.degoede at hhs.nl Mon Sep 17 19:50:10 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Sep 2007 21:50:10 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190058386.16960.67.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> Message-ID: <46EEDA72.9040706@hhs.nl> Richi Plana wrote: > How about some reference links to CCRMA on the SIG wiki, particularly > the software-related ones? > > The SIG is called AudioCreation, but is it going to concentrate > specifically on CCRMA for its lifecycle? I understand there are other > audio-related Linux packaging attempts like AGNULA > or any of the attempts at this page: > http://linux-sound.org/distro.html > Have you read the wiki? Quoting it: "The Audio Creation SIG is currently in a phase were we are concentrating on getting more audio related packages in to Fedora and specifically concentrating on getting CCRMA packages integrated into Fedora" Notice the currently in a phase, so in the future we may well do other things too, including adding packages from other repositories / package software not yet packaged. Regards, Hans From kwizart at gmail.com Mon Sep 17 19:53:21 2007 From: kwizart at gmail.com (KH KH) Date: Mon, 17 Sep 2007 21:53:21 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <46EED66E.8040009@hhs.nl> References: <46EED66E.8040009@hhs.nl> Message-ID: > The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also > interested in this and are willing to help out. There are a lot of CCRMA > packages and we could use your help. Hence the creation of the Audio Creation > SIG, where all interested contributers can join and help out. The Audio > Creation SIG is further described here: > http://fedoraproject.org/wiki/SIGs/AudioCreation > Nice! i'm interested in taking part of this effort. I have already submitted jack-rack for inclusing in https://bugzilla.redhat.com/285331, that was already a duplicate (thought not updated for a long time)... Not have time to formally contact Fernando for co-ordination I can act as a reviewer also (more from the second part on this week...) Nicolas (kwizart) > Thanks & Regards, > > Hans > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From katzj at redhat.com Mon Sep 17 19:57:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Sep 2007 15:57:33 -0400 Subject: REMINDER: Fedora 8 Test3 Freeze Message-ID: <1190059053.21026.104.camel@localhost.localdomain> The Fedora 8 Test 3 freeze is rapidly approaching! This is your last major chance for getting any bug fixes or other changes tested prior to the release of Fedora 8. The freeze date is next Tuesday, September 25. For full details of the schedule, as always, see http://fedoraproject.org/wiki/Releases/8/Schedule What does this mean? It means that it's probably a good time to go through and look through all of the bugs that are filed against your packages. And as much as possible, fixing those bugs which you deem important for Fedora 8 prior to the freeze date. Also, for tracking purposes, you might want to attach important bugs to one of the tracker bugs according to the criteria at http://fedoraproject.org/wiki/QA/ReleaseCriteria. A quick summary of the main tracking bugs are * F8Blocker (235703): This is for bugs which are very very bad. Bugs which the release team should consider slipping the release for. Note, you should not use this characterization lightly. And the final judgement on whether a bug is worth slipping the release will be made by the release team. * F8Target (235704): Bugs which are pretty important, but not slip-worthy. The release team will keep an eye on this list and would ultimately like the open bugs here to be as minimal as possible. Once we enter the freeze, changes for the test release will be approved according to the normal test freeze policy (http://fedoraproject.org/wiki/ReleaseEngineering/TestFreezePolicy). After Test3, we want to reduce the number of changes going in to help ensure that the final release has as few regressions as possible. So it's very important to get as many of the fixes as possible done prior to Test3. More complete details about the post-test3 procedure will be forthcoming as we reach that point in the schedule. Thanks for your hard work! Jeremy _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From j.w.r.degoede at hhs.nl Mon Sep 17 19:56:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Sep 2007 21:56:14 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: References: <46EED66E.8040009@hhs.nl> Message-ID: <46EEDBDE.6070800@hhs.nl> KH KH wrote: >> The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also >> interested in this and are willing to help out. There are a lot of CCRMA >> packages and we could use your help. Hence the creation of the Audio Creation >> SIG, where all interested contributers can join and help out. The Audio >> Creation SIG is further described here: >> http://fedoraproject.org/wiki/SIGs/AudioCreation >> > > Nice! i'm interested in taking part of this effort. > I have already submitted jack-rack for inclusing in > https://bugzilla.redhat.com/285331 Added to the list of packages which need to be reviewed on the wiki > I can act as a reviewer also (more from the second part on this week...) Good, welcome aboard! Regards, Hans p.s. Any progress with z88? From myfedora at richip.dhs.org Mon Sep 17 20:06:46 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 14:06:46 -0600 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <46EEDA72.9040706@hhs.nl> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> Message-ID: <1190059606.16960.79.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 21:50 +0200, Hans de Goede wrote: > Richi Plana wrote: > > How about some reference links to CCRMA on the SIG wiki, particularly > > the software-related ones? > > > > The SIG is called AudioCreation, but is it going to concentrate > > specifically on CCRMA for its lifecycle? I understand there are other > > audio-related Linux packaging attempts like AGNULA > > or any of the attempts at this page: > > http://linux-sound.org/distro.html > > > > Have you read the wiki? Quoting it: "The Audio Creation SIG is currently in a > phase were we are concentrating on getting more audio related packages in to > Fedora and specifically concentrating on getting CCRMA packages integrated into > Fedora" Yes, I read the page and the particular line in the page "concentrating on getting CCRMA packages integrated" (in fact, the line you qutoed is on your announcement, as well) is what has me confused. That's why I'm trying to clarify. Is the SIG specifically about CCRMA only or is it "AudioCreation" in general? > Notice the currently in a phase, so in the future we may well do other things > too, including adding packages from other repositories / package software not > yet packaged. And that's the answer to my question. Now for the reason that I asked: If it was going to be CCRMA-specific (and really there's nothing wrong with that IMO), then perhaps a change of SIG title would best reflect it. If it's going to be general like you just stated, then I was going to suggest putting links to other endeavors, if not now then maybe later. That's merely a suggestion that no one is obliged to do. But I suggest it so that if there's any way the good work on these various projects can be combined in one solution, then it would be best to look at them all now. If people are going to take the time to help getting CCRMA integrated into Fedora, they're not going to get thrown off or confused just by seeing what else is out there. Best of luck to the SIG. I'd like to see this succeed and am offering my help in packaging other CCRMA software. I'll assume that coordinating the efforts will be done on the fedora-music-list. -- Richi Plana From j.w.r.degoede at hhs.nl Mon Sep 17 20:20:31 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Sep 2007 22:20:31 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190059606.16960.79.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> Message-ID: <46EEE18F.3070503@hhs.nl> Richi Plana wrote: > Best of luck to the SIG. I'd like to see this succeed and am offering my > help in packaging other CCRMA software. I'll assume that coordinating > the efforts will be done on the fedora-music-list. Very gald to hear you want to help out! Coordination of packaging efforts will mainly be done through the wiki, through the packages needing review list. If it isn't on the list and it isn't in Fedora yet, it is still looking for a packager. Coordination of other issues will be done through the list. Regards, Hans From j.w.r.degoede at hhs.nl Mon Sep 17 20:20:45 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 17 Sep 2007 22:20:45 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190059606.16960.79.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> Message-ID: <46EEE19D.5010609@hhs.nl> Richi Plana wrote: > Best of luck to the SIG. I'd like to see this succeed and am offering my > help in packaging other CCRMA software. I'll assume that coordinating > the efforts will be done on the fedora-music-list. Very glad to hear you want to help out! Coordination of packaging efforts will mainly be done through the wiki, through the packages needing review list. If it isn't on the list and it isn't in Fedora yet, it is still looking for a packager. Coordination of other issues will be done through the list. Regards, Hans From jon.nettleton at gmail.com Mon Sep 17 20:50:15 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 17 Sep 2007 16:50:15 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190037053.7686.149.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> Message-ID: On 9/17/07, Adam Jackson wrote: > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote: > > Not sure if this is the relevant list, but...is there any possibility > > of F8 having a graphical shutdown? Perhaps even just a non-verbose > > shutdown mode? It's just my humble opinion, but I find it looks ugly > > and breaks the experience a bit... > > We (Red Hat) haven't looked into that yet. It's certainly a fine idea > though. > > My mental model of this is that the X session just stays up until the > computer actually halts, since it's not like the X server maintains any > state that needs to get flushed to disk. You might terminate all the > other clients besides the session leader, and then throw up some > animation so the user knows things are happening. > > But that's just a guess. It would take some design first to make sure > we think through the interactions. At this stage of F8 it might be too > late to fold this in before release, but that doesn't mean we shouldn't > work on it. > Using my early-gdm scripts, X and gdm are already running their sockets from a tmpfs. It would be trivial to reverse what I do on bootup for shutdown and unmount everything from underneath X and gdm. When the machine completely shutsdown *poof* tmpfs is gone and there are no ugly sockets or temp files left to cleanup on boot. I have been playing with this on the side to allow filesystems to do their maintenance fsck's on shutdown instead of bootup. This gives you more control over whether you have the time to wait on the maintenance or not. Jon From notting at redhat.com Mon Sep 17 21:00:05 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Sep 2007 17:00:05 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190057827.16960.60.camel@localhost6.localdomain6> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057827.16960.60.camel@localhost6.localdomain6> Message-ID: <20070917210005.GJ337@nostromo.devel.redhat.com> Richi Plana (myfedora at richip.dhs.org) said: > > - kill -TERM $pid > > - wait to see if it's dead > > - kill -KILL $pid > > > > for each service, as opposed to a global > > > > - kill -TERM $everything > > - wait a second > > - kill -KILL $everything > > You're talking academically, right? Because the second scenario is never > going to happen, right? Only somewhat. Did some testing a while back, set up everything that didn't need controlled shut down to just be killed. It cut shutdown time in half (13 seconds instead of 26, IIRC). Bill From kevin at scrye.com Mon Sep 17 22:19:37 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 17 Sep 2007 16:19:37 -0600 Subject: source file audit - 2007-09-17 Message-ID: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> Here's attached another run of my sources/patches url checker. Changes from the last run: - There is now a blacklist of packages where maintainers have told me the check isn't usefull. (non versioned upstream, wget blacklisted from getting files, needs login/license agreement to download, etc). - There are 620 lines in this run, verses 700 in the last run, so progress seems to be happening. - Should I keep running this? Do folks find it useful? - Should I try and spam maintainers? Or just keep posting in the list? You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20070917.txt And also attached to this mail. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. kevin -- abompard:BADURL:glest_source_2.0.1.zip:glest aconway:BADSOURCE:qpidc-0.2.tar.gz:qpidc aconway:BADURL:rhm-0.1.tar.gz:rhm adalloz:BADURL:pan-0.132.tar.bz2:pan addutko:BAD_CVS_SOURCE:mrxvt.desktop:mrxvt addutko:BADSOURCE:mrxvt-0.5.2.tar.gz:mrxvt adrian:BADURL:jabberd-2.0s11.tar.gz:jabberd afb:BADURL:slim-1.3.0.tar.gz:slim alexl:BADURL:gmime-2.2.10.tar.bz2:gmime alexl:BADURL:gnome-keyring-manager-2.19.92.tar.bz2:gnome-keyring-manager alexl:BADURL:gnome-vfs-2.19.91.tar.bz2:gnome-vfs2 alexl:BADURL:sabayon-2.19.2.tar.bz2:sabayon alexl:BADURL:xdg-user-dirs-0.9.tar.gz:xdg-user-dirs ascii:BADURL:fish-1.22.3.tar.bz2:fish athimm:BADSOURCE:po4a-0.32.tar.gz:po4a athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:fakeroot_1.6.4.tar.gz:fakeroot athimm:BADURL:freenx-0.7.0.tar.gz:freenx athimm:BADURL:greylistd_0.8.3.2.tar.gz:greylistd athimm:BADURL:nxagent-2.1.0-18.tar.gz:nx athimm:BADURL:nxcomp-2.1.0-7.tar.gz:nx athimm:BADURL:nxcompext-2.1.0-5.tar.gz:nx athimm:BADURL:nxdesktop-2.1.0-10.tar.gz:nx athimm:BADURL:nxproxy-2.1.0-3.tar.gz:nx athimm:BADURL:nxscripts-2.1.0-5.tar.gz:nx athimm:BADURL:nxviewer-2.1.0-12.tar.gz:nx athimm:BADURL:nx-X11-2.1.0-3.tar.gz:nx atkac:BAD_CVS_SOURCE:dnszone.schema:bind atkac:BADURL:bind-9.5.0a6.tar.gz:bind atkac:BADURL:rexec-1.5.tar.gz:rsh atkac:BADURL:vnc-4_1_2-unixsrc.tar.gz:vnc atkac:BADURL:vnc-4_1-javasrc.tar.gz:vnc atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools awjb:BADURL:atitvout_0.4-2.diff.gz:atitvout awjb:BADURL:libetpan-0.52.tar.gz:libetpan awjb:BADURL:treecc-0.3.8.tar.gz:treecc awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker behdad:BADURL:libao-0.8.6.tar.gz:libao behdad:BADURL:vorbis-tools-1.1.1.svn20070412.tar.gz:vorbis-tools belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa belegdol:BADURL:gchempaint-0.8.2.tar.bz2:gchempaint belegdol:BADURL:gnome-chemistry-utils-0.8.2.tar.bz2:gnome-chemistry-utils belegdol:BADURL:goffice-0.4.2.tar.bz2:goffice04 ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup bjohnson:BADSOURCE:queuegraph.tar.gz:queuegraph bjohnson:BADURL:mailgraph-1.13.tar.gz:mailgraph bjohnson:BADURL:pygoocanvas-0.9.0.tar.gz:pygoocanvas bojan:BADURL:libapreq2-2.09.tar.gz:libapreq2 bos:BADSOURCE:ghc-6.6.1-src.tar.bz2:ghc bpeck:BADURL:conmux-493svn.tar.gz:conmux bpepple:BADSOURCE:evolution-brutus-1.1.28.7.tar.gz:evolution-brutus bpepple:BADURL:freeciv-2.0.9.tar.bz2:freeciv bpepple:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago bpepple:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog bpepple:BADURL:gnonlin-0.10.9.tar.bz2:gnonlin bpepple:BADURL:loudmouth-1.2.3.tar.bz2:loudmouth bpepple:BADURL:stdsounds3.tar.gz:freeciv caillon:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice caolanm:BADURL:alt-myspell-pl-20070903.tar.bz2:hunspell-pl caolanm:BADURL:evolocal.odb:openoffice.org cbalint:BADURL:grass-6.2.2-fedora.tar.gz:grass cbalint:BADURL:libgeotiff-1.2.4RC1.tar.gz:libgeotiff cchance:BADURL:nhpf-1.42.tar.gz:nhpf cgrau:BADURL:frotz-2.43.tar.gz:frotz cgrau:BADURL:ifm-5.1.tar.gz:ifm chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project chitlesh:BADSOURCE:gdsto3d-20070815.tar.bz2:gds2pov chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome chitlesh:BADURL:13969-crystal-1.0.5.tar.bz2:crystal chitlesh:BADURL:26521-kio_resources-0.2.tar.bz2:kio_resources chitlesh:BADURL:31025-kmenu-gnome-0.6.8.tar.gz:kmenu-gnome chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear chitlesh:BADURL:geda-docs-1.2.0.tar.gz:geda-docs chitlesh:BADURL:geda-examples-1.2.0.tar.gz:geda-examples chitlesh:BADURL:geda-gattrib-1.2.0.tar.gz:geda-gattrib chitlesh:BADURL:geda-gnetlist-1.2.0.tar.gz:geda-gnetlist chitlesh:BADURL:geda-gschem-1.2.0.tar.gz:geda-gschem chitlesh:BADURL:geda-gsymcheck-1.2.0.tar.gz:geda-gsymcheck chitlesh:BADURL:geda-symbols-1.2.0.tar.gz:geda-symbols chitlesh:BADURL:geda-utils-1.2.0.tar.gz:geda-utils chitlesh:BADURL:guile-1.6.7.tar.gz:compat-guile-16 chitlesh:BADURL:keurocalc-0.9.7.tgz:keurocalc chitlesh:BADURL:ktechlab-0.3.69.tar.bz2:ktechlab chitlesh:BADURL:libgeda-1.2.0.tar.gz:libgeda chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito chrisw:BADURL:asciidoc-8.2.2.tar.gz:asciidoc clumens:BADURL:rhpxl-0.49.tar.gz:rhpxl coldwell:BADURL:emacs-22.1.tar.gz:emacs corsepiu:BADURL:lib3ds-1.2.0.tar.gz:lib3ds corsepiu:BADURL:OpenSceneGraph-2.0.zip:OpenSceneGraph cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym cweyl:BADURL:POE-0.9989.tar.gz:perl-POE cweyl:BADURL:POE-Filter-Zlib-1.8.tar.gz:perl-POE-Filter-Zlib cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym cweyl:BADURL:WWW-Myspace-0.60.tar.gz:perl-WWW-Myspace cwickert:BADURL:gnome-ppp-0.3.23.tar.bz2:gnome-ppp cwickert:BADURL:xfce4-minicmd-plugin-0.4.tar.bz2:xfce4-minicmd-plugin danielm:BADURL:initng-ifiles-0.1.4.tar.bz2:initng-ifiles davidz:BADSOURCE:gnome-speech-0.4.16.tar.bz2:gnome-speech davidz:BADURL:dbus-glib-0.73.tar.gz:dbus-glib davidz:BADURL:dbus-python-0.82.0.tar.gz:dbus-python davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival davidz:BADURL:tsclient-0.150.tar.gz:tsclient dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator dbhole:BADURL:lucene-1.9.1-src.tar.gz:lucene dcantrel:BADURL:dhcp-0.10.tgz:dhcpv6 dcantrel:BADURL:ps3pf_utils-1.0.9.tar.bz2:ppc64-utils dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound dcbw:BADURL:plague-0.4.4.1.tar.bz2:plague dchen:BADSOURCE:scim-array-0.0.2.tar.gz:scim-array dchen:BADURL:man-pages-es-1.28.tar.bz2:man-pages-es dchen:BADURL:man-pages-it-0.3.0.tar.gz:man-pages-it deji:BADSOURCE:gnomescan-0.4.0.2.tar.gz:gnomescan denis:BADURL:gimmage-0.2.3.tar.gz:gimmage denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ denis:BADURL:pam_keyring-0.0.9.tar.gz:pam_keyring denis:BADURL:soundconverter-0.9.7.tar.gz:soundconverter devrim:BADSOURCE:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin devrim:BADSOURCE:phpPgAdmin-4.1.3.tar.bz2:phpPgAdmin dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja dionysos:BADURL:eurofont.tar.gz:tetex-eurofont dionysos:BADURL:kbackup-0.5.2.tar.bz2:kbackup dwalsh:BADSOURCE:selinux-doc-1.26.tgz:selinux-doc dwalsh:BADURL:checkpolicy-2.0.3.tgz:checkpolicy dwalsh:BADURL:libselinux-2.0.33.tgz:libselinux dwalsh:BADURL:libsemanage-2.0.6.tgz:libsemanage dwalsh:BADURL:libsepol-2.0.9.tgz:libsepol dwalsh:BADURL:mcstrans-0.2.6.tgz:mcstrans dwalsh:BADURL:policycoreutils-2.0.25.tgz:policycoreutils dwalsh:BADURL:sepolgen-1.0.10.tgz:policycoreutils dwmw2:BADSOURCE:petitboot-0.0.1.tar.gz:petitboot dwmw2:BADURL:apmud-1.0.0.tgz:apmud dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot dwmw2:BADURL:nano-2.0.6.tar.gz:nano ecik:BADURL:dcopexport-0.11.1-20060320-0.5.0-svn.tar.bz2:kadu ecik:BADURL:kadu-profiles-0.1.tar.gz:kadu ecik:BADURL:sonata-1.2.3.tar.bz2:sonata ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder ensc:BADURL:hunt-1.5.tgz:hunt ensc:BADURL:libextractor-0.5.18a.tar.gz.sig:libextractor errr:BADSOURCE:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg faucamp:BADURL:12956-knemo-0.4.7.tar.bz2:knemo faucamp:BADURL:dekorator-0.3.tar.gz:dekorator fche:BADURL:systemtap-0.5.14.tar.gz:systemtap fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail frankb:BAD_CVS_SOURCE:nasd.init:nas frankb:BADSOURCE:qsa-x11-opensource-1.2.2.tar.gz:qt4-qsa gajownik:BADURL:29153-yakuake-2.7.5.tar.bz2:yakuake gemi:BADSOURCE:curry-0.9.11.tar.gz:curry gemi:BADSOURCE:HTMLmanual.tar.gz:pl gemi:BADSOURCE:userguide.html.tgz:pl gemi:BADURL:GtkAda-gpl-2.8.0.tgz:GtkAda gemi:BADURL:plt-371-src-unix.tgz:plt-scheme gemi:BADURL:skencil-0.6.tar.gz:skencil gemi:BADURL:sweep-0.9.2.tar.bz2:sweep gemi:BADURL:wingspov-0.98.28_v1.tgz:wings ghenry:BADURL:pgadmin3-1.6.3.tar.gz:pgadmin3 gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm hadess:BADURL:gnome-audio-2.0.0.tar.bz2:gnome-audio hadess:BADURL:gnome-media-2.19.92.tar.gz:gnome-media hadess:BADURL:rhythmbox-0.11.2.tar.bz2:rhythmbox hadess:BADURL:speex-1.2beta1.tar.gz:speex hadess:BADURL:totem-2.19.90.tar.bz2:totem iburrell:BADURL:File-chdir-0.06.tar.gz:perl-File-chdir iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class icon:BADURL:diction-1.10-rc4.tar.gz:diction icon:BADURL:gazpacho-0.7.2.tar.bz2:gazpacho icon:BADURL:kid-0.9.6.tar.gz:python-kid icon:BADURL:libxml++-2.18.2.tar.bz2:libxml++ icon:BADURL:repoview-0.6.0.tar.gz:repoview icon:BADURL:verbiste-0.1.21.tar.gz:verbiste ixs:BADSOURCE:dd_rhelp-0.0.6.tar.gz:dd_rescue ixs:BADSOURCE:GraphicsMagick-1.1.8.tar.bz2:GraphicsMagick ixs:BADURL:hevea-1.09.tar.gz:hevea ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel jakub:BADURL:prelink-20061201.tar.bz2:prelink jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen jamatos:BADURL:pygsl-0.9.1.tar.gz:pygsl jamatos:BADURL:rpy-1.0-RC3.tar.gz:rpy jbowes:BADSOURCE:tig-0.8.tar.gz:tig jcollie:BADURL:libosip-0.9.7.tar.gz:libosip jcollie:BADURL:pitivi-0.10.3.tar.bz2:pitivi jcollie:BADURL:radiusclient-ng-0.5.6.tar.gz:radiusclient-ng jcollie:BADURL:schroedinger-0.6.1.tar.gz:schroedinger jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2 jima:BAD_CVS_SOURCE:dnsmasq-2.33-initscript.patch:dnsmasq jima:BADSOURCE:clusterssh-3.19.1.tar.gz:clusterssh jima:BADURL:dnsmasq-2.40rc2.tar.gz:dnsmasq jjohnstn:BADURL:eclipse-changelog-src-2.5.1.zip:eclipse-changelog jkeating:BADURL:cleanfeed-0.95.7b.tar.gz:cleanfeed jkeating:BADURL:mock-0.7.6.tar.gz:mock jkeating:BADURL:pungi-1.0.2.tar.gz:pungi jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate jlayton:BADURL:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist jmoskovc:BADSOURCE:hexedit-1.2.12.src.tgz:hexedit jmoskovc:BADURL:acl_2.2.39-1.tar.gz:acl jmoskovc:BADURL:openobex-1.3.tar.gz:openobex jmoskovc:BADURL:rdate-1.4.tar.gz:rdate jmrcpn:BADURL:clement-2.1-241.tar.gz:clement jnovy:BADSOURCE:db-4.2.52.tar.gz:compat-db jnovy:BADSOURCE:db-4.3.29.tar.gz:compat-db jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:tetex jnovy:BADURL:mc-2007-06-04-22.tar.gz:mc jnovy:BADURL:mendexk2.6d.tar.bz2:tetex jnovy:BADURL:platex209.tar.bz2:tetex jnovy:BADURL:ptex-src-3.1.9.tar.bz2:tetex jnovy:BADURL:ptex-texmf-2.4.tar.bz2:tetex jnovy:BADURL:tetex-src-3.0.tar.bz2:tetex jnovy:BADURL:tetex-texmf-3.0.tar.bz2:tetex jorge:BADSOURCE:mimetex.zip:mimetex jorton:BADURL:imap-2004g.tar.Z:libc-client jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx jpo:BADURL:AppConfig-1.65.tar.gz:perl-AppConfig jpo:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles jpo:BADURL:Email-Simple-1.999.tar.gz:perl-Email-Simple jpo:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record jpo:BADURL:SNMP_Session-1.08.tar.gz:perl-SNMP_Session jpo:BADURL:Test-Exception-0.21.tar.gz:perl-Test-Exception jpo:BADURL:Test-File-1.16.tar.gz:perl-Test-File jpo:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa jspaleta:BADURL:gpodder-0.9.5.tar.gz:gpodder jspaleta:BADURL:istanbul-0.2.2.tar.bz2:istanbul jsteffan:BADURL:revisor-2.0.4.3.tar.gz:revisor jwb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard jwb:BADSOURCE:blacklists.tar.gz:squidGuard jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt jwilson:BADURL:conman-0.1.9.2.tar.bz2:conman jwilson:BADURL:powerman-1.0.25.tar.bz2:powerman jwrdegoede:BADSOURCE:BASS-Floppy.zip:beneath-a-steel-sky jwrdegoede:BADSOURCE:njam-1.25-src.tar.gz:njam jwrdegoede:BADURL:supertuxkart-0.3-src.tar.bz2:supertuxkart kaboom:BADURL:fping-2.4b2_to-ipv6.tar.gz:fping karsten:BADURL:automake-1.5.tar.bz2:automake15 karsten:BADURL:hdparm-7.7.tar.gz:hdparm karsten:BADURL:privoxy-3.0.6-stable-src.tar.gz:privoxy kasal:BADURL:libvte-java-0.12.1.tar.bz2:libvte-java kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf krh:BADURL:evince-2.19.92.tar.bz2:evince kwizart:BADURL:zd1211rw_fw_2007-03-19.tar.bz2:zd1211-firmware kzak:BADURL:lslk_1.29_W.tar.gz:lslk kzak:BADURL:util-linux-2.13-pre7.tar.bz2:util-linux kzak:BADURL:vlock-1.3.tar.gz:vlock leo:BADURL:pcmanx-gtk2.tar.gz:pcmanx-gtk2 limb:BADSOURCE:tiquit-2.4.tar.gz:tiquit limb:BADSOURCE:xmoto-edit.6.gz:xmoto-edit limb:BADURL:netpanzer-0.8.2.tar.bz2:netpanzer liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak lkundrak:BADSOURCE:c2070-0.99.tar.gz:c2070 llim:BAD_CVS_SOURCE:lsb-release-2.0.tar.gz:redhat-lsb lmacken:BADURL:deskbar-applet-2.19.90.1.tar.bz2:deskbar-applet lmacken:BADURL:Myghty-1.1.tar.gz:python-myghty lmacken:BADURL:naim-0.11.8.3.1.tar.bz2:naim lmacken:BADURL:RuleDispatch-0.5a0.dev-r2306.tar.gz:python-ruledispatch lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears lmacken:BADURL:valknut-0.3.10.tar.bz2:valknut lutter:BADSOURCE:activesupport-1.4.0.tgz:ruby-activesupport luya:BADURL:gDesklets-0.35.4.tar.bz2:gdesklets lvm-team:BADURL:dmraid-1.0.0.rc14.tar.bz2:dmraid maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine mbacovsk:BAD_CVS_SOURCE:FAQ.sgml:squid mbacovsk:BADURL:psutils-p17.tar.gz:psutils mbacovsk:BADURL:traceroute-2.0.7.tag.gz:traceroute mbarabas:BADSOURCE:system-config-vsftpd-0.4.5.tar.gz:system-config-vsftpd mbarabas:BADURL:lftp-3.5.10.tar.gz:lftp mbarnes:BADURL:rarian-0.6.0.tar.bz2:rarian mclasen:BADURL:fast-user-switch-applet-2.18.0.tar.bz2:fast-user-switch-applet mclasen:BADURL:glade-2.12.1.tar.bz2:glade2 mclasen:BADURL:glib-2.14.0.tar.bz2:glib2 mclasen:BADURL:gtk+-2.12.0.tar.bz2:gtk2 mclasen:BADURL:intltool-0.36.1.tar.bz2:intltool mclasen:BADURL:libgail-gnome-1.19.5.tar.bz2:libgail-gnome mclasen:BADURL:libgnomekbd-2.19.91.tar.bz2:libgnomekbd mclasen:BADURL:libIDL-0.8.8.tar.bz2:libIDL mclasen:BADURL:ORBit2-2.14.7.tar.bz2:ORBit2 mdomsch:BADSOURCE:signing-party_0.4.9.orig.tar.gz:pgp-tools mebourne:BADSOURCE:ZoneMinder-1.22.3.tar.gz:zoneminder meme:BADURL:vultures-2.1.0-full.tar.bz2:nethack-vultures mgarski:BADURL:digikam-doc-0.9.2-beta2.tar.bz2:digikam-doc mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV misa:BADURL:pyOpenSSL-0.6.tar.gz:pyOpenSSL mlichvar:BADURL:ncurses-5.5-20060701.patch.gz:termcap mlichvar:BADURL:ncurses-5.5.tar.gz:termcap mlichvar:BADURL:patch-5.5-20060625.sh.gz:termcap mlichvar:BADURL:readline-5.2.tar.gz:readline mlichvar:BADURL:termcap-2.0.8.tar.bz2:libtermcap mmaslano:BADSOURCE:mansupfr.tar.bz2:man-pages-fr mmaslano:BADURL:iptraf-3.0.0.tar.gz:iptraf mmcgrath:BADURL:phpMyAdmin-2.11.0-all-languages.tar.bz2:phpMyAdmin mmcgrath:BADURL:SOAP-Lite-0.68.tar.gz:perl-SOAP-Lite mtasaka:BADSOURCE:manedit-0.8.1.tar.bz2:manedit mtasaka:BADURL:jd-1.9.6-svn1335.tgz:jd mtasaka:BADURL:ruby-bsearch-1.5.tar.gz:ruby-bsearch mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler nalin:BADSOURCE:pam_ldap-184.tar.gz:nss_ldap nalin:BADURL:nss_db-2.2.tar.gz:nss_db nhorman:BADURL:cscope-15.5.tar.gz:cscope nigelj:BADURL:britepno.pat.bz2:timidity++ nigelj:BADURL:cvsutils-0.2.3.tar.gz:cvsutils nigelj:BADURL:instruments.tar.bz2:timidity++ nigelj:BADURL:pistol.pat.bz2:timidity++ nigelj:BADURL:TiMidity++-2.13.2.tar.bz2:timidity++ nim:BADURL:dejavu-sfd-2.19.tar.bz2:dejavu-fonts nomis80:BADURL:camstream-0.26.3.tar.gz:camstream notting:BADSOURCE:Maelstrom-3.0.6.tar.gz:Maelstrom notting:BADURL:Finance-Quote-1.13.tar.gz:perl-Finance-Quote nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp oddsocks:BADSOURCE:fuse-0.8.0.1.tar.gz:fuse-emulator oddsocks:BADSOURCE:kcometen3-1.1.tar.gz:kcometen3 oddsocks:BADURL:cbios-0.21.zip:cbios oddsocks:BADURL:kdetv-0.8.9.tar.bz2:kdetv odvorace:BADURL:gdbm-1.8.0.tar.gz:gdbm odvorace:BADURL:netkit-bootparamd-0.17-pre20000412.tar.gz:bootparamd ondrejj:BADURL:micq-0.5.4.2.tgz:micq orion:BADURL:4.2r1-hrepack-p4.tar.gz:hdf orion:BADURL:gdl-0.9pre5.tar.gz:gdl orion:BADURL:paraview-3.0.2.tar.gz:paraview orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins orphan:BADSOURCE:gurlchecker-0.10.0.tar.gz:gurlchecker orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script otaylor:BADURL:mugshot-1.1.52.tar.gz:mugshot ovasik:BADURL:docbook-utils-0.6.14.tar.gz:docbook-utils ovasik:BADURL:gnome-bluetooth-0.9.1.tar.bz2:gnome-bluetooth ovasik:BADURL:libbtctl-0.9.0.tar.bz2:libbtctl ovasik:BADURL:passivetex-1.25.zip:passivetex ovasik:BADURL:xmltex-1.9.tar.gz:xmltex ovasik:BADURL:xmlto-0.0.18.tar.bz2:xmlto owentl:BADURL:Calendar-0.41.tar.gz:gdesklets-calendar owentl:BADURL:GoodWeather-0.3.tar.gz:gdesklets-goodweather pcheung:BADURL:asm-2.1.tar.gz:asm2 peter:BADSOURCE:rlog-1.3.7.tgz:rlog petersen:BADSOURCE:scim-1.4.7.tar.gz:scim petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk pfj:BADURL:CastPodder-5.0.tar.bz2:CastPodder pfj:BADURL:db4o-6.1-mono.tar.gz:db4o pfj:BADURL:gtksourceview-sharp-2.0-0.10.tar.gz:gtksourceview-sharp pfj:BADURL:ikvm-0.22.tar.gz:ikvm pfrields:BADURL:nautilus-open-terminal-0.8.tar.gz:nautilus-open-terminal pgordon:BADURL:Clearlooks-Big_Pack-0.6.x.tar.gz:gnome-theme-clearlooks-bigpack pgordon:BADURL:deluge-0.5.5.tar.gz:deluge pgordon:BADURL:libtorrent-0.12.tar.gz:rb_libtorrent pjones:BADSOURCE:cdparanoia-III-alpha9.8.src.tgz:cdparanoia pjones:BADURL:syslinux-3.36.tar.bz2:syslinux pknirsch:BADSOURCE:ipmitool-1.8.9.tar.gz:OpenIPMI pknirsch:BADURL:sg3_utils-1.23.tgz:sg3_utils pmachata:BADURL:ElectricFence-2.2.2.tar.gz:ElectricFence pmachata:BADURL:flex-2.5.4a.tar.gz:compat-flex pmachata:BADURL:genromfs-0.5.1.tar.gz:genromfs pnemade:BADURL:scim-sinhala-trans-0.2.0-20060825.tar.gz:scim-sinhala pvrabec:BADURL:rsyslog-1.19.2.tar.gz:rsyslog pvrabec:BADURL:shadow-4.0.18.1.tar.bz2:shadow-utils pwouters:BADURL:ks3switch-0.1.tar.gz:ks3switch qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas qspencer:BADURL:lilypond-2.10.29.tar.gz:lilypond rafalzaq:BADSOURCE:glob2-0.9.1.tar.gz:glob2 rathann:BADURL:crm114-20070301-BlameBaltar.no-TRE.src.tar.bz2:crm114 rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2 rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview rdieter:BADURL:30375-akode-2.0.1.tar.bz2:akode rdieter:BADURL:fltk-1.1.x-r5750.tar.bz2:fltk rdieter:BADURL:gen_python_api_20050605.tar.gz:eric rdieter:BADURL:gen_sip_api_20060711.tar.gz:eric rdieter:BADURL:kmymoney2-0.8.7.tar.gz:kmymoney2 rdieter:BADURL:libofa-0.9.3.tar.gz:libofa rdieter:BADURL:macref.pdf:maxima rdieter:BADURL:mtextralic.htm:mathml-fonts rdieter:BADURL:PyQt-x11-gpl-3.17.1.tar.gz:PyQt-qscintilla rjones:BADURL:pcre-ocaml-5.11.4.tar.gz:ocaml-pcre rmeggins:BADSOURCE:mozldap-6.0.4.tar.gz:mozldap rmeggins:BADURL:adminutil-1.1.4.tar.bz2:adminutil rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP rnorwood:BADURL:IO-Zlib-1.04.tar.gz:perl-IO-Zlib rnorwood:BADURL:XML-Grove-0.46alpha.tar.bz2:perl-XML-Grove robert:BADSOURCE:magickwand-0.1.8.tar.gz:php-magickwand robmv:BADURL:kanatest-0.4.2.tar.gz:kanatest robmv:BADURL:org.tmatesoft.svn_1.1.0.beta4.src.zip:javasvn rrelyea:BADSOURCE:ccid-1.2.1.tar.gz:ccid rrelyea:BADSOURCE:pcsc-lite-1.3.3.tar.gz:pcsc-lite rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 rstrode:BADURL:bug-buddy-2.19.91.svn20070904.tar.bz2:bug-buddy rstrode:BADURL:gnome-applets-2.19.91.tar.bz2:gnome-applets rstrode:BADURL:gnome-utils-2.19.92.tar.bz2:gnome-utils rstrode:BADURL:libxklavier-3.3.tar.gz:libxklavier ruben:BADURL:Pound-2.4d.tgz:Pound rvinyard:BADSOURCE:IEEEtran.zip:tetex-IEEEtran rvokal:BADURL:gaim-guifications-2.13beta6.tar.bz2:gaim-guifications rvokal:BADURL:wireshark-0.99.6.tar.gz:wireshark ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender s4504kr:BADURL:lightning-1.2.tar.gz:lightning s4504kr:BADURL:luma-2.3.tar.bz2:luma s4504kr:BADURL:stellarium_user_guide-0.9.0-1.pdf:stellarium s4504kr:BADURL:suck-4.3.2.tar.gz:suck sandeen:BADURL:blktrace-git-20070730162628.tar.gz:blktrace schmidtw:BADURL:dfu-programmer-0.4.3.tar.gz:dfu-programmer sconklin:BADURL:db-4.5.20.tar.gz:cyrus-sasl sconklin:BADURL:ipsec-tools-0.7.tar.bz2:ipsec-tools sconklin:BADURL:netlabel_tools-0.17.tar.gz:netlabel_tools scop:BADURL:pscan_1.2-5.diff.gz:pscan scop:BADURL:pscan.tar.gz:pscan sergiopr:BADSOURCE:wcstools-3.7.0.tar.gz:wcstools shahms:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols sharkcz:BADURL:qgit-1.5.7.tar.bz2:qgit sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod sheltren:BADURL:fortune-tao.tar.gz:fortune-mod sheltren:BADURL:osfortune.tar.gz:fortune-mod simo:BADURL:rsync-2.6.9.tar.gz:rsync simo:BADURL:samba-3.0.26a.tar.gz:samba sindrepb:BADSOURCE:avant-window-navigator-0.1.1.tar.gz:avant-window-navigator sindrepb:BADURL:DBIx-SQLite-Simple-0.34.tar.gz:perl-DBIx-SQLite-Simple skvidal:BADURL:seahorse-1.0.1.tar.gz:seahorse smccann:BAD_CVS_SOURCE:proj.copyright:proj smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib snecker:BADURL:jokosher-1.0.tar.gz:jokosher snirkel:BADURL:njb-sharp-0.3.0.tar.bz2:njb-sharp splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm splinux:BADURL:pessulus-2.16.2.tar.bz2:pessulus spot:BADURL:Class-Data-Inheritable-0.06.tar.gz:perl-Class-Data-Inheritable spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg spot:BADURL:gambas-1.0.19.tar.bz2:gambas spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI spot:BADURL:rx-1.5.tar.bz2:librx spot:BADURL:user.ps.gz:lout ssp:BADURL:libXinerama-1.0.2.tar.bz2:libXinerama ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile stahnma:BADSOURCE:pastebin.tar.gz:pastebin steve:BADURL:eperl_2.2.14-13.diff.gz:perl-eperl steved:BADURL:nfs.doc.tar.gz:nfs-utils steved:BADURL:quota-3.14.tar.gz:quota stingray:BADURL:conntrack-1.00beta2.tar.bz2:conntrack stingray:BADURL:roundup-1.3.3.tar.gz:roundup stransky:BADURL:awesfx-0.5.0d.tar.gz:awesfx stransky:BADURL:gu11-rom.zip:awesfx tagoh:BADURL:alt-cannadic-070805.tar.bz2:anthy tagoh:BADURL:anthy-9100.tar.gz:anthy tagoh:BADURL:Canna37p3.tar.bz2:Canna tagoh:BADURL:im-chooser-0.5.1.tar.gz:im-chooser tagoh:BADURL:k14-oldkanji.tar.gz:fonts-japanese tagoh:BADURL:knm_new.tar.gz:fonts-japanese tagoh:BADURL:mew-5.2.50.tar.gz:mew tagoh:BADURL:mplus_bitmap_fonts-2.2.4.tar.gz:fonts-japanese tagoh:BADURL:nkf207.tar.gz:nkf tagoh:BADURL:ruby-refm-rdp-1.8.1-ja-html.tar.gz:ruby tagoh:BADURL:scim-anthy-1.2.4.tar.gz:scim-anthy tagoh:BADURL:shion.tar.gz:Canna tagoh:BADURL:uim-1.4.1.tar.bz2:uim tagoh:BADURL:zipcode-20030204.tar.bz2:Canna tanguy:BADURL:freehdl-0.0.4.tar.gz:freehdl terjeros:BADURL:libast-0.7.1.tar.gz:libast tgl:BADSOURCE:pgtcl1.5.3.tar.gz:postgresql tgl:BADSOURCE:pgtcldocs-20060909.zip:postgresql tgl:BADURL:jpegsrc.v6b.tar.bz2:libjpeg tgl:BADURL:libpng-1.2.16.tar.bz2:libpng tgl:BADURL:mysql-3.23.58.tar.gz:mysqlclient10 tgl:BADURL:mysql-4.1.14.tar.gz:mysqlclient14 tgl:BADURL:mysql-5.0.45.tar.gz:mysql tgl:BADURL:mysql-connector-odbc-3.51.14r248.tar.gz:mysql-connector-odbc tgl:BADURL:pg_filedump-8.2.0.tar:rhdb-utils tgl:BADURL:postgresql-8.2.1-US.pdf:postgresql tgl:BADURL:psqlodbc-08.02.0200.tar.gz:postgresql-odbc than:BAD_CVS_SOURCE:French.txt:wordtrans than:BAD_CVS_SOURCE:post-3.5.7-kdebase-konqueror.diff:kdebase than:BAD_CVS_SOURCE:post-3.5.7-kdelibs-kdecore.diff:kdelibs than:BADSOURCE:css.tar.bz2:kdewebdev than:BADSOURCE:html.tar.bz2:kdewebdev than:BADSOURCE:javascript.tar.bz2:kdewebdev than:BADURL:arts-1.5.7.tar.bz2:arts than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R than:BADURL:eject-2.1.5.tar.gz:eject than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils than:BADURL:kde-i18n-ar-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-bg-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-bn-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ca-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-cs-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-da-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-de-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-el-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-en_GB-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-es-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-et-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-fi-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-fr-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-he-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-hi-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-hu-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-is-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-it-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ja-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ko-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-lt-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-nb-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-nl-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-nn-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-pa-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-pl-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt_BR-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ro-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ru-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-sk-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-sl-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-sr-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-sv-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-ta-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-tr-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-uk-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_CN-3.5.6.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_TW-3.5.6.tar.bz2:kde-i18n than:BADURL:kdemultimedia-3.5.7-patched-2.tar.bz2:kdemultimedia than:BADURL:kdepimlibs-3.93.0.tar.bz2:kdepimlibs than:BADURL:kdevelop-3.4.1.tar.bz2:kdevelop than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R than:BADURL:mozplugger-1.7.3.tar.gz:mozplugger than:BADURL:PyQt-x11-gpl-3.17.1.tar.gz:PyQt than:BADURL:rp-pppoe-3.8.tar.gz:rp-pppoe than:BADURL:sip-4.6.tar.gz:sip than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans than:BADURL:Xaw3d-1.3.tar.gz:Xaw3d than:BADURL:xferstats-2.16.tar.gz:xferstats than:BADURL:xfig.3.2.5.full.tar.gz:xfig thias:BADSOURCE:ipvsadm-1.24.tar.gz:ipvsadm thias:BADSOURCE:linux_logo-5.01.tar.gz:linux_logo thias:BADSOURCE:metakit-2.4.9.7.tar.gz:metakit thias:BADSOURCE:Nevow-0.9.18.tar.gz:python-nevow thias:BADSOURCE:powermanga-0.90.tgz:powermanga thias:BADSOURCE:thttpd-2.25b.tar.gz:thttpd thias:BADURL:speex-xmms-0.9.1.tar.gz:xmms-speex thl:BADSOURCE:CHANGELOG:rss2email thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml thomasvs:BADSOURCE:liboggz-0.9.5.tar.gz:liboggz thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex thomasvs:BADURL:rasqal-0.9.12.tar.gz:rasqal timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime timj:BADSOURCE:php_manual_en.tar.gz:php-manual-en timj:BADURL:rapidsvn-0.9.4.tar.gz:rapidsvn timj:BADURL:rpl_1.5.3.tar.gz:rpl tjanouse:BADURL:dovecot-1.1.alpha3.tar.gz:dovecot tjanouse:BADURL:dovecot-sieve-1.1-0367450c9382.tar.gz:dovecot tscherf:BADURL:libprelude-0.9.13.tar.gz:libprelude tscherf:BADURL:libpreludedb-0.9.11.1.tar.gz:libpreludedb tscherf:BADURL:prelude-lml-0.9.8.1.tar.gz:prelude-lml tscherf:BADURL:prelude-manager-0.9.7.1.tar.gz:prelude-manager tscherf:BADURL:prewikka-0.9.10.tar.gz:prewikka tsmetana:BADURL:ast-base-locale.2007-03-28.tgz:ksh tsmetana:BADURL:ast-ksh.2007-06-28.tgz:ksh tsmetana:BADURL:INIT.2007-06-28.tgz:ksh tsmetana:BADURL:nut-2.2.0.tar.gz:nut tsmetana:BADURL:procinfo-18.tar.bz2:procinfo tsmetana:BADURL:psmisc-22.5.tar.gz:psmisc twaugh:BADURL:cups-1.3.0-source.tar.bz2:cups twaugh:BADURL:foomatic-db-3.0-20070614.tar.gz:foomatic twaugh:BADURL:foomatic-db-engine-3.0-20070614.tar.gz:foomatic twaugh:BADURL:foomatic-db-hpijs-20070614.tar.gz:foomatic twaugh:BADURL:foomatic-filters-3.0-20070614.tar.gz:foomatic twaugh:BADURL:libieee1284-0.2.9.tar.bz2:libieee1284 twaugh:BADURL:ppa-0.8.6.tar.gz:pnm2ppa varekova:BADURL:acct-6.3.2.tar.gz:psacct varekova:BADURL:aspell-ga-0.50-4.tar.bz2:aspell-ga varekova:BADURL:gd-2.0.34.tar.bz2:gd varekova:BADURL:gzip-1.3.12.tar.gz:gzip varekova:BADURL:lynx2.8.6.tar.bz2:lynx varekova:BADURL:mailx-8.1.1.tar.gz:mailx varekova:BADURL:manpages-da-0.1.1.tar.gz:man-pages-da varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl varekova:BADURL:unzip552.tar.gz:unzip varekova:BADURL:zcrypt29.tar.gz:zip varekova:BADURL:zip231.tar.gz:zip vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect vcrhonek:BADURL:netkit-ntalk-0.17.tar.gz:talk vcrhonek:BADURL:pegasus-2.6.1.tar.gz:tog-pegasus veillard:BADURL:ekiga-2.0.9.tar.gz:ekiga veillard:BADURL:libxml2-2.6.30.tar.gz:libxml2 veillard:BADURL:libxslt-1.1.22.tar.gz:libxslt veillard:BADURL:opal-2.2.8.tar.gz:opal veillard:BADURL:pwlib-1.10.7.tar.gz:pwlib vlg:BADSOURCE:libassa-3.4.2.tar.gz:libassa vlg:BADURL:granule-1.2.4.tar.gz:granule walters:BADURL:bigboard-0.5.16.tar.gz:bigboard walters:BADURL:hippo-canvas-0.2.24.tar.gz:hippo-canvas walters:BADURL:hotwire-0.595.zip:hotwire walters:BADURL:online-desktop-0.2.13.tar.gz:online-desktop wtogami:BADURL:IO-Socket-SSL-1.02.tar.gz:perl-IO-Socket-SSL wtogami:BADURL:memtest86+-1.70.tar.gz:memtest86+ wtogami:BADURL:pidgin-2.1.1.tar.bz2:pidgin xgl-maint:BADURL:font-util-1.0.1.tar.bz2:xorg-x11-font-utils xris:BADURL:lineak-kdeplugins-0.9.tar.gz:lineak-kdeplugins xulchris:BADSOURCE:PHPUnit2-2.3.6.tgz:php-pear-PHPUnit2 xulchris:BADURL:fpconst-0.7.2.tar.gz:python-fpconst zhu:BADSOURCE:libhangul-0.0.6.tar.gz:libhangul zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar zmc:BADSOURCE:pyspi-0.6.1.tar.gz:pyspi zprikryl:BADURL:bc-1.06.tar.bz2:bc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nando at ccrma.Stanford.EDU Mon Sep 17 22:29:38 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 17 Sep 2007 15:29:38 -0700 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: References: <46EED66E.8040009@hhs.nl> Message-ID: <1190068178.12423.6.camel@cmn3.stanford.edu> On Mon, 2007-09-17 at 21:53 +0200, KH KH wrote: > > The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also > > interested in this and are willing to help out. There are a lot of CCRMA > > packages and we could use your help. Hence the creation of the Audio Creation > > SIG, where all interested contributers can join and help out. The Audio > > Creation SIG is further described here: > > http://fedoraproject.org/wiki/SIGs/AudioCreation > > > > Nice! i'm interested in taking part of this effort. > I have already submitted jack-rack for inclusing in > https://bugzilla.redhat.com/285331, that was already a duplicate > (thought not updated for a long time)... > Not have time to formally contact Fernando for co-ordination Thanks! The more there are to help the better! > I can act as a reviewer also (more from the second part on this week...) Good news... I have a couple of packages that I have to reactivate to put in the queue as well (freqtweak & sooperlooper). -- Fernando From nando at ccrma.Stanford.EDU Mon Sep 17 22:32:55 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 17 Sep 2007 15:32:55 -0700 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190059606.16960.79.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> Message-ID: <1190068375.12423.11.camel@cmn3.stanford.edu> On Mon, 2007-09-17 at 14:06 -0600, Richi Plana wrote: > On Mon, 2007-09-17 at 21:50 +0200, Hans de Goede wrote: > > Richi Plana wrote: > > > How about some reference links to CCRMA on the SIG wiki, particularly > > > the software-related ones? > > > > > > The SIG is called AudioCreation, but is it going to concentrate > > > specifically on CCRMA for its lifecycle? I understand there are other > > > audio-related Linux packaging attempts like AGNULA > > > or any of the attempts at this page: > > > http://linux-sound.org/distro.html > > > > > > > Have you read the wiki? Quoting it: "The Audio Creation SIG is currently in a > > phase were we are concentrating on getting more audio related packages in to > > Fedora and specifically concentrating on getting CCRMA packages integrated into > > Fedora" > > Yes, I read the page and the particular line in the page "concentrating > on getting CCRMA packages integrated" (in fact, the line you qutoed is > on your announcement, as well) is what has me confused. That's why I'm > trying to clarify. Is the SIG specifically about CCRMA only or is it > "AudioCreation" in general? For now it would be great to get the Planet CCRMA packages that are already there moved into Fedora proper (I think Planet CCRMA is quite complete, but of course I'm slightly biased :-). If there are interesting apps missing I/we'd like to know, of course - I'm sure there are cool apps out there I have not yet packaged :-) -- Fernando From mzerqung at 0pointer.de Mon Sep 17 23:43:11 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Sep 2007 01:43:11 +0200 Subject: USB audio takes over other devices on boot In-Reply-To: References: Message-ID: <20070917234311.GB25080@tango.0pointer.de> On Sat, 15.09.07 09:59, Konstantin Ryabitsev (icon at fedoraproject.org) wrote: Hi! > Since there isn't a mic input jack on Mac Mini, I have to use a USB > headset. If I leave it plugged in when booting, the HDA Intel onboard > device doesn't even show up any more in my ALSA device selector -- > only USB audio devices are present. So, I have to remember to unplug > the headset before booting, in order for the onboard audio to still > show up and work (we like music). > > I don't think this is desired behaviour -- both devices appear to work > correctly when I plug in the USB headset after the boot. > > I'm not sure if this is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=219023, but the symptoms > do seem similar. > > Can anyone confirm with other devices? This is on F7. This is probably caused by /etc/modprobe.conf fragments that system-config-sound writes. Those fragments are written to make the binding between audio device and ALSA device index stabl. However, they cause problems when an audio device is later plugged in that was not plugged when s-c-s was first run. So, as far as I understood the problem: s-c-s finds your first sound card, decides it should get index 0 assigned. Hence it writes a fragment which enforces this mapping. Now, on next bootup a new device is around, which is configured by the kernel before the already known one. Because it has no modprobe.conf fragment it gets an index assigned automatically. The first one that is free happens to be 0, so it get's that index assigned. Next the already known sound card gets configured by the kernel. The modprobe.conf fragment is used, which assigns it index 0 -- which however is already taken at this point. And thus the "main" device is not configured and thus doesn't appear anymore. So, what's the fix for this? A quick fix would be to simply remove that modprobe.conf fragment in question. For Fedora the right fix is probably to remove s-c-s from firstboot, so that the fragment is not written anymore. It's obsolete now, anyway. Of course, that way we lose the fixed alsa device indexes. But, in -- my opinion -- that was a bad idea anyway. Sound cards should be identified by a device path, like the HAL device string. PulseAudio always uses HAL device strings for identification of sound cards. Since we moved to PA now, this problem thus goes away. This all is an educated guess. Haven't checked if the above recommendations actually fix your problem. Please report back! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Mon Sep 17 23:54:03 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 18 Sep 2007 01:54:03 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1189807798.24350.19.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> Message-ID: <20070917235403.GD25080@tango.0pointer.de> On Fri, 14.09.07 16:09, Richi Plana (myfedora at richip.dhs.org) wrote: > > On Sat, 2007-09-15 at 00:00 +0200, Lennart Poettering wrote: > > On Fri, 14.09.07 15:52, Richi Plana (myfedora at richip.dhs.org) wrote: > > > > > > > I havn't tested it yet that why I said it _should_ be fixed ... > > > > > tested it and it seems that it still broken.... :( > > > > > > > > > > > > > It works fine here. > > > > > > Which device-API does the flash plugin use (/dev/dsp-OSS, ALSA)? What > > > was the proposed fix to make it work with PulseAudio enabled? > > > > Flash uses its own (crappy) audio abstraction called > > libflashsupport.so. pulseaudio-libs installs an implementation of > > that file which connects to PA for audio playback. > > Thanks. I was about to ask what pulseaudio-libs had that Flash would > use. > > So what did pulseaudio-libs have to implement to get Flash working? Are > there talk with the Penguin.SWF folks on making their stuff use > PulseAudio? Or do we have to live with layers-upon-layers of > abstractions? ;) I basically just implemented the mentioned libflashsupport.so. Which is intended to be an API that can be used to replace the audio output interface of Adobe Flash. For now this is enough to get Flash working. Eventually it would be preferable if Flash would using PA natively. But since the current API will eventually be replaced by something called libsydney I have not asked Adobe to move this abstraction upstream. The libflashsupport.so solution is good enough for the near future. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From myfedora at richip.dhs.org Mon Sep 17 23:59:27 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 17:59:27 -0600 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190068375.12423.11.camel@cmn3.stanford.edu> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> Message-ID: <1190073567.16960.90.camel@localhost6.localdomain6> On Mon, 2007-09-17 at 15:32 -0700, Fernando Lopez-Lezcano wrote: > For now it would be great to get the Planet CCRMA packages that are > already there moved into Fedora proper (I think Planet CCRMA is quite > complete, but of course I'm slightly biased :-). If there are > interesting apps missing I/we'd like to know, of course - I'm sure there > are cool apps out there I have not yet packaged :-) Could someone update the wiki with a list of outstanding packages that need attention, then? I google'd for Planet CCRMA's site (not on the wiki) and found the current repo. I found the compiled binaries but the SRPMS subdirectory is empty. What are the packages that need to be packaged for Fedora? And is packaging going to start from scratch or are we picking up where Planet CCRMA left off? I've found the CCRMA site http://ccrma.stanford.edu/ and the Planet CCRMA site (http://ccrma.stanford.edu/planetccrma/software/). How exactly are the two related? I understand that CCRMA has a couple of software projects (some old, some active). Is PlanetCCRMA currently in-sync with the projects at CCRMA? I guess what I'm trying to ask (and I can't find the right words to express it) is what's the intersection of the two entities in terms of software and what is the ? -- Richi Plana From lamont at gurulabs.com Tue Sep 18 00:04:37 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Mon, 17 Sep 2007 18:04:37 -0600 Subject: Where is Alexander Larsson (Nautilus bug)? In-Reply-To: <46EDC8C8.6040105@avtechpulse.com> References: <20070916152436.200557d1@reaver.lamontpeterson.net> <46EDC8C8.6040105@avtechpulse.com> Message-ID: <20070917180437.4a471e59@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 16 Sep 2007 20:22:32 -0400 "Dr. Michael J. Chudobiak" wrote: > Lamont Peterson wrote: > > > > Where in the World is Alexander Larson? #243309 > > [ https://bugzilla.redhat.com/show_bug.cgi?id=243309 ] (Nautilus > > folder icons get stuck in open state) is assigned to him, but he > > isn't responding to it. > > I imagine he has a million high-priority bugs and new features to > deal with... I can appreciate a man being busy. > > The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and > > added my +1 to it on 2007-08-29. > > If it's not fixed in 30 days, it's free... Seriously, though, try > investigating the bug upstream. For instance: > > http://bugzilla.gnome.org/show_bug.cgi?id=314137 Yeah, I should have looked, but I was lazy this time as I was traveling, working on 5 other projects at once and participating (including some presentations) at a conference. > looks similar. I can not reproduce the problem on my F7 system. Are > you using the default theme? I am using the default theme. I'll also explore it some more, looking at the upstream bug, maybe I can track it down. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG7xYV+YBsl9wN1AkRAge6AKC9mT+xgO0QlLiSlhzO8Wjpbji+PQCfdJJX utmXqTVgNnrk9osUTFl/Yx4= =AqX3 -----END PGP SIGNATURE----- From myfedora at richip.dhs.org Tue Sep 18 00:06:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 17 Sep 2007 18:06:10 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070917235403.GD25080@tango.0pointer.de> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> Message-ID: <1190073970.16960.96.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 01:54 +0200, Lennart Poettering wrote: > I basically just implemented the mentioned libflashsupport.so. Which is > intended to be an API that can be used to replace the audio output > interface of Adobe Flash. For now this is enough to get Flash > working. Eventually it would be preferable if Flash would using PA > natively. But since the current API will eventually be replaced by > something called libsydney I have not asked Adobe to move this > abstraction upstream. The libflashsupport.so solution is good enough > for the near future. Sorry. It was the alsa-oss-libs packages requirement that tripped me up. Let's see if I understand correctly now: flash-plugins tries the OSS /dev/dsp interface (which didn't work on my system when alsa-oss-libs.i386 was missing because the OSS emulation doesn't work without those libs?) and, failing that, tries to find libflashsupport.so within $PATH or $LD_LIBRARY_PATH, loads it and uses it? (actually, it might even be preferring that over OSS). The reason I'm asking is I'm trying to figure out what the best way is to ensure that there is support for flash-plugins packaging-wise. If PA isn't installed, then the other alternative requirements should be installed (either OSS or OSS-emulation by ALSA). -- Richi Plana From rodd at clarkson.id.au Tue Sep 18 04:30:57 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 18 Sep 2007 14:30:57 +1000 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46E959F5.4010804@fedoraproject.org> References: <46E959F5.4010804@fedoraproject.org> Message-ID: <1190089857.24295.8.camel@localhost.localdomain> Please ignore this post. I'm testing a strange sorting behavior in evolution to see what happens. Thanks R. On Thu, 2007-09-13 at 21:10 +0530, Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/F8Test2/ReleaseNotes > > I have updated the release notes with information on changes new to test > 2. If there is anything important I have missed, please edit the wiki or > let me know. > > Rahul > -- "It's a fine line between denial and faith. It's much better on my side" From pekkas at netcore.fi Tue Sep 18 05:43:36 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 18 Sep 2007 08:43:36 +0300 (EEST) Subject: gcc-java update fails if eclipse-ecj is missing Message-ID: Hi, I haven't been able to update Fedora 7 w/ yum for about two weeks now because gcc-java update seems to require eclipse-ecj (more specifically, /usr/share/hava/eclipse-ecj.jar) but isn't able to install eclipse-ecj package. I've reopened an old PR on this: https://bugzilla.redhat.com/show_bug.cgi?id=231591 -- 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 spng.yang at gmail.com Tue Sep 18 05:54:53 2007 From: spng.yang at gmail.com (Ken YANG) Date: Tue, 18 Sep 2007 13:54:53 +0800 Subject: compiz-fusion in F8 test 2 default? Message-ID: <46EF682D.3070902@gmail.com> hi all i noticed that there are compiz fusion in test 2, but i can not find relative package in development repository or koji. there are only compiz, compiz-gnome... can anyone give me some hints? From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 18 06:04:33 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 18 Sep 2007 15:04:33 +0900 Subject: compiz-fusion in F8 test 2 default? In-Reply-To: <46EF682D.3070902@gmail.com> References: <46EF682D.3070902@gmail.com> Message-ID: <46EF6A71.7060908@ioa.s.u-tokyo.ac.jp> Ken YANG wrote, at 09/18/2007 02:54 PM +9:00: > hi all > > i noticed that there are compiz fusion in test 2, > but i can not find relative package in development > repository or koji. > > there are only compiz, compiz-gnome... > > can anyone give me some hints? > See: https://bugzilla.redhat.com/show_bug.cgi?id=253692 Regards, Mamoru From debarshi.ray at gmail.com Tue Sep 18 06:12:00 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 18 Sep 2007 11:42:00 +0530 Subject: Closing FEver bugs Message-ID: <3170f42f0709172312j23ea8a12x6c852f6e8c44c166@mail.gmail.com> When should we close the bugs generated by FEver (http://fedoraproject.org/wiki/PackageMaintainers/FEver) to indicate availability of new upstream releases? The bugs are filed against the 'devel' branch, so should we close it when it is available in Rawhide or wait for it to be available in the stable branches too? Should we close it as CURRENTRELEASE or NEXTRELEASE? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From j.w.r.degoede at hhs.nl Tue Sep 18 06:50:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 18 Sep 2007 08:50:21 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190068178.12423.6.camel@cmn3.stanford.edu> References: <46EED66E.8040009@hhs.nl> <1190068178.12423.6.camel@cmn3.stanford.edu> Message-ID: <46EF752D.6070808@hhs.nl> Fernando Lopez-Lezcano wrote: > On Mon, 2007-09-17 at 21:53 +0200, KH KH wrote: >>> The SIG wiki says Fedora Contributers, as I'm hoping that some of you are also >>> interested in this and are willing to help out. There are a lot of CCRMA >>> packages and we could use your help. Hence the creation of the Audio Creation >>> SIG, where all interested contributers can join and help out. The Audio >>> Creation SIG is further described here: >>> http://fedoraproject.org/wiki/SIGs/AudioCreation >>> >> Nice! i'm interested in taking part of this effort. >> I have already submitted jack-rack for inclusing in >> https://bugzilla.redhat.com/285331, that was already a duplicate >> (thought not updated for a long time)... >> Not have time to formally contact Fernando for co-ordination > > Thanks! The more there are to help the better! > >> I can act as a reviewer also (more from the second part on this week...) > > Good news... I have a couple of packages that I have to reactivate to > put in the queue as well (freqtweak & sooperlooper). > Could you put links to the bugzilla tickets on the wiki page please, or mail them to me then I'll put them on the wiki. Thanks & Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 18 07:08:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 18 Sep 2007 09:08:39 +0200 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190073567.16960.90.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> <1190073567.16960.90.camel@localhost6.localdomain6> Message-ID: <46EF7977.40104@hhs.nl> Richi Plana wrote: > On Mon, 2007-09-17 at 15:32 -0700, Fernando Lopez-Lezcano wrote: >> For now it would be great to get the Planet CCRMA packages that are >> already there moved into Fedora proper (I think Planet CCRMA is quite >> complete, but of course I'm slightly biased :-). If there are >> interesting apps missing I/we'd like to know, of course - I'm sure there >> are cool apps out there I have not yet packaged :-) > > Could someone update the wiki with a list of outstanding packages that > need attention, then? > Erm, keeping a list like that up to date is a pain, so it will most likely always be out of date and thus have little use. Anything from CCRMA which meets Fedora's legal demands and is not in Fedora (nor in the review queue) is fair game, you can find all CCRMA packages available in the SRPMS dir (see below). > I google'd for Planet CCRMA's site (not on the wiki) and found the > current repo. I found the compiled binaries but the SRPMS subdirectory > is empty. > Erm yes the CCRMA srpms dir is a bit hidden, I'll add a link to it it the links section of the SIG wiki page (which already contains a link to planet CCRMA). The SRPMS are here: http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/ > What are the packages that need to be packaged for Fedora? And is > packaging going to start from scratch or are we picking up where Planet > CCRMA left off? > The idea is to use CCRMA packages as a base. I'm currently working on the ladspa plugin packages. Other good candidates are jaaa and japa, but as said anything meeting the legal guidelines and not yet in Fedora or under review is fair game. > I've found the CCRMA site http://ccrma.stanford.edu/ and the Planet > CCRMA site (http://ccrma.stanford.edu/planetccrma/software/). How > exactly are the two related? I understand that CCRMA has a couple of > software projects (some old, some active). Is PlanetCCRMA currently > in-sync with the projects at CCRMA? I guess what I'm trying to ask (and > I can't find the right words to express it) is what's the intersection > of the two entities in terms of software and what is the > ? > -- I'll leave the answer to this question up to Fernando. Regards, Hans From pertusus at free.fr Tue Sep 18 07:17:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Sep 2007 09:17:04 +0200 Subject: source file audit - 2007-09-17 In-Reply-To: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> References: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> Message-ID: <20070918071704.GA12385@free.fr> On Mon, Sep 17, 2007 at 04:19:37PM -0600, Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. > > - Should I keep running this? Do folks find it useful? Very useful, it allowed to fix bad url/packaging issues. > - Should I try and spam maintainers? Or just keep posting in the list? Posting to the list seems enough to me, at least until most of the issues are fixed. Then you could start spamming maintainers. But since it is not very priority, I guess it won't be before long. Maybe future additions to the list could deserve a mail to the maintainer. -- Pat From buildsys at fedoraproject.org Tue Sep 18 08:42:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 18 Sep 2007 04:42:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-18 Message-ID: <20070918084217.6B72615212C@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 13 CGAL-3.3.1-2.fc6 NEW climm-0.6-2.fc6 : Text/line based ICQ client with many features ctapi-cyberjack-3.0.4-1.fc6 gcstar-1.2.2-1.fc6 gnomebaker-0.6.2-1.fc6 gq-1.2.2-7.fc6 NEW homebank-3.5-5.fc6 : Free easy personal accounting for all ipe-6.0-0.20.pre28.fc6 lesstif-0.95.0-20.fc6 ntfs-3g-1.913-1.fc6 plone-3.0.1-1.fc6 python-TurboMail-2.0.4-1.fc6 zope-2.10.4-3.fc6 Changes in Fedora Extras 6: CGAL-3.3.1-2.fc6 ---------------- * Mon Sep 03 2007 Laurent Rineau - 3.3.1-2.fc6 - Fix soversion. * Mon Sep 03 2007 Laurent Rineau - 3.3.1-1.fc6 - New upstream bug-fixes release. * Fri Aug 24 2007 Laurent Rineau - 3.3-7.fc6 - Add BR: mpfr since F-8. * Fri Aug 24 2007 Laurent Rineau - 3.3-6.fc6 - Add BR: gawk * Thu Aug 23 2007 Laurent Rineau - 3.3-5.fc6 - License: tag fixed. climm-0.6-2.fc6 --------------- * Mon Sep 17 2007 Jan ONDREJ (SAL) - 0.6-2 - updated description before gloox will be a part of Fedora * Mon Sep 17 2007 Jan ONDREJ (SAL) - 0.6-1 - package renamed to climm - glibc-open patch updated for new name - added obsolete for micq * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.5.4.2-4 - using iconv instead of convmv * Wed Sep 05 2007 Jan ONDREJ (SAL) - 0.5.4.2-3 - added forgotten enca to BuildRequires - updated description (removed author) - install keeps file tempstamps * Wed Sep 05 2007 Jan ONDREJ (SAL) - 0.5.4.2-2 - changelog section moved to end of spec file - compilation condition removed - paralel compilation support added - libotr-devel added to BuildRequires to build package on f8 too - compilation flags updated (-O4 removed) - man files converted to UTF-8 - added lang macros for man pages - EVR added to changelog entries * Sun Aug 26 2007 Jan ONDREJ (SAL) - 0.5.4.2-1 - rpmlint cleanups ctapi-cyberjack-3.0.4-1.fc6 --------------------------- * Mon Sep 17 2007 Frank B?ttner - 3.0.4-1 - update to 3.0.4 gcstar-1.2.2-1.fc6 ------------------ * Mon Sep 17 2007 Tian - 1.2.2-1 - New upstream version gnomebaker-0.6.2-1.fc6 ---------------------- * Mon Sep 17 2007 Tomas Smetana - 0.6.2-1 - new upstream version gq-1.2.2-7.fc6 -------------- * Thu Sep 06 2007 Terje R?sten - 1.2.2-7 - Add default-codeset to configure (fix bz #281431) homebank-3.5-5.fc6 ------------------ * Sun Sep 16 2007 Johan Cwiklinski 3.5-5 - Removed pango from BR - Added libofx-devel to BR - Using macros everywhere - Added update-desktop-databas to post * Tue Sep 11 2007 Johan Cwiklinski 3.5-4 - Added release to doc subpackage requires * Tue Sep 11 2007 Johan Cwiklinski 3.5-3 - Removed duplicate desktop file and logo file - Corrected timestamps at install - Removing pango from Requires - Splitted doc into subpackage * Mon Sep 10 2007 Johan Cwiklinski 3.5-2 - Fixed tag licence - Fixed .desktop errors - Keep timestamps at install - Own installation directory - Use of icon cache and mime cache scriptlets * Mon Sep 03 2007 Johan Cwiklinski 3.5-1 - Upgrade to latest version - praparing for submit to fedora's repository ipe-6.0-0.20.pre28.fc6 ---------------------- * Mon Aug 27 2007 Laurent Rineau - 6.0-0.20.pre28.fc6 - Change the URL, in Source0. * Fri Aug 24 2007 Laurent Rineau - 6.0-0.19.pre28.fc6 - New patch: no longer check the version of freetype at runtime * Fri Aug 24 2007 Laurent Rineau - 6.0-0.18.pre28.fc6 - New License: tag. - Rebuild for F-8. lesstif-0.95.0-20.fc6 --------------------- * Sun Sep 16 2007 Patrice Dumas 0.95.0-20 - Correct patch XxxxProperty-64bit based on E. Sheldrake input (bz 284431) ntfs-3g-1.913-1.fc6 ------------------- * Mon Sep 17 2007 Tom "spot" Callaway 2:1.913-1 - bump to 1.913 plone-3.0.1-1.fc6 ----------------- * Fri Sep 14 2007 Jonathan Steffan 3.0.1-1 - Update to Plone 3.0.1 * Thu Aug 23 2007 Jonathan Steffan 3.0-1 - Moved plone install back to software_home - Updated to Plone 3.0 final release * Thu Aug 02 2007 Jonathan Steffan 3.0-0.2rc2 - Moved plone install from software_home to instance_home (workaround) * Wed Aug 01 2007 Jonathan Steffan 3.0-0.1rc2 - Initial Package python-TurboMail-2.0.4-1.fc6 ---------------------------- * Mon Sep 17 2007 Luke Macken 2.0.4-1 - Latest upstream release zope-2.10.4-3.fc6 ----------------- * Mon Sep 03 2007 Jonathan Steffan 2.10.4-3 - Updated Requires for libxml2-python and python-elementtree * Tue Aug 14 2007 Jonathan Steffan 2.10.4-2 - Added config patch From alexl at redhat.com Tue Sep 18 08:59:00 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 18 Sep 2007 10:59:00 +0200 Subject: Where is Alexander Larsson (Nautilus bug)? In-Reply-To: <20070916152436.200557d1@reaver.lamontpeterson.net> References: <20070916152436.200557d1@reaver.lamontpeterson.net> Message-ID: <1190105940.3904.120.camel@localhost.localdomain> On Sun, 2007-09-16 at 15:24 -0600, Lamont Peterson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Where in the World is Alexander Larson? #243309 > [ https://bugzilla.redhat.com/show_bug.cgi?id=243309 ] (Nautilus folder > icons get stuck in open state) is assigned to him, but he isn't > responding to it. I'm here. I also have 2295 open nautils bugs upstream (being the primary upstream maintainer), lots of nautilus bugs in redhat bugzilla (which are all likely dups of some upstream bug). At the same time I'm trying to work on new features like replacing gnome-vfs with the new gvfs glib module. In practice this means I'm very busy and thus I won't fix all bugs, or even have time to look at most of them. In fact, if I were to drop all new feature development and spend 2 hours on each open bug I would have to work over two man-years (8 hour days, 5 days a week). I tend to look over bugzilla looking for really high priority bugs, and I also have a bunch of bugsquad people who point me to these when they find them. This means less-than-high-prio bugs just show up quite low on the TODO list unfortunately. If people want to help out that would be very nice. > The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and > added my +1 to it on 2007-08-29. Is Alexander missing? Is there a > co-maintainer who should be available? I don't know what help a co-maintainer for fedora would do. What we need are more people to look at bugs, come up with patches that fix them and post them upstream, where I can review and commit them. This will then instantly come back to fedora (beacuse we track upstream closely). Unfortunately, not many people seem interested in doing this work. :( From alan at redhat.com Tue Sep 18 09:19:13 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 18 Sep 2007 05:19:13 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190037053.7686.149.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> Message-ID: <20070918091913.GE13425@devserv.devel.redhat.com> On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote: > My mental model of this is that the X session just stays up until the > computer actually halts, since it's not like the X server maintains any > state that needs to get flushed to disk. You might terminate all the > other clients besides the session leader, and then throw up some > animation so the user knows things are happening. You probably want to kill X off just before the final power down. A few boxes get a bit confuddled if the BIOS video mode isn't reset (I've got one here which objects if you do a hard reboot from inside an X window) - its fine after a real reset or if you got text mode first > But that's just a guess. It would take some design first to make sure > we think through the interactions. At this stage of F8 it might be too > late to fold this in before release, but that doesn't mean we shouldn't > work on it. Hard bit seems to me being sure the old X server is dead dead dead before the new one begins. Other problem is that X takes longer to start on some boxes than poweroff to finish.... From laroche at redhat.com Tue Sep 18 09:25:24 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 18 Sep 2007 11:25:24 +0200 Subject: Mirrors page In-Reply-To: <20070915132503.GB25308@auslistsprd01.us.dell.com> References: <20070915083634.GA6888@dudweiler.stuttgart.redhat.com> <20070915132249.GA25308@auslistsprd01.us.dell.com> <20070915132503.GB25308@auslistsprd01.us.dell.com> Message-ID: <20070918092524.GA4022@dudweiler.stuttgart.redhat.com> On Sat, Sep 15, 2007 at 08:25:03AM -0500, Matt Domsch wrote: > On Sat, Sep 15, 2007 at 08:22:49AM -0500, Matt Domsch wrote: > > On Sat, Sep 15, 2007 at 10:36:34AM +0200, Florian La Roche wrote: > > > Hello all, > > > > > > The fullsearch link at http://fedoraproject.org/wiki/Mirrors > > > does not make a lot of sense (just look at the result page if you > > > let this run through all pages). > > > > > > Who has access to this page? > > > > Where would you like it to point to instead? > > I pointed it at > http://mirrors.fedoraproject.org//mirrorlists/publiclist//Fedora/7/ > instead. Hello Matt, seems the fullsearch link is per default added to the top of all pages. I guess we're stress-testing search capabilities with this... So it has the following link for the Mirror page for me: http://fedoraproject.org/wiki/Mirrors?action=fullsearch&value=linkto%3A%22Mirrors%22&context=180 regards, Florian La Roche From jonathan.underwood at gmail.com Tue Sep 18 10:48:51 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 18 Sep 2007 11:48:51 +0100 Subject: source file audit - 2007-09-17 In-Reply-To: <20070918071704.GA12385@free.fr> References: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> <20070918071704.GA12385@free.fr> Message-ID: <645d17210709180348h1217f27dl646889ae6355badd@mail.gmail.com> On 18/09/2007, Patrice Dumas wrote: > On Mon, Sep 17, 2007 at 04:19:37PM -0600, Kevin Fenzi wrote: > > Here's attached another run of my sources/patches url checker. > > > > - Should I keep running this? Do folks find it useful? > > Very useful, it allowed to fix bad url/packaging issues. > I'd echo that - several of mine were bad, and your last list prompted me to fix them. Well worth carrying on with it. From buildsys at redhat.com Tue Sep 18 11:13:22 2007 From: buildsys at redhat.com (Build System) Date: Tue, 18 Sep 2007 07:13:22 -0400 Subject: rawhide report: 20070918 changes Message-ID: <200709181113.l8IBDMEI022240@porkchop.devel.redhat.com> New package homebank Free easy personal accounting for all New package libzzub Powerful music sequencing library New package tack Terminfo action checker Updated Packages: ConsoleKit-0.2.2-1.fc8 ---------------------- * Mon Sep 17 2007 Matthias Clasen - 0.2.2-1 - Update to 0.2.2 ORBit2-2.14.9-1.fc8 ------------------- * Mon Sep 17 2007 Matthias Clasen - 2.14.9-1 - Update to 2.14.9 OpenEXR-1.4.0a-6.fc8 -------------------- * Mon Sep 17 2007 Rex Dieter 1.4.0a-6 - libs: -Requires: %name * Wed Aug 22 2007 Rex Dieter 1.4.0a-5 - -libs: new subpkg to be multilib friendly - -utils: package exrdisplay separately (separate fltk dep) * Sat Oct 28 2006 Rex Dieter 1.4.0a-4 - Obsoletes/Provides: openexr(-devel) (rpmforge compatibility) aspell-fo-50:0.2.16-6.fc8 ------------------------- * Mon Sep 17 2007 Ivana Varekova - 50:0.2.16-1 - update to 0.2.16 aspell-ga-50:4.1-1.fc8 ---------------------- * Mon Sep 17 2007 Ivana Varekova - 50:4.1-1 - update to 4.1-1 aspell-no-50:0.50.1-12.fc8 -------------------------- * Mon Sep 17 2007 Ivana Varekova - 50:0.50.1-12 - remove useles souce file * Thu Mar 29 2007 Ivana Varekova - 50:0.50.1-11 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes at-spi-1.20.0-1.fc8 ------------------- * Mon Sep 17 2007 Matthias Clasen - 1.20.0-1 - Update to 1.20.0 atk-1.20.0-1.fc8 ---------------- * Mon Sep 17 2007 Matthias Clasen - 1.20.0-1 - Update to 1.20.0 automake16-1.6.3-14 ------------------- * Mon Sep 17 2007 Karsten Hopp 1.6.3-14 - update licenses - clarify BR autoconf for 'make check' only automake17-1.7.9-9 ------------------ * Mon Sep 17 2007 Karsten Hopp 1.7.9-9 - fix licenses - add README AUTHORS THANKS to %doc - add comment about using ./configure - fix automake17 info page and install it bluez-gnome-0.14-3.fc8 ---------------------- * Tue Sep 18 2007 - Bastien Nocera - 0.14-3 - Split out the analyzer so it's not installed by default - Don't prefix the properties .desktop with fedora for no reason bug-buddy-1:2.20.0-1.fc8 ------------------------ * Tue Sep 18 2007 Matthias Clasen - 1:2.20.0-1 - Update to 2.20.0 control-center-1:2.20.0-1.fc8 ----------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 ctapi-cyberjack-3.0.4-1.fc8 --------------------------- * Mon Sep 17 2007 Frank B??ttner - 3.0.4-1 - update to 3.0.4 cups-1:1.3.1-1.fc8 ------------------ * Mon Sep 17 2007 Tim Waugh 1:1.3.1-1 - 1.3.1. * Wed Aug 29 2007 Tim Waugh 1:1.3.0-2 - More specific license tag. * Mon Aug 13 2007 Tim Waugh 1:1.3.0-1 - 1.3.0. curl-7.16.4-7.fc8 ----------------- * Mon Sep 17 2007 Jindrich Novy 7.16.4-7 - add zlib-devel BR to enable gzip compressed transfers in curl (#292211) dasher-4.6.0-1.fc8 ------------------ * Mon Sep 17 2007 Matthias Clasen - 4.6.0-1 - Update to 4.6.0 deskbar-applet-2.20.0-1.fc8 --------------------------- * Mon Sep 17 2007 Luke Macken - 2.20.0-1 - 2.20.0 * Sun Sep 09 2007 Luke Macken - 2.19.92-1 - 2.19.92 dev86-0.16.17-7.fc8 ------------------- * Mon Sep 17 2007 Jindrich Novy - 0.16.17-7 - don't ifarch patch definition * Mon Aug 27 2007 Jindrich Novy - 0.16.17-6 - add missing BR on gawk - rebuild (#249952) * Tue Jan 30 2007 Jindrich Novy - 0.16.17-5 - don't strip debuginfo eclipse-cdt-1:4.0.0-7.fc8 ------------------------- * Thu Sep 13 2007 Jeff Johnston 4.0.0-7 - Resolves #288711 - Ensure that all features are unpacked. * Mon Sep 10 2007 Jeff Johnston 4.0.0-6 - Resolves #274551, #253331, #254246, #254248 - Rebase Autotools to 0.9.3 eclipse-egit-0.2.2-2.git20070911.fc8 ------------------------------------ * Mon Sep 17 2007 Ben Konrath 0.2.2-2.git20070911.fc8 - Update add feature and plugin patch. epiphany-2.20.0-1.fc8 --------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 * Fri Aug 24 2007 Adam Jackson - 2.19.90-2 - Rebuild for build ID evince-2.20.0-1.fc8 ------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 evolution-2.12.0-1.fc8 ---------------------- * Mon Sep 17 2007 Matthew Barnes - 2.12.0-1.fc8 - Update to 2.12.0 - Remove patch for RH bug #182247 (fixed upstream). * Sat Sep 15 2007 Matthew Barnes - 2.11.92-4.fc8 - Add patch for GNOME bug #477045 (use standard icon names). * Tue Sep 11 2007 Matthew Barnes - 2.11.92-3.fc8 - Add patch for GNOME bug #476040 (fix attachment icon). evolution-data-server-1.12.0-1.fc8 ---------------------------------- * Mon Sep 17 2007 Matthew Barnes - 1.12.0-1.fc8 - Update to 1.12.0 evolution-exchange-2.12.0-1.fc8 ------------------------------- * Mon Sep 17 2007 Matthew Barnes - 2.12.0-1.fc8 - Update to 2.12.0 fast-user-switch-applet-2.18.0-3.fc8 ------------------------------------ * Sun Sep 16 2007 Matthias Clasen 2.18.0-3 - Don't try to throttle gnome-screensaver (#246188) - Make the close button on the error dialog work - Make the handling of large numbers of users more efficient (#353831) * Mon Aug 06 2007 Matthias Clasen 2.18.0-2 - Use %find_lang for help files, too file-roller-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 freeradius-1.1.7-3.1.fc8 ------------------------ * Mon Sep 17 2007 Thomas Woerner 1.1.7-3.1 - made init script fully lsb conform * Mon Sep 17 2007 Thomas Woerner 1.1.7-3 - fixed initscript problem (rhbz#292521) gail-1.20.0-1.fc8 ----------------- * Mon Sep 17 2007 Matthias Clasen - 1.20.0-1 - Update to 1.20.0 gcalctool-5.20.0-1.fc8 ---------------------- * Mon Sep 17 2007 Matthias Clasen - 5.20.0-1 - Update to 5.20.0 gcc-4.1.2-25 ------------ * Mon Sep 17 2007 Jakub Jelinek 4.1.2-25 - fix ICE on __builtin_mem*_chk if it couldn't be folded until expand time and at that point it can avoid a call (PR middle-end/33423) - handle the upcoming POSIX 'm' *scanf allocation modifier in GCC format checking, fix up some details about %as/%aS/%a[ gcstar-1.2.2-1.fc8 ------------------ * Mon Sep 17 2007 Tian - 1.2.2-1 - New upstream version gedit-1:2.20.0-1.fc8 -------------------- * Mon Sep 17 2007 Matthias Clasen - 1:2.20.0-1 - Update to 2.20.0 gnome-backgrounds-2.20.0-1.fc8 ------------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-desktop-2.20.0-1.fc8 -------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-doc-utils-0.12.0-1.fc8 ---------------------------- * Mon Sep 17 2007 Matthias Clasen - 0.12.0-1 - Update to 0.12.0 gnome-icon-theme-2.20.0-1.fc8 ----------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-keyring-manager-2.20.0-1.fc8 ---------------------------------- * Tue Sep 18 2007 Matthias Clasen 2.20.0-1 - Update to 2.20.0 gnome-mag-0.14.10-1.fc8 ----------------------- * Mon Sep 17 2007 Matthias Clasen - 0.14.10-1 - Update to 0.14.10 gnome-media-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 - Bastien Nocera - 2.20.0-1 - Update to 2.20.0 gnome-panel-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Mon Sep 17 2007 Matthias Clasen - 2.19.92-7 - Can't require tomboy where there's no mono * Mon Sep 17 2007 Matthias Clasen - 2.19.92-6 - Turns out we need requires for applets in the default config (#293261) gnome-power-manager-2.20.0-1.fc8 -------------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-session-2.20.0-1.fc8 -------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-system-monitor-2.20.0-1.fc8 --------------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-user-docs-2.20.0-1.fc8 ---------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Tue Aug 07 2007 Matthias Clasen - 2.18.2-2 - Update the license field - Use %find_lang gnome-utils-1:2.20.0-1.fc8 -------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-vfs2-2.20.0-1.fc8 ----------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnomebaker-0.6.2-1.fc8 ---------------------- * Mon Sep 17 2007 Tomas Smetana - 0.6.2-1 - new upstream version gok-1.3.4-1.fc8 --------------- * Mon Sep 17 2007 Matthias Clasen - 1.3.4-1 - Update to 1.3.4 groff-1.18.1.4-9.fc8 -------------------- * Mon Sep 17 2007 Marcela Maslanova - 1.18.1.4-9 - fix license * Tue Sep 11 2007 Marcela Maslanova - 1.18.1.4-8 - another change in spec for review gtk2-engines-2.12.0-1.fc8 ------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.12.0-1 - Update to 2.12.0 gtkhtml3-3.16.0-1.fc8 --------------------- * Mon Sep 17 2007 Matthew Barnes - 3.16.0-1.fc8 - Update to 3.16.0 gtkmm24-2.12.0-1.fc8 -------------------- * Mon Sep 17 2007 Denis Leroy - 2.12.0-1 - Update to new stable branch 2.12.0 gtksourceview2-2.0.0-1.fc8 -------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.0.0-1 - Update to 2.0.0 icon-naming-utils-0.8.6-1.fc8 ----------------------------- * Mon Sep 17 2007 Matthias Clasen - 0.8.6-1 - Update to 0.8.6 ipe-6.0-0.21.pre28.fc8 ---------------------- * Mon Sep 17 2007 Laurent Rineau - 6.0-0.21.pre28.fc8 - New upstream patch. * Mon Aug 27 2007 Laurent Rineau - 6.0-0.20.pre28.fc8 - Change the URL, in Source0. iptables-1.3.8-2.1.fc8 ---------------------- * Mon Sep 17 2007 Thomas Woerner 1.3.8-2.1 - do not use lock file for condrestart test jasper-1.900.1-6.fc8 -------------------- * Mon Sep 17 2007 Rex Dieter 1.900.1-6 - -libs: -Requires: %name - -devel: +Provides: libjasper-devel - drop (unused) geojasper bits kde-filesystem-3.92-9.fc8 ------------------------- * Mon Aug 27 2007 Rex Dieter 3.92-9 - BR: gawk - - %_prefix/{env,shutdown} (non-FHS) * Wed Aug 15 2007 Rex Dieter 3.92-8 - simplify macros a bit * Tue Aug 14 2007 Rex Dieter 3.92-7 - kde4-macros(api), %_kde4_macros_api keepalived-1.1.15-1.fc8 ----------------------- * Mon Sep 17 2007 Matthias Saou 1.1.15-1 - Update to 1.1.15. - Remove merged genhashman and include patches. kernel-2.6.23-0.185.rc6.git7.fc8 -------------------------------- * Mon Sep 17 2007 Chuck Ebbert - Linux 2.6.23-rc6-git7 * Fri Sep 14 2007 Chuck Ebbert - leave boot option as "libata.pata_dma" for now * Fri Sep 14 2007 Chuck Ebbert - x86 setup: limit number of EDD devices scanned - x86 setup: print number of EDD device during scan - libata: change boot option name to "libata.dma" (still only affects PATA drives) lftp-3.5.14-2.fc8 ----------------- * Mon Sep 17 2007 Maros Barabas - 3.5.14-2 - rebase - deleted symlinks liblftp-jobs.so & liblftp-tasks.so libFS-1.0.0-5.fc8 ----------------- * Mon Sep 17 2007 Adam Jackson 1.0.0-5 - Rebuild for abstract socket support. libICE-1.0.3-4.fc8 ------------------ * Mon Sep 17 2007 Adam Jackson 1.0.3-4 - Rebuild for abstract socket support. libIDL-0.8.9-1.fc8 ------------------ * Mon Sep 17 2007 Matthias Clasen - 0.8.9-1 - Update to 0.8.9 * Wed Aug 08 2007 Matthias Clasen - 0.8.8-2 - Update the license field libSM-1.0.2-3.fc8 ----------------- * Mon Sep 17 2007 Adam Jackson 1.0.2-3 - Rebuild for abstract socket support. libX11-1.1.2-3.fc8 ------------------ * Mon Sep 17 2007 Adam Jackson 1.1.2-3 - libX11-1.1.2-GetMotionEvents.patch: Fix the definition of XGetMotionEvents to match the argument order in the headers. (#274671) libXfont-1.2.9-4.fc8 -------------------- * Mon Sep 17 2007 Adam Jackson 1.2.9-4 - Rebuild for abstract socket support. libbonobo-2.20.0-1.fc8 ---------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 libbonoboui-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 libgail-gnome-1.20.0-1.fc8 -------------------------- * Mon Sep 17 2007 Matthias Clasen - 1.20.0-1 - Update to 1.20.0 libglademm24-2.6.4-1.fc8 ------------------------ * Mon Sep 17 2007 Denis Leroy - 2.6.4-1 - Update to 2.6.4 - License tag update libgnome-2.20.0-1.fc8 --------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Tue Aug 28 2007 M??ir??n Duffy - 2.19.1-9 - Change default background to Infinity * Mon Aug 27 2007 Ray Strode - 2.19.1-8 - create .gnome2 directory by default for new users (bug 254237) libgnomecanvas-2.20.0-1.fc8 --------------------------- * Mon Sep 17 2007 Matthias Clasen 2.20.0-1 - Update to 2.20.0 * Sat Aug 25 2007 Ray Strode - 2.19.2-2 - Apply patch from Federico Mena Quintero to avoid tearing during scrolls and such (See http://mail.gnome.org/archives/desktop-devel-list/2007-August/msg00159.html) * Tue Aug 14 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 libgnomeprint22-2.18.2-1.fc8 ---------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.18.2-1 - Update to 2.18.2 libgnomeprintui22-2.18.1-1.fc8 ------------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.18.1-1 - Update to 2.18.1 libwnck-2.20.0-1.fc8 -------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 linux-libertine-fonts-2.6.9-1.fc8 --------------------------------- * Sun Sep 16 2007 Kevin Fenzi - 2.6.9-1 - Updated to 2.6.9 - Update License tag mash-0.2.4-1.fc8 ---------------- * Mon Sep 17 2007 Bill Nottingham 0.2.4-1 - repoview support () mutt-5:1.5.16-4.fc8 ------------------- * Mon Sep 17 2007 Miroslav Lichvar 5:1.5.16-4 - fix md5 on big-endian systems nautilus-cd-burner-2.20.0-1.fc8 ------------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 netatalk-4:2.0.3-15.fc8 ----------------------- * Wed Sep 12 2007 Maros Barabas -4:2.0.3-15 - patch to build on FC, bad open call * Tue Sep 11 2007 Maros Barabas - 4:2.0.3-13 - rebuild * Wed Aug 29 2007 Fedora Release Engineering - 4:2.0.3-12 - Rebuild for selinux ppc32 issue. nfs-utils-1:1.1.0-5.fc8 ----------------------- * Fri Sep 14 2007 Steve Dickson 1.1.0-5 - Changed the default paths in sm-notify to /var/lib/nfs/statd (bz 258461) - Updated exportfs manpage (bz 262861) * Wed Aug 15 2007 Steve Dickson 1.1.0-4 - Make sure the open() system calling in exportfs uses mode bits when creating the etab file (bz 252440). * Mon Aug 13 2007 Steve Dickson 1.1.0-3 - Added nosharecache mount option which re-enables rw/ro mounts to the same server (bz 243913). ntfs-3g-2:1.913-1.fc8 --------------------- * Mon Sep 17 2007 Tom "spot" Callaway 2:1.913-1 - bump to 1.913 openoffice.org-1:2.3.0-5.1.fc8 ------------------------------ * Mon Sep 17 2007 Jan Navratil - 1:2.3.0-5.1 - release candidate openssh-4.7p1-2.fc8 ------------------- * Mon Sep 17 2007 Tomas Mraz - 4.7p1-2 - revert default window size adjustments (#286181) openswan-2.4.9-2.fc8 -------------------- * Mon Sep 17 2007 Steve Conklin - 2.4.9-2 - Forgot changelog on last entry * Mon Sep 17 2007 Steve Conklin - 2.4.9-1 - sync to upstream latest pango-1.18.2-1.fc8 ------------------ * Tue Sep 18 2007 Matthias Clasen - 1.18.2-1 - Update to 1.18.2 pcre-7.3-1 ---------- * Mon Sep 17 2007 Than Ngo - 7.3-1 - bz292501, update to 7.3 perl-HTML-Mason-1:1.37-1.fc8 ---------------------------- * Mon Sep 17 2007 Steven Pritchard 1:1.37-1 - Update to 1.37. perl-Imager-0.60-1.fc8 ---------------------- * Mon Sep 17 2007 Steven Pritchard 0.60-1 - Update to 0.60. pungi-1.1.0-1.fc8 ----------------- * Fri Sep 14 2007 Jesse Keating - 1.1.0-1 - Create repoview content in the tree - Move the .composeinfo file into the directory we actually publish - Remove python2.5 needs (Mark McLoughlin) - Consolidate the download code for easier maint. (Mark McLoughlin) - Create a config class that can make using pungi modules easier. (Mark McLoughlin) - Use url line in kickstart files as a repo - Fix a bug with default dest dir (notting) - Include a man page (dcantrell) - Fix a bug with file:// based repos pygtksourceview-2.0.0-1.fc8 --------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.0.0-1 - Update to 2.0.0 qt-1:3.3.8-8.fc8 ---------------- * Mon Sep 17 2007 Than Ngo - 3.3.8-8 - CVE-2007-4137 * Wed Aug 29 2007 Than Ngo - 1:3.3.8-7.fc7.1 - CVE-2007-0242 * Tue Aug 28 2007 Than Ngo - 1:3.3.8-7 - CVE-2007-3388 qt3 format string flaw - backport to fix #bz243722, bz#244148, Applications using qt-mysql crash if database is removed before QApplication is destroyed - cleanup desktop files quagga-0:0.99.9-1.fc8 --------------------- * Mon Sep 17 2007 Martin Bacovsky - 0.99.9-1 - upgrade to new upstream 0.99.9 - Resolves: #292841: CVE-2007-4826 quagga bgpd DoS rpcbind-0.1.4-8.fc8 ------------------- * Sat Sep 15 2007 Steve Dickson 0.1.4-8 - Fixed typo in init script (bz 248285) - Added autoconf rules to turn on secure host checking via libwrap. Also turned on host check by default (bz 248284) - Changed init script to start service in runlevel 2 (bz 251568) - Added a couple missing Requires(pre) (bz 247134) rusers-0.17-51.fc8 ------------------ * Sat Sep 15 2007 Steve Dickson 0.17-51 - Removed portmap dependency and re-worked when the user privilege are drop; allowing port registration with rpcbind. (#247985) sendmail-8.14.1-4.2.fc8 ----------------------- * Mon Sep 17 2007 Thomas Woerner 8.14.1-4.2 - made init script fully lsb conform sound-juicer-2.20.0-1.fc8 ------------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 tk-1:8.4.15-5.fc8 ----------------- * Mon Sep 17 2007 Marcela Maslanova - 1:8.4.15-5 - CVE-2007-4851 Tk GIF processing buffer overflow - Resolves: rhbz#290991 * Fri Aug 31 2007 Jeremy Katz - 1:8.4.15-4 - BR gawk to unbreak things * Thu Aug 09 2007 Marcela Maslanova - 1:8.4.15-3 - check licence, build for mass rebuild tomboy-0.8.0-1.fc8 ------------------ * Mon Sep 17 2007 Matthias Clasen - 0.8.0-1 - Update to 0.8.0 vala-0.1.3-5.fc8 ---------------- * Mon Sep 17 2007 Michel Salim - 0.1.3-5 - vapigen subpackage: add missing Require: on perl-XML-Twig vino-2.20.0-1.fc8 ----------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 widelands-0-0.7.build11.fc8 --------------------------- * Mon Sep 17 2007 Karol Trzcionka - 0-0.7.build11 - Fix update problems xorg-x11-server-1.3.0.0-24.fc8 ------------------------------ * Mon Sep 17 2007 Adam Jackson 1.3.0.0-24 - xserver-1.3.0-edid-quirk-backports.patch: Update the EDID quirks code to match current git. * Thu Sep 06 2007 Adam Jackson 1.3.0.0-23 - xserver-1.3.0-xrandr-timestamp-buglet.patch: Make sure xrandr doesn't stop working after several hours. (Marius Gedminas, #273801) * Fri Aug 24 2007 Adam Jackson 1.3.0.0-22 - Bump BuildRequires: xorg-x11-xtrans-devel to pull in abstract socket support. yelp-2.20.0-1.fc8 ----------------- * Mon Sep 17 2007 Matthew Barnes - 2.20.0-1 - Update to 2.20.0 ypbind-3:1.20.4-2.fc8 --------------------- * Mon Sep 17 2007 Steve Dickson - 3:1.20.4-2 - Fixed a couple of typos in initscript (bz 281951) * Thu May 03 2007 Steve Dickson - 3:1.20.4-1 - updated to latest upstream version ypbind-mt-1.20.4 ypserv-2.19-6.fc8 ----------------- * Sat Sep 15 2007 Steve Dickson 2.19-6 - Fixed init scripts to return correct exit code on 'service status' (bz 248097) yum-3.2.5-3.fc8 --------------- * Mon Sep 17 2007 Jeremy Katz - 3.2.5-3 - fix traceback with closing repos zenity-2.20.0-1.fc8 ------------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From mschwendt.tmp0701.nospam at arcor.de Tue Sep 18 12:00:52 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 18 Sep 2007 14:00:52 +0200 Subject: jasper (was: Re: Useless OpenEXR split) In-Reply-To: References: <20070917181328.ac4e4250.mschwendt.tmp0701.nospam@arcor.de> <20070917183831.ec2bd744.mschwendt.tmp0701.nospam@arcor.de> <20070917191348.59d17631.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070918140052.59aed805.mschwendt.tmp0701.nospam@arcor.de> On Mon, 17 Sep 2007 12:18:26 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > >> It's unclear (to me anyway) whether these truly are optional or not, ie, > >> I have yet to determine here (or in the jasper case) whether apps assume > >> the > >> presence tools/binaries. In short, I'm playing it safe, and keeping the > >> same behavior as when there wasn't a -libs split. > > > > For jasper, the executables are _example programs_. RTFM confirms that. > > I've found at least one example (kopete?) where it assumes the presence of > the jasper binary. kopete in kdenetwork looks for a "jasper" executable, but is not linked to libjasper. It displays an error dialog if a jasper executable cannot be found. kopete/protocols/yahoo/yahoocontact.cpp kopete/protocols/yahoo/yahoowebcam.cpp kopete/protocols/yahoo/libkyahoo/webcamtask.cpp netpbm builds with an internal copy of libjasper. :) (jpeg2ktopam and pamtojpeg2k from netpbm-progs) From rjones at redhat.com Tue Sep 18 12:31:28 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 18 Sep 2007 13:31:28 +0100 Subject: source file audit - 2007-09-17 In-Reply-To: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> References: <20070917161937.6c3d403c@ghistelwchlohm.scrye.com> Message-ID: <46EFC520.5080407@redhat.com> Kevin Fenzi wrote: > rjones:BADURL:pcre-ocaml-5.11.4.tar.gz:ocaml-pcre I'll fix this one today. The upstream maintainer removes old tarballs from his site as soon as a new one is released, so this is probably going to be an ongoing chase :-) Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Tue Sep 18 11:13:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 07:13:51 -0400 Subject: Fedora 7 update data not valid, do not sync. In-Reply-To: <20070916204759.575d546a@localhost.localdomain> References: <20070916193942.6d45afa7@localhost.localdomain> <20070916204759.575d546a@localhost.localdomain> Message-ID: <20070918071351.22c33394@localhost.localdomain> On Sun, 16 Sep 2007 20:47:59 -0400 Jesse Keating wrote: > > We are re-populating the content from the build system but > > this will take some time (hours). > > Just to clarify. We aren't rebuilding things, we're just rsyncing the > content from the buildserver to the mirror masters. This is what is > taking time. The content will be the same once restored. All the data has been restored and a successful update push has occurred. It is safe once again to sync updates. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jon.nettleton at gmail.com Tue Sep 18 12:59:50 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Tue, 18 Sep 2007 08:59:50 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918091913.GE13425@devserv.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <20070918091913.GE13425@devserv.devel.redhat.com> Message-ID: On 9/18/07, Alan Cox wrote: > On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote: > > My mental model of this is that the X session just stays up until the > > computer actually halts, since it's not like the X server maintains any > > state that needs to get flushed to disk. You might terminate all the > > other clients besides the session leader, and then throw up some > > animation so the user knows things are happening. > > You probably want to kill X off just before the final power down. A few > boxes get a bit confuddled if the BIOS video mode isn't reset (I've got one > here which objects if you do a hard reboot from inside an X window) - its > fine after a real reset or if you got text mode first > > > But that's just a guess. It would take some design first to make sure > > we think through the interactions. At this stage of F8 it might be too > > late to fold this in before release, but that doesn't mean we shouldn't > > work on it. > > Hard bit seems to me being sure the old X server is dead dead dead before > the new one begins. Other problem is that X takes longer to start on some > boxes than poweroff to finish.... > I think the best way to do this would be to execute the shutdown gui in the PostLogin session of the first spawn X server. This allows us to avoid spawning another Xserver just to shut down. Jon From ajackson at redhat.com Tue Sep 18 13:38:08 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 18 Sep 2007 09:38:08 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918091913.GE13425@devserv.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <20070918091913.GE13425@devserv.devel.redhat.com> Message-ID: <1190122688.7686.231.camel@localhost.localdomain> On Tue, 2007-09-18 at 05:19 -0400, Alan Cox wrote: > On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote: > > But that's just a guess. It would take some design first to make sure > > we think through the interactions. At this stage of F8 it might be too > > late to fold this in before release, but that doesn't mean we shouldn't > > work on it. > > Hard bit seems to me being sure the old X server is dead dead dead before > the new one begins. Other problem is that X takes longer to start on some > boxes than poweroff to finish.... The waiting bit is done. I fixed X to issue both VT_ACTIVATE and VT_WAITACTIVE on both startup and shutdown for exactly this reason. When the X server process exits, it is off the hardware, guaranteed. If you have startup profiles from reasonable machines where we're taking more than, oh, four seconds to start, I'd love to see them. - ajax From sberry at northlc.com Tue Sep 18 14:52:08 2007 From: sberry at northlc.com (Scott) Date: Tue, 18 Sep 2007 09:52:08 -0500 Subject: Fedora 7 update data not valid, do not sync. References: <20070916193942.6d45afa7@localhost.localdomain><20070916204759.575d546a@localhost.localdomain> <20070918071351.22c33394@localhost.localdomain> Message-ID: <010f01c7fa03$b413f080$6601a8c0@Scott> Hey Jesse, Thank you very much for the heads up I bet ya that was a hell of a suprise when the update server went bonkers. Scott ----- Original Message ----- From: "Jesse Keating" To: Sent: Tuesday, September 18, 2007 6:13 AM Subject: Re: Fedora 7 update data not valid, do not sync. > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce -------------------------------------------------------------------------------- > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: 9/17/2007 1:29 PM From jkeating at redhat.com Tue Sep 18 14:57:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 10:57:41 -0400 Subject: Fedora 7 update data not valid, do not sync. In-Reply-To: <010f01c7fa03$b413f080$6601a8c0@Scott> References: <20070916193942.6d45afa7@localhost.localdomain> <20070916204759.575d546a@localhost.localdomain> <20070918071351.22c33394@localhost.localdomain> <010f01c7fa03$b413f080$6601a8c0@Scott> Message-ID: <20070918105741.117f279c@localhost.localdomain> On Tue, 18 Sep 2007 09:52:08 -0500 "Scott" wrote: > Hey Jesse, > > Thank you very much for the heads up I bet ya that was a hell of a > suprise when the update server went bonkers. It was an ..... interesting evening. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Lam at Lam.pl Tue Sep 18 15:30:50 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 18 Sep 2007 17:30:50 +0200 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190057477.8152.33.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057477.8152.33.camel@localhost.localdomain> Message-ID: <20070918173050.0bc8680d@pensja.lam.pl> Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce napisa?(a): > > - kill -TERM $everything > > - wait a second > > - kill -KILL $everything > > Do it with your services, don't try on mine :-) If your service is going to break whenever it gets killed, it's also going to break whenever the power is lost, whenever the kernel panics and whenever I accidentaly push the button. I don't believe Fedora ships such broken software :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Sep 18 15:38:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Sep 2007 11:38:08 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918173050.0bc8680d@pensja.lam.pl> References: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057477.8152.33.camel@localhost.localdomain> <20070918173050.0bc8680d@pensja.lam.pl> Message-ID: <20070918153808.GA27423@nostromo.devel.redhat.com> Leszek Matok (Lam at Lam.pl) said: > If your service is going to break whenever it gets killed, it's also going to > break whenever the power is lost, whenever the kernel panics and whenever I > accidentaly push the button. I don't believe Fedora ships such broken > software :) Sure, but it's more polite to, for example, shut down your mysql/postgres database gracefully. Bill From ssorce at redhat.com Tue Sep 18 15:55:11 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Sep 2007 11:55:11 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918173050.0bc8680d@pensja.lam.pl> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057477.8152.33.camel@localhost.localdomain> <20070918173050.0bc8680d@pensja.lam.pl> Message-ID: <1190130911.8152.56.camel@localhost.localdomain> On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote: > Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce napisa?(a): > > > > - kill -TERM $everything > > > - wait a second > > > - kill -KILL $everything > > > > Do it with your services, don't try on mine :-) > > If your service is going to break whenever it gets killed, it's also going to > break whenever the power is lost, whenever the kernel panics and whenever I > accidentaly push the button. I don't believe Fedora ships such broken > software :) There are many simple DBs that may break in such situations, and we have them in Fedora. Usually there are tools to recover them but they are not always 100% successful. And even if the state of the DB is consistent at the end of the process you may lose data. If you are trying to flush something to a file and you get killed you can't expect to be sure what's in the file when you are done. A good example is samba. By protocol, clients can and do use oplocks, which means they don't write data back to the server immediately but they are allowed to keep everything local and just flush down the data when requested or when they decide it is time to. When samba receive a shutdown request, it asks all client to please flush the data, it may take some time, as the size can be considerable. So if you kill samba while it is writing data received from clients, as a consequence you may corrupt files. A simple recycle may be easier to deal with as clients usually reconnect and flush data on simple disconnections. Same is for some tdb files we use or for BDB databases that use big write caches. Simo. From drago01 at gmail.com Tue Sep 18 16:27:05 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 18 Sep 2007 18:27:05 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1190073970.16960.96.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> Message-ID: <46EFFC59.40402@gmail.com> Richi Plana wrote: > Sorry. It was the alsa-oss-libs packages requirement that tripped me up. > Let's see if I understand correctly now: flash-plugins tries the > OSS /dev/dsp interface (which didn't work on my system when > alsa-oss-libs.i386 was missing because the OSS emulation doesn't work > without those libs?) and, failing that, tries to find libflashsupport.so > within $PATH or $LD_LIBRARY_PATH, loads it and uses it? (actually, it > might even be preferring that over OSS). > > The reason I'm asking is I'm trying to figure out what the best way is > to ensure that there is support for flash-plugins packaging-wise. If PA > isn't installed, then the other alternative requirements should be > installed (either OSS or OSS-emulation by ALSA). > you seem to be confused flash uses alsa by default not oss ... From overholt at redhat.com Tue Sep 18 16:33:22 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 18 Sep 2007 12:33:22 -0400 Subject: No Development SIG meeting today Message-ID: <20070918163322.GB20410@redhat.com> Hi, I've got an appointment that conflicts so I can't run the meeting today. If people want to discuss stuff and put a log on the wiki, that'd be great. I'm going to request the mailing list today and will announce it here when it's created. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Tue Sep 18 16:50:27 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 10:50:27 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <46EFFC59.40402@gmail.com> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> <46EFFC59.40402@gmail.com> Message-ID: <1190134227.16960.136.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 18:27 +0200, dragoran wrote: > Richi Plana wrote: > > Sorry. It was the alsa-oss-libs packages requirement that tripped me up. > > Let's see if I understand correctly now: flash-plugins tries the > > OSS /dev/dsp interface (which didn't work on my system when > > alsa-oss-libs.i386 was missing because the OSS emulation doesn't work > > without those libs?) and, failing that, tries to find libflashsupport.so > > within $PATH or $LD_LIBRARY_PATH, loads it and uses it? (actually, it > > might even be preferring that over OSS). > > > > The reason I'm asking is I'm trying to figure out what the best way is > > to ensure that there is support for flash-plugins packaging-wise. If PA > > isn't installed, then the other alternative requirements should be > > installed (either OSS or OSS-emulation by ALSA). > > > you seem to be confused > flash uses alsa by default not oss ... I think I'm misunderstanding how alsa-oss works. I "rpm -qi alsa-oss"'d now and found out that there are two OSS interfaces: /dev/dsp and preloading libaoss.so.0. I'm guessing the library wraps around some system calls like open(2) and ioctl(2). But if flash-plugin uses ALSA directly, then why doesn't the audio of flash-plugin.i386 work on my x86_64 machine using nspluginwrapper when alsa-oss-libs.i386 isn't installed? -- Richi Plana From drago01 at gmail.com Tue Sep 18 16:27:05 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 18 Sep 2007 18:27:05 +0200 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1190073970.16960.96.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> Message-ID: <46EFFC59.40402@gmail.com> Richi Plana wrote: > Sorry. It was the alsa-oss-libs packages requirement that tripped me up. > Let's see if I understand correctly now: flash-plugins tries the > OSS /dev/dsp interface (which didn't work on my system when > alsa-oss-libs.i386 was missing because the OSS emulation doesn't work > without those libs?) and, failing that, tries to find libflashsupport.so > within $PATH or $LD_LIBRARY_PATH, loads it and uses it? (actually, it > might even be preferring that over OSS). > > The reason I'm asking is I'm trying to figure out what the best way is > to ensure that there is support for flash-plugins packaging-wise. If PA > isn't installed, then the other alternative requirements should be > installed (either OSS or OSS-emulation by ALSA). > you seem to be confused flash uses alsa by default not oss ... From dwalsh at redhat.com Tue Sep 18 16:58:18 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Sep 2007 12:58:18 -0400 Subject: SELinux for BackupPC In-Reply-To: <46EAEFE4.1080403@x-tnd.be> References: <46EAEFE4.1080403@x-tnd.be> Message-ID: <46F003AA.4060207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johan Cwiklinski wrote: > Hi, > > I'm currently re-packaging BackupPC[1], a perl backup software server. > > As BackupPC need to use, for example, rsync or tar to backup itself, > wich cause SELinux denies. There also is a CGI interface to manage > backups/restore and config. > > As I'm not at all a SELinux guru, I've used 'audit2allow' to create a > selinux policy module included in my specfile, but I don't know if this > is the good way, and even if my policy module should causes issues... > > I'd like you to have advices related to SELinux integration in this RPM > file. I'll put online actual policy file[2], as I use it in the specfile[3] > I'd also like opinions on the best way to include an SELinux policy for > this software. > > Regards, > Johan > > [1] http://backuppc.sourceforge.net > [2] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te > [3] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec > > No alot of these rules are not good. Could you attach the audit log you used to create this. You probably need a context for this allow httpd_t etc_t:dir write; and these allow httpd_t usr_t:dir { write add_name }; allow httpd_t usr_t:file { write create }; Could be as simple as chcon -t httpd_sys_content_rw_t PATHTODIR I take it this is the socket file that BackupPC is creating. I think you need a policy for this, and then BackupPC could label it appropriately and allow httpd to communicate with it. allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_log_t:sock_file write; Not sure what these are either. allow httpd_t httpd_log_t:sock_file write; allow httpd_t httpd_sys_content_t:sock_file write; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8AOqrlYvE4MpobMRAl3UAKDD0uW2lWT9j2Ql3KediEC4g60XfQCeJW54 hQ2ka7VvyEcd2ssc41iVmCM= =ZwuW -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Sep 18 16:56:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 12:56:34 -0400 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <1190134227.16960.136.camel@localhost6.localdomain6> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> <46EFFC59.40402@gmail.com> <1190134227.16960.136.camel@localhost6.localdomain6> Message-ID: <20070918125634.496e9040@localhost.localdomain> On Tue, 18 Sep 2007 10:50:27 -0600 Richi Plana wrote: > But if flash-plugin uses ALSA directly, then why doesn't the audio of > flash-plugin.i386 work on my x86_64 machine using nspluginwrapper when > alsa-oss-libs.i386 isn't installed? Because the 32bit flash application needs to open the 32bit libaoss.so.0 ? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Tue Sep 18 17:01:21 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 11:01:21 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918173050.0bc8680d@pensja.lam.pl> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057477.8152.33.camel@localhost.localdomain> <20070918173050.0bc8680d@pensja.lam.pl> Message-ID: <1190134881.16960.146.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote: > Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce napisa?(a): > > > > - kill -TERM $everything > > > - wait a second > > > - kill -KILL $everything > > > > Do it with your services, don't try on mine :-) > > If your service is going to break whenever it gets killed, it's also going to > break whenever the power is lost, whenever the kernel panics and whenever I > accidentaly push the button. I don't believe Fedora ships such broken > software :) There's a difference between powering down and losing power. It's a fact of life that power loss can cause data loss. But that's something that's usually accidental and unintentional. Not something that might regularly be performed. Shutting down by choice is like kill -TERM. Power loss is like kill -KILL. With kill -TERM, you're giving the process the chance to do what it needs to do to shut down cleanly. SIGKILL doesn't even give it the chance to do anything and should only be used when the administrator is reasonably certain that the process can no longer exit cleanly with any of the other signal(7)s ... OR when the process absolutely has to die like in shutdowns. Some shutdown policies state (though unspoken) that shutting down the machine is a higher priority over assuring clean exits (as seem to be the case with Desktops). Of course, when the service is extremely important (servers where data integrity has a high monetary figure attached), then they would most likely opt for a different policy. -- Richi Plana From kevin.kofler at chello.at Tue Sep 18 17:18:49 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Sep 2007 17:18:49 +0000 (UTC) Subject: Latest updates missing announcements Message-ID: While F7 updates now work again, I can't see any announcements for the latest push in the fedora-package-announce archives. Kevin Kofler From myfedora at richip.dhs.org Tue Sep 18 17:23:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 11:23:06 -0600 Subject: Where is Alexander Larsson (Nautilus bug)? In-Reply-To: <1190105940.3904.120.camel@localhost.localdomain> References: <20070916152436.200557d1@reaver.lamontpeterson.net> <1190105940.3904.120.camel@localhost.localdomain> Message-ID: <1190136186.16960.161.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 10:59 +0200, Alexander Larsson wrote: > > The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and > > added my +1 to it on 2007-08-29. Is Alexander missing? Is there a > > co-maintainer who should be available? > > I don't know what help a co-maintainer for fedora would do. What we need > are more people to look at bugs, come up with patches that fix them and > post them upstream, where I can review and commit them. This will then > instantly come back to fedora (beacuse we track upstream closely). > > Unfortunately, not many people seem interested in doing this work. :( Either that or bugzilla needs a better way to allocate tasks. Having worked as a software developer for quite some time, I know how many developers would rather just work on a problem rather than try to validate bug reports and gather missing information. Personally, I would rather work on bugs that either interest me really well, or are provided in a format that allows me to work on the problem immediately. Unfortunately, qualifying bug reports (finding dupes, going back to the reporter for missing information) can only be done by people who know exactly what real problems are and what's needed to resolve them. I know this is something that requires discipline and structure ... something that doesn't always go hand-in-hand with the nature of volunteer work, but it's something that has to be addressed in order for bugs to be proactively addressed (rather than wait for someone to bring it up on a mailing list). As FOSS endeavors grow (and the number of users increase), there's got to be ways to improve on volunteer bug-fixing. Any ideas? I've always wondered if the assignment of tasks can be round-robin'd (or pick some better way of scheduling tasks that's completely and really fair, ;) ) assuming we had a couple of more volunteers. -- Richi Plana From myfedora at richip.dhs.org Tue Sep 18 17:30:08 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 11:30:08 -0600 Subject: Fedora 7 update data not valid, do not sync. In-Reply-To: <20070918105741.117f279c@localhost.localdomain> References: <20070916193942.6d45afa7@localhost.localdomain> <20070916204759.575d546a@localhost.localdomain> <20070918071351.22c33394@localhost.localdomain> <010f01c7fa03$b413f080$6601a8c0@Scott> <20070918105741.117f279c@localhost.localdomain> Message-ID: <1190136608.16960.166.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 10:57 -0400, Jesse Keating wrote: > On Tue, 18 Sep 2007 09:52:08 -0500 > "Scott" wrote: > > > Hey Jesse, > > > > Thank you very much for the heads up I bet ya that was a hell of a > > suprise when the update server went bonkers. > > > It was an ..... interesting evening. Of all the IT-related jobs I've held, nothing was more eventful (and remarkable) than systems and network administration. Anyone who's had to babysit Cisco routers or Oracle databases should be able to attest to that. Staying up at the NOC till the wee hours of the morning trying to put out a fire, etc. Hats off to the folks at RedHat keeping the servers going and pagers and cellphones close-at-hand, ;). -- Richi Plana From jima at beer.tclug.org Tue Sep 18 17:56:16 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 18 Sep 2007 12:56:16 -0500 (CDT) Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070918125634.496e9040@localhost.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> <46EFFC59.40402@gmail.com> <1190134227.16960.136.camel@localhost6.localdomain6> <20070918125634.496e9040@localhost.localdomain> Message-ID: On Tue, 18 Sep 2007, Jesse Keating wrote: > On Tue, 18 Sep 2007 10:50:27 -0600 > Richi Plana wrote: > >> But if flash-plugin uses ALSA directly, then why doesn't the audio of >> flash-plugin.i386 work on my x86_64 machine using nspluginwrapper when >> alsa-oss-libs.i386 isn't installed? > > Because the 32bit flash application needs to open the 32bit > libaoss.so.0 ? If that were the case, then flash wouldn't be using ALSA by default as dragoran claimed. Unless the flash player was recently changed to use ALSA, I don't quite buy this -- flash support (for a user) was my primary motivation for resurrecting alsa-oss. Last I heard, it does indeed use OSS. Jima From myfedora at richip.dhs.org Tue Sep 18 17:55:41 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 11:55:41 -0600 Subject: Fedora 8 Test 2 Release Notes In-Reply-To: <20070918125634.496e9040@localhost.localdomain> References: <46E959F5.4010804@fedoraproject.org> <6c3f5e6c0709141054h27934792hb4c20ea035ee80e3@mail.gmail.com> <46EADDE3.3090809@gmail.com> <20070914153110.6e83dc52@lumos.localdomain> <46EAE619.8020300@gmail.com> <1189799656.4181.2.camel@localhost.localdomain> <1189806773.24350.6.camel@localhost6.localdomain6> <20070914220043.GA5018@tango.0pointer.de> <1189807798.24350.19.camel@localhost6.localdomain6> <20070917235403.GD25080@tango.0pointer.de> <1190073970.16960.96.camel@localhost6.localdomain6> <46EFFC59.40402@gmail.com> <1190134227.16960.136.camel@localhost6.localdomain6> <20070918125634.496e9040@localhost.localdomain> Message-ID: <1190138141.16960.178.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 12:56 -0400, Jesse Keating wrote: > On Tue, 18 Sep 2007 10:50:27 -0600 > Richi Plana wrote: > > > But if flash-plugin uses ALSA directly, then why doesn't the audio of > > flash-plugin.i386 work on my x86_64 machine using nspluginwrapper when > > alsa-oss-libs.i386 isn't installed? > > Because the 32bit flash application needs to open the 32bit > libaoss.so.0 ? My mistake. After reading the replies, I went back and tried to investigate. I expected something to show that something was using /usr/lib/libaoss.so.0 while playing flash, but was surprised to when lsof returned nothing. So I removed alsa-oss-libs.i386 and flash audio still works. It's just that audio stopped working when I upgraded to the Beta version of flash-plugin and audio wouldn't work. I downgraded to the previous version (the release version) and audio still wouldn't work. Prior to that, I had removed some unneeded i386 packages on my system. When I installed alsa-oss-libs, audio came back so I assumed it was OSS. I still don't know what fixed the audio for me, but it wasn't alsa-oss-libs. Sorry for the mistake. -- Richi Plana From myfedora at richip.dhs.org Tue Sep 18 17:06:41 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 18 Sep 2007 11:06:41 -0600 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190122688.7686.231.camel@localhost.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <20070918091913.GE13425@devserv.devel.redhat.com> <1190122688.7686.231.camel@localhost.localdomain> Message-ID: <1190135201.16960.151.camel@localhost6.localdomain6> On Tue, 2007-09-18 at 09:38 -0400, Adam Jackson wrote: > If you have startup profiles from reasonable machines where we're taking > more than, oh, four seconds to start, I'd love to see them. And if that really is unavoidable, then the question becomes "What's more important: Graphical shutdown screens or fast shutdown processes?" Another sticky option, but not as crucial as when starting up. -- Richi Plana From cmadams at hiwaay.net Tue Sep 18 18:16:53 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 18 Sep 2007 13:16:53 -0500 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070918173050.0bc8680d@pensja.lam.pl> References: <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190057477.8152.33.camel@localhost.localdomain> <20070918173050.0bc8680d@pensja.lam.pl> Message-ID: <20070918181653.GB1261243@hiwaay.net> Once upon a time, Leszek Matok said: > If your service is going to break whenever it gets killed, it's also going to > break whenever the power is lost, whenever the kernel panics and whenever I > accidentaly push the button. I don't believe Fedora ships such broken > software :) I use Linux to avoid random OS crashes, I have redundant power to avoid random power failures, and I don't let others near the boxes to avoid random button pushes. I expect my system to shut down cleanly. Databases, filesystems, etc. are much happier when the rug isn't pulled out from under them. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gilboad at gmail.com Tue Sep 18 18:01:36 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 18 Sep 2007 20:01:36 +0200 Subject: Fwd: Graphical Shutdown In-Reply-To: <20070917191718.GC8848@nostromo.devel.redhat.com> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> Message-ID: <1190138496.24605.14.camel@gilboa-work-dev.localdomain> On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote: > Richi Plana (myfedora at richip.dhs.org) said: > > Are there use-cases where feedback on service shutdown would be desired? > > It seems that if there were, a couple of lines of text would be > > minimalist. > > > > If sourcing shells and scripts has become a sticky point, then perhaps > > that functionality should be included in init. Which sort of brings up > > the topic of evaluating current init replacements (or, better yet, an > > init, changerunlevel, shutdown system). > > I'd need to benchmark some more, but I suspect the delay is because of > a linear sequence of: > > - kill -TERM $pid > - wait to see if it's dead > - kill -KILL $pid > > for each service, as opposed to a global > > - kill -TERM $everything > - wait a second > - kill -KILL $everything > > Bill > Baaah... Some services need -time- to shut down. (E.g. save data to the disk) Killing everything simultaneously may/will trigger an IO race; some services just might not be able to save everything before they get -KILL'ed. - Gilboa From notting at redhat.com Tue Sep 18 18:32:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Sep 2007 14:32:38 -0400 Subject: Fwd: Graphical Shutdown In-Reply-To: <1190138496.24605.14.camel@gilboa-work-dev.localdomain> References: <3263b11b0709150425x29d0faf9m96702ba1f4a36099@mail.gmail.com> <3263b11b0709150518t6e819a04y269433dba41facc8@mail.gmail.com> <1190037053.7686.149.camel@localhost.localdomain> <1190038781.6779.7.camel@pmac.infradead.org> <20070917103448.39e6762a@localhost.localdomain> <1190052725.16960.13.camel@localhost6.localdomain6> <20070917142925.38636978@localhost.localdomain> <1190055840.16960.39.camel@localhost6.localdomain6> <20070917191718.GC8848@nostromo.devel.redhat.com> <1190138496.24605.14.camel@gilboa-work-dev.localdomain> Message-ID: <20070918183238.GA6136@nostromo.devel.redhat.com> Gilboa Davara (gilboad at gmail.com) said: > Baaah... Some services need -time- to shut down. (E.g. save data to the > disk) > Killing everything simultaneously may/will trigger an IO race; some > services just might not be able to save everything before they get > -KILL'ed. ... which is why it's opt-in. Bill From lmacken at redhat.com Tue Sep 18 19:08:33 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 18 Sep 2007 15:08:33 -0400 Subject: Latest updates missing announcements In-Reply-To: References: Message-ID: <20070918190833.GL2365@crow.myhome.westell.com> On Tue, Sep 18, 2007 at 05:18:49PM +0000, Kevin Kofler wrote: > While F7 updates now work again, I can't see any announcements for the latest > push in the fedora-package-announce archives. > > Kevin Kofler Weird.. for some reason TurboMail stopped dispatching mid-push, so only a handful of notices made it out to fedora-test-list. I just kicked the rest out the door, upgraded TurboMail on releng1, and enabled mail.debug in bodhi -- so hopefully we can track this down soon. Thanks, luke From tjb at unh.edu Tue Sep 18 19:39:40 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 18 Sep 2007 15:39:40 -0400 Subject: /bin/tcsh not in default install anymore? Message-ID: <1190144380.15361.40.camel@raptor.sr.unh.edu> Is it a bug or a feature that tcsh is no longer installed by default anymore? Maybe it was never explicitly listed but something pulled it in on a default install? Most people around here use it as their shell. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From notting at redhat.com Tue Sep 18 19:42:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Sep 2007 15:42:42 -0400 Subject: /bin/tcsh not in default install anymore? In-Reply-To: <1190144380.15361.40.camel@raptor.sr.unh.edu> References: <1190144380.15361.40.camel@raptor.sr.unh.edu> Message-ID: <20070918194242.GA10121@nostromo.devel.redhat.com> Thomas J. Baker (tjb at unh.edu) said: > Is it a bug or a feature that tcsh is no longer installed by default > anymore? Maybe it was never explicitly listed but something pulled it in > on a default install? Most people around here use it as their shell. It was done in August for rawhide/f8, mainly because nothing required it, and it is easy to add for new installs later. Bill From tjb at unh.edu Tue Sep 18 19:55:09 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 18 Sep 2007 15:55:09 -0400 Subject: /bin/tcsh not in default install anymore? In-Reply-To: <20070918194242.GA10121@nostromo.devel.redhat.com> References: <1190144380.15361.40.camel@raptor.sr.unh.edu> <20070918194242.GA10121@nostromo.devel.redhat.com> Message-ID: <1190145309.15361.50.camel@raptor.sr.unh.edu> On Tue, 2007-09-18 at 15:42 -0400, Bill Nottingham wrote: > Thomas J. Baker (tjb at unh.edu) said: > > Is it a bug or a feature that tcsh is no longer installed by default > > anymore? Maybe it was never explicitly listed but something pulled it in > > on a default install? Most people around here use it as their shell. > > It was done in August for rawhide/f8, mainly because nothing required it, > and it is easy to add for new installs later. > > Bill > In my nightmare use case scenario, install F8, enable NIS authentication at first boot, get the gdm prompt, no users are listed as their shell is tcsh, root login is now disabled, a graphically oriented user is locked out of their system. I know how to work around this, it likely won't happen for upgrades, but it does cause some problems. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From sundaram at fedoraproject.org Tue Sep 18 20:44:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 02:14:28 +0530 Subject: Root login in rawhide and display managers Message-ID: <46F038AC.9010503@fedoraproject.org> Hi Root login has been disabled in GDM for a while now in rawhide. Would KDM and other display managers be modified to be consistent with this behavior? I would prefer if it was. Rahul From pertusus at free.fr Tue Sep 18 20:57:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 18 Sep 2007 22:57:03 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F038AC.9010503@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> Message-ID: <20070918205703.GB2680@free.fr> On Wed, Sep 19, 2007 at 02:14:28AM +0530, Rahul Sundaram wrote: > Hi > > Root login has been disabled in GDM for a while now in rawhide. Would KDM > and other display managers be modified to be consistent with this behavior? > I would prefer if it was. wdm uses pam for those kind of things, is there a pam module that can disable root login? -- Pat From tmraz at redhat.com Tue Sep 18 21:14:42 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 18 Sep 2007 23:14:42 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <20070918205703.GB2680@free.fr> References: <46F038AC.9010503@fedoraproject.org> <20070918205703.GB2680@free.fr> Message-ID: <1190150082.8566.49.camel@vespa.kabelta.loc> On Tue, 2007-09-18 at 22:57 +0200, Patrice Dumas wrote: > On Wed, Sep 19, 2007 at 02:14:28AM +0530, Rahul Sundaram wrote: > > Hi > > > > Root login has been disabled in GDM for a while now in rawhide. Would KDM > > and other display managers be modified to be consistent with this behavior? > > I would prefer if it was. > > wdm uses pam for those kind of things, is there a pam module that can > disable root login? For example pam_succeed_if. auth required pam_succeed_if.so user != root quiet -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From martin.sourada at seznam.cz Tue Sep 18 21:20:44 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 18 Sep 2007 23:20:44 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? Message-ID: <1190150444.6908.19.camel@pc-notebook> hi, I noticed, xulrunner was successfully built for devel (finally), but I see there one issue - it obsoletes firefox < 2.1 but it does not supply it's functionality (unless you use only the libraries, like in epiphany, liferea, etc.). If I understand it correctly it means that tomorrow's rawhide will have a lot of dependency problems (new gecko-libs and removal of firefox) and on systems that don't have any packages dependent on firefox or gecko-libs even a removal of firefox. This isn't intended, is it? Or do you have already prepared firefox 3 (still alpha) for rawhide? An easy solution to this, IMHO, would be removal of the obsolete from xulrunner and removal of the gre(64).conf file from firefox package (it clashes with xulrunner's). Thanks, Martin -------------- 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 snecklifter at gmail.com Tue Sep 18 21:52:04 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 18 Sep 2007 22:52:04 +0100 Subject: Where is Alexander Larsson (Nautilus bug)? In-Reply-To: <1190136186.16960.161.camel@localhost6.localdomain6> References: <20070916152436.200557d1@reaver.lamontpeterson.net> <1190105940.3904.120.camel@localhost.localdomain> <1190136186.16960.161.camel@localhost6.localdomain6> Message-ID: <364d303b0709181452v46b0f1c6v77c9a5d3a0ce63f0@mail.gmail.com> On 18/09/2007, Richi Plana wrote: > > On Tue, 2007-09-18 at 10:59 +0200, Alexander Larsson wrote: > > > The bug was filed on 2007-06-08 (over 3 months ago) by J H Ettle and > > > added my +1 to it on 2007-08-29. Is Alexander missing? Is there a > > > co-maintainer who should be available? > > > > I don't know what help a co-maintainer for fedora would do. What we need > > are more people to look at bugs, come up with patches that fix them and > > post them upstream, where I can review and commit them. This will then > > instantly come back to fedora (beacuse we track upstream closely). > > > > Unfortunately, not many people seem interested in doing this work. :( > > Either that or bugzilla needs a better way to allocate tasks. > > Having worked as a software developer for quite some time, I know how > many developers would rather just work on a problem rather than try to > validate bug reports and gather missing information. Personally, I would > rather work on bugs that either interest me really well, or are provided > in a format that allows me to work on the problem immediately. > > Unfortunately, qualifying bug reports (finding dupes, going back to the > reporter for missing information) can only be done by people who know > exactly what real problems are and what's needed to resolve them. This is simply untrue. I am currently about halfway through a bug triage of all Fedora 7 kernel bugs and am doing so solely on the basis of one page from the wiki which the kernel team put together. I know nothing of kernel code but I do know having had a few pointers from people in the know what information to request under what circumstances. If I can do that for the kernel I'm sure the same goes for any application. I know this is something that requires discipline and structure ... > something that doesn't always go hand-in-hand with the nature of > volunteer work, but it's something that has to be addressed in order for > bugs to be proactively addressed (rather than wait for someone to bring > it up on a mailing list). As FOSS endeavors grow (and the number of > users increase), there's got to be ways to improve on volunteer > bug-fixing. > > Any ideas? > > I've always wondered if the assignment of tasks can be round-robin'd (or > pick some better way of scheduling tasks that's completely and really > fair, ;) ) assuming we had a couple of more volunteers. > > I think you just need to dive right into bugzilla and whatever component interests you then start with that. Bug triage is quite rewarding and people actually feel a little loved. Surely there is nothing like the hurt and pain of an un-answered bug report? Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at thecodergeek.com Tue Sep 18 21:54:59 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 18 Sep 2007 14:54:59 -0700 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190150444.6908.19.camel@pc-notebook> References: <1190150444.6908.19.camel@pc-notebook> Message-ID: <1190152499.13077.17.camel@tuxhugs> On Tue, 2007-09-18 at 23:20 +0200, Martin Sourada wrote: > I noticed, xulrunner was successfully built for devel (finally), but I > see there one issue - it obsoletes firefox < 2.1 but it does not supply > it's functionality (unless you use only the libraries, like in epiphany, > liferea, etc.). If I understand it correctly it means that tomorrow's > rawhide will have a lot of dependency problems (new gecko-libs and > removal of firefox) and on systems that don't have any packages > dependent on firefox or gecko-libs even a removal of firefox. This isn't > intended, is it? Or do you have already prepared firefox 3 (still alpha) > for rawhide? An easy solution to this, IMHO, would be removal of the > obsolete from xulrunner and removal of the gre(64).conf file from > firefox package (it clashes with xulrunner's). My understanding of this matter is that anything which depends on Gecko should be depending on gecko-devel (at build-time) and/or gecko-libs (at run-time). These virtuals are provided by both the Firefox and XULrunner packages, and therefore should allow smoothly upgrading from the former to the latter. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From martin.sourada at seznam.cz Tue Sep 18 22:11:07 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 19 Sep 2007 00:11:07 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190152499.13077.17.camel@tuxhugs> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> Message-ID: <1190153468.6908.26.camel@pc-notebook> On Tue, 2007-09-18 at 23:54 +0200, Peter Gordon wrote: > On Tue, 2007-09-18 at 23:20 +0200, Martin Sourada wrote: > > I noticed, xulrunner was successfully built for devel (finally), but I > > see there one issue - it obsoletes firefox < 2.1 but it does not supply > > it's functionality (unless you use only the libraries, like in epiphany, > > liferea, etc.). If I understand it correctly it means that tomorrow's > > rawhide will have a lot of dependency problems (new gecko-libs and > > removal of firefox) and on systems that don't have any packages > > dependent on firefox or gecko-libs even a removal of firefox. This isn't > > intended, is it? Or do you have already prepared firefox 3 (still alpha) > > for rawhide? An easy solution to this, IMHO, would be removal of the > > obsolete from xulrunner and removal of the gre(64).conf file from > > firefox package (it clashes with xulrunner's). > > My understanding of this matter is that anything which depends on Gecko > should be depending on gecko-devel (at build-time) and/or gecko-libs (at > run-time). > > These virtuals are provided by both the Firefox and XULrunner packages, > and therefore should allow smoothly upgrading from the former to the > latter. > -- This is the problem with broken deps (most of them will be solved just by rebuild or with slight changes to their spec files or if they do not have support for xulrunner yet then with some, mostly easy, patches), but there is the problem with obsoletes, too. Because xulrunner obsoletes firefox < 2.1, firefox will be removed during yum update, won't it? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bernie at codewiz.org Tue Sep 18 23:16:17 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 18 Sep 2007 19:16:17 -0400 Subject: chkconfig depens on xfs Message-ID: <46F05C41.7010708@codewiz.org> Hello, Could we drop this dependency in F8? It brings in xfs and libselinux-python. -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ From bernie at codewiz.org Tue Sep 18 23:20:46 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 18 Sep 2007 19:20:46 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190150082.8566.49.camel@vespa.kabelta.loc> References: <46F038AC.9010503@fedoraproject.org> <20070918205703.GB2680@free.fr> <1190150082.8566.49.camel@vespa.kabelta.loc> Message-ID: <46F05D4E.7060006@codewiz.org> Tomas Mraz wrote: > For example pam_succeed_if. > > auth required pam_succeed_if.so user != root quiet This would prevent root logins from ssh and the console too. Such direct root logins make sense for server-only systems, which don't normally have (or need) user accounts. -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ From ssorce at redhat.com Tue Sep 18 23:50:26 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Sep 2007 19:50:26 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F05D4E.7060006@codewiz.org> References: <46F038AC.9010503@fedoraproject.org> <20070918205703.GB2680@free.fr> <1190150082.8566.49.camel@vespa.kabelta.loc> <46F05D4E.7060006@codewiz.org> Message-ID: <1190159426.19794.14.camel@localhost.localdomain> On Tue, 2007-09-18 at 19:20 -0400, Bernardo Innocenti wrote: > Tomas Mraz wrote: > > > For example pam_succeed_if. > > > > auth required pam_succeed_if.so user != root quiet > > This would prevent root logins from ssh and the console too. Not if you put the directive in the xdm/kdm/*dm specific pam file, it doesn't have to be in the common file Simo. From tjb at unh.edu Wed Sep 19 00:10:24 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 18 Sep 2007 20:10:24 -0400 Subject: keyring primer? Message-ID: <1190160624.3268.3.camel@continuity.bakerconsulting.com> Seems gnome-keyring-pam is installed by default and according to the rpm info, it can unlock the "login" keyring on the gnome keyring. Problem I find so far is that nothing seems to use the "login" keyring. On one test desktop, Evolution uses the "default" keyring.of Anyone know how this is all supposed to work? Also I've seen references to gnome-keyring-manager being able to change the password of a keyring but the F8 version doesn't seem to have the option anywhere. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From notting at redhat.com Wed Sep 19 01:26:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 18 Sep 2007 21:26:11 -0400 Subject: chkconfig depens on xfs In-Reply-To: <46F05C41.7010708@codewiz.org> References: <46F05C41.7010708@codewiz.org> Message-ID: <20070919012611.GA21989@nostromo.devel.redhat.com> Bernardo Innocenti (bernie at codewiz.org) said: > Could we drop this dependency in F8? It brings in xfs and libselinux-python. Huh? $ rpm -qR chkconfig libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) Bill From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 01:59:38 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 03:59:38 +0200 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <46E264E4.6070501@gmx.net> References: <46E250F5.2000103@gmx.net> <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> <46E264E4.6070501@gmx.net> Message-ID: <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> On Sat, 08 Sep 2007 11:01:24 +0200, Frank B?ttner wrote: > Michael Schwendt schrieb: > > On Sat, 08 Sep 2007 09:36:21 +0200, Frank B?ttner wrote: > > > >> Hello, > >> something with the build system is wrong. > >> The build self will work, but the system says failed. > >> Have anyone see this also? > >> > >> Build ID: 36210 and 36211. > > > > It has been a topic on fedora-maintainer multiple times. Here's the > > corresponding ticket: > > > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 > > > > Yes, it's my problem too. I hope it will be fixed soon. Consider this fixed [1]. Resubmit your failed build-jobs for Extras and EPEL and see. After I'd noticed that approx. 5 out of 6 noarch build-jobs on the ppc2 server failed with the same symptoms, I've picked yum-cron as a test pkg for an online-debugging session on the ppc2 host. As another pkg that had failed very often, I've tested the final patch with ctapi-common. The reason for failure was a race condition between plague 0.4.4.1 and mock. The plague builder did not monitor the mock state accurately enough. Mock could change its state (e.g. from prepping/setup to building) while the plague builder was sleeping. In the cases I've observed, mock had exited already when plague woke up and made a wrong assumption about the state mock was in when it exited. [1] http://home.arcor.de/ms2002sep/tmp/plague-0.4.4.1-racecondition.patch From jkeating at redhat.com Wed Sep 19 02:35:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 22:35:33 -0400 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> References: <46E250F5.2000103@gmx.net> <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> <46E264E4.6070501@gmx.net> <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070918223533.4aa89ef8@localhost.localdomain> On Wed, 19 Sep 2007 03:59:38 +0200 Michael Schwendt wrote: > The reason for failure was a race condition between plague 0.4.4.1 and > mock. The plague builder did not monitor the mock state accurately > enough. Mock could change its state (e.g. from prepping/setup to > building) while the plague builder was sleeping. In the cases I've > observed, mock had exited already when plague woke up and made a wrong > assumption about the state mock was in when it exited. > > [1] > http://home.arcor.de/ms2002sep/tmp/plague-0.4.4.1-racecondition.patch This is really awesome that you were able to track this down. Thank you very much for this work. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Wed Sep 19 02:36:15 2007 From: dcbw at redhat.com (Dan Williams) Date: Tue, 18 Sep 2007 22:36:15 -0400 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> References: <46E250F5.2000103@gmx.net> <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> <46E264E4.6070501@gmx.net> <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1190169375.30482.1.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-19 at 03:59 +0200, Michael Schwendt wrote: > On Sat, 08 Sep 2007 11:01:24 +0200, Frank B?ttner wrote: > > > Michael Schwendt schrieb: > > > On Sat, 08 Sep 2007 09:36:21 +0200, Frank B?ttner wrote: > > > > > >> Hello, > > >> something with the build system is wrong. > > >> The build self will work, but the system says failed. > > >> Have anyone see this also? > > >> > > >> Build ID: 36210 and 36211. > > > > > > It has been a topic on fedora-maintainer multiple times. Here's the > > > corresponding ticket: > > > > > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 > > > > > > > Yes, it's my problem too. I hope it will be fixed soon. > > Consider this fixed [1]. Resubmit your failed build-jobs for Extras > and EPEL and see. > > After I'd noticed that approx. 5 out of 6 noarch build-jobs on the > ppc2 server failed with the same symptoms, I've picked yum-cron as a > test pkg for an online-debugging session on the ppc2 host. As another > pkg that had failed very often, I've tested the final patch with > ctapi-common. > > The reason for failure was a race condition between plague 0.4.4.1 and > mock. The plague builder did not monitor the mock state accurately > enough. Mock could change its state (e.g. from prepping/setup to > building) while the plague builder was sleeping. In the cases I've > observed, mock had exited already when plague woke up and made a wrong > assumption about the state mock was in when it exited. > > [1] http://home.arcor.de/ms2002sep/tmp/plague-0.4.4.1-racecondition.patch Workaround looks sane, diagnosis is correct, thanks for tracking this down and fixing it. Out of curiosity, did a mock update or a hardware change exacerbate the issue? We only just started seeing this after ~2 years of using plague. Dan From dennis at ausil.us Wed Sep 19 03:13:16 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 18 Sep 2007 22:13:16 -0500 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <1190169375.30482.1.camel@xo-3E-67-34.localdomain> References: <46E250F5.2000103@gmx.net> <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> <1190169375.30482.1.camel@xo-3E-67-34.localdomain> Message-ID: <200709182213.23036.dennis@ausil.us> Once upon a time Tuesday 18 September 2007, Dan Williams wrote: > Workaround looks sane, diagnosis is correct, thanks for tracking this > down and fixing it. Out of curiosity, did a mock update or a hardware > change exacerbate the issue? We only just started seeing this after ~2 > years of using plague. > > Dan not really sure, mock has not been updated on the builders for awhile. there has been no hardware changes. the only real difference that i see is that plague is being used less now. we are building EPEL-4 EPEL-5 and Extras 6 in plague. currently we have been keeping 4 cores available for x86_64 and 4 for ppc. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From vonbrand at inf.utfsm.cl Wed Sep 19 03:26:23 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 18 Sep 2007 23:26:23 -0400 Subject: /bin/tcsh not in default install anymore? In-Reply-To: <20070918194242.GA10121@nostromo.devel.redhat.com> References: <1190144380.15361.40.camel@raptor.sr.unh.edu> <20070918194242.GA10121@nostromo.devel.redhat.com> Message-ID: <200709190326.l8J3QNbG003816@laptop13.inf.utfsm.cl> Bill Nottingham wrote: > Thomas J. Baker (tjb at unh.edu) said: > > Is it a bug or a feature that tcsh is no longer installed by default > > anymore? Maybe it was never explicitly listed but something pulled it in > > on a default install? Most people around here use it as their shell. > > It was done in August for rawhide/f8, mainly because nothing required it, > and it is easy to add for new installs later. I seem to remember it was required for Perl's globbing operator. -- 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 stransky at redhat.com Wed Sep 19 05:33:29 2007 From: stransky at redhat.com (Martin Stransky) Date: Wed, 19 Sep 2007 07:33:29 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190153468.6908.26.camel@pc-notebook> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> Message-ID: <46F0B4A9.2050208@redhat.com> Martin Sourada wrote: > This is the problem with broken deps (most of them will be solved just > by rebuild or with slight changes to their spec files or if they do not > have support for xulrunner yet then with some, mostly easy, patches), > but there is the problem with obsoletes, too. Because xulrunner > obsoletes firefox < 2.1, firefox will be removed during yum update, > won't it? Both packages (firefox and xulrunner) provides gecko-libs and currently can't be installed together. I'll discus that with Chris Aillon next week (he's taking a vacation this week), he's the original submitter of that feature and xulrunner owner. martin From mclasen at redhat.com Wed Sep 19 05:45:13 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 01:45:13 -0400 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <46F0B4A9.2050208@redhat.com> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> Message-ID: <1190180713.21756.6.camel@localhost.localdomain> On Wed, 2007-09-19 at 07:33 +0200, Martin Stransky wrote: > Martin Sourada wrote: > > This is the problem with broken deps (most of them will be solved just > > by rebuild or with slight changes to their spec files or if they do not > > have support for xulrunner yet then with some, mostly easy, patches), > > but there is the problem with obsoletes, too. Because xulrunner > > obsoletes firefox < 2.1, firefox will be removed during yum update, > > won't it? > > Both packages (firefox and xulrunner) provides gecko-libs and currently > can't be installed together. > > I'll discus that with Chris Aillon next week (he's taking a vacation > this week), he's the original submitter of that feature and xulrunner owner. Hey Martin, I believe caillon is off until the end of the month (I could be wrong of course). Anyway, you might want to try and catch him on irc earlier, since we should try to get all the rebuilds against xulrunner done before test3, ie before next Tuesday... Kudos on getting it built, btw. From stransky at redhat.com Wed Sep 19 05:51:37 2007 From: stransky at redhat.com (Martin Stransky) Date: Wed, 19 Sep 2007 07:51:37 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190180713.21756.6.camel@localhost.localdomain> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190180713.21756.6.camel@localhost.localdomain> Message-ID: <46F0B8E9.5080906@redhat.com> Aha, okay. I'll try to catch him asap. Matthias Clasen wrote: > Hey Martin, > > I believe caillon is off until the end of the month (I could be wrong of > course). Anyway, you might want to try and catch him on irc earlier, > since we should try to get all the rebuilds against xulrunner done > before test3, ie before next Tuesday... > > Kudos on getting it built, btw. > From mclasen at redhat.com Wed Sep 19 06:16:54 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 02:16:54 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <1190055906.4134.21.camel@localhost.localdomain> References: <46EE899C.8070908@math.unl.edu> <1190055164.16960.28.camel@localhost6.localdomain6> <1190055906.4134.21.camel@localhost.localdomain> Message-ID: <1190182614.21756.12.camel@localhost.localdomain> On Mon, 2007-09-17 at 15:05 -0400, Matthias Clasen wrote: > On Mon, 2007-09-17 at 12:52 -0600, Richi Plana wrote: > > > > > Can't we do something like " > > " (ie. "Play Multimedia with Totem", "View Graphical Images > > with gimp", "Edit Graphical Images with gimp" or whatever the sequence > > is in other languages). Or perhaps " ()" like "Play > > Movies (Totem)" > > Any such attempts are broken i18n-wise. The only thing that works for > translation is complete strings. > I felt that I should maybe write down how I think this can be addressed. Changing translations is something that needs to happen upstream, and needs to have buy-in. The most realistic plan of attack, imo is to add a new field, e.g DescriptiveName and define that the value can contain placeholders for the name and generic name. Then we can add DescriptiveName=%N - %G or similar, which will work for a good number of locales, and still allow DescriptiveName[de]=Donnervogel, bringt die Post to override on a per-locale basis. As you can see, this requires a desktop entry spec addition, unless you want to go X-Fedora-, which I wouldn't recommend. Also, it may need gnome-menus api additions. In any case, this is not F8 material. From fedora at leemhuis.info Wed Sep 19 06:34:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 19 Sep 2007 08:34:09 +0200 Subject: Can Name=GenericName go away now, please? In-Reply-To: <1190182614.21756.12.camel@localhost.localdomain> References: <46EE899C.8070908@math.unl.edu> <1190055164.16960.28.camel@localhost6.localdomain6> <1190055906.4134.21.camel@localhost.localdomain> <1190182614.21756.12.camel@localhost.localdomain> Message-ID: <46F0C2E1.4060001@leemhuis.info> On 19.09.2007 08:16, Matthias Clasen wrote: > On Mon, 2007-09-17 at 15:05 -0400, Matthias Clasen wrote: >> On Mon, 2007-09-17 at 12:52 -0600, Richi Plana wrote: >>> Can't we do something like " >>> " (ie. "Play Multimedia with Totem", "View Graphical Images >>> with gimp", "Edit Graphical Images with gimp" or whatever the sequence >>> is in other languages). Or perhaps " ()" like "Play >>> Movies (Totem)" >> Any such attempts are broken i18n-wise. The only thing that works for >> translation is complete strings. > I felt that I should maybe write down how I think this can be addressed. > > Changing translations is something that needs to happen upstream, and > needs to have buy-in. The most realistic plan of attack, imo is to add a > new field, e.g > > DescriptiveName > > and define that the value can contain placeholders for the name and > generic name. > Then we can add > > DescriptiveName=%N - %G > > or similar, which will work for a good number of locales, and still > allow > > DescriptiveName[de]=Donnervogel, bringt die Post > > to override on a per-locale basis. > > As you can see, this requires a desktop entry spec addition, unless you > want to go X-Fedora-, which I wouldn't recommend. > > Also, it may need gnome-menus api additions. In any case, this is not F8 > material. In addition: wouldn't it make sense to display the DescriptiveName normally if just one app of that kind is installed? E.g. if just Evolution was installed -> you just find "E-Mail-Client" in your menu. If both Thunderbird and Evo are installed display "Evolution (E-Mail-Client) " and "Thunderbird (E-Mail-Client)" or something like that? Just my 2 cent. CU knird From jakub at redhat.com Tue Sep 18 23:33:06 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 18 Sep 2007 19:33:06 -0400 Subject: -D_FORTIFY_SOURCE=2 and C++ Message-ID: <20070918233306.GG25210@devserv.devel.redhat.com> Hi! Starting with gcc-4.1.2-25 and glibc-2.6.90-14 -D_FORTIFY_SOURCE=2 protects not only C code, but also C++. There have been several security issues already which would have been unexploitable if this checking was in place earlier. All the mem*, str* etc. routines that were previously protected in C will now do so in C++ as well, similarly *printf won't accept %n if format string is in writable memory, open{,at}{,64} functions are checked too (compile time detecteable O_CREAT with only 2 arguments (3 for openat{,64}) results in link time errors, if it is unclear whether oflag arg has O_CREAT or not at compile time and only 2 (resp. 3 for openat{,64}) args are provided, runtime checking is done). BTW, even for C open is no longer a function-like macro, while it is desirable to fix packages that don't allow open to be defined as function-like macro, it will no longer be a necessity for F8 to change this. If you see any bugs on the toolchain side (rather than newly discovered package bugs), please let us know in bugzilla ASAP. Thanks. Jakub From martin.sourada at seznam.cz Wed Sep 19 07:03:03 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 19 Sep 2007 09:03:03 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <46F0B4A9.2050208@redhat.com> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> Message-ID: <1190185383.6908.34.camel@pc-notebook> On Wed, 2007-09-19 at 07:33 +0200, Martin Stransky wrote: > Both packages (firefox and xulrunner) provides gecko-libs and currently > can't be installed together. > AFAIK, the gecko-lib provides should not be a problem. The only problem I am aware of is that both firefox and xulrunner packages have /etc/gre.d/gre(64).conf files. Martin > I'll discus that with Chris Aillon next week (he's taking a vacation > this week), he's the original submitter of that feature and xulrunner owner. > > martin > -------------- 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 alexl at redhat.com Wed Sep 19 07:14:27 2007 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 19 Sep 2007 09:14:27 +0200 Subject: keyring primer? In-Reply-To: <1190160624.3268.3.camel@continuity.bakerconsulting.com> References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> Message-ID: <1190186067.3904.151.camel@localhost.localdomain> On Tue, 2007-09-18 at 20:10 -0400, Thomas J. Baker wrote: > Seems gnome-keyring-pam is installed by default and according to the rpm > info, it can unlock the "login" keyring on the gnome keyring. Problem I > find so far is that nothing seems to use the "login" keyring. On one > test desktop, Evolution uses the "default" keyring.of > > Anyone know how this is all supposed to work? Also I've seen references > to gnome-keyring-manager being able to change the password of a keyring > but the F8 version doesn't seem to have the option anywhere. http://live.gnome.org/GnomeKeyring/Pam From bernie at codewiz.org Wed Sep 19 08:09:43 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 19 Sep 2007 04:09:43 -0400 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <20070919012611.GA21989@nostromo.devel.redhat.com> References: <46F05C41.7010708@codewiz.org> <20070919012611.GA21989@nostromo.devel.redhat.com> Message-ID: <46F0D947.8040202@codewiz.org> Bill Nottingham wrote: > Bernardo Innocenti (bernie at codewiz.org) said: >> Could we drop this dependency in F8? It brings in xfs and libselinux-python. > > Huh? Silly me. It's chkfontpath. And I also had a typo in the subject... becoming senile? -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 08:37:52 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 10:37:52 +0200 Subject: Builds on buildsys.fedoraproject.org fails, but the build self will work. In-Reply-To: <1190169375.30482.1.camel@xo-3E-67-34.localdomain> References: <46E250F5.2000103@gmx.net> <20070908103657.435011dd.mschwendt.tmp0701.nospam@arcor.de> <46E264E4.6070501@gmx.net> <20070919035938.88bb8b6e.mschwendt.tmp0701.nospam@arcor.de> <1190169375.30482.1.camel@xo-3E-67-34.localdomain> Message-ID: <20070919103752.8a8da406.mschwendt.tmp0701.nospam@arcor.de> On Tue, 18 Sep 2007 22:36:15 -0400, Dan Williams wrote: > > [1] http://home.arcor.de/ms2002sep/tmp/plague-0.4.4.1-racecondition.patch > > Workaround looks sane, diagnosis is correct, thanks for tracking this > down and fixing it. Out of curiosity, did a mock update or a hardware > change exacerbate the issue? We only just started seeing this after ~2 > years of using plague. I have doubts that the .../mock-state/status file is in sync with mock. It either shows symptoms of buffering or changes too quickly. It stays in "prep" for most of the time, then very quickly steps through "setu" -> "buil" -> "done". So quickly that plague-builder cannot sleep for 3 secs without missing the state changes before mock is done. Perhaps this is different for longer builds which don't run for just 6-8 minutes. Look at this debug log excerpt made when plague-builder was monitoring the "prepping" step (the "string" value is the four chars from the mock-state file after a refresh): Running _status_prepping: prepping string = prep _watch_mock(): waitpid = 0,0 continuing _status_prepping: prepping string = prep Running _status_prepping: prepping string = done ^ here mock-state changed while plague-builder was sleeping for 3s => from "prep" to mock-exit in plague-builder's view (!) => when not reloading mock's state file to verify string = done _watch_mock(): waitpid = 4139,0 _watch_mock(): PID 4139 exit status 0 Setting Status Good! - failed ^ this is based on the assumption that a mock-exit during "prepping" would always be an error condition despite the zero exit code init clean prep This may take a while setup build ending done ^ this is what mock has processed actually while plague-builder assumed that mock still was doing only "prep"+"setu" Results and/or logs in: /mnt/build/builder_work/46bb3113e41a4745e4b1217cb9d5b6b8ef5cc73b/result Cleaning up the buildroot... /usr/bin/setarch ppc32 /usr/bin/mock clean --uniqueext=46bb3113e41a4745e4b1217cb9d5b6b8ef5cc73b -r fedora-6-ppc-core From abo at kth.se Wed Sep 19 08:45:56 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 19 Sep 2007 10:45:56 +0200 Subject: Goal: Increased Modularity? In-Reply-To: <46DFFD5A.40609@gmail.com> References: <1188923882.12969.36.camel@localhost6.localdomain6> <604aa7910709041057t6855e1dap3023f5a81ba23d7f@mail.gmail.com> <1188932892.12969.107.camel@localhost6.localdomain6> <604aa7910709041228v43484cc5qdedab40dec64b0eb@mail.gmail.com> <46DDBE45.7080703@gmail.com> <46DED57F.7080607@gmail.com> <1189009413.1641.22.camel@localhost6.localdomain6> <1189010800.32292.19.camel@rousalka.dyndns.org> <46DEE878.4080006@gmail.com> <1189020585.3241.23.camel@rousalka.dyndns.org> <46DF12F3.4030405@gmail.com> <1189058894.3446.7.camel@rousalka.dyndns.org> <46DFA4C0.1000007@gmail.com> <53854.192.54.193.51.1189065244.squirrel@rousalka.dyndns.org> <46DFFD5A.40609@gmail.com> Message-ID: <1190191557.26487.290.camel@home.alexander.bostrom.net> On Thu, 2007-09-06 at 08:15 -0500, Les Mikesell wrote: > It's just annoying that the > packaged location is different from what Sun uses in their RPM version > and Sun should be somewhat of an authority on matters pertaining to java Sun is certainly no authority on how Fedora should build rpms or how GNU/Linux systems should organise directories. But the nice thing is, they're now sort of following the JPackage conventions in their official Java 1.6 RPM:s, so no need for JPackage rpms. Just run their install script (which they confusingly call a self-extracting archive), and you get some rpms installed which interact nicely with alternatives. > - and even more annoying that in this long chain of questions I still > don't have the simple answer of where JAVA_HOME has been hidden for some > small variety of JVMs. Uhm... They're all very consistently placed in /usr/lib/jvm, each directory there is a JAVA_HOME. I wouldn't call that hidden. It's a nice scheme. And Richi Plana pointed out how to set JAVA_HOME already... /abo From buildsys at redhat.com Wed Sep 19 10:59:53 2007 From: buildsys at redhat.com (Build System) Date: Wed, 19 Sep 2007 06:59:53 -0400 Subject: rawhide report: 20070919 changes Message-ID: <200709191059.l8JAxraR008520@porkchop.devel.redhat.com> New package climm Text/line based ICQ client with many features New package compiz-fusion Collection of Compiz Fusion plugins for Compiz New package compiz-fusion-extras Additional Compiz Fusion plugins for Compiz New package grsync A Gtk+ GUI for rsync New package ladspa-amb-plugins Ambisonics LADSPA plugins New package mencal Menstruation calendar New package perl-Test-Script Cross-platform basic tests for scripts New package pguiman The PostgreSQL database server managing tool New package xulrunner XUL Runtime for Gecko Applications Updated Packages: ConsoleKit-0.2.3-1.fc8 ---------------------- * Tue Sep 18 2007 Matthias Clasen - 0.2.3-1 - Update to 0.2.3 anaconda-11.3.0.31-1 -------------------- * Tue Sep 18 2007 Chris Lumens 11.3.0.31-1 - Really include new Japanese font (katzj, #279931). - Use /dev/live-osimg-min if it exists (katzj). - Copy driver disk contents to /root (#289751). - Write out /root/anaconda-ks.cfg earlier (#292571). * Mon Sep 17 2007 Jeremy Katz - 11.3.0.30-1 - Firewire module names changed again (#292421) - Some liveinst improvements (Douglas McClendon) - Create tape devices (dlehman) - Fix traceback on no more mirrors (dlehman) - Fix treeinfo path to stage2 (wwoods) - Remove unused graphics (notting) - Look at root path for kernels (Douglas McClendon) - Netlink fixes (pjones) anthy-9100b-1.fc8 ----------------- * Tue Sep 18 2007 Akira TAGOH - 9100b-1 - New upstream release. apr-1.2.11-2 ------------ * Tue Sep 18 2007 Joe Orton 1.2.11-2 - fix %check for non-multilib 64-bit platforms * Sun Sep 09 2007 Bojan Smojver 1.2.11-1 - bump up to 1.2.11 - drop openlfs patch (fixed upstream) * Sun Sep 02 2007 Joe Orton 1.2.9-4 - fix API/ABI of 32-bit builds (#254241) automake17-1.7.9-11 ------------------- * Tue Sep 18 2007 Karsten Hopp 1.7.9-11 - next attempt of getting the conflicts/obsoletes right (Stepan Kasal) * Tue Sep 18 2007 Karsten Hopp 1.7.9-10 - fix obsoletes - mv check into %check bc-1.06-29 ---------- * Tue Sep 18 2007 Zdenek Prikryl 1.06-29 - update of source URI * Wed Aug 22 2007 Zdenek Prikryl 1.06-28 - fixed incorrect processing of decimal separator - Resolves: #253729 * Thu Jul 26 2007 Zdenek Prikryl 1.06-27 - dc accepts the input which contains wrong symbols of radix in same way like bc - Resolves: #151844 - Added library string.h to remove warnings. c2070-0.99-3.fc8 ---------------- checkpolicy-2.0.4-1.fc8 ----------------------- * Tue Sep 18 2007 Dan Walsh - 2.0.4-1 * Merged handle unknown policydb flag support from Eric Paris. Adds new command line options -U {allow, reject, deny} for selecting the flag when a base module or kernel policy is built. clusterssh-3.19.1-3.fc8 ----------------------- * Tue Sep 18 2007 Patrick "Jima" Laughton 3.19.1-3 - License clarification - Switch back to unmodified, upstream-provided tarball cups-1:1.3.1-3.fc8 ------------------ * Tue Sep 18 2007 Tim Waugh 1:1.3.1-3 - Write printcap when a remote queue is deleted (bug #290831). * Tue Sep 18 2007 Tim Waugh 1:1.3.1-2 - Avoid write printcap unnecessarily (bug #290831). * Mon Sep 17 2007 Tim Waugh 1:1.3.1-1 - 1.3.1. cvs-1.11.22-12.fc8 ------------------ * Mon Sep 17 2007 Jiri Moskovcak - 1.11.22-12 - rewriten previous patch when trying to diff removed files - Resolves: #277501, #242049 * Mon Jul 30 2007 Jiri Moskovcak - 1.11.22-11 - fix diff on removed file when "-r BASE" tag is used - Resolves: #242049 * Fri Jun 15 2007 Stepan Kasal - 1.11.22-10 - make sccs2rcs non-executable, so that find-requires does not add dependency on /bin/csh when /bin/csh is available - add CSH=/bin/csh to configure, so that sccs2rcs #! line is not corrupted when /bin/csh is not available - replace the deprecated %makeinstall (see Packaging Guidelines) cyrus-sasl-2.1.22-7 ------------------- * Tue Sep 18 2007 Steve Conklin 2.1.22-7 - use db4 version 4.6.19 bz#249737 dclib-0.3.10-2.fc8 ------------------ * Tue Sep 18 2007 Luke Macken 0.3.10-2 - Remove RSA MD5 implementation in favor of the gnulib implementation. Patches taken from upstream ticket: https://sourceforge.net/tracker/?func=detail&atid=897767&aid=1796674&group_id=181579 dejavu-fonts-2.20-1.fc8 ----------------------- * Tue Sep 18 2007 Nicolas Mailhot ??? 2.20-1 ??? 2.20 final ??? bugfix release (Hebrew fixes mostly) dnsmasq-2.40-1.fc8 ------------------ * Tue Sep 18 2007 Patrick "Jima" Laughton 2.40-1 - Finalized upstream release - Removing URLs from patch lines (CVS is the authoritative source) - Added more magic to make spinning rc/test packages more seamless docbook-utils-0.6.14-9.fc8 -------------------------- * Tue Sep 18 2007 Ondrej Vasik 0.6.14-9 - fixed typo in Source URL e2fsprogs-1.40.2-7.fc8 ---------------------- * Tue Sep 18 2007 Eric Sandeen 1.40.2-7 - Fix blkid fat probe when there is a real MBR (#290951) * Tue Sep 18 2007 Oliver Falk 1.40.2-6 - Add alpha to the header wrappers eclipse-1:3.3.0-20.fc8 ---------------------- * Tue Sep 18 2007 Andrew Overholt 3.3.0-20 - Move requirements on subclipse, cdt, mylyn, etc. to comps.xml. * Mon Sep 10 2007 Andrew Overholt 3.3.0-19 - Don't require subclipse, cdt, or rpm-editor on ppc64. * Fri Sep 07 2007 Ben Konrath 3.3.0-18 - Build 1.6 plugins when building with IcedTea. eclipse-mylyn-2.0.0-7.fc8 ------------------------- * Tue Sep 18 2007 Andrew Overholt 2.0.0-7 - Fix filename of webcore jar. * Tue Sep 18 2007 Andrew Overholt 2.0.0-6 - Re-add gcj support (accidentally removed the flag). eel2-2.20.0-1.fc8 ----------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 ekiga-2.0.11-1.fc8 ------------------ * Tue Sep 18 2007 Daniel Veillard - 2.0.11-1 - Upgrade to ekiga-2.0.11 * Sun Apr 15 2007 Daniel Veillard - 2.0.9-1 - Upgrade to ekiga-2.0.9 * Mon Mar 12 2007 Daniel Veillard - 2.0.7-1 - Upgrade to ekiga-2.0.7 emacs-22.1-5.fc8 ---------------- * Wed Sep 12 2007 Chip Coldwell - 22.1-5 - require xorg-x11-fonts-ISO8859-1-100dpi instead of 75dpi (Resolves: bz281861) - drop broken python mode (Resolves: bz262801) eog-2.20.0-1.fc8 ---------------- * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 evolution-sharp-0.14.0.1-1.fc8 ------------------------------ * Tue Sep 18 2007 Matthew Barnes - 0.14.0.1-1.fc8 - Update to 0.14.0.1 evolution-webcal-2.12.0-1.fc8 ----------------------------- * Tue Sep 18 2007 Matthew Barnes - 2.12.0-1.fc8 - Update to 2.12.0 exiv2-0.15-4.fc8 ---------------- * Tue Sep 18 2007 Rex Dieter 0.15-4 - -libs: -Requires: %name fast-user-switch-applet-2.20.0-1.fc8 ------------------------------------ * Tue Sep 18 2007 Matthias Clasen 2.20.0-1 - Update to 2.20.0 * Sun Sep 16 2007 Matthias Clasen 2.18.0-3 - Don't try to throttle gnome-screensaver (#246188) - Make the close button on the error dialog work - Make the handling of large numbers of users more efficient (#353831) * Mon Aug 06 2007 Matthias Clasen 2.18.0-2 - Use %find_lang for help files, too firstboot-1.4.37-1.fc8 ---------------------- * Tue Sep 18 2007 Chris Lumens 1.4.37-1 - Remove sound card module (#294101). gchempaint-0.8.3-1.fc8 ---------------------- * Sun Aug 26 2007 Julian Sikorski - 0.8.3-1 - Updated to 0.8.3 - Dropped upstreamed patches - Made the License tag more precise - Changed the way rpaths are dealt with, previous one was breaking the build gconf-editor-2.20.0-1.fc8 ------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gd-2.0.35-1.fc8 --------------- * Tue Sep 18 2007 Ivana Varekova 2.0.35-1 - update to 2.0.35 * Tue Sep 04 2007 Ivana Varekova 2.0.34-3 - fix font paths (#225786#5) - fix pkgconfig Libs flag (#225786#4) * Thu Feb 22 2007 Ivana Varekova 2.0.34-2 - incorporate package review feedback gdm-1:2.20.0-1.fc8 ------------------ * Tue Sep 18 2007 Matthias Clasen - 1:2.20.0-1 - Update to 2.20.0 * Wed Sep 12 2007 Ray Strode - 1:2.19.8-4 - Change default password character back to circle instead of asterisk (bug 287951) * Fri Sep 07 2007 Ray Strode - 1:2.19.8-3 - rebuild --with-selinux glibc-2.6.90-14 --------------- * Tue Sep 18 2007 Jakub Jelinek 2.6.90-14 - -D_FORTIFY_SOURCE{,=2} support for C++ - fortification of fread{,_unlocked} - support *scanf m allocation modifier (%ms, %mls, %mc, ...) - in -std=c99 or -D_XOPEN_SOURCE=600 mode don't recognize %as, %aS and %a[ as a GNU extension for *scanf - fix splice, vmsplice, tee return value, make them cancellation points - mq_open checking - use inline function rather than function-like macro for open{,at}{,64} checking - IFA_F_OPTIMISTIC handling in getaddrinfo (#259681) - fix an ABBA deadlock in ld.so (#284171) - remove sparc{32,64} unwind info from _start and clone gnome-bluetooth-0.9.1-3.fc8 --------------------------- * Tue Sep 18 2007 - Ondrej Vasik - 0.9.1-3 - fixed wrong source URL gnome-chemistry-utils-0.8.3-1.fc8 --------------------------------- * Mon Sep 17 2007 Julian Sikorski - 0.8.3-1 - Updated to 0.8.3 gnome-games-1:2.20.0.1-1.fc8 ---------------------------- * Tue Sep 18 2007 Matthias Clasen - 1:2.20.0.1-1 - Update to 2.20.0.1 * Tue Sep 18 2007 Matthias Clasen - 1:2.20.0-1 - Update to 2.20.0 * Tue Sep 04 2007 Matthias Clasen - 1:2.19.92-1 - 2.19.92 gnome-games-extra-data-2.20.0-1 ------------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-icon-theme-2.20.0-2.fc8 ----------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-2 - Rebuild with newer icon-naming-utils gnome-keyring-2.20-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20-1 - Update to 2.20 * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 * Sun Aug 12 2007 Matthias Clasen - 2.19.90-1 - Update to 2.19.90 gnome-menus-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-nettool-2.20.0-1.fc8 -------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-panel-2.20.0.1-1.fc8 -------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0.1-1 - Update to 2.20.0.1 gnome-screensaver-2.20.0-1.fc8 ------------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-terminal-2.18.2-1.fc8 --------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.18.2-1 - Update to 2.18.2 gnome-utils-1:2.20.0.1-1.fc8 ---------------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0.1-1 - Update to 2.20.0.1 gnupg2-2.0.7-1.fc8 ------------------ * Mon Sep 10 2007 Rex Dieter 2.0.7-1 - gnupg-2.0.7 * Fri Aug 24 2007 Rex Dieter 2.0.6-2 - respin (libassuan) goffice04-0.4.3-1.fc8 --------------------- * Sat Sep 15 2007 Julian Sikorski - 0.4.3-1 - Updated to 0.4.3 gstreamer-plugins-farsight-0.12.5-1.fc8 --------------------------------------- * Tue Sep 18 2007 Brian Pepple - 0.12.5-1 - Update to 0.12.5. - Drop memset patch, fixed upstream. gtk2-2.12.0-2.fc8 ----------------- * Tue Sep 18 2007 Matthias Clasen - 2.12.0-2 - Adapt to tracker ABI changes gucharmap-1.10.1-1.fc8 ---------------------- * Tue Sep 18 2007 Matthias Clasen - 1.10.1-1 - Update to 1.10.1 * Tue Aug 07 2007 Matthias Clasen - 1.10.0-2 - Update license field - Use %find_lang for help files hexedit-1.2.12-6.fc8 -------------------- * Tue Sep 18 2007 Jiri Moskovcak 1.2.12-6 - changed to new upstream source tarbal with some minor fixes httpd-2.2.6-3 ------------- * Mon Sep 17 2007 Joe Orton 2.2.6-3 - add fix for SSL library string regression (PR 43334) - use powered-by logo from system-logos (#250676) - preserve timestamps for installed config files im-chooser-0.5.2-1.fc8 ---------------------- * Tue Sep 18 2007 Akira TAGOH - 0.5.2-1 - New upstream release. - Fix to allow users disabling IM. jd-1.9.6-0.5.beta070918.fc8 --------------------------- * Tue Sep 18 2007 Mamoru Tasaka - 1.9.6-0.5.beta070918 - 1.9.6 beta 070918 * Sun Aug 05 2007 Mamoru Tasaka - 1.9.6-0.2.beta070804 - 1.9.6 beta 070804 release 2 * Sat Aug 04 2007 Mamoru Tasaka - 1.9.6-0.1.beta070804 - 1.9.6 beta 070804 kbd-1.12-25.fc8 --------------- * Tue Sep 18 2007 Vitezslav Crhonek - 1.12-25 - Add new romanian keymap Resolves: #253892 kdenetwork-7:3.5.7-6.fc8 ------------------------ * Tue Sep 18 2007 Rex Dieter 7:3.5.7-6 - fix ppp patch * Mon Sep 17 2007 Rex Dieter 7:3.5.7-5 - +Requires: jasper (kopete yahoo support) * Wed Aug 29 2007 Rex Dieter 7:3.5.7-4 - ppp patch (to enable kppp build again) kernel-2.6.23-0.187.rc6.git7.fc8 -------------------------------- * Tue Sep 18 2007 Eric Sandeen - ext3 bugfixes: fix potential corruption in do_split dx leaf split (#28650), handle dx directory corruption gracefully, w/o BUG (#236464). - xfs bugfixes: setfattr/getfattr/getversion 32-bit compat fixes (#291981), log replay vs. filesize update fixes from sgi. * Tue Sep 18 2007 John W. Linville - Update bits from wireless-2.6 and wireless-dev * Mon Sep 17 2007 Chuck Ebbert - Linux 2.6.23-rc6-git7 kflickr-0.9-1.fc8 ----------------- * Tue Sep 18 2007 Michael Stahnke - 0.9-1 - License updated per new guidelines - Bump for upstream release (0.9) koan-0.6.1-2.fc8 ---------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) * Thu Aug 09 2007 Michael DeHaan - 0.6.0-1 - Upstream changes (see CHANGELOG) * Thu Jul 26 2007 Michael DeHaan - 0.5.2-1 - Upstream changes (see CHANGELOG) lagan-2.0-1.fc8 --------------- * Tue Sep 18 2007 Christian Iseli 2.0-1 - New upstream release. libbtctl-0.9.0-3.fc8 -------------------- * Tue Sep 18 2007 - Ondrej Vasik - 0.9.0-3 - fixed wrong Source URL libgnome-2.20.0-2.fc8 --------------------- * Tue Sep 18 2007 Ray Strode - 2.20.0-2 - the location of the default background setting changed, update correct schema input file * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Tue Aug 28 2007 M??ir??n Duffy - 2.19.1-9 - Change default background to Infinity libgnomekbd-2.20.0-1.fc8 ------------------------ * Mon Sep 17 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 libieee1284-0.2.11-1.fc8 ------------------------ * Tue Sep 18 2007 Tim Waugh 0.2.11-1 - 0.2.11 (bug #246406). libkdcraw-0.1.2-1.fc8 --------------------- * Tue Sep 18 2007 Marcin Garski 0.1.2-1 - Update to 0.1.2 libkexiv2-0.1.6-1.fc8 --------------------- * Tue Sep 18 2007 Rex Dieter 1.1.6-1 - libkexiv2-0.1.6 libnetfilter_queue-0.0.15-1.fc8 ------------------------------- * Tue Sep 18 2007 Paul P Komkoff Jr - 0.0.15-1 - new upstream version libselinux-2.0.34-1.fc8 ----------------------- * Tue Sep 18 2007 Dan Walsh - 2.0.34-1 - Upgrade to latest from NSA * Fix selabel option flag setting for 64-bit from Stephen Smalley. * Tue Sep 18 2007 Dan Walsh - 2.0.33-2 - Change matchpatcon to use syslog instead of syserror libsepol-2.0.10-1.fc8 --------------------- * Tue Sep 18 2007 Dan Walsh 2.0.10-1 - Upgrade to latest from NSA * Merged support for the handle_unknown policydb flag from Eric Paris. libtorrent-0.11.8-1.fc8 ----------------------- * Tue Sep 18 2007 Marek Mahut - 0.11.8-1 - New upstream version lzop-1.02-0.5.rc1.fc8 --------------------- * Tue Sep 18 2007 Nicolas Mailhot ??? 1.02-0.5.rc1 ??? License fix man-pages-2.65-1.fc8 -------------------- * Tue Sep 18 2007 Ivana Varekova - 2.65-1 - update to 2.65 * Tue Aug 14 2007 Ivana Varekova - 2.64-1 - update to 2.64 - remove obsolete patch * Tue Aug 07 2007 Ivana Varekova - 2.63-3 - add iconv patch (245040) thanks to Josef Kubin mash-0.2.5-1.fc8 ---------------- * Tue Sep 18 2007 Bill Nottingham 0.2.5-1 - handle valgrind for multilib differently (#294761) nautilus-2.20.0-1.fc8 --------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 * Mon Aug 13 2007 Matthias Clasen - 2.19.90-1 - Update to 2.19.90 ocaml-pcre-5.12.2-1.fc8 ----------------------- * Tue Sep 18 2007 Richard W.M. Jones - 5.12.2-1 - New upstream version 5.12.2. - Clarified license is LGPLv2. - Strip .so file. octave-6:2.9.14-1.fc8 --------------------- * Tue Sep 18 2007 Quentin Spencer 2.9.14-1 - New release. - Remove redundant menu category in desktop file (bug 274431). - Update license tag. - Add qhull-devel as new build dependency. * Thu Jul 26 2007 Quentin Spencer 2.9.13-1 - New release. - Changed ufsparse-devel dependency to suitesparse-devel. - Add configure flag to close bug 245562. - Add directories for add-on packages (bug 234012). - Since texinfo is now separate from tetex, it is a build requirement. * Wed May 23 2007 Quentin Spencer 2.9.12-1 - New release. opal-2.2.11-1.fc8 ----------------- * Tue Sep 18 2007 Daniel Veillard - 2.2.11-1 - upstream release of 2.2.11 * Tue Sep 18 2007 Daniel Veillard - 2.2.10-1 - upstream release of 2.2.10 - includes the 2 cisco patches openldap-2.3.38-2.fc8 --------------------- * Mon Sep 17 2007 Jan Safranek 2.3.38-2.fc8 - skeleton /etc/sysconfig/ldap added - new SLAPD_LDAP option to turn off listening on ldap:/// (#292591) - fixed checking of SSL (#292611) - fixed upgrade with empty database openobex-1.3-8.fc8 ------------------ * Tue Sep 18 2007 Jiri Moskovcak 1.3-8 - Changed sources in specfile URL to point to the right location pam-0.99.8.1-7.fc8 ------------------ * Tue Sep 18 2007 Tomas Mraz 0.99.8.1-7 - when SELinux enabled always run the helper binary instead of direct shadow access (#293181) * Fri Aug 24 2007 Tomas Mraz 0.99.8.1-6 - do not ask for blank password when SELinux confined (#254044) - initialize homedirs in namespace init script (original patch by dwalsh) * Wed Aug 22 2007 Tomas Mraz 0.99.8.1-5 - most devices are now handled by HAL and not pam_console (patch by davidz) - license tag fix - multifunction scanner device support (#251468) perl-DateTime-1:0.41-1.fc8 -------------------------- * Mon Sep 17 2007 Steven Pritchard 1:0.41-1 - Update to DateTime 0.41. - Update to DateTime::Locale 0.35. - Update to DateTime::TimeZone 0.67. * Wed Aug 29 2007 Fedora Release Engineering - 1:0.39-2 - Rebuild for selinux ppc32 issue. * Sun Jul 22 2007 Steven Pritchard 1:0.39-1 - Update to DateTime 0.39. - Update to DateTime::TimeZone 0.6603. perl-Module-Load-Conditional-0.18-1.fc8 --------------------------------------- * Tue Sep 18 2007 Steven Pritchard 0.18-1 - Update to 0.18. - BR Test::More. perl-Test-Deep-0.098-1.fc8 -------------------------- * Tue Sep 18 2007 Steven Pritchard 0.098-1 - Update to 0.098. perl-Test-Tester-0.106-1.fc8 ---------------------------- * Tue Sep 18 2007 Steven Pritchard 0.106-1 - Update to 0.106. - BR Test::Builder. perl-X11-Protocol-0.56-1.fc8 ---------------------------- * Tue Sep 18 2007 Patrick "Jima" Laughton 0.56-1 - New upstream release (bugfix) - Added BR for perl(ExtUtils::MakeMaker) - License clarification - Minor spec cleanup, mainly to suppress rpmlint warnings perl-YAML-Syck-0.97-1.fc8 ------------------------- * Tue Sep 18 2007 Steven Pritchard 0.97-1 - Update to 0.97. pidgin-2.2.0-2.fc8 ------------------ * Tue Sep 18 2007 Warren Togami - 2.2.0-2 - License clarification - Backport patches to fix memory leaks - Backport patches to fix proxy settings & status scores * Tue Sep 18 2007 Warren Togami - 2.2.0-1 - 2.2.0 pirut-1.3.19-1.fc8 ------------------ * Tue Sep 18 2007 Jeremy Katz - 1.3.19-1 - Make reboot vs warnings clearer (#292011) - Select on row activation in lists (#292261) - Don't show the (truncated) URL being downloaded (#292271) - Fix handling of already mounted volumes - Search improvements (skvidal) psutils-1.17-27.fc8 ------------------- * Tue Sep 18 2007 Martin Bacovsky - 1.17-27 - fixed Source url pointing to non-existing site pungi-1.1.1-1.fc8 ----------------- * Tue Sep 18 2007 Jesse Keating - 1.1.1-1 - Create a media.repo file on the first iso pwlib-1.10.10-2.fc8 ------------------- * Tue Sep 18 2007 Daniel Veillard - 1.10.10-2 - rebuild for chain-build * Tue Sep 18 2007 Daniel Veillard - 1.10.10-1 - Update to 1.10.10 rtorrent-0.7.8-1.fc8 -------------------- * Tue Sep 18 2007 Marek Mahut - 0.7.8-1 - New upstream release rusers-0.17-52.fc8 ------------------ * Tue Sep 18 2007 Jiri Moskovcak 0.17-52 - Fixed init script to work properly with rpcbind scim-1.4.7-4.fc8 ---------------- * Tue Sep 18 2007 Jens Petersen - 1.4.7-4 - source none.conf in xinput script when skipping scim startup * Thu Sep 13 2007 Jens Petersen - 1.4.7-3 - add scim-1.4.7-ja-sinhala-236715.patch to add Japanese translation of Sinhala (#236715) - gtk2 now owns /usr/lib/gtk-2.0/immodules - add Nepali meta package - specify full paths in xinput script and use SHORT_DESC * Fri Aug 17 2007 Jens Petersen - 1.4.7-2 - update License field - modify xinput.d script to not startup scim if no IMEs are installed - devel package requires pkgconfig - improve meta package macro language in summary and description - subpackage rawcode engine - update meta packages for m17n-contrib - move ownership of libdir dirs to main package selinux-policy-3.0.8-2.fc8 -------------------------- * Tue Sep 18 2007 Dan Walsh 3.0.8-2 - Remove hplip_etc_t change back to etc_t. * Mon Sep 17 2007 Dan Walsh 3.0.8-1 - Allow cron to search nfs and samba homedirs slang-2.1.2-1.fc8 ----------------- * Mon Sep 17 2007 Miroslav Lichvar - 2.1.2-1 - update to 2.1.2 speex-1.2-0.3.beta2 ------------------- * Tue Sep 18 2007 - Bastien Nocera - 1.2-0.3.beta2 - Update to Beta 2 system-config-rootpassword-1.1.10-4.fc8 --------------------------------------- * Fri Sep 07 2007 Matthias Clasen - 1.1.10-4 - Fix menu categories tcpdump-14:3.9.7-5.fc8 ---------------------- * Tue Sep 18 2007 Miroslav Lichvar - 14:3.9.7-5 - support decoding IKEv2 packets traceroute-3:2.0.8-1.fc8 ------------------------ * Tue Sep 18 2007 Martin Bacovsky - 3:2.0.8-1 - upgrade to new upstream traceroute-2.0.8 - fixed traceroute.8 install source path and traceroute6.8 link source - fixed typo in Source0 URL * Tue Aug 28 2007 Dmitry Butskoy - Change URL and Source0 (upstream is at SourceForge now) vte-0.16.9-1.fc8 ---------------- * Tue Sep 18 2007 Matthias Clasen - 0.16.9-1 - Update to 0.16.9 xinetd-2:2.3.14-14.fc8 ---------------------- * Thu Sep 06 2007 Jan Safranek - 2:2.3.14-14 - removed inetdconvert script, nobody is using inetd xscreensaver-1:5.03-7.fc8 ------------------------- * Wed Sep 19 2007 Mamoru Tasaka - 1:5.03-7 - Remove noreplace flag from XScreenSaver.ad as this is updated automatically. zenity-2.20.0-2.fc8 ------------------- * Tue Sep 18 2007 Matthias Clasen - 2.20.0-2 - Drop yelp dependency to avoid exploding live cds (#295091) Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.i386 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 digikam - 0.9.2-4.fc8.i386 requires libkexiv2.so.1 digikam - 0.9.2-4.fc8.i386 requires libkdcraw.so.1 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kipi-plugins - 0.1.4-2.fc8.i386 requires libkexiv2.so.1 kipi-plugins - 0.1.4-2.fc8.i386 requires libkdcraw.so.1 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.x86_64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) digikam - 0.9.2-4.fc8.i386 requires libkexiv2.so.1 digikam - 0.9.2-4.fc8.i386 requires libkdcraw.so.1 digikam - 0.9.2-4.fc8.x86_64 requires libkdcraw.so.1()(64bit) digikam - 0.9.2-4.fc8.x86_64 requires libkexiv2.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.x86_64 requires libkdcraw.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.x86_64 requires libkexiv2.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.i386 requires libkexiv2.so.1 kipi-plugins - 0.1.4-2.fc8.i386 requires libkdcraw.so.1 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 claws-mail-plugins - 3.0.0-1.fc8.ppc requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 digikam - 0.9.2-4.fc8.ppc requires libkdcraw.so.1 digikam - 0.9.2-4.fc8.ppc requires libkexiv2.so.1 digikam - 0.9.2-4.fc8.ppc64 requires libkdcraw.so.1()(64bit) digikam - 0.9.2-4.fc8.ppc64 requires libkexiv2.so.1()(64bit) gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kipi-plugins - 0.1.4-2.fc8.ppc64 requires libkdcraw.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.ppc64 requires libkexiv2.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.ppc requires libkexiv2.so.1 kipi-plugins - 0.1.4-2.fc8.ppc requires libkdcraw.so.1 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins - 3.0.0-1.fc8.ppc64 requires claws-mail-plugins-spamreport = 0:3.0.0-1.fc8 digikam - 0.9.2-4.fc8.ppc64 requires libkdcraw.so.1()(64bit) digikam - 0.9.2-4.fc8.ppc64 requires libkexiv2.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.ppc64 requires libkdcraw.so.1()(64bit) kipi-plugins - 0.1.4-2.fc8.ppc64 requires libkexiv2.so.1()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From rdieter at math.unl.edu Wed Sep 19 11:49:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Sep 2007 06:49:22 -0500 Subject: Root login in rawhide and display managers References: <46F038AC.9010503@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Root login has been disabled in GDM for a while now in rawhide. Would > KDM and other display managers be modified to be consistent with this > behavior? I would prefer if it was. What's the rationale (again?) for disabling root login? -- Rex From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 12:01:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 14:01:03 +0200 Subject: diff missing in plague buildroot Message-ID: <20070919140103.bed29d24.mschwendt.tmp0701.nospam@arcor.de> http://buildsys.fedoraproject.org/logs/fedora-6-extras/36389-fslint-2.24-1.fc6/noarch/build.log Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/fslint-2.24-1-root-mockbuild /usr/lib/rpm/check-files: line 25: diff: command not found Strange. Has anybody changed the FE6 buildroot defs? Doesn't rpm-build require diffutils anymore? EPEL5+4 don't seem to be affected. From alan at redhat.com Wed Sep 19 12:05:25 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 08:05:25 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> Message-ID: <20070919120525.GA5410@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 06:49:22AM -0500, Rex Dieter wrote: > > Root login has been disabled in GDM for a while now in rawhide. Would > > KDM and other display managers be modified to be consistent with this > > behavior? I would prefer if it was. > > What's the rationale (again?) for disabling root login? I assume its to make sure that if your LDAP or NIS services fail you are totally screwed and cannot rescue the machine. Alan From rjones at redhat.com Wed Sep 19 12:04:18 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 19 Sep 2007 13:04:18 +0100 Subject: rpmlint message '%ifarch-applied-patch' Message-ID: <46F11042.2020302@redhat.com> What does this rpmlint message mean? I don't understand why it's harmful to have patches only applying to particular architectures. ----- ical.src: W: %ifarch-applied-patch Patch3: ical-2.2-ia64.patch A patch is applied inside an %ifarch block. Patches must be applied on all architectures and may contain necessary configure and/or code patch to be effective only on a given arch. ----- The patch in question is: --- ical-2.2/calendar/uid.C.ia64 Wed May 29 22:51:03 1996 +++ ical-2.2/calendar/uid.C Mon Apr 30 00:13:58 2001 @@ -13,7 +13,7 @@ #ifndef HAVE_GETHOSTNAME_PROTO #ifdef linux -extern "C" int gethostname(char*, unsigned int); +extern "C" int gethostname(char*, unsigned long); #else /* !linux */ extern "C" int gethostname(char*, int); #endif /* linux */ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Wed Sep 19 12:04:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 17:34:09 +0530 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> Message-ID: <46F11039.3020802@fedoraproject.org> Rex Dieter wrote: > Rahul Sundaram wrote: > >> Root login has been disabled in GDM for a while now in rawhide. Would >> KDM and other display managers be modified to be consistent with this >> behavior? I would prefer if it was. > > What's the rationale (again?) for disabling root login? See fedora-desktop list discussions. The goal IIUC was to discourage root login via display managers since there isn't normally a reason to do that and it presents a higher security risk. This has also been a often requested feature in the past and with the introduction of Policy Kit makes it even more sense to do so. Users who are inclined to ignore this safeguard can always turn the option on. Rahul From jnovy at redhat.com Wed Sep 19 12:10:13 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 19 Sep 2007 14:10:13 +0200 Subject: rpmlint message '%ifarch-applied-patch' In-Reply-To: <46F11042.2020302@redhat.com> References: <46F11042.2020302@redhat.com> Message-ID: <20070919121013.GA2601@dhcp-lab-186.brq.redhat.com> Hi, On Wed, Sep 19, 2007 at 01:04:18PM +0100, Richard W.M. Jones wrote: > What does this rpmlint message mean? I don't understand why it's harmful > to have patches only applying to particular architectures. > > ----- > > ical.src: W: %ifarch-applied-patch Patch3: ical-2.2-ia64.patch > A patch is applied inside an %ifarch block. Patches must be applied > on all architectures and may contain necessary configure and/or code > patch to be effective only on a given arch. > > ----- It likely means that you have a construct like this in a spec file: %ifarch x86_64 Patch1: some.patch %endif what means that the patch is included to srpm only on the x86_64 arch. This is wrong since the patch has to be included in sprm for all arches even though it's applied only on one arch. I had build problems related to this recently ;) -- Jindrich Novy http://people.redhat.com/jnovy/ From jakub at redhat.com Wed Sep 19 12:17:18 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 19 Sep 2007 08:17:18 -0400 Subject: rpmlint message '%ifarch-applied-patch' In-Reply-To: <46F11042.2020302@redhat.com> References: <46F11042.2020302@redhat.com> Message-ID: <20070919121718.GJ25210@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 01:04:18PM +0100, Richard W.M. Jones wrote: > What does this rpmlint message mean? I don't understand why it's > harmful to have patches only applying to particular architectures. It is harmful, because the patch isn't tested on all the other arches. Also eventually if further patches are applied which touch the same locations you end up with a twisty unmaintanable maze of per-arch patches. > The patch in question is: That is very bogus patch. 1) gethostbyname has the second argument size_t, so if anything, you should patch it everywhere for the right type 2) you really should find out why configure doesn't find gethostname prototype on Linux, it is present in unistd.h in glibc on all arches, unless you request a namespace which forbids it in unistd.h. > --- ical-2.2/calendar/uid.C.ia64 Wed May 29 22:51:03 1996 > +++ ical-2.2/calendar/uid.C Mon Apr 30 00:13:58 2001 > @@ -13,7 +13,7 @@ > #ifndef HAVE_GETHOSTNAME_PROTO > > #ifdef linux > -extern "C" int gethostname(char*, unsigned int); > +extern "C" int gethostname(char*, unsigned long); > #else /* !linux */ > extern "C" int gethostname(char*, int); > #endif /* linux */ > Jakub From denis at poolshark.org Wed Sep 19 12:16:50 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 14:16:50 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F11039.3020802@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> Message-ID: <46F11332.2040708@poolshark.org> Rahul Sundaram wrote: > since there isn't normally a reason to > do that I beg to differ here, that are many scenarios where the security issues are irrelevant. I see such systems on a daily basis here at work. From rc040203 at freenet.de Wed Sep 19 12:23:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 19 Sep 2007 14:23:49 +0200 Subject: rpmlint message '%ifarch-applied-patch' In-Reply-To: <20070919121013.GA2601@dhcp-lab-186.brq.redhat.com> References: <46F11042.2020302@redhat.com> <20070919121013.GA2601@dhcp-lab-186.brq.redhat.com> Message-ID: <1190204630.11618.53.camel@mccallum.corsepiu.local> On Wed, 2007-09-19 at 14:10 +0200, Jindrich Novy wrote: > Hi, > > On Wed, Sep 19, 2007 at 01:04:18PM +0100, Richard W.M. Jones wrote: > > What does this rpmlint message mean? I don't understand why it's harmful > > to have patches only applying to particular architectures. > > > > ----- > > > > ical.src: W: %ifarch-applied-patch Patch3: ical-2.2-ia64.patch > > A patch is applied inside an %ifarch block. Patches must be applied > > on all architectures and may contain necessary configure and/or code > > patch to be effective only on a given arch. > > > > ----- > > It likely means that you have a construct like this in a spec file: > > %ifarch x86_64 > Patch1: some.patch > %endif Besides this, this patch seems rather silly to me. Instead of trying to mess around with local defs of gethostname(), you should probably better "#include ". Ralf PS.: __linux__ is the correct (POSIX-compliant) define to identify linux. From mattdm at mattdm.org Wed Sep 19 12:25:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 08:25:54 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919120525.GA5410@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> Message-ID: <20070919122553.GA4526@jadzia.bu.edu> On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote: > > What's the rationale (again?) for disabling root login? > I assume its to make sure that if your LDAP or NIS services fail you > are totally screwed and cannot rescue the machine. Proposed alternative: enable root logins, but customize the default root GUI environment so it is a clear and simple rescue/configuration workspace, not just another user's desktop. At BU, we've been doing this for a long time -- you get system-config-users and a terminal window and that's it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Wed Sep 19 12:23:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 17:53:22 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <46F11332.2040708@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> Message-ID: <46F114BA.6010308@fedoraproject.org> Denis Leroy wrote: > Rahul Sundaram wrote: >> since there isn't normally a reason to do that > > I beg to differ here, that are many scenarios where the security issues > are irrelevant. I see such systems on a daily basis here at work. You snipped out the later part of my mail. If security concerns are irrelevant, just turn on the option to enable root login just like you are free to turn off the firewall or SELinux. KDM root login was disabled until the last release anyway. Rahul From rjones at redhat.com Wed Sep 19 12:29:34 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 19 Sep 2007 13:29:34 +0100 Subject: rpmlint message '%ifarch-applied-patch' In-Reply-To: <1190204630.11618.53.camel@mccallum.corsepiu.local> References: <46F11042.2020302@redhat.com> <20070919121013.GA2601@dhcp-lab-186.brq.redhat.com> <1190204630.11618.53.camel@mccallum.corsepiu.local> Message-ID: <46F1162E.5060808@redhat.com> Ralf Corsepius wrote: > On Wed, 2007-09-19 at 14:10 +0200, Jindrich Novy wrote: >> Hi, >> >> On Wed, Sep 19, 2007 at 01:04:18PM +0100, Richard W.M. Jones wrote: >>> What does this rpmlint message mean? I don't understand why it's harmful >>> to have patches only applying to particular architectures. >>> >>> ----- >>> >>> ical.src: W: %ifarch-applied-patch Patch3: ical-2.2-ia64.patch >>> A patch is applied inside an %ifarch block. Patches must be applied >>> on all architectures and may contain necessary configure and/or code >>> patch to be effective only on a given arch. >>> >>> ----- >> It likely means that you have a construct like this in a spec file: >> >> %ifarch x86_64 >> Patch1: some.patch >> %endif > > Besides this, this patch seems rather silly to me. > > Instead of trying to mess around with local defs of gethostname(), > you should probably better "#include ". > > Ralf > > PS.: __linux__ is the correct (POSIX-compliant) define to identify > linux. This code is ancient history anyway. Development on ical was _abandoned_ around 1994. https://bugzilla.redhat.com/show_bug.cgi?id=296161 Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From limb at jcomserv.net Wed Sep 19 12:04:10 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 19 Sep 2007 07:04:10 -0500 (CDT) Subject: Root login in rawhide and display managers In-Reply-To: <46F038AC.9010503@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> Message-ID: <44147.63.85.68.164.1190203450.squirrel@mail.jcomserv.net> > Hi > > Root login has been disabled in GDM for a while now in rawhide. Would > KDM and other display managers be modified to be consistent with this > behavior? I would prefer if it was. I assume exceptions are made for LiveCDs? > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From denis at poolshark.org Wed Sep 19 12:36:35 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 14:36:35 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F114BA.6010308@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> Message-ID: <46F117D3.70102@poolshark.org> Rahul Sundaram wrote: > Denis Leroy wrote: >> Rahul Sundaram wrote: >>> since there isn't normally a reason to do that >> >> I beg to differ here, that are many scenarios where the security >> issues are irrelevant. I see such systems on a daily basis here at work. > > You snipped out the later part of my mail. If security concerns are > irrelevant, just turn on the option to enable root login just like you > are free to turn off the firewall or SELinux. Is that an anaconda option ? Obviously it's impossible to run gdmsetup since one can't login as root :-) From snecklifter at gmail.com Wed Sep 19 12:39:30 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 19 Sep 2007 13:39:30 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <20070919122553.GA4526@jadzia.bu.edu> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> Message-ID: <364d303b0709190539j153facbcp1c3a9c00d76883e8@mail.gmail.com> On 19/09/2007, Matthew Miller wrote: > > On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote: > > > What's the rationale (again?) for disabling root login? > > I assume its to make sure that if your LDAP or NIS services fail you > > are totally screwed and cannot rescue the machine. > > Proposed alternative: enable root logins, but customize the default root > GUI environment so it is a clear and simple rescue/configuration > workspace, > not just another user's desktop. > > At BU, we've been doing this for a long time -- you get > system-config-users > and a terminal window and that's it. Or we could actually leave the user in control of the system and allow them to nuke it if they want to. Give them enough rope and all that. I recall that one system used to place a black bomb image in each corner of the desktop and use a big red desktop background. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Wed Sep 19 12:41:33 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 19 Sep 2007 13:41:33 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <46F114BA.6010308@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> Message-ID: <364d303b0709190541s408ae83cm367a4b83d8a3469f@mail.gmail.com> On 19/09/2007, Rahul Sundaram wrote: > > Denis Leroy wrote: > > Rahul Sundaram wrote: > >> since there isn't normally a reason to do that > > > > I beg to differ here, that are many scenarios where the security issues > > are irrelevant. I see such systems on a daily basis here at work. > > You snipped out the later part of my mail. If security concerns are > irrelevant, just turn on the option to enable root login just like you > are free to turn off the firewall or SELinux. Unless I'm very much mistaken, the ability to turn on/off root login is not an option during install. This differs a little from firewall and SEL therefore. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Wed Sep 19 12:39:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:09:29 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <46F117D3.70102@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> Message-ID: <46F11881.6030103@fedoraproject.org> Denis Leroy wrote: > Rahul Sundaram wrote: >> Denis Leroy wrote: >>> Rahul Sundaram wrote: >>>> since there isn't normally a reason to do that >>> >>> I beg to differ here, that are many scenarios where the security >>> issues are irrelevant. I see such systems on a daily basis here at work. >> >> You snipped out the later part of my mail. If security concerns are >> irrelevant, just turn on the option to enable root login just like you >> are free to turn off the firewall or SELinux. > > Is that an anaconda option ? Obviously it's impossible to run gdmsetup > since one can't login as root :-) Why would it be impossible? Anaconda allows to set a root password and first boot asks for setting up a normal user. Login via the normal user and use su to run gdmsetup or switch to a virtual terminal and login as root. Rahul From sundaram at fedoraproject.org Wed Sep 19 12:41:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:11:12 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <364d303b0709190541s408ae83cm367a4b83d8a3469f@mail.gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <364d303b0709190541s408ae83cm367a4b83d8a3469f@mail.gmail.com> Message-ID: <46F118E8.9090805@fedoraproject.org> Christopher Brown wrote: > > Unless I'm very much mistaken, the ability to turn on/off root login is > not an option during install. This differs a little from firewall and > SEL therefore. Not really. You can turn either of them, on or off post installation. You can do a root login as explained in my other mail. Again KDM root login was disabled until the last release and I am merely asking for the user experience to be consistent across display manager. Rahul From k.georgiou at imperial.ac.uk Wed Sep 19 12:48:12 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Wed, 19 Sep 2007 13:48:12 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <46F11039.3020802@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> Message-ID: <20070919124811.GA20979@imperial.ac.uk> On Wed, Sep 19, 2007 at 05:34:09PM +0530, Rahul Sundaram wrote: > Rex Dieter wrote: > >Rahul Sundaram wrote: > > > >>Root login has been disabled in GDM for a while now in rawhide. Would > >>KDM and other display managers be modified to be consistent with this > >>behavior? I would prefer if it was. > > > >What's the rationale (again?) for disabling root login? > > See fedora-desktop list discussions. The goal IIUC was to discourage > root login via display managers since there isn't normally a reason to > do that and it presents a higher security risk. Aren't those users the ones that most likely will need to login as root (with a GUI) at some point in the future because for example they managed to disable their user account? Do you really expect them to be able use the command line from the console? Kostas Georgiou From sundaram at fedoraproject.org Wed Sep 19 12:49:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:19:03 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070919124811.GA20979@imperial.ac.uk> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> Message-ID: <46F11ABF.8000601@fedoraproject.org> Kostas Georgiou wrote: > Aren't those users the ones that most likely will need to login as root > (with a GUI) at some point in the future because for example they > managed to disable their user account? Do you really expect them to be > able use the command line from the console? I don't see how normal users would somehow manage to disable their user account. Can you explain such a scenario that you have experienced? I guess they do need to use a console in such circumstances. Rahul From alan at redhat.com Wed Sep 19 12:52:58 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 08:52:58 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919122553.GA4526@jadzia.bu.edu> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> Message-ID: <20070919125258.GA7373@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote: > Proposed alternative: enable root logins, but customize the default root > GUI environment so it is a clear and simple rescue/configuration workspace, > not just another user's desktop. Thats an extremely good idea and one I like a great deal From denis at poolshark.org Wed Sep 19 12:49:19 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 14:49:19 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F11881.6030103@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> Message-ID: <46F11ACF.40302@poolshark.org> Rahul Sundaram wrote: > Denis Leroy wrote: >> Rahul Sundaram wrote: >>> Denis Leroy wrote: >>>> Rahul Sundaram wrote: >>>>> since there isn't normally a reason to do that >>>> >>>> I beg to differ here, that are many scenarios where the security >>>> issues are irrelevant. I see such systems on a daily basis here at >>>> work. >>> >>> You snipped out the later part of my mail. If security concerns are >>> irrelevant, just turn on the option to enable root login just like >>> you are free to turn off the firewall or SELinux. >> >> Is that an anaconda option ? Obviously it's impossible to run gdmsetup >> since one can't login as root :-) > > Why would it be impossible? Anaconda allows to set a root password and > first boot asks for setting up a normal user. Login via the normal user > and use su to run gdmsetup or switch to a virtual terminal and login as > root. Creating a normal user is not mandatory in anaconda (as it should be). Maybe anaconda should only enable the option if no normal users were creating during installation ? The idea here is to avoid a scenario where after a successful X installation you just can't login into the system! From sundaram at fedoraproject.org Wed Sep 19 12:51:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:21:12 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <44147.63.85.68.164.1190203450.squirrel@mail.jcomserv.net> References: <46F038AC.9010503@fedoraproject.org> <44147.63.85.68.164.1190203450.squirrel@mail.jcomserv.net> Message-ID: <46F11B40.6080100@fedoraproject.org> Jon Ciesla wrote: >> Hi >> >> Root login has been disabled in GDM for a while now in rawhide. Would >> KDM and other display managers be modified to be consistent with this >> behavior? I would prefer if it was. > > I assume exceptions are made for LiveCDs? Live images enable timed auto login as normal user with no password for any user. First boot is only set to run when you install it to a hard disk. Rahul From petersen at redhat.com Wed Sep 19 12:55:01 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 19 Sep 2007 22:55:01 +1000 Subject: I18n Bug Event Message-ID: <46F11C25.7060606@redhat.com> The Fedora I18n team is hosting a Fedora i18n bug event starting this Friday: When? We will start with an all day bug squashing event during 2007-09-20 23:00 UTC to 2007-09-21 12:00 UTC, and continue the effort until the Test3 devel freeze is due to start on Tuesday. What? We will basically be focusing on bugs from this list: but if you have other urgent issues related to i18n that you believe need addressing for F8 you're welcome to bring those along to discuss. How to help? (see ) Bugzilla: unless you just want to ask questions you'll need a bugzilla account of course: see the above link. IRC: Freenode #fedora-i18n (people from the I18n Team should be online Friday (at least during 2007-09-20 23:00 UTC to 2007-09-21 12:00) and also on Monday - during the weekend it may be more sporadic but please hang around if you can) QA/Testing: install Test2 or current Fedora development (rawhide) and helping to test and triage bugs, reporting problems, etc. Mailing-list: fedora-i18n-list at redhat.com - bugzilla is the preferred place for discussion but if you can't join us or find us on irc, or are unsure about something and have questions feel free to ask on the mailing-list. Goal? This event is taking place just before the the F8 Test3 freeze in order to improve the quality of the F8 release and help close/move more i18n bugs before the final devel freeze. Hope you will be able to join us and help squash those bugs. :-) Have fun, Jens From sundaram at fedoraproject.org Wed Sep 19 12:53:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:23:28 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <46F11ACF.40302@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> Message-ID: <46F11BC8.8070700@fedoraproject.org> Denis Leroy wrote: > > Creating a normal user is not mandatory in anaconda (as it should be). > > Maybe anaconda should only enable the option if no normal users were > creating during installation ? The idea here is to avoid a scenario > where after a successful X installation you just can't login into the > system! There was some discussions in fedora-desktop list into moving this option away from first boot into Anaconda itself so that this would be mandatory. This is indeed a good thing to do in this instance. Do file a RFE in Anaconda. The idea was to entirely get rid of first boot if possible in the desktop spin. Rahul From alan at redhat.com Wed Sep 19 13:00:08 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 09:00:08 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F11ACF.40302@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> Message-ID: <20070919130008.GC7373@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote: > Creating a normal user is not mandatory in anaconda (as it should be). It should not be. In an environment using single sign on systems, ldap, NIS or yellow pages it makes no sense. Secondly the security argument here is simply peeing in the wind as you can hit ctrl-alt-f1 and log in as root on a text console. Alan From alan at redhat.com Wed Sep 19 13:00:58 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 09:00:58 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F11BC8.8070700@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> Message-ID: <20070919130058.GD7373@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > There was some discussions in fedora-desktop list into moving this > option away from first boot into Anaconda itself so that this would be > mandatory. This is indeed a good thing to do in this instance. Do file a > RFE in Anaconda. The idea was to entirely get rid of first boot if If you file an RFE please post the number here so I can attach a violent disagreement to the bug From limb at jcomserv.net Wed Sep 19 12:34:48 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 19 Sep 2007 07:34:48 -0500 (CDT) Subject: Root login in rawhide and display managers In-Reply-To: <20070919125258.GA7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <20070919125258.GA7373@devserv.devel.redhat.com> Message-ID: <2183.63.85.68.164.1190205288.squirrel@mail.jcomserv.net> > On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote: >> Proposed alternative: enable root logins, but customize the default root >> GUI environment so it is a clear and simple rescue/configuration >> workspace, >> not just another user's desktop. > > Thats an extremely good idea and one I like a great deal +1 > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mclasen at redhat.com Wed Sep 19 13:06:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 09:06:38 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130008.GC7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> Message-ID: <1190207198.4236.5.camel@localhost.localdomain> On Wed, 2007-09-19 at 09:00 -0400, Alan Cox wrote: > On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote: > > Creating a normal user is not mandatory in anaconda (as it should be). > > It should not be. In an environment using single sign on systems, ldap, NIS > or yellow pages it makes no sense. > > Secondly the security argument here is simply peeing in the wind as you can > hit ctrl-alt-f1 and log in as root on a text console. Yeah, but then you don't walk away from your root session expecting the screensaver to kick in - which it doesn't for root. Face it, running a desktop session as root is just broken. From denis at poolshark.org Wed Sep 19 13:06:57 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 15:06:57 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130008.GC7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> Message-ID: <46F11EF1.3090405@poolshark.org> Alan Cox wrote: > On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote: >> Creating a normal user is not mandatory in anaconda (as it should be). > > It should not be. In an environment using single sign on systems, ldap, NIS > or yellow pages it makes no sense. Yes I agree with you here, my statement above was confusing. Having to create a normal user should absolutely not be mandatory. From denis at poolshark.org Wed Sep 19 13:08:29 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 15:08:29 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F11BC8.8070700@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> Message-ID: <46F11F4D.3060900@poolshark.org> Rahul Sundaram wrote: > Denis Leroy wrote: > >> >> Creating a normal user is not mandatory in anaconda (as it should be). >> >> Maybe anaconda should only enable the option if no normal users were >> creating during installation ? The idea here is to avoid a scenario >> where after a successful X installation you just can't login into the >> system! > > There was some discussions in fedora-desktop list into moving this > option away from first boot into Anaconda itself so that this would be > mandatory. Wait, make creating a normal user mandatory ?!? I don't know who's on fedora-desktop, but it must be people with absolutely no real-life experience with linux systems and how they're used. Just ask your RHEL customers. From limb at jcomserv.net Wed Sep 19 12:37:13 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 19 Sep 2007 07:37:13 -0500 (CDT) Subject: Root login in rawhide and display managers In-Reply-To: <20070919130008.GC7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> Message-ID: <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> > On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote: >> Creating a normal user is not mandatory in anaconda (as it should be). > > It should not be. In an environment using single sign on systems, ldap, > NIS > or yellow pages it makes no sense. > > Secondly the security argument here is simply peeing in the wind as you > can > hit ctrl-alt-f1 and log in as root on a text console. Can this information be included on the login screen, somewhere small and discreet, like in faded text on the bottom left or something? I was unaware of it and would have found it useful one evening some time ago. > Alan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From sundaram at fedoraproject.org Wed Sep 19 13:07:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 18:37:18 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <46F11F4D.3060900@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> Message-ID: <46F11F06.8030607@fedoraproject.org> Denis Leroy wrote: > Wait, make creating a normal user mandatory ?!? I don't know who's on > fedora-desktop, but it must be people with absolutely no real-life > experience with linux systems and how they're used. > > Just ask your RHEL customers. Again, this is for the desktop spin. RHEL customers don't come into the picture at all. Rahul From mclasen at redhat.com Wed Sep 19 13:14:55 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 09:14:55 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F11F4D.3060900@poolshark.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> Message-ID: <1190207695.4236.8.camel@localhost.localdomain> On Wed, 2007-09-19 at 15:08 +0200, Denis Leroy wrote: > > There was some discussions in fedora-desktop list into moving this > > option away from first boot into Anaconda itself so that this would be > > mandatory. > > Wait, make creating a normal user mandatory ?!? I don't know who's on > fedora-desktop, but it must be people with absolutely no real-life > experience with linux systems and how they're used. Thanks for bringing the thread down to this level so quickly, that allows us all to move on to more useful thing faster... Anyway, why don't you come over to fedora-desktop and find out who "those people" are ? From denis at poolshark.org Wed Sep 19 13:13:59 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Sep 2007 15:13:59 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <1190207198.4236.5.camel@localhost.localdomain> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> Message-ID: <46F12097.5040209@poolshark.org> Matthias Clasen wrote: > On Wed, 2007-09-19 at 09:00 -0400, Alan Cox wrote: >> On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote: >>> Creating a normal user is not mandatory in anaconda (as it should be). >> It should not be. In an environment using single sign on systems, ldap, NIS >> or yellow pages it makes no sense. >> >> Secondly the security argument here is simply peeing in the wind as you can >> hit ctrl-alt-f1 and log in as root on a text console. > > Yeah, but then you don't walk away from your root session expecting the > screensaver to kick in - which it doesn't for root. Yes but who cares about a screensaver when you 1) use a kvm switch 2) have no monitor connected, but use vlc-server (you do need gnome installed for that) 3) have no monitor connected, but use a virtual remote console (as in our sun systems). As mentioned earlier, the best solution may be to turn the root desktop into a special rescue environment... From jakub at redhat.com Tue Sep 18 23:33:06 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 18 Sep 2007 19:33:06 -0400 Subject: -D_FORTIFY_SOURCE=2 and C++ Message-ID: <20070918233306.GG25210@devserv.devel.redhat.com> Hi! Starting with gcc-4.1.2-25 and glibc-2.6.90-14 -D_FORTIFY_SOURCE=2 protects not only C code, but also C++. There have been several security issues already which would have been unexploitable if this checking was in place earlier. All the mem*, str* etc. routines that were previously protected in C will now do so in C++ as well, similarly *printf won't accept %n if format string is in writable memory, open{,at}{,64} functions are checked too (compile time detecteable O_CREAT with only 2 arguments (3 for openat{,64}) results in link time errors, if it is unclear whether oflag arg has O_CREAT or not at compile time and only 2 (resp. 3 for openat{,64}) args are provided, runtime checking is done). BTW, even for C open is no longer a function-like macro, while it is desirable to fix packages that don't allow open to be defined as function-like macro, it will no longer be a necessity for F8 to change this. If you see any bugs on the toolchain side (rather than newly discovered package bugs), please let us know in bugzilla ASAP. Thanks. Jakub _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ajackson at redhat.com Wed Sep 19 13:21:50 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 19 Sep 2007 09:21:50 -0400 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <46F0D947.8040202@codewiz.org> References: <46F05C41.7010708@codewiz.org> <20070919012611.GA21989@nostromo.devel.redhat.com> <46F0D947.8040202@codewiz.org> Message-ID: <1190208110.7686.271.camel@localhost.localdomain> On Wed, 2007-09-19 at 04:09 -0400, Bernardo Innocenti wrote: > Bill Nottingham wrote: > > Bernardo Innocenti (bernie at codewiz.org) said: > >> Could we drop this dependency in F8? It brings in xfs and libselinux-python. > > > > Huh? > > Silly me. It's chkfontpath. > > And I also had a typo in the subject... becoming senile? % rpm -q --requires chkfontpath /sbin/pidof libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libpopt.so.0()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) xfs % rpm -q --whatrequires chkfontpath no package requires chkfontpath So I don't see where you're getting libselinux-python from at all, nor why you think you need chkfontpath in the first place. - ajax From walters at redhat.com Wed Sep 19 13:42:35 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 09:42:35 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130058.GD7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> Message-ID: On 9/19/07, Alan Cox wrote: > On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > > There was some discussions in fedora-desktop list into moving this > > option away from first boot into Anaconda itself so that this would be > > mandatory. This is indeed a good thing to do in this instance. Do file a > > RFE in Anaconda. The idea was to entirely get rid of first boot if > > If you file an RFE please post the number here so I can attach a violent > disagreement to the bug > Alan, we are trying to improve the experience for the specific audience of artists, developers and the like who download the Desktop Live image from the web site and want to install it on a laptop or home PC. No one is saying that all these changes are applicable to every situation in which Linux is used. No one is advocating taking away the old style Linux installation (the Fedora "choose your own adventure" DVD). From jkeating at redhat.com Tue Sep 18 13:49:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 09:49:12 -0400 Subject: Can Name=GenericName go away now, please? In-Reply-To: <46F0C2E1.4060001@leemhuis.info> References: <46EE899C.8070908@math.unl.edu> <1190055164.16960.28.camel@localhost6.localdomain6> <1190055906.4134.21.camel@localhost.localdomain> <1190182614.21756.12.camel@localhost.localdomain> <46F0C2E1.4060001@leemhuis.info> Message-ID: <20070918094912.1ecd38cd@localhost.localdomain> On Wed, 19 Sep 2007 08:34:09 +0200 Thorsten Leemhuis wrote: > In addition: wouldn't it make sense to display the DescriptiveName > normally if just one app of that kind is installed? E.g. if just > Evolution was installed -> you just find "E-Mail-Client" in your menu. > If both Thunderbird and Evo are installed display "Evolution > (E-Mail-Client) " and "Thunderbird (E-Mail-Client)" or something like > that? > > Just my 2 cent. I think that would be pretty terrible, as your menu would change if you happened to add another app. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Sep 18 13:51:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 09:51:49 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130058.GD7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> Message-ID: <20070918095149.7481105c@localhost.localdomain> On Wed, 19 Sep 2007 09:00:58 -0400 Alan Cox wrote: > On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > > There was some discussions in fedora-desktop list into moving this > > option away from first boot into Anaconda itself so that this would > > be mandatory. This is indeed a good thing to do in this instance. > > Do file a RFE in Anaconda. The idea was to entirely get rid of > > first boot if > > If you file an RFE please post the number here so I can attach a > violent disagreement to the bug My suggested method was that you were presented with a user add option in anaconda, but the ability to opt out (for say network login systems). If you opt-out then the no root login policy could be lifted, but if you opt-in and create a local user then only that local user would be allowed to graphical log in upon boot (unless you manually change policy through a gui tool or a hand edit.) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Sep 19 13:50:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 19:20:41 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> Message-ID: <46F12931.9070808@fedoraproject.org> Jon Ciesla wrote: > Can this information be included on the login screen, somewhere small and > discreet, like in faded text on the bottom left or something? I was > unaware of it and would have found it useful one evening some time ago. > Sounds useful if the method to return back is also mentioned. I am not sure there is a way to describe this without making the interface cluttered. You can file a request in http://bugzilla.gnome.org Rahul From overholt at redhat.com Wed Sep 19 13:56:56 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 19 Sep 2007 09:56:56 -0400 Subject: wiki/ScreenCasting fedora-av-splice.sh needs update Message-ID: <20070919135656.GA8187@redhat.com> Hi, I recorded a screencast the other day and want to merge the audio and video. I followed http://fedoraproject.org/wiki/ScreenCasting but the audio-video merge script -- fedora-av-splice.sh -- doesn't work on my F7 box. Can someone who knows gstreamer please update it? 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 alan at redhat.com Wed Sep 19 13:58:00 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 09:58:00 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> Message-ID: <20070919135800.GB10005@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 09:42:35AM -0400, Colin Walters wrote: > Alan, we are trying to improve the experience for the specific > audience of artists, developers and the like who download the Desktop > Live image from the web site and want to install it on a laptop or > home PC. No one is saying that all these changes are applicable to > every situation in which Linux is used. I appreciate that, but its often being done in a way that is so narrow minded you could see stereo through a keyhole. > No one is advocating taking away the old style Linux installation (the > Fedora "choose your own adventure" DVD). And my violent objection would be to forcing the creation of a local user account IFF the user has not selected any remote authentication scheme. If I've not ticked any of ldap, nis, .. etc then its a very good idea to be extremely clear to the user that they want a non root account. Alan From johannbg at hi.is Wed Sep 19 13:57:34 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 13:57:34 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <20070919122553.GA4526@jadzia.bu.edu> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> Message-ID: <46F12ACE.2050205@hi.is> Matthew Miller wrote: > On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote: > >>> What's the rationale (again?) for disabling root login? >>> >> I assume its to make sure that if your LDAP or NIS services fail you >> are totally screwed and cannot rescue the machine. >> > > Proposed alternative: enable root logins, but customize the default root > GUI environment so it is a clear and simple rescue/configuration workspace, > not just another user's desktop. > +1 Great idea!!! Default root desktop with only System --> administration, Terminal and some text editors Identical in both Gnome and KDE.. Best regards J?hann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From pertusus at free.fr Wed Sep 19 14:00:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Sep 2007 16:00:46 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <20070918095149.7481105c@localhost.localdomain> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070918095149.7481105c@localhost.localdomain> Message-ID: <20070919140046.GC2578@free.fr> On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote: > On Wed, 19 Sep 2007 09:00:58 -0400 > > My suggested method was that you were presented with a user add option > in anaconda, but the ability to opt out (for say network login > systems). If you opt-out then the no root login policy could be > lifted, but if you opt-in and create a local user then only that local Will this be integrated with all the display managers (xdm, wdm, kdm and the other one I don't remember its name but I reviewed it)? -- Pat From myfedora at richip.dhs.org Wed Sep 19 14:02:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:02:29 -0600 Subject: Can Name=GenericName go away now, please? In-Reply-To: <46F0C2E1.4060001@leemhuis.info> References: <46EE899C.8070908@math.unl.edu> <1190055164.16960.28.camel@localhost6.localdomain6> <1190055906.4134.21.camel@localhost.localdomain> <1190182614.21756.12.camel@localhost.localdomain> <46F0C2E1.4060001@leemhuis.info> Message-ID: <1190210549.2949.3.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 08:34 +0200, Thorsten Leemhuis wrote: > In addition: wouldn't it make sense to display the DescriptiveName > normally if just one app of that kind is installed? E.g. if just > Evolution was installed -> you just find "E-Mail-Client" in your menu. > If both Thunderbird and Evo are installed display "Evolution > (E-Mail-Client) " and "Thunderbird (E-Mail-Client)" or something like that? Personally, I think it's best to be consistent all throughout so as not to confuse users when apps are added. Besides, would you believe that some people these days are more familiar with the term Firefox than they are with "browser" or even the phrase "Browse the Internet"?! "Internet" would probably suffice, but that would answer to a lot of other things, too. Sad. -- Richi Plana From walters at redhat.com Wed Sep 19 14:04:59 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 10:04:59 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919135800.GB10005@devserv.devel.redhat.com> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> Message-ID: On 9/19/07, Alan Cox wrote: > > And my violent objection would be to forcing the creation of a local user > account IFF the user has not selected any remote authentication scheme. As the desktop spin is designed for home users on laptops, I don't think it should offer remote authentication as an option during installation at all, so there is no failure scenario here. For people who want to set up labs of Fedora desktop machines - that's what the DVD and kickstart files are for. From johannbg at hi.is Wed Sep 19 14:06:28 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 14:06:28 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <46F11BC8.8070700@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> Message-ID: <46F12CE4.1050103@hi.is> Rahul Sundaram wrote: > Denis Leroy wrote: > >> >> Creating a normal user is not mandatory in anaconda (as it should be). >> >> Maybe anaconda should only enable the option if no normal users were >> creating during installation ? The idea here is to avoid a scenario >> where after a successful X installation you just can't login into the >> system! > > There was some discussions in fedora-desktop list into moving this > option away from first boot into Anaconda itself so that this would be > mandatory. This is indeed a good thing to do in this instance. Do file > a RFE in Anaconda. The idea was to entirely get rid of first boot if > possible in the desktop spin. > User should be able to turn on/off/enable/disable services ( the service's that aren't the mandatory one's ) in Anaconda If I like/dislike some service being started after installation I could enable/disable those service's during the installation *faze* be it firstboot, cups, bluetooth, hplip,ip6tables etc. Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mattdm at mattdm.org Wed Sep 19 14:08:51 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 10:08:51 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F11BC8.8070700@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> Message-ID: <20070919140851.GA13393@jadzia.bu.edu> On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > There was some discussions in fedora-desktop list into moving this > option away from first boot into Anaconda itself so that this would be > mandatory. This is indeed a good thing to do in this instance. Do file a No way -- that would be a regression. Moving this to firstboot was a huge step forward. If you put it in anaconda and make it mandatory, what do you plan to do in environments with network-based accounts? > RFE in Anaconda. The idea was to entirely get rid of first boot if > possible in the desktop spin. Pushing stuff to Anaconda ain't the answer. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Wed Sep 19 14:08:54 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:08:54 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070919124811.GA20979@imperial.ac.uk> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> Message-ID: <1190210934.2949.6.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 13:48 +0100, Kostas Georgiou wrote: > Aren't those users the ones that most likely will need to login as root > (with a GUI) at some point in the future because for example they > managed to disable their user account? Do you really expect them to be > able use the command line from the console? I'm guessing their assumption is anyone who administers a Fedora Linux box should know how to use the console and commandline-apps. Which is kinda contrary to us developing more GUI administration apps, come to think of it. -- Richi Plana From johannbg at hi.is Wed Sep 19 14:09:00 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 14:09:00 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <46F11F06.8030607@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> Message-ID: <46F12D7C.5010802@hi.is> Rahul Sundaram wrote: > Denis Leroy wrote: > >> Wait, make creating a normal user mandatory ?!? I don't know who's on >> fedora-desktop, but it must be people with absolutely no real-life >> experience with linux systems and how they're used. >> >> Just ask your RHEL customers. > > Again, this is for the desktop spin. RHEL customers don't come into > the picture at all. > You mean RHEL customers don't come into the picture at all -- so far.... Spider pig,spider pig does whatever a spider pig does... :) Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mattdm at mattdm.org Wed Sep 19 14:10:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 10:10:07 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F11F06.8030607@fedoraproject.org> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> Message-ID: <20070919141007.GB13393@jadzia.bu.edu> On Wed, Sep 19, 2007 at 06:37:18PM +0530, Rahul Sundaram wrote: > Again, this is for the desktop spin. RHEL customers don't come into the > picture at all. Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin isn't useable here. Buy RHEL, will ya?" Grrr. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From walters at redhat.com Wed Sep 19 14:11:20 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 10:11:20 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919140851.GA13393@jadzia.bu.edu> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> Message-ID: On 9/19/07, Matthew Miller wrote: > If you put it in anaconda and make it mandatory, what do you plan to do in > environments with network-based accounts? What's wrong with using the DVD and kickstart files? From jkeating at redhat.com Tue Sep 18 14:09:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 10:09:13 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190210934.2949.6.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> Message-ID: <20070918100913.7f2c9e3a@localhost.localdomain> On Wed, 19 Sep 2007 08:08:54 -0600 Richi Plana wrote: > I'm guessing their assumption is anyone who administers a Fedora Linux > box should know how to use the console and commandline-apps. > > Which is kinda contrary to us developing more GUI administration apps, > come to think of it. No, it's just getting rid of the assumption that you have to log in as root to administrate something. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Wed Sep 19 14:11:53 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Sep 2007 10:11:53 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> Message-ID: <20070919141153.GA11025@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote: > As the desktop spin is designed for home users on laptops, I don't > think it should offer remote authentication as an option during > installation at all, so there is no failure scenario here. For people > who want to set up labs of Fedora desktop machines - that's what the > DVD and kickstart files are for. Insert clue: I have a laptop and desktop boxes. I have better things to do that download two sets of media. (and no the laptop doesn't have a DVD drive, and yes its less than 12 months old) Alan From mattdm at mattdm.org Wed Sep 19 14:13:50 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 10:13:50 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> Message-ID: <20070919141350.GC13393@jadzia.bu.edu> On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote: > > If you put it in anaconda and make it mandatory, what do you plan to do in > > environments with network-based accounts? > What's wrong with using the DVD and kickstart files? That'd be really annoying to have to resort to that for a one-off installation. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Wed Sep 19 14:14:28 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:14:28 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> Message-ID: <1190211268.2949.9.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote: > Can this information be included on the login screen, somewhere small and > discreet, like in faded text on the bottom left or something? I was > unaware of it and would have found it useful one evening some time ago. How about suggest a change in GDM so that when a user tries to log-in with the "root" account, it displays a message box informing them that root login is disabled and what their options are? -- Richi Plana From sundaram at fedoraproject.org Wed Sep 19 14:12:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 19:42:50 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <46F12D7C.5010802@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <46F12D7C.5010802@hi.is> Message-ID: <46F12E62.8060909@fedoraproject.org> J?hann B. Gu?mundsson wrote: > Rahul Sundaram wrote: >> Denis Leroy wrote: >> >>> Wait, make creating a normal user mandatory ?!? I don't know who's on >>> fedora-desktop, but it must be people with absolutely no real-life >>> experience with linux systems and how they're used. >>> >>> Just ask your RHEL customers. >> >> Again, this is for the desktop spin. RHEL customers don't come into >> the picture at all. >> > You mean RHEL customers don't come into the picture at all -- so far.... When they do, they can send their feedback about it. This isn't the forum for that. Rahul From walters at redhat.com Wed Sep 19 14:21:06 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 10:21:06 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919141153.GA11025@devserv.devel.redhat.com> References: <46F11332.2040708@poolshark.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> <20070919141153.GA11025@devserv.devel.redhat.com> Message-ID: On 9/19/07, Alan Cox wrote: > On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote: > > As the desktop spin is designed for home users on laptops, I don't > > think it should offer remote authentication as an option during > > installation at all, so there is no failure scenario here. For people > > who want to set up labs of Fedora desktop machines - that's what the > > DVD and kickstart files are for. > > Insert clue: > > I have a laptop and desktop boxes. I have better things to do that download > two sets of media. (and no the laptop doesn't have a DVD drive, and yes its > less than 12 months old) You're running an enterprise network in your house, I understand. Personally, I think that's a huge amount of pain (especially for laptops) just so that your passwords are synchronized, but I'll accept that you want to do it =) Anyways, you don't actually need to download the full DVD. You can also just download the boot.iso, and point it at a kickstart file that has all your NIS information filled in, what packages you want, etc. http://docs.fedoraproject.org/install-guide/f7/en_US/sn-automating-installation.html From sundaram at fedoraproject.org Wed Sep 19 14:17:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 19:47:39 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070919141007.GB13393@jadzia.bu.edu> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> Message-ID: <46F12F83.80608@fedoraproject.org> Matthew Miller wrote: > On Wed, Sep 19, 2007 at 06:37:18PM +0530, Rahul Sundaram wrote: >> Again, this is for the desktop spin. RHEL customers don't come into the >> picture at all. > > Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin > isn't useable here. Buy RHEL, will ya?" > > Grrr. Can you try and be more reasonable? Rahul From seandarcy2 at gmail.com Wed Sep 19 14:20:34 2007 From: seandarcy2 at gmail.com (sean) Date: Wed, 19 Sep 2007 10:20:34 -0400 Subject: why does yum want xulrunner? Message-ID: from today: yum update ............ --> Finished Dependency Resolution Error: Unresolvable requirement libxpcom_core.so()(64bit) for yelp Error: Unresolvable requirement gecko-libs = 1.8.1.6 for yelp Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for yelp Error: Missing Dependency: firefox is needed by package libswt3-gtk2 Error: Unresolvable requirement gecko-libs = 1.8.1.6 for devhelp Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for devhelp Error: Unresolvable requirement libgtkembedmoz.so for devhelp yum --exclude=xulrunner update works. and xulrunner is not installed: rpm -q xulrunner package xulrunner is not installed sean From johannbg at hi.is Wed Sep 19 14:22:13 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 14:22:13 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <1190211268.2949.9.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> <1190211268.2949.9.camel@localhost6.localdomain6> Message-ID: <46F13095.5090504@hi.is> Richi Plana wrote: > On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote: > >> Can this information be included on the login screen, somewhere small and >> discreet, like in faded text on the bottom left or something? I was >> unaware of it and would have found it useful one evening some time ago. >> > > How about suggest a change in GDM so that when a user tries to log-in > with the "root" account, it displays a message box informing them that > root login is disabled and what their options are? > -- > Your currently trying to log in as root ( oh did I type root I was gonna write smurkydoo ) The root account is currently disable please press F1 type root as your Login name and the root password enable the root account exit then try again.. lol.... Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mattdm at mattdm.org Wed Sep 19 14:24:08 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 10:24:08 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F12F83.80608@fedoraproject.org> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> Message-ID: <20070919142408.GA14757@jadzia.bu.edu> On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote: > >>Again, this is for the desktop spin. RHEL customers don't come into the > >>picture at all. > >Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin > >isn't useable here. Buy RHEL, will ya?" > >Grrr. > Can you try and be more reasonable? Probably. :) No coffee yet this morning. But what I meant was: just because RHEL customers are an *example* of a class where this is obviously a bad idea doesn't mean that it's not also a bad idea for Fedora users. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Wed Sep 19 14:23:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 19:53:59 +0530 Subject: why does yum want xulrunner? In-Reply-To: References: Message-ID: <46F130FF.9020909@fedoraproject.org> sean wrote: > from today: > > yum update > ............ > --> Finished Dependency Resolution > Error: Unresolvable requirement libxpcom_core.so()(64bit) for yelp > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for yelp > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for yelp > Error: Missing Dependency: firefox is needed by package libswt3-gtk2 > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for devhelp > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for devhelp > Error: Unresolvable requirement libgtkembedmoz.so for devhelp > > yum --exclude=xulrunner update works. Yum doesn't want xulrunner. The repository has some packages that need to be rebuild which is a known issue. See previous discussions in this list before posting questions. Rahul From walters at redhat.com Wed Sep 19 14:28:04 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 10:28:04 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919141350.GC13393@jadzia.bu.edu> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> <20070919141350.GC13393@jadzia.bu.edu> Message-ID: On 9/19/07, Matthew Miller wrote: > On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote: > > > If you put it in anaconda and make it mandatory, what do you plan to do in > > > environments with network-based accounts? > > What's wrong with using the DVD and kickstart files? > > That'd be really annoying to have to resort to that for a one-off > installation. I can't think of a situation in which NIS is used where using kickstart files would be close to the biggest annoyance. From ssorce at redhat.com Wed Sep 19 14:30:09 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Sep 2007 10:30:09 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919120525.GA5410@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> Message-ID: <1190212209.3257.5.camel@localhost.localdomain> On Wed, 2007-09-19 at 08:05 -0400, Alan Cox wrote: > On Wed, Sep 19, 2007 at 06:49:22AM -0500, Rex Dieter wrote: > > > Root login has been disabled in GDM for a while now in rawhide. Would > > > KDM and other display managers be modified to be consistent with this > > > behavior? I would prefer if it was. > > > > What's the rationale (again?) for disabling root login? > > I assume its to make sure that if your LDAP or NIS services fail you > are totally screwed and cannot rescue the machine. It's just disabled in GDM not via console/ssh if I understood correctly. Simo. From myfedora at richip.dhs.org Wed Sep 19 14:29:58 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:29:58 -0600 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190185383.6908.34.camel@pc-notebook> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190185383.6908.34.camel@pc-notebook> Message-ID: <1190212198.2949.16.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 09:03 +0200, Martin Sourada wrote: > On Wed, 2007-09-19 at 07:33 +0200, Martin Stransky wrote: > > Both packages (firefox and xulrunner) provides gecko-libs and currently > > can't be installed together. > > > AFAIK, the gecko-lib provides should not be a problem. The only problem > I am aware of is that both firefox and xulrunner packages > have /etc/gre.d/gre(64).conf files. Can't firefox be cut down so that it doesn't include it's own gecko-libs but instead uses xulrunner so that it's just like any other gecko app (Disclaimer: I'm not really familiar with xulrunner so don't shoot me)? -- Richi Plana From sundaram at fedoraproject.org Wed Sep 19 14:31:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 20:01:44 +0530 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <1190212198.2949.16.camel@localhost6.localdomain6> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190185383.6908.34.camel@pc-notebook> <1190212198.2949.16.camel@localhost6.localdomain6> Message-ID: <46F132D0.4010304@fedoraproject.org> Richi Plana wrote: > On Wed, 2007-09-19 at 09:03 +0200, Martin Sourada wrote: >> On Wed, 2007-09-19 at 07:33 +0200, Martin Stransky wrote: >>> Both packages (firefox and xulrunner) provides gecko-libs and currently >>> can't be installed together. >>> >> AFAIK, the gecko-lib provides should not be a problem. The only problem >> I am aware of is that both firefox and xulrunner packages >> have /etc/gre.d/gre(64).conf files. > > Can't firefox be cut down so that it doesn't include it's own gecko-libs > but instead uses xulrunner so that it's just like any other gecko app > (Disclaimer: I'm not really familiar with xulrunner so don't shoot me)? That's the plan. Rahul From ssorce at redhat.com Wed Sep 19 14:38:57 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Sep 2007 10:38:57 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F12ACE.2050205@hi.is> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <46F12ACE.2050205@hi.is> Message-ID: <1190212737.3257.9.camel@localhost.localdomain> On Wed, 2007-09-19 at 13:57 +0000, "J?hann B. Gu?mundsson" wrote: > Matthew Miller wrote: > > On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote: > > > >>> What's the rationale (again?) for disabling root login? > >>> > >> I assume its to make sure that if your LDAP or NIS services fail you > >> are totally screwed and cannot rescue the machine. > >> > > > > Proposed alternative: enable root logins, but customize the default root > > GUI environment so it is a clear and simple rescue/configuration workspace, > > not just another user's desktop. > > > +1 Great idea!!! > Default root desktop with only System --> administration, Terminal and > some text editors > Identical in both Gnome and KDE.. Even better force root to login only with twm (or something worst if it exists) and only a xterm ... now that would be a great punishment for not doing as told Simo. From johannbg at hi.is Wed Sep 19 14:40:44 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 14:40:44 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <46F13095.5090504@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> <1190211268.2949.9.camel@localhost6.localdomain6> <46F13095.5090504@hi.is> Message-ID: <46F134EC.2030108@hi.is> J?hann B. Gu?mundsson wrote: > Richi Plana wrote: >> On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote: >> >>> Can this information be included on the login screen, somewhere >>> small and >>> discreet, like in faded text on the bottom left or something? I was >>> unaware of it and would have found it useful one evening some time ago. >>> >> >> How about suggest a change in GDM so that when a user tries to log-in >> with the "root" account, it displays a message box informing them that >> root login is disabled and what their options are? >> -- >> > Your currently trying to log in as root ( oh did I type root I was > gonna write smurkydoo ) > The root account is currently disable please press F1 type > root as your Login name and the root password enable the root account > exit then try again.. > > lol.... > > If this is gonna be *good* user experience users need to be able to enable the root account in gdm/kdm/xdm etc.. First user tries to log in as root gets an *hint* that he need to go to option --> enable root login, types the root password, root account enabled logs in as root receives an stripped down administrative/rescue desktop Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From myfedora at richip.dhs.org Wed Sep 19 14:45:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:45:19 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070919142408.GA14757@jadzia.bu.edu> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> Message-ID: <1190213119.2949.27.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 10:24 -0400, Matthew Miller wrote: > On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote: > > >>Again, this is for the desktop spin. RHEL customers don't come into the > > >>picture at all. > > >Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin > > >isn't useable here. Buy RHEL, will ya?" > > >Grrr. > > Can you try and be more reasonable? > > > Probably. :) No coffee yet this morning. But what I meant was: just because > RHEL customers are an *example* of a class where this is obviously a bad > idea doesn't mean that it's not also a bad idea for Fedora users. I think what Rahul is trying to impress upon us is that RHEL is to be treated like any other distro spinner out there. Fedora chooses its default but makes it easy for anyone else to customize their spin as they see it. They're also welcome to provide feedback. Fedora isn't trying to be the perfect default. It's just chosen its target and allows others to spin off of it. -- Richi Plana From limb at jcomserv.net Wed Sep 19 14:19:45 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 19 Sep 2007 09:19:45 -0500 (CDT) Subject: Root login in rawhide and display managers In-Reply-To: <20070919142408.GA14757@jadzia.bu.edu> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> Message-ID: <25913.63.85.68.164.1190211585.squirrel@mail.jcomserv.net> > On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote: >> >>Again, this is for the desktop spin. RHEL customers don't come into >> the >> >>picture at all. >> >Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop >> spin >> >isn't useable here. Buy RHEL, will ya?" >> >Grrr. >> Can you try and be more reasonable? > > > Probably. :) No coffee yet this morning. But what I meant was: just > because > RHEL customers are an *example* of a class where this is obviously a bad > idea doesn't mean that it's not also a bad idea for Fedora users. Maybe Matthew was simply celebrating Talk Like a Pirate Day. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From sundaram at fedoraproject.org Wed Sep 19 14:51:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 20:21:35 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070919142408.GA14757@jadzia.bu.edu> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> Message-ID: <46F13777.6040600@fedoraproject.org> Matthew Miller wrote: > > Probably. :) No coffee yet this morning. But what I meant was: just because > RHEL customers are an *example* of a class where this is obviously a bad > idea doesn't mean that it's not also a bad idea for Fedora users. Correct but just be direct and explain why it would be a bad idea for a desktop spin of Fedora. That's more useful than talking about RHEL. We all know the audience is different between these distributions. Rahul From johannbg at hi.is Wed Sep 19 14:55:27 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Wed, 19 Sep 2007 14:55:27 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <1190212737.3257.9.camel@localhost.localdomain> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <46F12ACE.2050205@hi.is> <1190212737.3257.9.camel@localhost.localdomain> Message-ID: <46F1385F.8050909@hi.is> Simo Sorce wrote: > On Wed, 2007-09-19 at 13:57 +0000, "J?hann B. Gu?mundsson" wrote: > >> Matthew Miller wrote: >> >>> On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote: >>> >>> >>>>> What's the rationale (again?) for disabling root login? >>>>> >>>>> >>>> I assume its to make sure that if your LDAP or NIS services fail you >>>> are totally screwed and cannot rescue the machine. >>>> >>>> >>> Proposed alternative: enable root logins, but customize the default root >>> GUI environment so it is a clear and simple rescue/configuration workspace, >>> not just another user's desktop. >>> >>> >> +1 Great idea!!! >> Default root desktop with only System --> administration, Terminal and >> some text editors >> Identical in both Gnome and KDE.. >> > > Even better force root to login only with twm (or something worst if it > exists) and only a xterm ... now that would be a great punishment for > not doing as told > > Simo. > > Hum let's see uh... Application --> 1. Archive manager -- Might be used in rescue situations 2. Calculator -- Not gonna be used in rescue stituations ( could be removed ) 3. Character map -- Not gonna be used in rescue situations ( could be removed ) 4. Dictionary -- Not gonna be used in rescue situations ( could be removed ) 5. Take a screenshot -- Not gonna be used in rescue situations ( could be removed ) 6. Terminal -- Might be used in rescue situations 7. Text Editor -- Might be used in rescue situations 8. VNC -- Not gonna be used in rescue situations for his machine ( could be removed ) Edutainment --> Not gonna be used in rescue stituations ( could be removed ) Games --> Not gonna be used in rescue stituations ( could be removed ) Graphics --> Not gonna be used in rescue stituations ( could be removed ) Internet, an browser an email client, pidgin, xchat -- > Rest could be removed Office --> Not gonna be used in rescue stituations ( could be removed ) Programming --> Not gonna be used in rescue stituations ( could be removed ) Sound and Video --> Not gonna be used in rescue stituations ( could be removed ) System tools --> Not gonna be used in rescue stituations ( could be removed ) ( questionable File browser/Software updater ) Wine --> Not gonna be used in rescue stituations ( could be removed ) Places could stay ( from my point of view or be removed neutral ) System left as is.. Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From myfedora at richip.dhs.org Wed Sep 19 14:57:36 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:57:36 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070919141350.GC13393@jadzia.bu.edu> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> <20070919141350.GC13393@jadzia.bu.edu> Message-ID: <1190213856.2949.40.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 10:13 -0400, Matthew Miller wrote: > On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote: > > > If you put it in anaconda and make it mandatory, what do you plan to do in > > > environments with network-based accounts? > > What's wrong with using the DVD and kickstart files? > > That'd be really annoying to have to resort to that for a one-off > installation. A one-off? I might be misunderstanding you, but I thought you were arguing for network-based account installs and multiple machines? If it's just one machine, then does it really matter whether you do it at firstboot or Anaconda? -- Richi Plana From jkeating at redhat.com Tue Sep 18 14:56:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 10:56:57 -0400 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <46F132D0.4010304@fedoraproject.org> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190185383.6908.34.camel@pc-notebook> <1190212198.2949.16.camel@localhost6.localdomain6> <46F132D0.4010304@fedoraproject.org> Message-ID: <20070918105657.29de91c8@localhost.localdomain> On Wed, 19 Sep 2007 20:01:44 +0530 Rahul Sundaram wrote: > > Can't firefox be cut down so that it doesn't include it's own > > gecko-libs but instead uses xulrunner so that it's just like any > > other gecko app (Disclaimer: I'm not really familiar with xulrunner > > so don't shoot me)? > > That's the plan. But IIRC not for F8. Firefox isn't ready for that IIRC. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 15:05:41 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 17:05:41 +0200 Subject: why does yum want xulrunner? In-Reply-To: <46F130FF.9020909@fedoraproject.org> References: <46F130FF.9020909@fedoraproject.org> Message-ID: <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Sep 2007 19:53:59 +0530, Rahul Sundaram wrote: > sean wrote: > > from today: > > > > yum update > > ............ > > --> Finished Dependency Resolution > > Error: Unresolvable requirement libxpcom_core.so()(64bit) for yelp > > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for yelp > > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for yelp > > Error: Missing Dependency: firefox is needed by package libswt3-gtk2 > > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for devhelp > > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for devhelp > > Error: Unresolvable requirement libgtkembedmoz.so for devhelp > > > > yum --exclude=xulrunner update works. > > Yum doesn't want xulrunner. Sure it does. See my earlier reply. From jkeating at redhat.com Tue Sep 18 14:51:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 10:51:37 -0400 Subject: Xulrunner in Fedora 8 Message-ID: <20070918105137.1da06ba6@localhost.localdomain> A xulrunner build appeared in Fedora 8 buildroot and was pushed out to rawhide. This was a bit premature and as such we have untagged the build. There is no older build, nor any new build to immediately fix issues. Therefor xulrunner will not be available in buildroots and it will disappear from rawhide until the issues surrounding it are resolved (matching firefox build, ppc(64) support, no conflicting files). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dwmw2 at infradead.org Wed Sep 19 15:07:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 16:07:37 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <20070918105137.1da06ba6@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> Message-ID: <1190214457.2926.88.camel@pmac.infradead.org> On Tue, 2007-09-18 at 10:51 -0400, Jesse Keating wrote: > ppc(64) support, Er, wot? Anything I need to do here? This should JustWork?, shouldn't it? -- dwmw2 From jkeating at redhat.com Tue Sep 18 15:07:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 11:07:32 -0400 Subject: why does yum want xulrunner? In-Reply-To: <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070918110732.43d136cd@localhost.localdomain> On Wed, 19 Sep 2007 17:05:41 +0200 Michael Schwendt wrote: > > > yum --exclude=xulrunner update works. > > > > Yum doesn't want xulrunner. > > Sure it does. See my earlier reply. Language issue. "yum" itself doesn't "want" (as in require) xulrunner, which is what Rahul was saying. However due to improper obsoletes a yum update action will see xulrunner as obsoleting installed software and thus add it to the transaction, which is what you (and others) are saying. Both are right. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Sep 19 15:09:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 19 Sep 2007 11:09:48 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190214457.2926.88.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> Message-ID: <1190214588.10222.0.camel@localhost.localdomain> On Wed, 2007-09-19 at 16:07 +0100, David Woodhouse wrote: > On Tue, 2007-09-18 at 10:51 -0400, Jesse Keating wrote: > > ppc(64) support, > > Er, wot? Anything I need to do here? This should JustWork?, shouldn't > it? What I vaguely remember caillon saying last week was that some of the ppc bits from firefox aren't in the upstream trunk for xulrunner. But that's purely hearsay :) Jeremy From sundaram at fedoraproject.org Wed Sep 19 15:07:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 20:37:23 +0530 Subject: why does yum want xulrunner? In-Reply-To: <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46F13B2B.2000505@fedoraproject.org> Michael Schwendt wrote: > On Wed, 19 Sep 2007 19:53:59 +0530, Rahul Sundaram wrote: >>> yum --exclude=xulrunner update works. >> Yum doesn't want xulrunner. > > Sure it does. See my earlier reply. Not sure which one you are referring to. I understand X wants Y to specific a direct or indirect dependency which is not the case here. Yum is merely indicating a repository issue in this instance. Rahul From jkeating at redhat.com Tue Sep 18 15:09:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 11:09:46 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190214457.2926.88.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> Message-ID: <20070918110946.260820a6@localhost.localdomain> On Wed, 19 Sep 2007 16:07:37 +0100 David Woodhouse wrote: > Er, wot? Anything I need to do here? This should JustWork?, shouldn't > it? I have no idea. Caillon added ExcludeArch on those on the 5th of this month, but no comments around it or changelog entry. But cvslog shows: date: 2007/09/05 18:57:33; author: caillon; state: Exp; lines: +1 -1 xptcall not implemented on ppc? ExcludeArch for now Whether or not that has been fixed is unknown. But unless we're going to allow for software to build against xul on x86 and firefox on ppc(64) we can't go forward with this package. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Sep 19 15:14:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 16:14:18 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190214588.10222.0.camel@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> Message-ID: <1190214858.2926.92.camel@pmac.infradead.org> On Wed, 2007-09-19 at 11:09 -0400, Jeremy Katz wrote: > What I vaguely remember caillon saying last week was that some of the > ppc bits from firefox aren't in the upstream trunk for xulrunner. Sounds about right, if you mean ppc64 and not ppc. The patch to support ppc64 should ideally just apply and work without problems -- feel free to poke me directly if not, and I'll look at it. -- dwmw2 From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 15:15:56 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 17:15:56 +0200 Subject: why does yum want xulrunner? In-Reply-To: <46F13B2B.2000505@fedoraproject.org> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> <46F13B2B.2000505@fedoraproject.org> Message-ID: <20070919171556.3f87a0dc.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Sep 2007 20:37:23 +0530, Rahul Sundaram wrote: > Michael Schwendt wrote: > > On Wed, 19 Sep 2007 19:53:59 +0530, Rahul Sundaram wrote: > > >>> yum --exclude=xulrunner update works. > >> Yum doesn't want xulrunner. > > > > Sure it does. See my earlier reply. > > Not sure which one you are referring to. One in this thread. > I understand X wants Y to > specific a direct or indirect dependency which is not the case here. Yum > is merely indicating a repository issue in this instance. A "repository issue" because it attempted at replacing firefox with xulrunner. Which is because "yum wants xulrunner" in the update transaction set. From dwmw2 at infradead.org Wed Sep 19 15:19:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 16:19:49 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <20070918110946.260820a6@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <20070918110946.260820a6@localhost.localdomain> Message-ID: <1190215189.2926.97.camel@pmac.infradead.org> On Tue, 2007-09-18 at 11:09 -0400, Jesse Keating wrote: > I have no idea. Caillon added ExcludeArch on those on the 5th of this > month, but no comments around it or changelog entry. But cvslog shows: Hm. When can we start enforcing the 'ExcludeArch MUST have bug filed' rule? :) > date: 2007/09/05 18:57:33; author: caillon; state: Exp; lines: +1 -1 > xptcall not implemented on ppc? ExcludeArch for now > > Whether or not that has been fixed is unknown. The xptcall stubs have been implemented on ppc for a long time. I implemented them for ppc64 last year, and that patch seems to be present in our xulrunner package in CVS. I'll build it and see what happens. Caillon? -- dwmw2 From johannbg at hi.is Wed Sep 19 15:22:06 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 19 Sep 2007 15:22:06 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <20070919141153.GA11025@devserv.devel.redhat.com> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> <20070919141153.GA11025@devserv.devel.redhat.com> Message-ID: <46F13E9E.4070209@hi.is> Alan Cox wrote: > On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote: > >> As the desktop spin is designed for home users on laptops, I don't >> think it should offer remote authentication as an option during >> installation at all, so there is no failure scenario here. For people >> who want to set up labs of Fedora desktop machines - that's what the >> DVD and kickstart files are for. >> > > Insert clue: > > I have a laptop and desktop boxes. I have better things to do that download > two sets of media. (and no the laptop doesn't have a DVD drive, and yes its > less than 12 months old) > > Alan > > +1 Plus too many option for users means too many things can go wrong.... So keeping simple set of installation-images ( we should not start to release fedora-desktop, fedora-server,fedora-laptop, fedora-blue,fedora-black etc etc.. ) and rather let the user choose what *type* of fedora he wants in Anaconda... Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From jkeating at redhat.com Tue Sep 18 15:20:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 11:20:20 -0400 Subject: why does yum want xulrunner? In-Reply-To: <46F13B2B.2000505@fedoraproject.org> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> <46F13B2B.2000505@fedoraproject.org> Message-ID: <20070918112020.12598007@localhost.localdomain> On Wed, 19 Sep 2007 20:37:23 +0530 Rahul Sundaram wrote: > Not sure which one you are referring to. I understand X wants Y to > specific a direct or indirect dependency which is not the case here. > Yum is merely indicating a repository issue in this instance. Ok, shame on me for giving you the benefit of the doubt. Yum update transactions /will/ in fact bring xulrunner into the transaction set. You could verify this yourself if you tried. Apologies to Michael. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Sep 18 15:20:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 11:20:54 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190215189.2926.97.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <20070918110946.260820a6@localhost.localdomain> <1190215189.2926.97.camel@pmac.infradead.org> Message-ID: <20070918112054.2ae3da75@localhost.localdomain> On Wed, 19 Sep 2007 16:19:49 +0100 David Woodhouse wrote: > Hm. When can we start enforcing the 'ExcludeArch MUST have bug filed' > rule? :) Got reasonable suggestions/patches on how to "enforce" this? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Sep 19 15:20:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 20:50:08 +0530 Subject: why does yum want xulrunner? In-Reply-To: <20070919171556.3f87a0dc.mschwendt.tmp0701.nospam@arcor.de> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> <46F13B2B.2000505@fedoraproject.org> <20070919171556.3f87a0dc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46F13E28.6030407@fedoraproject.org> Michael Schwendt wrote: > On Wed, 19 Sep 2007 20:37:23 +0530, Rahul Sundaram wrote: > >> Michael Schwendt wrote: >>> On Wed, 19 Sep 2007 19:53:59 +0530, Rahul Sundaram wrote: >>>>> yum --exclude=xulrunner update works. >>>> Yum doesn't want xulrunner. >>> Sure it does. See my earlier reply. >> Not sure which one you are referring to. > > One in this thread. Didn't get any other mails from you in this thread. >> I understand X wants Y to >> specific a direct or indirect dependency which is not the case here. Yum >> is merely indicating a repository issue in this instance. > > A "repository issue" because it attempted at replacing firefox with > xulrunner. Which is because "yum wants xulrunner" in the update > transaction set. Right. As Jesse Keating, we are merely reading things differently. Rahul From jkeating at redhat.com Tue Sep 18 15:21:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Sep 2007 11:21:36 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190214858.2926.92.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> Message-ID: <20070918112136.6bcd2167@localhost.localdomain> On Wed, 19 Sep 2007 16:14:18 +0100 David Woodhouse wrote: > Sounds about right, if you mean ppc64 and not ppc. The patch to > support ppc64 should ideally just apply and work without problems -- > feel free to poke me directly if not, and I'll look at it. Apply and "in the upstream trunk" are two different things, and in the case of Mozilla goo, rather important things :/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Sep 19 15:21:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 20:51:38 +0530 Subject: why does yum want xulrunner? In-Reply-To: <20070918112020.12598007@localhost.localdomain> References: <46F130FF.9020909@fedoraproject.org> <20070919170541.a4df0c12.mschwendt.tmp0701.nospam@arcor.de> <46F13B2B.2000505@fedoraproject.org> <20070918112020.12598007@localhost.localdomain> Message-ID: <46F13E82.10104@fedoraproject.org> Jesse Keating wrote: > On Wed, 19 Sep 2007 20:37:23 +0530 > Rahul Sundaram wrote: > >> Not sure which one you are referring to. I understand X wants Y to >> specific a direct or indirect dependency which is not the case here. >> Yum is merely indicating a repository issue in this instance. > > Ok, shame on me for giving you the benefit of the doubt. Yum update > transactions /will/ in fact bring xulrunner into the transaction set. > You could verify this yourself if you tried. Apologies to Michael. You were correct. I was referring to direct/indirect dependencies to yum itself and not update transactions. Rahul From dwmw2 at infradead.org Wed Sep 19 15:37:30 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 16:37:30 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <20070918112054.2ae3da75@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <20070918110946.260820a6@localhost.localdomain> <1190215189.2926.97.camel@pmac.infradead.org> <20070918112054.2ae3da75@localhost.localdomain> Message-ID: <1190216250.2926.100.camel@pmac.infradead.org> On Tue, 2007-09-18 at 11:20 -0400, Jesse Keating wrote: > On Wed, 19 Sep 2007 16:19:49 +0100 > David Woodhouse wrote: > > > Hm. When can we start enforcing the 'ExcludeArch MUST have bug filed' > > rule? :) > > Got reasonable suggestions/patches on how to "enforce" this? Dude, I hack kernels for a living. You've _seen_ my attempts at python. Do you _want_ me to come up with a kernel patch for it? :) -- dwmw2 From dwmw2 at infradead.org Wed Sep 19 15:41:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 16:41:19 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <20070918112136.6bcd2167@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> Message-ID: <1190216479.2926.106.camel@pmac.infradead.org> On Tue, 2007-09-18 at 11:21 -0400, Jesse Keating wrote: > Apply and "in the upstream trunk" are two different things, and in the > case of Mozilla goo, rather important things :/ True in the general case, but this is a patch we're carrying already -- so presumably it shouldn't be much of an issue to carry it in xulrunner too (is xulrunner subject to the same rules, or is that only if we link firefox against it?). Actually the patch in question seems to be applied already -- the only problem seems to be that while $(OS_TEST) used to be set to 'ppc' it's now set to 'powerpc', so the makefile fails to select a set of stubs and the build aborts (yay, aborts rather than silently building a broken library, like it used to). I assume it'll be the same issue for ppc64/powerpc64. but will let the 32-bit build finish first. If the xulrunner package is teamwork-enabled, I can commit the fixes immediately. :) -- dwmw2 From myfedora at richip.dhs.org Wed Sep 19 14:41:34 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:41:34 -0600 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> Message-ID: <1190212894.2949.23.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 10:04 -0400, Colin Walters wrote: > As the desktop spin is designed for home users on laptops, I don't > think it should offer remote authentication as an option during > installation at all, so there is no failure scenario here. For people > who want to set up labs of Fedora desktop machines - that's what the > DVD and kickstart files are for. Desktop != home users. If anything, home users are just a subset of desktop users. Besides, with the trend in today's houses is towards networking all equipment, it's not unheard of for mom to log in on the kitchen computer to view her recipes. At my place, all the Desktops (that's laptops as well as desktops) were configured to authenticate from a central server. Going back to the install option, it does make sense to make "local account setup" and "network authentication" an OR proposal (at least one has to be configured but the other would be optional). -- Richi Plana From rc040203 at freenet.de Wed Sep 19 15:46:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 19 Sep 2007 17:46:59 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F13777.6040600@fedoraproject.org> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> Message-ID: <1190216819.11618.97.camel@mccallum.corsepiu.local> On Wed, 2007-09-19 at 20:21 +0530, Rahul Sundaram wrote: > Matthew Miller wrote: > > > > > Probably. :) No coffee yet this morning. But what I meant was: just because > > RHEL customers are an *example* of a class where this is obviously a bad > > idea doesn't mean that it's not also a bad idea for Fedora users. > > Correct but just be direct and explain why it would be a bad idea for a > desktop spin of Fedora. The desktop spin is the bad idea - A desktop/Single user/single seat system is just a setup of a modular OS/set of packages, just as is a "universal server" or a "dedicated server". I am pretty certain many Fedora users use Fedora for both situations and consider a "mere desktop spin" a waste of time. > That's more useful than talking about RHEL. We > all know the audience is different between these distributions. It is not. - Otherwise EPEL would not exist. - Those using RHEL @situation X (eg. @work) not unlikely are the same people running Fedora @situation Y (eg. @home) ... Ralf From walters at redhat.com Wed Sep 19 15:50:09 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 11:50:09 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190212894.2949.23.camel@localhost6.localdomain6> References: <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> <1190212894.2949.23.camel@localhost6.localdomain6> Message-ID: On 9/19/07, Richi Plana wrote: > At my place, all the Desktops (that's laptops as well as desktops) were > configured to authenticate from a central server. That's great. If you are running this sort of complex home networking, know how to set up servers and NIS etc., then the choose your own adventure DVD or boot.iso, combined with kickstart files are appropriate for you. From myfedora at richip.dhs.org Wed Sep 19 14:52:08 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:52:08 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <46F12CE4.1050103@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F12CE4.1050103@hi.is> Message-ID: <1190213528.2949.34.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 14:06 +0000, "J?hann B. Gu?mundsson" wrote: > User should be able to turn on/off/enable/disable services ( the > service's that aren't the mandatory one's ) in Anaconda Beg to disagree. Anaconda should just concentrate on getting the real Fedora image installed so that it becomes the running system (its kernel and filesystem is used). You can argue for it at firstboot, though. Or just put it in kickstart (if possible). I think firstboot is being thinned down to just retain the bare minimum needed for a Desktop login. What's the time differential anyway between doing it at Install time and waiting to log in as a regular user? Or is it that you want a window to pop up on first Log-on (we don't really take advantage of first login, unfortunately) to ask you if you want to configure some additional services? -- Richi Plana From mattdm at mattdm.org Wed Sep 19 16:05:56 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 12:05:56 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190213856.2949.40.camel@localhost6.localdomain6> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> <20070919141350.GC13393@jadzia.bu.edu> <1190213856.2949.40.camel@localhost6.localdomain6> Message-ID: <20070919160556.GA23282@jadzia.bu.edu> On Wed, Sep 19, 2007 at 08:57:36AM -0600, Richi Plana wrote: > > That'd be really annoying to have to resort to that for a one-off > > installation. > A one-off? I might be misunderstanding you, but I thought you were > arguing for network-based account installs and multiple machines? If > it's just one machine, then does it really matter whether you do it at > firstboot or Anaconda? Consider an environment where network authentication is desired but OS choice is not enforced. People are likely to download and want to use the Fedora Desktop spin on their desktop computers. But this is all really a moot point because I think it's highly unlikely that anaconda will go back to its old behavior -- that stuff was moved out for reasons other than policy. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ssorce at redhat.com Wed Sep 19 16:08:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 19 Sep 2007 12:08:47 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F134EC.2030108@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <4161.63.85.68.164.1190205433.squirrel@mail.jcomserv.net> <1190211268.2949.9.camel@localhost6.localdomain6> <46F13095.5090504@hi.is> <46F134EC.2030108@hi.is> Message-ID: <1190218127.3257.17.camel@localhost.localdomain> On Wed, 2007-09-19 at 14:40 +0000, "J?hann B. Gu?mundsson" wrote: > J?hann B. Gu?mundsson wrote: > > Richi Plana wrote: > >> On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote: > >> > >>> Can this information be included on the login screen, somewhere > >>> small and > >>> discreet, like in faded text on the bottom left or something? I was > >>> unaware of it and would have found it useful one evening some time ago. > >>> > >> > >> How about suggest a change in GDM so that when a user tries to log-in > >> with the "root" account, it displays a message box informing them that > >> root login is disabled and what their options are? > >> -- > >> > > Your currently trying to log in as root ( oh did I type root I was > > gonna write smurkydoo ) > > The root account is currently disable please press F1 type > > root as your Login name and the root password enable the root account > > exit then try again.. > > > > lol.... > > > > > If this is gonna be *good* user experience users need to be able to enable > the root account in gdm/kdm/xdm etc.. > > First user tries to log in as root gets an *hint* that he need to go to > option --> enable root login, types the root password, root account enabled > logs in as root receives an stripped down administrative/rescue desktop This is a very reasonable proposal, I think it is a very sensible way to help users do the right thing (or the wrong one ... details :-). Simo. From ellson at research.att.com Wed Sep 19 16:17:27 2007 From: ellson at research.att.com (John Ellson) Date: Wed, 19 Sep 2007 12:17:27 -0400 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) Message-ID: <1190218648.2653.11.camel@mashtun.mt.att.com> On Wed, 19 Sep 2007 09:21:50 -0400, Adam Jackson wrote: > % rpm -q --whatrequires chkfontpath > no package requires chkfontpath I get a different result on x86_64, so perhaps this is a bug? # rpm -q --whatrequires chkfontpath libdockapp-fonts-0.6.1-3.fc8.x86_64 John From walters at redhat.com Wed Sep 19 16:21:33 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 12:21:33 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070919160556.GA23282@jadzia.bu.edu> References: <46F11332.2040708@poolshark.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919140851.GA13393@jadzia.bu.edu> <20070919141350.GC13393@jadzia.bu.edu> <1190213856.2949.40.camel@localhost6.localdomain6> <20070919160556.GA23282@jadzia.bu.edu> Message-ID: On 9/19/07, Matthew Miller wrote: > > Consider an environment where network authentication is desired but OS > choice is not enforced. People are likely to download and want to use the > Fedora Desktop spin on their desktop computers. Can you be more specific? I don't understand what these scenarios would be. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Sep 19 16:22:27 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 20 Sep 2007 01:22:27 +0900 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <1190218648.2653.11.camel@mashtun.mt.att.com> References: <1190218648.2653.11.camel@mashtun.mt.att.com> Message-ID: <46F14CC3.1070908@ioa.s.u-tokyo.ac.jp> John Ellson wrote, at 09/20/2007 01:17 AM +9:00: > On Wed, 19 Sep 2007 09:21:50 -0400, Adam Jackson wrote: >> % rpm -q --whatrequires chkfontpath >> no package requires chkfontpath > > > I get a different result on x86_64, so perhaps this is a bug? > > > # rpm -q --whatrequires chkfontpath > libdockapp-fonts-0.6.1-3.fc8.x86_64 See: https://bugzilla.redhat.com/show_bug.cgi?id=252280 Regards, Mamoru From tcallawa at redhat.com Wed Sep 19 16:21:42 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Sep 2007 12:21:42 -0400 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <1190218648.2653.11.camel@mashtun.mt.att.com> References: <1190218648.2653.11.camel@mashtun.mt.att.com> Message-ID: <1190218902.3418.0.camel@localhost.localdomain> On Wed, 2007-09-19 at 12:17 -0400, John Ellson wrote: > On Wed, 19 Sep 2007 09:21:50 -0400, Adam Jackson wrote: > > % rpm -q --whatrequires chkfontpath > > no package requires chkfontpath > > > I get a different result on x86_64, so perhaps this is a bug? > > > # rpm -q --whatrequires chkfontpath > libdockapp-fonts-0.6.1-3.fc8.x86_64 Not a bug, ajax just doesn't have all possible packages installed. You really want to ask repoquery: [spot at localhost ~]$ repoquery -q --whatrequires chkfontpath libdockapp-fonts-0:0.6.1-3.fc8.x86_64 grace-0:5.1.21-2.fc8.x86_64 ~spot From pertusus at free.fr Wed Sep 19 16:28:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 19 Sep 2007 18:28:33 +0200 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <1190218648.2653.11.camel@mashtun.mt.att.com> References: <1190218648.2653.11.camel@mashtun.mt.att.com> Message-ID: <20070919162831.GF2578@free.fr> On Wed, Sep 19, 2007 at 12:17:27PM -0400, John Ellson wrote: > On Wed, 19 Sep 2007 09:21:50 -0400, Adam Jackson wrote: > > % rpm -q --whatrequires chkfontpath > > no package requires chkfontpath > > > I get a different result on x86_64, so perhaps this is a bug? > > > # rpm -q --whatrequires chkfontpath > libdockapp-fonts-0.6.1-3.fc8.x86_64 It depends on what you have installed. This is a packaging bug (mine), but I still don't have time to handle that issue; -- Pat From sundaram at fedoraproject.org Wed Sep 19 16:42:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 22:12:25 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190216819.11618.97.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> Message-ID: <46F15171.8070606@fedoraproject.org> Ralf Corsepius wrote: > I am pretty certain many Fedora users use Fedora for both situations and > consider a "mere desktop spin" a waste of time. That's ok. We will know soon enough how much interest there is when there is a general release of Fedora 8 and we get downloads and feedback. >> That's more useful than talking about RHEL. We >> all know the audience is different between these distributions. > It is not. > - Otherwise EPEL would not exist. > - Those using RHEL @situation X (eg. @work) not unlikely are the same > people running Fedora @situation Y (eg. @home) Your own example of running Fedora at home and RHEL at work is exactly the different kind of roles and expectations that I was talking about. Rahul From johannbg at hi.is Wed Sep 19 17:21:52 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Wed, 19 Sep 2007 17:21:52 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <1190213528.2949.34.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F12CE4.1050103@hi.is> <1190213528.2949.34.camel@localhost6.localdomain6> Message-ID: <46F15AB0.3010200@hi.is> Richi Plana wrote: > On Wed, 2007-09-19 at 14:06 +0000, "J?hann B. Gu?mundsson" wrote: > >> User should be able to turn on/off/enable/disable services ( the >> service's that aren't the mandatory one's ) in Anaconda >> > > Beg to disagree. Anaconda should just concentrate on getting the real > Fedora image installed so that it becomes the running system (its kernel > and filesystem is used). You can argue for it at firstboot, though. Or > just put it in kickstart (if possible). > > Then you must agree with me that Anaconda should enable just the service's that are the mandatory one's and no other.. For a system functional installation... And the user enables the rest of the services himself during first boot, first login or when ever he chooses to do so... If we are gonna go the way to let the system make the decision for the user then where are we gonna draw the line on how *smart* the system is.... Lets just go all the way!!!!... Anaconda should then be able to install *default* installation for the user in no more then 3 clicks.. User inserts CD/DVD/USB/ boots up AND ends up in Anaconda ---> User is presented with installation types Desktop System does educated guess on user preference ---> Server/Advanced Finish screen... User presented with reboot < click3 > 3 mouse clicks!!! no more no less.. Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From martin at bugs.unl.edu.ar Wed Sep 19 17:22:07 2007 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 19 Sep 2007 14:22:07 -0300 Subject: man page symlinks on symlinked binary Message-ID: <46F15ABF.10308@bugs.unl.edu.ar> There was a discussion earlier today on the fedora-list related with the fact that cdrecord doesn't have a man page. The person who made the question didn't know that cdrecord is just a symlink to wodim, so that man wodim would have given the man page he was looking for. The thing is that the discussion started flipping towards why, if there is a binary symlink, there isn't a man page symlink? This could, in the case of cdrecord and wodim, or mkisofs and genisofs, end in bugtrack tickets for those packages, but I am more interested in a general solution, for all packages that have binary symlinks. So, shouldn't there be something in respect of this issue in the packaging policy? From lmacken at redhat.com Wed Sep 19 17:21:16 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Sep 2007 13:21:16 -0400 Subject: bodhi interface changes Message-ID: <20070919172116.GC6429@crow.myhome.westell.com> Hey everyone, I recently made some UI modifications to my bodhi development branch that, in my opinion, make things a bit more elegant, and remove a lot of unnecessary data. http://lmacken.fedorapeople.org/before.png http://lmacken.fedorapeople.org/after.png So, with regard to the left side menu, I re-organized it by Release, instead of by update status. This not only makes things less redundant, but will also allow us to know exactly what release an update is getting pushed for in the New Update Form -- which will let us remove the release dropdown[0], and auto-complete *only* builds that *can* be pushed for that specific release. Regarding the update list.. I removed the Release column and the status, because that can be implied by the title of the list. I also added a submitter column, because accountability is a good thing. With the pending screen, I added a Request column, so people can get a quick glance as to where the updates are going. I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, and to see if anyone has any comments/suggestions/oppositions. luke [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84 From tmz at pobox.com Wed Sep 19 17:29:36 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 19 Sep 2007 13:29:36 -0400 Subject: man page symlinks on symlinked binary In-Reply-To: <46F15ABF.10308@bugs.unl.edu.ar> References: <46F15ABF.10308@bugs.unl.edu.ar> Message-ID: <20070919172936.GE24288@psilocybe.teonanacatl.org> Martin Marques wrote: > This could, in the case of cdrecord and wodim, or mkisofs and > genisofs, end in bugtrack tickets for those packages, but I am more > interested in a general solution, for all packages that have binary > symlinks. Skipping the larger policy issue, I did file a bug (with a patch) about adding the man page symlinks for cdrkit. https://bugzilla.redhat.com/show_bug.cgi?id=296611 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hardware: the parts of a computer that can be kicked. -- Jeff Pesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From opensource at till.name Wed Sep 19 17:41:12 2007 From: opensource at till.name (Till Maas) Date: Wed, 19 Sep 2007 19:41:12 +0200 Subject: bodhi interface changes In-Reply-To: <20070919172116.GC6429@crow.myhome.westell.com> References: <20070919172116.GC6429@crow.myhome.westell.com> Message-ID: <200709191941.18303.opensource@till.name> On Mi September 19 2007, Luke Macken wrote: > pushed for in the New Update Form -- which will let us remove the release > dropdown[0], and auto-complete *only* builds that *can* be pushed for that > specific release. > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, > and to see if anyone has any comments/suggestions/oppositions. Imho there should be also a way to createa an update for two releases at once. E.g. when Fedora 8 is out, and a package is updated for it, often there will be the same update for Fedora 7. It seems that this was easier possible with the old interface, because one should be able to just go back and change the release and the build, but keep the bugs / cves and notice. But for a complete support of "identical" updates for two releases, I guess there needs to be changed a lot more, anyway, e.g. when one wants to edit both updates. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Wed Sep 19 17:51:23 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 19 Sep 2007 19:51:23 +0200 Subject: is Miro (aka Democracy player) supported in Fedora ? In-Reply-To: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> References: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> Message-ID: <64b14b300709191051t1e3f944csfb1d4cf7be6e6e62@mail.gmail.com> On 9/19/07, Valent Turkovic wrote: > Is Miro (aka Democracy player) supported under Fedora? > I tried to install it but for weeks now it is not possible to install > it under Rawhide. > So I'm asking will Miro be supported in Fedora 8 - or if my question > it not precise enough - will I be able to 'yum install Miro' and > expect it to install and work? > > Thank you. > I forgot to send this bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=273961 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lmacken at redhat.com Wed Sep 19 17:47:55 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Sep 2007 13:47:55 -0400 Subject: bodhi interface changes In-Reply-To: <200709191941.18303.opensource@till.name> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> Message-ID: <20070919174755.GA3091@crow.boston.redhat.com> On Wed, Sep 19, 2007 at 07:41:12PM +0200, Till Maas wrote: > On Mi September 19 2007, Luke Macken wrote: > > > pushed for in the New Update Form -- which will let us remove the release > > dropdown[0], and auto-complete *only* builds that *can* be pushed for that > > specific release. > > > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, > > and to see if anyone has any comments/suggestions/oppositions. > > Imho there should be also a way to createa an update for two releases at once. > E.g. when Fedora 8 is out, and a package is updated for it, often there will > be the same update for Fedora 7. It seems that this was easier possible with > the old interface, because one should be able to just go back and change the > release and the build, but keep the bugs / cves and notice. But for a > complete support of "identical" updates for two releases, I guess there needs > to be changed a lot more, anyway, e.g. when one wants to edit both updates. In that case it may be best to make a single generic update form that will accept any candidate build, and will imply the Release(s) from there. luke From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 15:03:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 19 Sep 2007 17:03:21 +0200 Subject: why does yum want xulrunner? In-Reply-To: References: Message-ID: <20070919170321.b4760b3d.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Sep 2007 10:20:34 -0400, sean wrote: > from today: > > yum update > ............ > --> Finished Dependency Resolution > Error: Unresolvable requirement libxpcom_core.so()(64bit) for yelp > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for yelp > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for yelp > Error: Missing Dependency: firefox is needed by package libswt3-gtk2 > Error: Unresolvable requirement gecko-libs = 1.8.1.6 for devhelp > Error: Unresolvable requirement libgtkembedmoz.so()(64bit) for devhelp > Error: Unresolvable requirement libgtkembedmoz.so for devhelp > > yum --exclude=xulrunner update works. > > and xulrunner is not installed: > > rpm -q xulrunner > package xulrunner is not installed It is not installed, but in the yum metadata it replaces firefox and at the same time takes away packages capabilities required by other packages. The xulrunner package includes things such as Provides: gecko-libs = 1.9a7 Provides: gecko-libs = 1.9 Provides: libsqlite3.so <-- ought to be filtered out! Obsoletes: firefox < 2.1 with some required package updates not being available yet. From limb at jcomserv.net Wed Sep 19 17:26:07 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 19 Sep 2007 12:26:07 -0500 (CDT) Subject: bodhi interface changes In-Reply-To: <20070919172116.GC6429@crow.myhome.westell.com> References: <20070919172116.GC6429@crow.myhome.westell.com> Message-ID: <5639.63.85.68.164.1190222767.squirrel@mail.jcomserv.net> > Hey everyone, > > I recently made some UI modifications to my bodhi development branch that, > in my opinion, make things a bit more elegant, and remove a lot of > unnecessary data. > > http://lmacken.fedorapeople.org/before.png > http://lmacken.fedorapeople.org/after.png > > So, with regard to the left side menu, I re-organized it by Release, > instead of by update status. This not only makes things less redundant, > but will also allow us to know exactly what release an update is getting > pushed for in the New Update Form -- which will let us remove the release > dropdown[0], and auto-complete *only* builds that *can* be pushed for that > specific release. > > Regarding the update list.. I removed the Release column and the status, > because that can be implied by the title of the list. I also added a > submitter column, because accountability is a good thing. With the > pending screen, I added a Request column, so people can get a quick glance > as to where the updates are going. > > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, > and to see if anyone has any comments/suggestions/oppositions. +1 helpful > luke > > [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From fedora at leemhuis.info Wed Sep 19 18:04:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 19 Sep 2007 20:04:16 +0200 Subject: bodhi interface changes In-Reply-To: <200709191941.18303.opensource@till.name> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> Message-ID: <46F164A0.4090409@leemhuis.info> On 19.09.2007 19:41, Till Maas wrote: > On Mi September 19 2007, Luke Macken wrote: >> pushed for in the New Update Form -- which will let us remove the release >> dropdown[0], and auto-complete *only* builds that *can* be pushed for that >> specific release. >> I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, >> and to see if anyone has any comments/suggestions/oppositions. > Imho there should be also a way to createa an update for two releases at once. > E.g. when Fedora 8 is out, and a package is updated for it, often there will > be the same update for Fedora 7. It seems that this was easier possible with > the old interface, because one should be able to just go back and change the > release and the build, but keep the bugs / cves and notice. But for a > complete support of "identical" updates for two releases, I guess there needs > to be changed a lot more, anyway, e.g. when one wants to edit both updates. While I agree in general to make stuff easier: Wouldn't it be better to normally ship the F7 update some days after shipping the one for F8 (and that itself some days after it hit devel)? That IMHO has a important benefit: if a crucial bug made it into F8 because it was not noticed in devel or updates-testing earlier there is still time left to *not* ship that update for F7. Cu knurd From dwmw2 at infradead.org Wed Sep 19 18:26:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 19:26:05 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190216479.2926.106.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> Message-ID: <1190226365.14091.5.camel@pmac.infradead.org> On Wed, 2007-09-19 at 16:41 +0100, David Woodhouse wrote: > Actually the patch in question seems to be applied already -- the only > problem seems to be that while $(OS_TEST) used to be set to 'ppc' it's > now set to 'powerpc', so the makefile fails to select a set of stubs > and the build aborts (yay, aborts rather than silently building a > broken library, like it used to). I assume it'll be the same issue for > ppc64/powerpc64. but will let the 32-bit build finish first. Ah, the patch also needs to be updated to the one from mozilla bug #361415, rather than the older patch for firefox 1.5 thru 2.0. One more minor change to a function name and it seems to build the xptc bits fine (with the attached patch). It still fails for me in in mock, but I hereby declare this error to be Someone Else's Problem?: /usr/include/bits/unistd.h: In function 'int gethostname(char*, size_t)': /usr/include/bits/unistd.h:225: error: declaration of 'int gethostname(char*, size_t) throw ()' throws different exceptions /usr/include/unistd.h:845: error: from previous declaration 'int gethostname(char*, size_t)' /usr/include/bits/unistd.h: In function 'int getdomainname(char*, size_t)': /usr/include/bits/unistd.h:243: error: declaration of 'int getdomainname(char*, size_t) throw ()' throws different exceptions /usr/include/unistd.h:864: error: from previous declaration 'int getdomainname(char*, size_t)' gmake[5]: *** [nsGREGlue.o] Error 1 -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-head-ppc64.patch Type: text/x-patch Size: 30013 bytes Desc: URL: From tla at rasmil.dk Wed Sep 19 18:28:46 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 19 Sep 2007 20:28:46 +0200 Subject: bodhi interface changes In-Reply-To: <20070919172116.GC6429@crow.myhome.westell.com> References: <20070919172116.GC6429@crow.myhome.westell.com> Message-ID: <46F16A5E.2080006@rasmil.dk> Luke Macken wrote: > Hey everyone, > > I recently made some UI modifications to my bodhi development branch that, in my opinion, make things a bit more elegant, and remove a lot of unnecessary data. > > http://lmacken.fedorapeople.org/before.png > http://lmacken.fedorapeople.org/after.png > > So, with regard to the left side menu, I re-organized it by Release, instead of by update status. This not only makes things less redundant, but will also allow us to know exactly what release an update is getting pushed for in the New Update Form -- which will let us remove the release dropdown[0], and auto-complete *only* builds that *can* be pushed for that specific release. > > Regarding the update list.. I removed the Release column and the status, because that can be implied by the title of the list. I also added a submitter column, because accountability is a good thing. With the pending screen, I added a Request column, so people can get a quick glance as to where the updates are going. > > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, and to see if anyone has any comments/suggestions/oppositions. > > luke > > [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84 > > Looks good to me. Tim From valent.turkovic at gmail.com Wed Sep 19 18:31:52 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 19 Sep 2007 20:31:52 +0200 Subject: usb hotplug stopped working on Fedora Core 6 - any ideas how to troubleshoot? In-Reply-To: <64b14b300709140712j6b289e37jbb41a25e6494b85e@mail.gmail.com> References: <64b14b300709120552p408cc5a9x37cba21ce008a0cf@mail.gmail.com> <46E7E303.9000208@zianet.com> <64b14b300709130652o57dcde66k1b528df40be5ed84@mail.gmail.com> <46E953AF.8080007@zianet.com> <64b14b300709140712j6b289e37jbb41a25e6494b85e@mail.gmail.com> Message-ID: <64b14b300709191131p7d4b93feoa490954a78099618@mail.gmail.com> On 9/14/07, Valent Turkovic wrote: > On 9/13/07, Karl Larsen wrote: > > Valent Turkovic wrote: > > > grep udev rpm > > > udev-095-17.fc6 Tue 16 Jan 2007 11:20:16 > > > AM CET > > I can't tell but the RPM you loaded is from last January and it > > may be the problem. > > sorry that should have been: > > # rpm -qa |grep udev > udev-095-17.fc6 > > I have no updates since that packet is the latest one. > > I did: > yum clean all > yum update > > and no updates came, that is the latest udev that FC6 has in it's repos. > > Do you have some other suggestions? > > > > > > > > uname -a > > > Linux fedora 2.6.22.2-42.fc6 #1 SMP Wed Aug 15 12:34:26 EDT 2007 i686 > > > i686 i386 GNU/Linux > > > > > This is the next to last kernel for F7 and it should be fine IF you have > > a udev that works. I think you might try to yum install a later udev. > > > > I'm on a FC6 box... > > > > What else feedback do you need? > > > > > > On 9/12/07, *Karl Larsen* > > > > wrote: > > > > > > Valent Turkovic wrote: > > > > Hi, I have issues with usb hotplug. > > > > I used to plug my usb memory sticks and mp3 players and they would > > > > automount and gnome would show them on the desktop and open an > > > > nautilus window. > > > > > > > > How I see kernel sees device when I plug it but no automount > > > happens. > > > > I can still manually do 'mount /dev/sdb1 /media/disk' but I liked it > > > > how it automatically just worked. > > > > I have two Fedeora Core 6 laptops and I didn't pay attention > > > when it > > > > stopped working on which but now automount doesn't work on both of > > > > them. Maybe some update broke it? > > > > > > > > I have no idea how to troubleshoot it and if this is a bug, and > > > should > > > > I report it as a bug and where... so any suggestions are welcome. > > > > > > > > Thank you. > > > > > > > > Valent from Croatia. > > > > > > > > -- > > > > http://kernelreloaded.blog385.com/ < > > > http://kernelreloaded.blog385.com/> > > > > linux, blog, anime, spirituality, windsurf, wireless > > > > registered as user #367004 with the Linux Counter, > > > http://counter.li.org. > > > > ICQ: 2125241, Skype: valent.turkovic > > > Please tell us what kernel your using. Also find out what the last > > > few update's were by looking at /var/log/yum.log. Look for kernel and > > > udev updates. > > > > > > On F7 we had that problem and it was corrected by new kernels and > > > updated udev. You may be have the F7 problem :( > Anybody? Is udev dead on Fedora Core 6? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lmacken at redhat.com Wed Sep 19 18:30:02 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Sep 2007 14:30:02 -0400 Subject: bodhi interface changes In-Reply-To: <46F164A0.4090409@leemhuis.info> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> Message-ID: <20070919183002.GB3091@crow.boston.redhat.com> On Wed, Sep 19, 2007 at 08:04:16PM +0200, Thorsten Leemhuis wrote: > On 19.09.2007 19:41, Till Maas wrote: > > On Mi September 19 2007, Luke Macken wrote: > >> pushed for in the New Update Form -- which will let us remove the release > >> dropdown[0], and auto-complete *only* builds that *can* be pushed for that > >> specific release. > >> I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, > >> and to see if anyone has any comments/suggestions/oppositions. > > Imho there should be also a way to createa an update for two releases at once. > > E.g. when Fedora 8 is out, and a package is updated for it, often there will > > be the same update for Fedora 7. It seems that this was easier possible with > > the old interface, because one should be able to just go back and change the > > release and the build, but keep the bugs / cves and notice. But for a > > complete support of "identical" updates for two releases, I guess there needs > > to be changed a lot more, anyway, e.g. when one wants to edit both updates. > > While I agree in general to make stuff easier: Wouldn't it be better to > normally ship the F7 update some days after shipping the one for F8 (and > that itself some days after it hit devel)? > > That IMHO has a important benefit: if a crucial bug made it into F8 > because it was not noticed in devel or updates-testing earlier there is > still time left to *not* ship that update for F7. Agreed. Stuffing multiple releases into a single update would make the whole karma/updates-testing thing painful. Maybe the best solution is to make it trivial to "clone" an update for another release ? Or we could have the form automatically clone the update for each release based on the provided builds ? luke From opensource at till.name Wed Sep 19 18:40:44 2007 From: opensource at till.name (Till Maas) Date: Wed, 19 Sep 2007 20:40:44 +0200 Subject: bodhi interface changes In-Reply-To: <46F164A0.4090409@leemhuis.info> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> Message-ID: <200709192040.54809.opensource@till.name> On Wednesday 19 September 2007 20:04:16 Thorsten Leemhuis wrote: > While I agree in general to make stuff easier: Wouldn't it be better to > normally ship the F7 update some days after shipping the one for F8 (and > that itself some days after it hit devel)? The creation of an update and pushing it to stable or testing are two different tasks, even when both updates are created at the same time, this does not mean that they need to be pushed to some repository at the same time. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Wed Sep 19 18:42:39 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 19 Sep 2007 20:42:39 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <46DB0EFB.5080107@olen.net> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> <46DB0EFB.5080107@olen.net> Message-ID: <64b14b300709191142q60688f4dv4d04ca9f352d899d@mail.gmail.com> On 9/2/07, Ola Thoresen wrote: > Valent Turkovic wrote: > > > > Ok, thanks > > > > So any ideas? Any help from you or anybody else? > > > No ideas, I'm afraid, but I believe I have the same problem. > No matter what position the kill switch is set - and no matter if I boot > or just rmmod/modprobe the module I get the "Kill switch is on"-message. > > There is a thread over at the Ubuntu-forums where I have made a few > postings: > > http://ubuntuforums.org/showthread.php?t=246074 > > > Rgds. > > Ola Thoresen Ok, I fixed the issue but only with using Windows :( I booted to my windows partition (which I don't use more than once a month) to test this behavior also there. When I presses hardware button only bluetooth got enabled or disabled, but when I clicked on the pop up window from HP wireless assistant from there enabling wireless was only click away. After software enabling wireless through HP Wireless assistant now pressing hardware button (RF_KILL switch) enables or disables BOTH bluetooth and wireless under windows. Now I booted back to Fedora and I have wireless device if I leave in enabled during boot via RF_KILL switch. If I try to enable it via RF_KILL switch after the machine has booted I don't get wireless but rmmod and modprobe fixes that. it this helpful? Why can't I overrule software RF_KILL switch within linux? When I bootup my system with software kill ON from windows and into Fedora I get this: # cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill 2 # iwconfig lo no wireless extensions. eth0 no wireless extensions. then I try to echo "0" [root at rawhide ~]# echo "0" >> /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill [root at rawhide ~]# [root at rawhide ~]# cat /sys/bus/pci/drivers/iwl3945/module/drivers/pci\:iwl3945/0000\:10\:00.0/rf_kill 2 So as you can seen I cannot switch off software kill under linux, but I can under windows. I must add that all the time hardware RF_KILL switch is DISABLED and not enabled as you could conclude from reading "rf_kill" kernel file. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ville.skytta at iki.fi Wed Sep 19 18:44:16 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 19 Sep 2007 21:44:16 +0300 Subject: man page symlinks on symlinked binary In-Reply-To: <46F15ABF.10308@bugs.unl.edu.ar> References: <46F15ABF.10308@bugs.unl.edu.ar> Message-ID: <200709192144.16934.ville.skytta@iki.fi> On Wednesday 19 September 2007, Martin Marques wrote: > The thing is that the discussion started flipping towards why, if there > is a binary symlink, there isn't a man page symlink? This could, in the > case of cdrecord and wodim, or mkisofs and genisofs, end in bugtrack > tickets for those packages, but I am more interested in a general > solution, for all packages that have binary symlinks. > > So, shouldn't there be something in respect of this issue in the > packaging policy? I support that (or the more or less AFAIK equivalent 'echo ".so man1/wodim.1" > cdrecord.1' approach as an alternative to symlinks). Could you write a draft for that? I can take it onwards from there in the packaging committee. From bpepple at fedoraproject.org Wed Sep 19 19:17:46 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 19 Sep 2007 15:17:46 -0400 Subject: Plan for tomorrows (20070920) FESCO meeting Message-ID: <1190229466.3519.3.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- revisiting status of features which we gave a pass to go in post-feature freeze - jeremy /topic FESCO-Meeting -- MISC -- transition plan for switching devel to rawhide - warren /topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy /topic Status Update: FESCo Proposal Template - f13 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nando at ccrma.Stanford.EDU Wed Sep 19 19:20:15 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 19 Sep 2007 12:20:15 -0700 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190073567.16960.90.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> <1190073567.16960.90.camel@localhost6.localdomain6> Message-ID: <1190229615.29210.28.camel@cmn3.stanford.edu> On Mon, 2007-09-17 at 17:59 -0600, Richi Plana wrote: > On Mon, 2007-09-17 at 15:32 -0700, Fernando Lopez-Lezcano wrote: > > For now it would be great to get the Planet CCRMA packages that are > > already there moved into Fedora proper (I think Planet CCRMA is quite > > complete, but of course I'm slightly biased :-). If there are > > interesting apps missing I/we'd like to know, of course - I'm sure there > > are cool apps out there I have not yet packaged :-) > > Could someone update the wiki with a list of outstanding packages that > need attention, then? > > I google'd for Planet CCRMA's site (not on the wiki) and found the > current repo. I found the compiled binaries but the SRPMS subdirectory > is empty. Sorry, the source packages are common to all versions and architectures currently supported. They all can be found here in the link posted by Hans. Maybe I should write a script to cross link them but I'd rather be doing other things.... > What are the packages that need to be packaged for Fedora? And is > packaging going to start from scratch or are we picking up where Planet > CCRMA left off? Please don't start from scratch... I'm sure all packages can be improved but I have spent a lot of time (see below) in them and they do work. Of course Planet CCRMA does not have _everything_ so there's bound to be music, midi and audio packages that it does not have and would be interesting to add to Fedora anyway. > I've found the CCRMA site http://ccrma.stanford.edu/ and the Planet > CCRMA site (http://ccrma.stanford.edu/planetccrma/software/). How > exactly are the two related? I understand that CCRMA has a couple of > software projects (some old, some active). Is PlanetCCRMA currently > in-sync with the projects at CCRMA? I guess what I'm trying to ask (and > I can't find the right words to express it) is what's the intersection > of the two entities in terms of software and what is the > ? CCRMA, the Center for Computer Research in Music and Acoustics is were I work, it is part of the Music Department at Stanford but it is quite interdisciplinary (there are students from Music, EE, Computer Science, Psychology, etc, etc). We have been using linux as our main computing platform for quite a while (first installs around the end of '96 - before that we were using NeXTs and before _that_ - before my time here - a mainframe and custom built hardware synthesizer and before __that__ computer music hackers were "allowed" to use the computer resources of the AI lab at Stanford at night only). We also have OSX machines as well (no Windows so far). I maintain the computer and networking infrastructure here, including software (and I also teach and I am a composer and researcher - when I find time for that :-). At the beginning of the Linux era, as we used more and more Linux machines (dual booting with NextStep!) I started packaging software we were using for teaching, so that installs would be easier (we currently have around 50 Linux machines online). And added kernels with the low latency patches. And added ALSA drivers and the infrastructure they needed when they were just starting. After a while some CCRMAlites started asking about the packages and I pointed to the directory where they lived. Then they asked how to install them. Eventually I wrote a short web page about them. I then made the mistake of announcing the informal project in the cmdist mailing list :-) That was back in 2001 and I think it was based on RedHat 7.2 at the time. The project was called "Planet CCRMA"[*]. After that it went downhill (figuratively speaking :-) as it became very popular and transformed into a black hole for any ammount of available time I had. As the community of users grew worldwide I started getting requests for packages that I would probably not have installed at CCRMA. So the opening of the project to the world had the nice side effect of broadening the scope of software that I installed at CCRMA. Very good overall. Hope this all makes sense and answers your question... CCRMA is the institution for/on/with which I created the project, Planet CCRMA is the project. Without the continued support of CCRMA, Planet CCRMA would not exist. -- Fernando [*] the name Planet CCRMA actually predates the repository, it was used by a bunch of web pages we maintained with Juan Reyes (a Visiting Scholar and Composer who coined the name) explaining how to use the linux based resources we had. From a.badger at gmail.com Wed Sep 19 19:22:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 19 Sep 2007 12:22:10 -0700 Subject: Packaging Minutes 2007-08-28 Message-ID: <46F176E2.2030708@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For full logs, please see: http://fedoraproject.org/wiki/Packaging/Minutes20070918 === Fedora Packaging Committee Meeting of {2007-09-18} === ==== Present ==== * JesseKeating (`f13`) * RalfCorsepius (`racor`) * TomCallaway (`spot`) * ToshioKuratomi (`abadger1999`) * VilleSkytt? (`scop`) * Rex Dieter (`rdieter`) ==== Writeups ==== No new guidelines this week. ==== Votes ==== The following proposals were considered: * Python Egg Guidelines: http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs * Accepted (5 - 0) * Voting for: spot abadger1999 scop rdieter racor ==== Other Discussions ==== KMods were briefly discussed. spot will be changing the guidelines to reflect that FESCo issued a ban on new kmods, old kmods can remain for F8 but will either be merged into the kernel or dropped for F9. The issue of user-land tools that require the kernel module was brought up. What to do with them was deferred until we know if the kmods in question will be merged into the kernel or not. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8XbiX6yAic2E7kgRAmWUAKCIgwQUhIxhMsvwwJwa0zikqzoBigCfahIf AlEu9sfJUcFW+35PZiOdzoU= =LrpY -----END PGP SIGNATURE----- From jon at fedoraunity.org Wed Sep 19 19:30:23 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Wed, 19 Sep 2007 13:30:23 -0600 Subject: bodhi interface changes In-Reply-To: <20070919183002.GB3091@crow.boston.redhat.com> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> <20070919183002.GB3091@crow.boston.redhat.com> Message-ID: <46F178CF.40308@fedoraunity.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luke Macken wrote: [...] > Agreed. Stuffing multiple releases into a single update would make the > whole karma/updates-testing thing painful. Maybe the best solution is > to make it trivial to "clone" an update for another release ? Or we > could have the form automatically clone the update for each release > based on the provided builds ? I might have missed this... What is karma, how do we use it? How do we increase our packages' karma? What is karma currently used for? Jonathan Steffan daMaestro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8XjOrRJs5w2Gr1kRAqS+AJ91vZZu291JbYYXxYyuFRlUF2kUiwCgkDRw EIcpEhzCY47KSDYUCY7Y518= =BZiH -----END PGP SIGNATURE----- From lamont at gurulabs.com Wed Sep 19 19:36:07 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 19 Sep 2007 13:36:07 -0600 Subject: man page symlinks on symlinked binary In-Reply-To: <200709192144.16934.ville.skytta@iki.fi> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> Message-ID: <20070919133607.6ae819c5@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 19 Sep 2007 21:44:16 +0300 Ville Skytt? wrote: > On Wednesday 19 September 2007, Martin Marques wrote: > > > The thing is that the discussion started flipping towards why, if > > there is a binary symlink, there isn't a man page symlink? This > > could, in the case of cdrecord and wodim, or mkisofs and genisofs, > > end in bugtrack tickets for those packages, but I am more > > interested in a general solution, for all packages that have binary > > symlinks. > > > > So, shouldn't there be something in respect of this issue in the > > packaging policy? > > I support that (or the more or less AFAIK equivalent 'echo ".so > man1/wodim.1" > > cdrecord.1' approach as an alternative to symlinks). Could you > > write a > draft for that? I can take it onwards from there in the packaging > committee. I would suggest creating a cdrecord(1) man page that says "This is no more. See wodim(1), which replaces it." Put that cdrecord(1) man page into the wodim package. This way, we teach people that there's been a change and we don't get "Um, when I type 'man cdrecord' I get a man page for something totally different; what gives?" kinds of questions/bug reports/requests. Of course, adjust the verbage appropriately in the "this command went bye-bye" man pages. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8Xon+YBsl9wN1AkRAhdtAJ43J8X8zY++WFz3J/yP2rp5zNhcUwCgpbtn YHhhBo5yl29FWGpPCR8RDTc= =KqqQ -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Wed Sep 19 19:34:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 01:04:53 +0530 Subject: bodhi interface changes In-Reply-To: <46F178CF.40308@fedoraunity.org> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> <20070919183002.GB3091@crow.boston.redhat.com> <46F178CF.40308@fedoraunity.org> Message-ID: <46F179DD.4060209@fedoraproject.org> Jonathan Steffan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Luke Macken wrote: > [...] >> Agreed. Stuffing multiple releases into a single update would make the >> whole karma/updates-testing thing painful. Maybe the best solution is >> to make it trivial to "clone" an update for another release ? Or we >> could have the form automatically clone the update for each release >> based on the provided builds ? > > I might have missed this... What is karma, how do we use it? How do we > increase our packages' karma? What is karma currently used for? See http://bpepple.fedorapeople.org/FESCo-2007-09-06.html. It is a feedback/voting mechanism for pushing packages from updates-testing to updates. Rahul From myfedora at richip.dhs.org Wed Sep 19 20:04:07 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 14:04:07 -0600 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190229615.29210.28.camel@cmn3.stanford.edu> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> <1190073567.16960.90.camel@localhost6.localdomain6> <1190229615.29210.28.camel@cmn3.stanford.edu> Message-ID: <1190232247.6854.22.camel@localhost6.localdomain6> Hi, Fernando. First of all, thanks for the comprehensive introduction. On Wed, 2007-09-19 at 12:20 -0700, Fernando Lopez-Lezcano wrote: > Sorry, the source packages are common to all versions and architectures > currently supported. They all can be found here in the link posted by > Hans. Maybe I should write a script to cross link them but I'd rather be > doing other things.... Hopefully if things get transitioned to Fedora or one of the other third-party repos, it won't be necessary. There WILL be a discrepancy between your packages and the ones on Fedora as time goes by, though. > At the beginning of the Linux era, as we used more and more Linux > machines (dual booting with NextStep!) I started packaging software we > were using for teaching, so that installs would be easier (we currently > have around 50 Linux machines online). And added kernels with the low > latency patches. And added ALSA drivers and the infrastructure they > needed when they were just starting. After a while some CCRMAlites > started asking about the packages and I pointed to the directory where > they lived. Then they asked how to install them. Eventually I wrote a > short web page about them. I then made the mistake of announcing the > informal project in the cmdist mailing list :-) That was back in 2001 > and I think it was based on RedHat 7.2 at the time. The project was > called "Planet CCRMA"[*]. > > After that it went downhill (figuratively speaking :-) as it became very > popular and transformed into a black hole for any ammount of available > time I had. As the community of users grew worldwide I started getting > requests for packages that I would probably not have installed at CCRMA. > So the opening of the project to the world had the nice side effect of > broadening the scope of software that I installed at CCRMA. Very good > overall. > > Hope this all makes sense and answers your question... It does answer things I've been wondering about, but I also wanted to know how many of the packages in PlanetCCRMA are still actively being developed or maintained. As well, are there any software packages in CCRMA that aren't packaged yet for PlanetCCRMA? Also, some software might rely on a specific kernel (low-latency patches, etc.) Those packages which rely on that kernel might have to be tagged as requiring a low-latency kernel. Personally, I'd like to look into the package meta-info for this, but most likely it will mean having a package called kernel-ccrma (or -lowlatency or -rt or whatever). It will now be a part of the Fedora package namespace. To work with the rest of Fedora, we might need to transition those patches to the official Fedora kernel. This is specially important when the kmods get sucked into the kernel SRPM. Is there a way to tell which app packages need the -rt kernel? Since you (Fernando) know the packages better than most, could you list the apps you think should be given higher priority for transitioning? -- Richi Plana From kevin.kofler at chello.at Wed Sep 19 20:16:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 19 Sep 2007 20:16:38 +0000 (UTC) Subject: Root login in rawhide and display managers References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > KDM root login was disabled until the last release anyway. That doesn't make it any better an idea. Why should we regress this now? Kevin Kofler From myfedora at richip.dhs.org Wed Sep 19 20:17:36 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 14:17:36 -0600 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> <1190212894.2949.23.camel@localhost6.localdomain6> Message-ID: <1190233056.6854.32.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 11:50 -0400, Colin Walters wrote: > That's great. If you are running this sort of complex home > networking, know how to set up servers and NIS etc., then the choose > your own adventure DVD or boot.iso, combined with kickstart files are > appropriate for you. There's nothing complex about it, and as I mentioned, it's becoming the standard these days to have multiple computers and networked homes. Say what you will, but I doubt configuring network authentication at install-time will go away. First of all, it's already there and it's non-intrusive. Even inexperienced installers aren't stymied by it (though I would agree to a message stating "If you don't know what this is, then don't ignore it"). Second, there are just too many people who use Fedora now who need it. People who actually use Fedora are likely to use that option or wish they did. If anyone can show that having the option to configure network authentication at install-time is a bigger detriment compared to having the current number of people who DO use it suddenly create their own ISOs or kickstart files OR be forced to create local users other than root when it's unnecessary, then it may get a chance at being adopted. -- Richi Plana From lmacken at redhat.com Wed Sep 19 20:10:35 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Sep 2007 16:10:35 -0400 Subject: bodhi interface changes In-Reply-To: <46F178CF.40308@fedoraunity.org> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> <20070919183002.GB3091@crow.boston.redhat.com> <46F178CF.40308@fedoraunity.org> Message-ID: <20070919201035.GB5524@crow.boston.redhat.com> On Wed, Sep 19, 2007 at 01:30:23PM -0600, Jonathan Steffan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Luke Macken wrote: > [...] > > Agreed. Stuffing multiple releases into a single update would make the > > whole karma/updates-testing thing painful. Maybe the best solution is > > to make it trivial to "clone" an update for another release ? Or we > > could have the form automatically clone the update for each release > > based on the provided builds ? > > I might have missed this... What is karma, how do we use it? How do we > increase our packages' karma? What is karma currently used for? It's a simple integer that is incremented/decremented based on if the update works or not for the tester. Right now, when an update reaches a karma of 3, it is automatically pushed to stable. This mechanism is definitely subject to change over time, so feedback is welcome :) luke From kevin.kofler at chello.at Wed Sep 19 20:18:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 19 Sep 2007 20:18:08 +0000 (UTC) Subject: Root login in rawhide and display managers References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> Message-ID: Matthias Clasen redhat.com> writes: > Yeah, but then you don't walk away from your root session expecting the > screensaver to kick in - which it doesn't for root. Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking for root work just fine in KDE. Kevin Kofler From valent.turkovic at gmail.com Wed Sep 19 17:49:25 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 19 Sep 2007 19:49:25 +0200 Subject: is Miro (aka Democracy player) supported in Fedora ? Message-ID: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> Is Miro (aka Democracy player) supported under Fedora? I tried to install it but for weeks now it is not possible to install it under Rawhide. So I'm asking will Miro be supported in Fedora 8 - or if my question it not precise enough - will I be able to 'yum install Miro' and expect it to install and work? Thank you. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From myfedora at richip.dhs.org Wed Sep 19 14:24:27 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 08:24:27 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <2183.63.85.68.164.1190205288.squirrel@mail.jcomserv.net> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <20070919125258.GA7373@devserv.devel.redhat.com> <2183.63.85.68.164.1190205288.squirrel@mail.jcomserv.net> Message-ID: <1190211867.2949.13.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 07:34 -0500, Jon Ciesla wrote: > > On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote: > >> Proposed alternative: enable root logins, but customize the default root > >> GUI environment so it is a clear and simple rescue/configuration > >> workspace, > >> not just another user's desktop. > > > > Thats an extremely good idea and one I like a great deal > > +1 Well, if it is ever decided to re-allow root login, then +1 to that idea. Regular gnome sessions and KDE sessions just require so many user processes to run and some to even daemonize themselves that it's scary to think they've root privileges. I mean, who knows how well they're written and what kind of havoc they could cause. As for the X environment, give them TWM, ;). -- Richi Plana From tcallawa at redhat.com Wed Sep 19 20:23:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Sep 2007 16:23:32 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190226365.14091.5.camel@pmac.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> <1190226365.14091.5.camel@pmac.infradead.org> Message-ID: <1190233412.3418.11.camel@localhost.localdomain> On Wed, 2007-09-19 at 19:26 +0100, David Woodhouse wrote: > On Wed, 2007-09-19 at 16:41 +0100, David Woodhouse wrote: > > Actually the patch in question seems to be applied already -- the only > > problem seems to be that while $(OS_TEST) used to be set to 'ppc' it's > > now set to 'powerpc', so the makefile fails to select a set of stubs > > and the build aborts (yay, aborts rather than silently building a > > broken library, like it used to). I assume it'll be the same issue for > > ppc64/powerpc64. but will let the 32-bit build finish first. > > Ah, the patch also needs to be updated to the one from mozilla bug > #361415, rather than the older patch for firefox 1.5 thru 2.0. One more > minor change to a function name and it seems to build the xptc bits fine > (with the attached patch). It still fails for me in in mock, but I > hereby declare this error to be Someone Else's Problem?: > > /usr/include/bits/unistd.h: In function 'int gethostname(char*, size_t)': > /usr/include/bits/unistd.h:225: error: declaration of 'int gethostname(char*, size_t) throw ()' throws different exceptions > /usr/include/unistd.h:845: error: from previous declaration 'int gethostname(char*, size_t)' > /usr/include/bits/unistd.h: In function 'int getdomainname(char*, size_t)': > /usr/include/bits/unistd.h:243: error: declaration of 'int getdomainname(char*, size_t) throw ()' throws different exceptions > /usr/include/unistd.h:864: error: from previous declaration 'int getdomainname(char*, size_t)' > gmake[5]: *** [nsGREGlue.o] Error 1 > This looks like a bug in -Wp,-D_FORTIFY_SOURCE=2 for C++ code. If I remove that option, it gets past that point. ~spot From myfedora at richip.dhs.org Wed Sep 19 20:27:52 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 14:27:52 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <46F15AB0.3010200@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F12CE4.1050103@hi.is> <1190213528.2949.34.camel@localhost6.localdomain6> <46F15AB0.3010200@hi.is> Message-ID: <1190233672.6854.42.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 17:21 +0000, "J?hann B. Gu?mundsson" wrote: > Richi Plana wrote: > > On Wed, 2007-09-19 at 14:06 +0000, "J?hann B. Gu?mundsson" wrote: > > > >> User should be able to turn on/off/enable/disable services ( the > >> service's that aren't the mandatory one's ) in Anaconda > >> > > > > Beg to disagree. Anaconda should just concentrate on getting the real > > Fedora image installed so that it becomes the running system (its kernel > > and filesystem is used). You can argue for it at firstboot, though. Or > > just put it in kickstart (if possible). > > > > > Then you must agree with me that Anaconda should enable just the > service's that are the mandatory one's and no other.. How I wish! I want all my installations to be as lean and mean, as possible. Unfortunately, you're relying on people to choose which services should be enabled or not when it should be the user (via his/her use of the computer) that should decide. Once the software is installed on a person's machine, we won't be there to enable or disable a service should it all of a sudden be needed. Ideally, the software should be smart enough to enable what needs to be enabled when the user says "I need to do this" (and one of it's requirements is an enabled service), but we aren't there yet and there's no formal mention that that's the direction we are actually going. Really, the system should try to be smarter when it comes to guessing what the user needs (as opposed to being static and set at spin-time). Even Windows tries to be smart and keeps track of what apps have been recently used and presents those first. It also knows which ones are less likely to be used and offers to remove them. We're nowhere near that with services and packages. So as much as I want just the services that I actually use running on my system (and packages that I only intend to use installed) automatically done for me, I have to be satisfied with doing things manually. -- Richi Plana From mclasen at redhat.com Wed Sep 19 20:29:42 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 16:29:42 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> Message-ID: <1190233782.4236.45.camel@localhost.localdomain> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: > > Yeah, but then you don't walk away from your root session expecting the > > screensaver to kick in - which it doesn't for root. > > Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking > for root work just fine in KDE. And I assume that KDE users are just happy to run tons of unaudited toolkit code as root... Anyway, its a moot point, we'll re-enable root login for test3. From martin at bugs.unl.edu.ar Wed Sep 19 20:34:27 2007 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 19 Sep 2007 17:34:27 -0300 Subject: man page symlinks on symlinked binary In-Reply-To: <20070919133607.6ae819c5@reaver.lamontpeterson.net> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> Message-ID: <46F187D3.1000605@bugs.unl.edu.ar> Lamont Peterson escribi?: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 19 Sep 2007 21:44:16 +0300 > Ville Skytt? wrote: > >> On Wednesday 19 September 2007, Martin Marques wrote: >> >>> The thing is that the discussion started flipping towards why, if >>> there is a binary symlink, there isn't a man page symlink? This >>> could, in the case of cdrecord and wodim, or mkisofs and genisofs, >>> end in bugtrack tickets for those packages, but I am more >>> interested in a general solution, for all packages that have binary >>> symlinks. >>> >>> So, shouldn't there be something in respect of this issue in the >>> packaging policy? >> I support that (or the more or less AFAIK equivalent 'echo ".so >> man1/wodim.1" >>> cdrecord.1' approach as an alternative to symlinks). Could you >>> write a >> draft for that? I can take it onwards from there in the packaging >> committee. > > I would suggest creating a cdrecord(1) man page that says "This is no more. See wodim(1), which replaces it." Put that cdrecord(1) man page into the wodim package. This way, we teach people that there's been a change and we don't get "Um, when I type 'man cdrecord' I get a man page for something totally different; what gives?" kinds of questions/bug reports/requests. If they read the man they would note that: NOTE There may be similarities and differences between this program and other disk recording application(s). See the CREDITS and AUTHORS sec- tions below to learn about the origin of wodim. And later that: This application is a spinoff from the original program "cdrecord" delivered in the cdrtools package [1] created by Joerg Schilling, who deserves the most credits for its success. However, he is not involved into the development of this spinoff and therefore he shall not be made responsible for any problem caused by it. Do not refer to this applica- tion as "cdrecord", do not try to get support for wodim by contacting the original authors. So, better would be to teach users to read the manual. This is obviously IMHO. > - -- > Lamont Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > > NOTE: All messages from this email address should be digitally signed with my > 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as > well as other keyservers that sync with MIT's. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFG8Xon+YBsl9wN1AkRAhdtAJ43J8X8zY++WFz3J/yP2rp5zNhcUwCgpbtn > YHhhBo5yl29FWGpPCR8RDTc= > =KqqQ > -----END PGP SIGNATURE----- > From bloch at verdurin.com Wed Sep 19 20:46:23 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Wed, 19 Sep 2007 21:46:23 +0100 (BST) Subject: Wireless and D-Bus problems with latest rawhide? Message-ID: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> With the latest batch of rawhide updates (kernel-2.6.23-0.185.rc6.git7.fc8 etc.) there seems to be something wrong with D-Bus and/or HAL. The brightness applet reports that it can't connect to gnome-power-manager and the NetworkManager applet doesn't appear. I restarted HAL and D-Bus and eventually the NM applet appeared but it would not connect to my network: Sep 19 21:23:36 vaio NetworkManager: Activation (wlan0) failed. Upon rebooting to the 2.6.23-0.184.rc6.git4.fc8 kernel, I had the same symptoms and had to restart the same services, but I was able to connect to the network. The wireless hardware is ipw3945, though I'm not sure whether this is a kernel problem or a problem with other packages. From redhat at olen.net Wed Sep 19 20:46:54 2007 From: redhat at olen.net (Ola Thoresen) Date: Wed, 19 Sep 2007 22:46:54 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <64b14b300709191142q60688f4dv4d04ca9f352d899d@mail.gmail.com> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> <46DB0EFB.5080107@olen.net> <64b14b300709191142q60688f4dv4d04ca9f352d899d@mail.gmail.com> Message-ID: <46F18ABE.1050809@olen.net> Valent Turkovic wrote: > Ok, I fixed the issue but only with using Windows :( (...) > > it this helpful? > > Why can't I overrule software RF_KILL switch within linux? This sounds very much like my problem - except that I don't have any windows partition to test with. It is strange that it can't be controled from linux. Rgds. -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From opensource at till.name Wed Sep 19 20:24:24 2007 From: opensource at till.name (Till Maas) Date: Wed, 19 Sep 2007 22:24:24 +0200 Subject: bodhi interface changes In-Reply-To: <20070919201035.GB5524@crow.boston.redhat.com> References: <20070919172116.GC6429@crow.myhome.westell.com> <46F178CF.40308@fedoraunity.org> <20070919201035.GB5524@crow.boston.redhat.com> Message-ID: <200709192224.27283.opensource@till.name> On Wednesday 19 September 2007 22:10:35 Luke Macken wrote: > This mechanism is definitely subject to change over time, so feedback is > welcome :) It would be nice if one could easily change ones karma vote instead of adding another value, i.e. each user should only be able to give either +1,0 or -1 Karma Votes and the last given vote counts. Currently it seems that one can only change a -1 vote to +1 with to +1 votes. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dgboles at gmail.com Wed Sep 19 21:06:57 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 19 Sep 2007 17:06:57 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190233782.4236.45.camel@localhost.localdomain> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> Message-ID: <46F18F71.5070900@gmail.com> on 9/19/2007 4:29 PM, Matthias Clasen wrote: > On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: >> Matthias Clasen redhat.com> writes: >>> Yeah, but then you don't walk away from your root session expecting the >>> screensaver to kick in - which it doesn't for root. >> Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking >> for root work just fine in KDE. > > And I assume that KDE users are just happy to run tons of unaudited > toolkit code as root... > > Anyway, its a moot point, we'll re-enable root login for test3. I have watched this thread since the beginning and I can no longer keep my peace. A knowledgeable Linux user would know how to change this default. Or figure out how to change. I know how and I am certainly not on the level of many here. A 'not so knowledgeable Linux user' would use the 'enter Roots password' windows to preform these tasks. Any user that can not do either of these things *does not* have any business logging in as root in a GUI. Period. Or do you want Fedora 8 to be like Windows? Where 'run as root' is the default for the 'not so knowledgeable Windows user'? You want them to be able to shoot themselves in the foot? I hope not. Want to use Linux, be a Linux Geek, so to speak? Learn a little more about it first. More than downloading an ISO and burning it it Windows. I did that years ago. How about you? -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Wed Sep 19 21:08:52 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 17:08:52 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190211867.2949.13.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <20070919125258.GA7373@devserv.devel.redhat.com> <2183.63.85.68.164.1190205288.squirrel@mail.jcomserv.net> <1190211867.2949.13.camel@localhost6.localdomain6> Message-ID: <20070919210852.GA29241@jadzia.bu.edu> On Wed, Sep 19, 2007 at 08:24:27AM -0600, Richi Plana wrote: > As for the X environment, give them TWM, ;). There's no need to make things *painful*. How about metacity + lxpanel? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From walters at redhat.com Wed Sep 19 21:12:55 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Sep 2007 17:12:55 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F18F71.5070900@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> Message-ID: On 9/19/07, David Boles wrote: > > Or do you want Fedora 8 to be like Windows? Where 'run as root' is the > default for the 'not so knowledgeable Windows user'? It is not the default. You have to actively work to arrive at the situation, ignoring a warning dialog. It is not worth developer time at this stage to improve the warnings, create a special X session, etc. It will be fixed correctly for F9. From dwmw2 at infradead.org Wed Sep 19 21:15:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Sep 2007 22:15:49 +0100 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190233412.3418.11.camel@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> <1190226365.14091.5.camel@pmac.infradead.org> <1190233412.3418.11.camel@localhost.localdomain> Message-ID: <1190236549.4524.1.camel@shinybook.infradead.org> On Wed, 2007-09-19 at 16:23 -0400, Tom "spot" Callaway wrote: > This looks like a bug in -Wp,-D_FORTIFY_SOURCE=2 for C++ code. If I > remove that option, it gets past that point. Anyway, as with the majority of failures I encounter or investigate on PowerPC or even PPC64, it's not an arch-specific issue. /me paints it pink... -- dwmw2 From johannbg at hi.is Wed Sep 19 21:17:30 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Wed, 19 Sep 2007 21:17:30 -0000 (GMT) Subject: Root login in rawhide and display managers In-Reply-To: <1190233672.6854.42.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F12CE4.1050103@hi.is> <1190213528.2949.34.camel@localhost6.localdomain6> <46F15AB0.3010200@hi.is> <1190233672.6854.42.camel@localhost6.localdomain6> Message-ID: <27709.88.149.97.225.1190236650.squirrel@webmail.hi.is> > On Wed, 2007-09-19 at 17:21 +0000, "J??hann B. Gu??mundsson" wrote: >> Richi Plana wrote: >> > On Wed, 2007-09-19 at 14:06 +0000, "J??hann B. Gu??mundsson" wrote: >> > >> >> User should be able to turn on/off/enable/disable services ( the >> >> service's that aren't the mandatory one's ) in Anaconda >> >> >> > >> > Beg to disagree. Anaconda should just concentrate on getting the real >> > Fedora image installed so that it becomes the running system (its >> kernel >> > and filesystem is used). You can argue for it at firstboot, though. Or >> > just put it in kickstart (if possible). >> > >> > >> Then you must agree with me that Anaconda should enable just the >> service's that are the mandatory one's and no other.. > > How I wish! I want all my installations to be as lean and mean, as > possible. Unfortunately, you're relying on people to choose which > services should be enabled or not when it should be the user (via > his/her use of the computer) that should decide. I think you misunderstood me there, I am for all as much auto install/configure as possible for the novice user But.... I want an option to disable and choose to do those things manually before the system does those things for me, Instead of always have to back trace what was configured for me and revert it to my choosing. :) > Once the software is > installed on a person's machine, we won't be there to enable or disable > a service should it all of a sudden be needed. Ideally, the software > should be smart enough to enable what needs to be enabled when the user > says "I need to do this" (and one of it's requirements is an enabled > service), Agreed... > but we aren't there yet and there's no formal mention that > that's the direction we are actually going. How about getting some formal answers from the those who make that ruling Which by the way are ??? > > Really, the system should try to be smarter when it comes to guessing > what the user needs (as opposed to being static and set at spin-time). > Even Windows tries to be smart and keeps track of what apps have been > recently used and presents those first. It also knows which ones are > less likely to be used and offers to remove them. We're nowhere near > that with services and packages. Agreed.. > > So as much as I want just the services that I actually use running on > my system (and packages that I only intend to use installed) > automatically done for me, I have to be satisfied with doing things > manually. > -- As do we all... Best regards Johann B. From lmacken at redhat.com Wed Sep 19 21:11:10 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Sep 2007 17:11:10 -0400 Subject: bodhi interface changes In-Reply-To: <200709192224.27283.opensource@till.name> References: <20070919172116.GC6429@crow.myhome.westell.com> <46F178CF.40308@fedoraunity.org> <20070919201035.GB5524@crow.boston.redhat.com> <200709192224.27283.opensource@till.name> Message-ID: <20070919211110.GC3091@crow.boston.redhat.com> On Wed, Sep 19, 2007 at 10:24:24PM +0200, Till Maas wrote: > On Wednesday 19 September 2007 22:10:35 Luke Macken wrote: > > > This mechanism is definitely subject to change over time, so feedback is > > welcome :) > > It would be nice if one could easily change ones karma vote instead of adding > another value, i.e. each user should only be able to give either +1,0 or -1 > Karma Votes and the last given vote counts. Currently it seems that one can > only change a -1 vote to +1 with to +1 votes. Yeah, that definitely sounds reasonable... right now you can only adjust the karma once in each direction -- thus negating your vote. Feel free to open a ticket. luke From jon at fedoraunity.org Wed Sep 19 21:27:08 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Wed, 19 Sep 2007 15:27:08 -0600 Subject: bodhi interface changes In-Reply-To: <20070919201035.GB5524@crow.boston.redhat.com> References: <20070919172116.GC6429@crow.myhome.westell.com> <200709191941.18303.opensource@till.name> <46F164A0.4090409@leemhuis.info> <20070919183002.GB3091@crow.boston.redhat.com> <46F178CF.40308@fedoraunity.org> <20070919201035.GB5524@crow.boston.redhat.com> Message-ID: <46F1942C.2040907@fedoraunity.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luke Macken wrote: > On Wed, Sep 19, 2007 at 01:30:23PM -0600, Jonathan Steffan wrote: >> I might have missed this... What is karma, how do we use it? How do we >> increase our packages' karma? What is karma currently used for? > > It's a simple integer that is incremented/decremented based on if > the update works or not for the tester. Right now, when an update > reaches a karma of 3, it is automatically pushed to stable. > > This mechanism is definitely subject to change over time, so feedback is > welcome :) I think it is awesome. Good work. Jonathan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8ZQsrRJs5w2Gr1kRAglnAKCDjNEtNTbFxGEhLrqS6yQ+sDsgVgCfQc7W zuBGi85VeKKED+cnSWIGes0= =5Qb8 -----END PGP SIGNATURE----- From lamont at gurulabs.com Wed Sep 19 21:28:11 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 19 Sep 2007 15:28:11 -0600 Subject: man page symlinks on symlinked binary In-Reply-To: <46F187D3.1000605@bugs.unl.edu.ar> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> <46F187D3.1000605@bugs.unl.edu.ar> Message-ID: <20070919152811.69e08de8@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 19 Sep 2007 17:34:27 -0300 Martin Marques wrote: > Lamont Peterson escribi?: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wed, 19 Sep 2007 21:44:16 +0300 > > Ville Skytt? wrote: > > > >> On Wednesday 19 September 2007, Martin Marques wrote: > >> > >>> The thing is that the discussion started flipping towards why, if > >>> there is a binary symlink, there isn't a man page symlink? This > >>> could, in the case of cdrecord and wodim, or mkisofs and genisofs, > >>> end in bugtrack tickets for those packages, but I am more > >>> interested in a general solution, for all packages that have > >>> binary symlinks. > >>> > >>> So, shouldn't there be something in respect of this issue in the > >>> packaging policy? > >> I support that (or the more or less AFAIK equivalent 'echo ".so > >> man1/wodim.1" > >>> cdrecord.1' approach as an alternative to symlinks). Could you > >>> write a > >> draft for that? I can take it onwards from there in the packaging > >> committee. > > > > I would suggest creating a cdrecord(1) man page that says "This is > > no more. See wodim(1), which replaces it." Put that cdrecord(1) > > man page into the wodim package. This way, we teach people that > > there's been a change and we don't get "Um, when I type 'man > > cdrecord' I get a man page for something totally different; what > > gives?" kinds of questions/bug reports/requests. > > If they read the man they would note that: > > NOTE > There may be similarities and differences between this program > and other disk recording application(s). See the CREDITS and > AUTHORS sec- tions below to learn about the origin of wodim. > > > And later that: > > This application is a spinoff from the original program > "cdrecord" delivered in the cdrtools package [1] created by Joerg > Schilling, who deserves the most credits for its success. However, he > is not involved into the development of this spinoff and therefore > he shall not be made responsible for any problem caused by it. Do not > refer to this applica- tion as "cdrecord", do not try to get > support for wodim by contacting the original authors. > > So, better would be to teach users to read the manual. > > This is obviously IMHO. I honestly do not understand how what you are saying here helps in any way to answer the question being discussed in this thread. Of course it's best for the users to read the manual. That's not the point. We're talking about how to help people find the manual when the name has changed from something (like cdrecord, which prompted this thread in the first place) that has been around a long time. Of course I saw the item you quoted/mentioned in the wodim(1) man page. It doesn't help anyone who doesn't know that wodim is what they want because cdrecord no longer exists on their systems (in the distribution). If I've missed something here, help me understand it. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8ZRr+YBsl9wN1AkRAgW9AKCiyCfeATOFIyU+jEyihvo9p42JKQCfTxYU jLg7TrJjw1GkJiA83Fx4ZKs= =dbXo -----END PGP SIGNATURE----- From dgboles at gmail.com Wed Sep 19 21:33:13 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 19 Sep 2007 17:33:13 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> Message-ID: <46F19599.9030608@gmail.com> on 9/19/2007 5:12 PM, Colin Walters wrote: > On 9/19/07, David Boles wrote: >> Or do you want Fedora 8 to be like Windows? Where 'run as root' is the >> default for the 'not so knowledgeable Windows user'? > > It is not the default. You have to actively work to arrive at the > situation, ignoring a warning dialog. > > It is not worth developer time at this stage to improve the warnings, > create a special X session, etc. > > It will be fixed correctly for F9. I do not think that you understood me. I do *not* think that what many are arguing for here, GUI root logins as a default 'on' feature, is a good idea for the average new user. Those that have enough experience can change it, if they want to do that. You developers are much too busy to see what those of us that follow the fedora-user list see every day. Many are trying very hard to make a working system and to learn Linux but most are true Newbies that need to be somewhat protected from themselves until they learn a little about Linux. If not they will be as open to 'attack' as most Windows users. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From martin at bugs.unl.edu.ar Wed Sep 19 21:38:41 2007 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 19 Sep 2007 18:38:41 -0300 Subject: man page symlinks on symlinked binary In-Reply-To: <20070919152811.69e08de8@reaver.lamontpeterson.net> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> <46F187D3.1000605@bugs.unl.edu.ar> <20070919152811.69e08de8@reaver.lamontpeterson.net> Message-ID: <46F196E1.50304@bugs.unl.edu.ar> Lamont Peterson escribi?: > > I honestly do not understand how what you are saying here helps in any way to answer the question being discussed in this thread. Of course it's best for the users to read the manual. That's not the point. We're talking about how to help people find the manual when the name has changed from something (like cdrecord, which prompted this thread in the first place) that has been around a long time. > > Of course I saw the item you quoted/mentioned in the wodim(1) man page. It doesn't help anyone who doesn't know that wodim is what they want because cdrecord no longer exists on their systems (in the distribution). OK, better: add at the beginning of the wodim man page that "wodim is a fork of cdrecord". How about that? From myfedora at richip.dhs.org Wed Sep 19 21:54:08 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 15:54:08 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070919210852.GA29241@jadzia.bu.edu> References: <46F038AC.9010503@fedoraproject.org> <20070919120525.GA5410@devserv.devel.redhat.com> <20070919122553.GA4526@jadzia.bu.edu> <20070919125258.GA7373@devserv.devel.redhat.com> <2183.63.85.68.164.1190205288.squirrel@mail.jcomserv.net> <1190211867.2949.13.camel@localhost6.localdomain6> <20070919210852.GA29241@jadzia.bu.edu> Message-ID: <1190238848.12402.14.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 17:08 -0400, Matthew Miller wrote: > On Wed, Sep 19, 2007 at 08:24:27AM -0600, Richi Plana wrote: > > As for the X environment, give them TWM, ;). > > There's no need to make things *painful*. How about metacity + lxpanel? I was being facetious, :). Seriously, though, a window manager and an application launcher should be maximum. No gnome session managers, no nautilus, no dbus, no applets. Does lxpanel make use of the menu options inside /usr/share/applications/ or does it require it's own menu configuration? Even a stripped-down menu selection (no games, no office apps) might be a good idea. Wouldn't want a bug in gsudoku to bring the machine down, ;). -- Richi Plana From johannbg at hi.is Wed Sep 19 22:09:18 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Wed, 19 Sep 2007 22:09:18 -0000 (GMT) Subject: Root login in rawhide and display managers In-Reply-To: <46F18F71.5070900@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> Message-ID: <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> > on 9/19/2007 4:29 PM, Matthias Clasen wrote: >> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: >>> Matthias Clasen redhat.com> writes: >>>> Yeah, but then you don't walk away from your root session expecting >>>> the >>>> screensaver to kick in - which it doesn't for root. >>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop >>> locking >>> for root work just fine in KDE. >> >> And I assume that KDE users are just happy to run tons of unaudited >> toolkit code as root... >> >> Anyway, its a moot point, we'll re-enable root login for test3. > > > I have watched this thread since the beginning and I can no longer keep my > peace. > > A knowledgeable Linux user would know how to change this default. Or > figure out how to change. I know how and I am certainly not on the level > of many here. > True so he know he can simply F1 and take it from there... > A 'not so knowledgeable Linux user' would use the 'enter Roots password' > windows to preform these tasks. > And if the user manage to shoot himself in the foot so he cant login using his username and password how is he gonna manage to get to his "enter the root password dialog".... > Any user that can not do either of these things *does not* have any > business logging in as root in a GUI. Period. Wrong he has a fighting chance to save himself log into familiar surroundings fix the situation with S-C-* tools, learn from his mistake instead of have to do clean install or bother advanced users given that they are some where around him. The alternitive "dropping him to terminal window" were he would be dead in the water... > > Or do you want Fedora 8 to be like Windows? No... > Where 'run as root' is the > default for the 'not so knowledgeable Windows user'? Last time I used M$ windows it made dam sure that the user could harm the system ( windows it self ) and question every other move he did.. Maybe Windows is actually trusting user today but I doubt it... > You want them to be > able to shoot themselves in the foot? Yes. the users will learn from there mistakes, adopt,evolve and move on.. Let's place the trust on the user always. > I hope not. > > Want to use Linux, be a Linux Geek, so to speak? Learn a little more about > it first. More than downloading an ISO and burning it it Windows. Nope get the user first into linux as hazle free and comfortable as possible... >From there he will start using, playing, fiddle around *expanding his knowledge about linux. etc.. Best regards Johann B. From tcallawa at redhat.com Wed Sep 19 22:14:13 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 19 Sep 2007 18:14:13 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190236549.4524.1.camel@shinybook.infradead.org> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> <1190226365.14091.5.camel@pmac.infradead.org> <1190233412.3418.11.camel@localhost.localdomain> <1190236549.4524.1.camel@shinybook.infradead.org> Message-ID: <1190240053.3418.21.camel@localhost.localdomain> On Wed, 2007-09-19 at 22:15 +0100, David Woodhouse wrote: > On Wed, 2007-09-19 at 16:23 -0400, Tom "spot" Callaway wrote: > > This looks like a bug in -Wp,-D_FORTIFY_SOURCE=2 for C++ code. If I > > remove that option, it gets past that point. > > Anyway, as with the majority of failures I encounter or investigate on > PowerPC or even PPC64, it's not an arch-specific issue. It also is triggered on x86_64, and would have been caught there first. *cough*. ~spot From lamont at gurulabs.com Wed Sep 19 22:16:58 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 19 Sep 2007 16:16:58 -0600 Subject: man page symlinks on symlinked binary In-Reply-To: <46F196E1.50304@bugs.unl.edu.ar> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> <46F187D3.1000605@bugs.unl.edu.ar> <20070919152811.69e08de8@reaver.lamontpeterson.net> <46F196E1.50304@bugs.unl.edu.ar> Message-ID: <20070919161658.0c09d67e@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 19 Sep 2007 18:38:41 -0300 Martin Marques wrote: > Lamont Peterson escribi?: > > > > I honestly do not understand how what you are saying here helps in > > any way to answer the question being discussed in this thread. Of > > course it's best for the users to read the manual. That's not the > > point. We're talking about how to help people find the manual when > > the name has changed from something (like cdrecord, which prompted > > this thread in the first place) that has been around a long time. > > > > Of course I saw the item you quoted/mentioned in the wodim(1) man > > page. It doesn't help anyone who doesn't know that wodim is what > > they want because cdrecord no longer exists on their systems (in > > the distribution). > > OK, better: add at the beginning of the wodim man page that "wodim is > a fork of cdrecord". How about that? I think the wodim(1) man page already does an adequate job of explaining this, though I do like your idea of a very concise piece of text at the beginning of the man page, just to make things more clear. Still, the issue we're discussing in this thread isn't about problems with the wodim(1) man page. It's about the problem that there is no cdrecord(1) man page anymore. Since there is no cdrecord(1) man page, running "man cdrecord" just like users may have been doing for 5-10 years now, will not work. However, they still have a "cdrecord" command (as a symlink to "wodim"), so they would now be frustrated and not know where to look for the "missing man page to cdrecord". So, what this thread was trying to discuss was the idea that we need to do something for commands that still exist as symlinks as a convenience for users who are used to those commands and for scripts that might be using them, too. My suggestion was to not create a symlink to, or a copy of, the wodim(1) man page in order to make "man cdrecord" work again, but to instead create a bona-fide cdrecord(1) man page with content such as "This isn't the command you want, anymore. You now want wodim(1)". - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8Z/a+YBsl9wN1AkRAjn5AJ9Ap3i13L6sz8I2fB9KoCKNnlyYSACgs0Li fVDb+ytDqdG9yR89MbMKulw= =p+GZ -----END PGP SIGNATURE----- From jakub at redhat.com Wed Sep 19 22:27:37 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 19 Sep 2007 18:27:37 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190240053.3418.21.camel@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> <1190226365.14091.5.camel@pmac.infradead.org> <1190233412.3418.11.camel@localhost.localdomain> <1190236549.4524.1.camel@shinybook.infradead.org> <1190240053.3418.21.camel@localhost.localdomain> Message-ID: <20070919222736.GA2625@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 06:14:13PM -0400, Tom spot Callaway wrote: > > On Wed, 2007-09-19 at 22:15 +0100, David Woodhouse wrote: > > On Wed, 2007-09-19 at 16:23 -0400, Tom "spot" Callaway wrote: > > > This looks like a bug in -Wp,-D_FORTIFY_SOURCE=2 for C++ code. If I > > > remove that option, it gets past that point. > > > > Anyway, as with the majority of failures I encounter or investigate on > > PowerPC or even PPC64, it's not an arch-specific issue. > > It also is triggered on x86_64, and would have been caught there first. It seems to be some function type sharing bug, minimal testcase: extern int foo (char *) __attribute__ ((warn_unused_result)); extern int bar (char *) throw () __attribute__ ((warn_unused_result)); extern int bar (char *) throw (); (or nonnull attribute, regparm attr or some other that affects the type rather than the decl). I have reproduced this bug with GCC 4.1.x-RH, 4.2.2 and GCC trunk. Debugging... Jakub From florin at andrei.myip.org Wed Sep 19 22:44:31 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 19 Sep 2007 15:44:31 -0700 Subject: screen blanking considered useless Message-ID: <46F1A64F.8030604@andrei.myip.org> In text mode, the console goes blank after a predetermined time - I think it's 15 minutes or something like that. I would argue that this is unnecessary nowadays. Machines in text mode these days are typically servers, and those run headless in the vast majority of cases (or with the monitor turned off to save power). Screen blanking does nothing in that case, and it's actually confusing when you switch inputs in the console multiplexer - is this input actually connected, or is the machine powered off, or is just the screen blank? It seems like screen blanking is a remnant from the days when systems running in text mode with a monitor attached and powered on were a lot more likely. Nowadays, this is probably very rare. What I usually do on servers is run "setterm -blank 0" on each server, then add the same command to rc.local so it's persistent. But this is unnecessary work for the sysadmin. It would be nice to have an option somewhere in the installer allowing the sysadmin to set the blanking time, or disable it altogether. My preference would be to disable it by default and let the sysadmin override that in the installer, but I think it's fine if it's enabled by default as long as it can be changed in the installer (and it becomes a kickstart parameter too). -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Wed Sep 19 22:52:48 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 19 Sep 2007 15:52:48 -0700 Subject: is Miro (aka Democracy player) supported in Fedora ? In-Reply-To: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> References: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> Message-ID: <46F1A840.3090207@andrei.myip.org> Valent Turkovic wrote: > Is Miro (aka Democracy player) supported under Fedora? > I tried to install it but for weeks now it is not possible to install > it under Rawhide. For a long time it didn't work on F7, but then after an update was released it magically worked somehow. Rebuilding the "official" src.rpm on Fedora fails for what looks like too narrow dependencies. > So I'm asking will Miro be supported in Fedora 8 - or if my question > it not precise enough - will I be able to 'yum install Miro' and > expect it to install and work? That would be very nice. -- Florin Andrei http://florin.myip.org/ From d.jacobfeuerborn at conversis.de Wed Sep 19 22:04:58 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Thu, 20 Sep 2007 00:04:58 +0200 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <46F132D0.4010304@fedoraproject.org> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190185383.6908.34.camel@pc-notebook> <1190212198.2949.16.camel@localhost6.localdomain6> <46F132D0.4010304@fedoraproject.org> Message-ID: <46F19D0A.5030003@conversis.de> Rahul Sundaram wrote: > Richi Plana wrote: >> On Wed, 2007-09-19 at 09:03 +0200, Martin Sourada wrote: >>> On Wed, 2007-09-19 at 07:33 +0200, Martin Stransky wrote: >>>> Both packages (firefox and xulrunner) provides gecko-libs and >>>> currently can't be installed together. >>>> >>> AFAIK, the gecko-lib provides should not be a problem. The only problem >>> I am aware of is that both firefox and xulrunner packages >>> have /etc/gre.d/gre(64).conf files. >> >> Can't firefox be cut down so that it doesn't include it's own gecko-libs >> but instead uses xulrunner so that it's just like any other gecko app >> (Disclaimer: I'm not really familiar with xulrunner so don't shoot me)? > > That's the plan. If I understood the discussion regarding xulrunner correctly the whole reason the Mozilla people aren't shipping a xulrunner based version of Firefox is because they don't want to be limited by a runtime that needs to be stable rather than cutting edge. If Fedora plans to ship a xulrunner based Firefox anyway wouldn't that basically require a fork of the code? Regards, Dennis From wtogami at redhat.com Wed Sep 19 23:22:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 19 Sep 2007 19:22:24 -0400 Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> Message-ID: <46F1AF30.8090308@redhat.com> bloch at verdurin.com wrote: > With the latest batch of rawhide updates (kernel-2.6.23-0.185.rc6.git7.fc8 > etc.) there seems to be something wrong with D-Bus and/or HAL. The > brightness applet reports that it can't connect to gnome-power-manager and > the NetworkManager applet doesn't appear. > > I restarted HAL and D-Bus and eventually the NM applet appeared but it > would not connect to my network: > > Sep 19 21:23:36 vaio NetworkManager: Activation (wlan0) failed. > > Upon rebooting to the 2.6.23-0.184.rc6.git4.fc8 kernel, I had the same > symptoms and had to restart the same services, but I was able to connect > to the network. > > The wireless hardware is ipw3945, though I'm not sure whether this is a > kernel problem or a problem with other packages. > I am experiencing the same problem. Uncertain what component exactly is broken. Makes it difficult to file a bug or query for it. Warren Togami wtogami at redhat.com From mschwendt.tmp0701.nospam at arcor.de Wed Sep 19 23:29:29 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Sep 2007 01:29:29 +0200 Subject: mono Provides Message-ID: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name... banshee provides mono(Boo.Lang) = 0:1.0.0.0 boo provides mono(Boo.Lang) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386 banshee provides mono(Boo.Lang.Compiler) = 0:1.0.0.0 boo provides mono(Boo.Lang.Compiler) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386 banshee provides mono(Boo.Lang.Parser) = 0:1.0.0.0 boo provides mono(Boo.Lang.Parser) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 banshee provides mono(ipod-sharp) = 0:0.0.1.0 ipod-sharp provides mono(ipod-sharp) = 0:0.0.1.0 required by: banshee - 0.13.1-1.fc8.i386 banshee provides mono(ipod-sharp-ui) = 0:0.0.1.0 ipod-sharp provides mono(ipod-sharp-ui) = 0:0.0.1.0 required by: banshee - 0.13.1-1.fc8.i386 banshee provides mono(NDesk.DBus) = 0:1.0.0.0 f-spot provides mono(NDesk.DBus) = 0:1.0.0.0 required by: f-spot - 0.4.0-2.fc8.i386 required by: banshee - 0.13.1-1.fc8.i386 banshee provides mono(Boo.Lang.Interpreter) = 0:1.0.0.0 boo provides mono(Boo.Lang.Interpreter) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386 db4o provides mono(Mono.Cecil) = 0:0.4.3.1 monodevelop provides mono(Mono.Cecil) = 0:0.4.3.1 required by: db4o - 6.1-2.fc7.i386 db4o provides mono(Mono.GetOptions) = 0:2.0.0.0 mono-core provides mono(Mono.GetOptions) = 0:2.0.0.0 mono-core provides mono(Mono.GetOptions) = 0:1.0.5000.0 required by: f-spot - 0.4.0-2.fc8.i386 required by: mono-debugger - 0.31-2.fc7.i386 required by: mono-devel - 1.2.4-2.fc8.i386 required by: db4o - 6.1-2.fc7.i386 f-spot provides mono(Mono.Addins.Gui) = 0:0.2.0.0 tomboy provides mono(Mono.Addins.Gui) = 0:0.2.0.0 required by: tomboy - 0.8.0-1.fc8.i386 required by: f-spot - 0.4.0-2.fc8.i386 f-spot provides mono(Mono.Addins) = 0:0.2.0.0 tomboy provides mono(Mono.Addins) = 0:0.2.0.0 required by: tomboy - 0.8.0-1.fc8.i386 required by: f-spot - 0.4.0-2.fc8.i386 mono-core provides mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 nant provides mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 From packages at amiga-hardware.com Wed Sep 19 23:31:48 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 20 Sep 2007 00:31:48 +0100 Subject: screen blanking considered useless In-Reply-To: <46F1A64F.8030604@andrei.myip.org> References: <46F1A64F.8030604@andrei.myip.org> Message-ID: <46F1B164.5030609@amiga-hardware.com> Florin Andrei wrote: > In text mode, the console goes blank after a predetermined time - I > think it's 15 minutes or something like that. > > I would argue that this is unnecessary nowadays. Less necessary, probably true. However I have an iMac that now has a nice "burn-in" on it's flat panel of a text mode dialogue box telling me X has restarted too many times. I didn't think it could happen on modern monitors, in paritcularly I thought it was only really applicable to CRTs but it appears in at least some circumstances it still can. -- Ian Chapman. From martin at bugs.unl.edu.ar Wed Sep 19 23:39:59 2007 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Wed, 19 Sep 2007 20:39:59 -0300 Subject: man page symlinks on symlinked binary In-Reply-To: <20070919161658.0c09d67e@reaver.lamontpeterson.net> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> <46F187D3.1000605@bugs.unl.edu.ar> <20070919152811.69e08de8@reaver.lamontpeterson.net> <46F196E1.50304@bugs.unl.edu.ar> <20070919161658.0c09d67e@reaver.lamontpeterson.net> Message-ID: <46F1B34F.7050201@bugs.unl.edu.ar> Lamont Peterson escribi?: > > My suggestion was to not create a symlink to, or a copy of, the wodim(1) man page in order to make "man cdrecord" work again, but to instead create a bona-fide cdrecord(1) man page with content such as "This isn't the command you want, anymore. You now want wodim(1)". Let's see if I can get my ideas out. :-) There is no cdrecord, and won't be any in future versions of Fedora. What there is is a symlink to wodim, just because wodim is a fork of cdrecord. If I do man cdrecord and end up seeing the wodim man page, I would first nod my head, and then say "what's this wodim?" (maybe even ask a fellow linux friend) and then read the man. To end this: why create a man page for something that doesn't exist, and maybe in a future version of fedora not even the symlink will be left (maybe yes, maybe not). My opinion, link the manuals, and the info pages if they exist. From jakub at redhat.com Thu Sep 20 00:09:28 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 19 Sep 2007 20:09:28 -0400 Subject: Xulrunner in Fedora 8 In-Reply-To: <1190240053.3418.21.camel@localhost.localdomain> References: <20070918105137.1da06ba6@localhost.localdomain> <1190214457.2926.88.camel@pmac.infradead.org> <1190214588.10222.0.camel@localhost.localdomain> <1190214858.2926.92.camel@pmac.infradead.org> <20070918112136.6bcd2167@localhost.localdomain> <1190216479.2926.106.camel@pmac.infradead.org> <1190226365.14091.5.camel@pmac.infradead.org> <1190233412.3418.11.camel@localhost.localdomain> <1190236549.4524.1.camel@shinybook.infradead.org> <1190240053.3418.21.camel@localhost.localdomain> Message-ID: <20070920000928.GC2625@devserv.devel.redhat.com> On Wed, Sep 19, 2007 at 06:14:13PM -0400, Tom spot Callaway wrote: > > On Wed, 2007-09-19 at 22:15 +0100, David Woodhouse wrote: > > On Wed, 2007-09-19 at 16:23 -0400, Tom "spot" Callaway wrote: > > > This looks like a bug in -Wp,-D_FORTIFY_SOURCE=2 for C++ code. If I > > > remove that option, it gets past that point. > > > > Anyway, as with the majority of failures I encounter or investigate on > > PowerPC or even PPC64, it's not an arch-specific issue. > > It also is triggered on x86_64, and would have been caught there first. http://gcc.gnu.org/PR33506 Jakub From tmz at pobox.com Thu Sep 20 01:17:12 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 19 Sep 2007 21:17:12 -0400 Subject: man page symlinks on symlinked binary In-Reply-To: <20070919161658.0c09d67e@reaver.lamontpeterson.net> References: <46F15ABF.10308@bugs.unl.edu.ar> <200709192144.16934.ville.skytta@iki.fi> <20070919133607.6ae819c5@reaver.lamontpeterson.net> <46F187D3.1000605@bugs.unl.edu.ar> <20070919152811.69e08de8@reaver.lamontpeterson.net> <46F196E1.50304@bugs.unl.edu.ar> <20070919161658.0c09d67e@reaver.lamontpeterson.net> Message-ID: <20070920011712.GB25106@psilocybe.teonanacatl.org> Lamont Peterson wrote: > My suggestion was to not create a symlink to, or a copy of, the > wodim(1) man page in order to make "man cdrecord" work again, but to > instead create a bona-fide cdrecord(1) man page with content such as > "This isn't the command you want, anymore. You now want wodim(1)". Unless there is a good reason to remove the cdrecord (and other old command name) symlinks, I would hope that they stick around. The name wodim (and the other new command names) is not nearly as useful as the more generic cdrecord is. It's also my opinion that the man pages should remain available under the old (sane) names as well. Whether that's via a symlink or ".so man1/wodim.1" isn't terribly important to me. If there's a compelling reason to prefer one over the other, then let that be suggested in whatever packaging guidelines may arise from this discussion. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (When asked whether he liked children) "Ah yes...boiled or fried." -- W.C. Fields -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rc040203 at freenet.de Thu Sep 20 01:22:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Sep 2007 03:22:49 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F15171.8070606@fedoraproject.org> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> Message-ID: <1190251369.11618.160.camel@mccallum.corsepiu.local> On Wed, 2007-09-19 at 22:12 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > > I am pretty certain many Fedora users use Fedora for both situations and > > consider a "mere desktop spin" a waste of time. > > That's ok. We will know soon enough how much interest there is when > there is a general release of Fedora 8 and we get downloads and feedback. > > >> That's more useful than talking about RHEL. We > >> all know the audience is different between these distributions. > > It is not. > > - Otherwise EPEL would not exist. > > - Those using RHEL @situation X (eg. @work) not unlikely are the same > > people running Fedora @situation Y (eg. @home) > > Your own example of running Fedora at home and RHEL at work is exactly > the different kind of roles and expectations that I was talking about. You violently don't want to understand, don't you? The main reason why you probably won't find many RHEL installations @home is it's price and this product's characteristics (bundled with service, promise of long term support, lack of suitable applications for use @home, ...). "desktop-use vs. server-use" isn't the real difference between RHEL and Fedora - Of cause, you'll find more "desktop use-cases" for Fedora, but this is just because you'll find more desktop-installation than server-installations in general. Ralf From nando at ccrma.Stanford.EDU Thu Sep 20 01:26:51 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 19 Sep 2007 18:26:51 -0700 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190232247.6854.22.camel@localhost6.localdomain6> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> <1190073567.16960.90.camel@localhost6.localdomain6> <1190229615.29210.28.camel@cmn3.stanford.edu> <1190232247.6854.22.camel@localhost6.localdomain6> Message-ID: <1190251611.29210.54.camel@cmn3.stanford.edu> On Wed, 2007-09-19 at 14:04 -0600, Richi Plana wrote: > Hi, Fernando. > > First of all, thanks for the comprehensive introduction. > > On Wed, 2007-09-19 at 12:20 -0700, Fernando Lopez-Lezcano wrote: > > Sorry, the source packages are common to all versions and architectures > > currently supported. They all can be found here in the link posted by > > Hans. Maybe I should write a script to cross link them but I'd rather be > > doing other things.... > > Hopefully if things get transitioned to Fedora or one of the other > third-party repos, it won't be necessary. There WILL be a discrepancy > between your packages and the ones on Fedora as time goes by, though. Hopefully not. As packages transition to Fedora I will drop them from Planet CCRMA (that has already happened with some packages I originally had in Planet CCRMA like, for example, rosegarden4 or lilypond). Not immediately maybe, but surely when they are evr greater in Fedora or when transitioning Planet CCRMA to a n+1 version of Fedora. [MUNCH] > > Hope this all makes sense and answers your question... > > It does answer things I've been wondering about, but I also wanted to > know how many of the packages in PlanetCCRMA are still actively being > developed or maintained. Most of them, I think. I don't keep a count. Some older stuff got dropped but most is still around. Some packages don't see a big rate of change but that does not mean they are not useful (they are actually "stable" :-). > As well, are there any software packages in > CCRMA that aren't packaged yet for PlanetCCRMA? Pretty much everything we use is packaged. That's the point :-) Remember, Planet CCRMA is a side effect of me trying to maintain a usable sound environment at CCRMA. There are some exceptions, things like matlab, but there are not many. > Also, some software might rely on a specific kernel (low-latency > patches, etc.) Those packages which rely on that kernel might have to be > tagged as requiring a low-latency kernel. No package _requires_ a low latency kernel. You can run everything on top of the stock Fedora kernel if you want. The difference is that you will not be able to reliably run Jack (the audio server most apps use) at a low latency - by low I mean 5 or less milliseconds. That is needed when you are using the computer as a performance instrument. And the likelihood of an xrun happening (when the kernel takes too long in doing something and the soundcard is starved of samples - and you get an audible dropout) even at higher latencies goes up. And it all depends also on what hardware you use and how you set it up. > Personally, I'd like to look > into the package meta-info for this, but most likely it will mean having > a package called kernel-ccrma (or -lowlatency or -rt or whatever). It > will now be a part of the Fedora package namespace. To work with the > rest of Fedora, we might need to transition those patches to the > official Fedora kernel. That is happening but very slowly, Ingo has been slowly moving basic infrastructure to the mainline kernel with the result that the realtime preemption patch is smaller now (I think). But there is a LOT to be done before the patch goes into the mainline kernel. And a LOT more before the more aggresive (and useful) preemption options are enabled in a stock Fedora build. I can hope....... For now I don't see a low latency kernel happening in Fedora. Apps first... > This is specially important when the kmods get > sucked into the kernel SRPM. I don't quite follow you... > Is there a way to tell which app packages need the -rt kernel? > > Since you (Fernando) know the packages better than most, could you list > the apps you think should be given higher priority for transitioning? I can make a list, of course. I suggested already all the ladspa plugin collections I host and that's what Hans already submitted, those have immediate impact in all apps that use ladpsa plugins. I'll post more suggestions tomorrow (time to go home)... -- Fernando From mattdm at mattdm.org Thu Sep 20 01:47:31 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Sep 2007 21:47:31 -0400 Subject: screen blanking considered useless In-Reply-To: <46F1A64F.8030604@andrei.myip.org> References: <46F1A64F.8030604@andrei.myip.org> Message-ID: <20070920014731.GA16760@jadzia.bu.edu> On Wed, Sep 19, 2007 at 03:44:31PM -0700, Florin Andrei wrote: > It would be nice to have an option somewhere in the installer allowing > the sysadmin to set the blanking time, or disable it altogether. My > preference would be to disable it by default and let the sysadmin > override that in the installer, but I think it's fine if it's enabled by > default as long as it can be changed in the installer (and it becomes a > kickstart parameter too). Nah -- monitor burn-in is still a potential problem. It *can* be changed (man setterm, man console_codes), but I believe the upper limit is one hour, which is probably too short for what you want. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dgboles at gmail.com Thu Sep 20 01:36:22 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 19 Sep 2007 21:36:22 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> Message-ID: <46F1CE96.7070308@gmail.com> on 9/19/2007 6:09 PM, ? wrote: >> on 9/19/2007 4:29 PM, Matthias Clasen wrote: >>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: >>>> Matthias Clasen redhat.com> writes: >>>>> Yeah, but then you don't walk away from your root session expecting >>>>> the >>>>> screensaver to kick in - which it doesn't for root. >>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop >>>> locking >>>> for root work just fine in KDE. >>> And I assume that KDE users are just happy to run tons of unaudited >>> toolkit code as root... >>> >>> Anyway, its a moot point, we'll re-enable root login for test3. >> >> I have watched this thread since the beginning and I can no longer keep my >> peace. >> >> A knowledgeable Linux user would know how to change this default. Or >> figure out how to change. I know how and I am certainly not on the level >> of many here. >> > > True so he know he can simply F1 and take it from there... > >> A 'not so knowledgeable Linux user' would use the 'enter Roots password' >> windows to preform these tasks. >> > > And if the user manage to shoot himself in the foot so he cant login > using his username and password how is he gonna manage to get to his > "enter the root password dialog".... > >> Any user that can not do either of these things *does not* have any >> business logging in as root in a GUI. Period. > > Wrong he has a fighting chance to save himself log into familiar > surroundings fix the situation with S-C-* tools, learn from his mistake > instead of have to do clean install or bother advanced users given that they > are some where around him. > > The alternitive "dropping him to terminal window" were he would be dead in > the water... > >> Or do you want Fedora 8 to be like Windows? > > No... > >> Where 'run as root' is the >> default for the 'not so knowledgeable Windows user'? > > Last time I used M$ windows it made dam sure that the user could harm > the system ( windows it self ) and question every other move he did.. > > Maybe Windows is actually trusting user today but I doubt it... > >> You want them to be >> able to shoot themselves in the foot? > > Yes. the users will learn from there mistakes, adopt,evolve and move on.. > > Let's place the trust on the user always. > >> I hope not. >> >> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about >> it first. More than downloading an ISO and burning it it Windows. > > Nope get the user first into linux as hazle free and comfortable as > possible... > >>From there he will start using, playing, fiddle around *expanding his > knowledge about linux. etc.. Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and the so many other Windows games you will get a *lot* of 'new Linux users' from Windows. Just as ignorant as you are looking for here. I give up. Logical thinking does not work when dealing with zealots. But I still think that you are wrong. No default GUI root logins. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From cmadams at hiwaay.net Thu Sep 20 02:13:10 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 19 Sep 2007 21:13:10 -0500 Subject: screen blanking considered useless In-Reply-To: <20070920014731.GA16760@jadzia.bu.edu> References: <46F1A64F.8030604@andrei.myip.org> <20070920014731.GA16760@jadzia.bu.edu> Message-ID: <20070920021309.GA1145100@hiwaay.net> Once upon a time, Matthew Miller said: > It *can* be changed (man setterm, man console_codes), but I believe the > upper limit is one hour, which is probably too short for what you want. No, you can disable it. I've been putting: /usr/bin/setterm -blank 0 -store < /dev/tty1 > /dev/tty1 in /etc/rc.d/rc.local on my servers for years (probably close to 10 years or so now). Of course, most of my servers now just have serial console, so it doesn't do much of anything anymore. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin at scrye.com Thu Sep 20 02:42:36 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 19 Sep 2007 20:42:36 -0600 Subject: diff missing in plague buildroot In-Reply-To: <20070919140103.bed29d24.mschwendt.tmp0701.nospam@arcor.de> References: <20070919140103.bed29d24.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070919204236.7448e51a@ghistelwchlohm.scrye.com> On Wed, 19 Sep 2007 14:01:03 +0200 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36389-fslint-2.24-1.fc6/noarch/build.log > > Checking for unpackaged > file(s): /usr/lib/rpm/check-files /var/tmp/fslint-2.24-1-root-mockbuild /usr/lib/rpm/check-files: > line 25: diff: command not found > > > Strange. Has anybody changed the FE6 buildroot defs? > Doesn't rpm-build require diffutils anymore? Yeah, it looks like the buildsys-build package was updated recently to match the new min buildroot requirements. ;( diffutils is no longer required by buildsys-build. I personally would say we should just revert back to the previous one, especially since fc6 isn't going to be around too much longer anyhow. I don't think it gains us much to change it at this point... > EPEL5+4 don't seem to be affected. Yeah, they were updated I think, then reverted due to a bug... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Wed Sep 19 21:43:12 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 19 Sep 2007 15:43:12 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <46F18F71.5070900@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> Message-ID: <1190238192.12402.9.camel@localhost6.localdomain6> On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote: > Want to use Linux, be a Linux Geek, so to speak? Learn a little more about > it first. More than downloading an ISO and burning it it Windows. I did > that years ago. How about you? Now that's not a nice mentality. I'm a self-professed computer geek, but it's my opinion that a person should be good at what they aim to accomplish. If they mean to write a great essay on a wordprocessor on Linux, then they don't need to be proficient with Linux. Just writing. OTOH, if you want to be a Linux machines system administrator, then that person should damn well know what the heck is going on under the hood of their machine (as opposed to just button-clicking). Even with grammar-correction, writers should know well the rules of grammar. The beauty in Linux is that as the software matures, people find themselves being more productive in whatever goal they set themselves out to use a computer for. Hopefully, it might even allow them to be creative about it in ways that weren't open to them before using Linux. (That's how I got hooked on code reusability and the Unix philosophy.) -- Richi Plana From dennis at ausil.us Thu Sep 20 03:52:57 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 19 Sep 2007 22:52:57 -0500 Subject: diff missing in plague buildroot In-Reply-To: <20070919204236.7448e51a@ghistelwchlohm.scrye.com> References: <20070919140103.bed29d24.mschwendt.tmp0701.nospam@arcor.de> <20070919204236.7448e51a@ghistelwchlohm.scrye.com> Message-ID: <200709192253.05944.dennis@ausil.us> Once upon a time Wednesday 19 September 2007, Kevin Fenzi wrote: > On Wed, 19 Sep 2007 14:01:03 +0200 > > mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36389-fslint-2.24- > >1.fc6/noarch/build.log > > > > Checking for unpackaged > > file(s): /usr/lib/rpm/check-files /var/tmp/fslint-2.24-1-root-mockbuild > > /usr/lib/rpm/check-files: line 25: diff: command not found > > > > > > Strange. Has anybody changed the FE6 buildroot defs? > > Doesn't rpm-build require diffutils anymore? > > Yeah, it looks like the buildsys-build package was updated recently to > match the new min buildroot requirements. ;( > > diffutils is no longer required by buildsys-build. > > I personally would say we should just revert back to the previous one, > especially since fc6 isn't going to be around too much longer anyhow. > I don't think it gains us much to change it at this point... > > > EPEL5+4 don't seem to be affected. > > Yeah, they were updated I think, then reverted due to a bug... they had a different bug. i have reverted the fc6 version. i will make sure diff is in the fc-6 buildroot. Dennis -------------- 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 dgboles at gmail.com Thu Sep 20 03:42:06 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 19 Sep 2007 23:42:06 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190238192.12402.9.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <1190238192.12402.9.camel@localhost6.localdomain6> Message-ID: <46F1EC0E.6020307@gmail.com> on 9/19/2007 5:43 PM, Richi Plana wrote: > On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote: >> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about >> it first. More than downloading an ISO and burning it it Windows. I did >> that years ago. How about you? > > Now that's not a nice mentality. > > I'm a self-professed computer geek, but it's my opinion that a person > should be good at what they aim to accomplish. If they mean to write a > great essay on a wordprocessor on Linux, then they don't need to be > proficient with Linux. Just writing. OTOH, if you want to be a Linux > machines system administrator, then that person should damn well know > what the heck is going on under the hood of their machine (as opposed to > just button-clicking). Even with grammar-correction, writers should know > well the rules of grammar. > > The beauty in Linux is that as the software matures, people find > themselves being more productive in whatever goal they set themselves > out to use a computer for. Hopefully, it might even allow them to be > creative about it in ways that weren't open to them before using Linux. > (That's how I got hooked on code reusability and the Unix philosophy.) I did *not* say that you needed to be a 'geek' to use Linux for common everyday tasks. What I said was that if you, the (any)user, wants to do really, really strange things that the user should know more about Linux than how to tie his shoes strings. When I started with Linux 'docs' was a joke. Man pages was just about the same. GUI configuration applications? What are those? Files, most of which, are done 'for you' now had to be done by hand during the installation or in text editors later. Firewalls. Port sentries. Lan connections. Almost everything had to be done by hand. Which took - OH MY $deity - reading and more than 'click here dummy or accept the default'. The *MAIN* fault with Windows is the 'user is root' situation. You want that for Linux? Do you really want someone who thinks that a harddrive is that 'big box on my desk that all of this stuff is connected to' to have kill it in one shot abilities? Really? Then Linux is doomed to follow the same path. When 'you' make Linux just like that - that is when the masses will/might convert to Linux. That will be when the guy in Russia starts writing the really kool screen saver that the dummy you enticed to try Linux downloads. The on that contacts the first major Linux Trojan/virus/ crap. I hope not. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From lucas at lucas-nussbaum.net Thu Sep 20 07:11:08 2007 From: lucas at lucas-nussbaum.net (Lucas Nussbaum) Date: Thu, 20 Sep 2007 09:11:08 +0200 Subject: Some questions about Fedora Message-ID: <20070920071108.GA2035@xanadu.blop.info> Hi, I'm involved both in Debian and Ubuntu development, and I'm often frustrated by how little I know about the other distributions. After discussing this in a blog post[1], I got the impression that I wasn't alone in that case. So I decided to do something about that, and to go ask the other distributions' developers a few questions. If this works well (answers and interest from other distros), I might do that again, or turn this into something more formal (for example, a mailing list and/or a wiki would seem well suited for that). I'll publish the answers on my blog[2], and, if this proves to raise interest, move them to a wiki. [1] http://www.lucas-nussbaum.net/blog/?p=250 [2] http://www.lucas-nussbaum.net/blog/ Here is a first set of questions. In your answers, please avoid codenames (act as if the reader didn't know anything about your distribution). Please try to write your answer as a short paragraph, answering all the sub-questions from the questions at once. Q1. Packages How many "pieces of software" do you have in your distribution? Do you distinguish between "source packages" and "binary packages"? (if yes, give numbers for both). Are there subdivisions in the set of packages (by kind of support, by "freeness")? Are all packages supported the same way, or are there different levels of support? (If different levels, how many packages are supported with each level?) Are some packages imported from another distribution, or are most of your packages done from scratch by your developers ? Q2. Your developers What's a "developer" in your distribution? How many developers do you have? How many of these developers were active in 2007? Does a company (which one?) employ a large number of developers? Do you have different "classes" of developers, or does everybody have the same access right to all your packages? How do you integrate new developers? How do you handle contributors who don't have access rights to the archive? (is there some kind of sponsoring system?) Q3. Developers and packages ownership What's the relationship between developers and packages? Does each package have an assigned developer, or can everybody modify all packages without stepping on anyone's toes? Are packages mostly maintained by teams, or by developers working alone? Other questions: - Did I send that mail to the right mailing list? - Which question should I have asked? What should I ask next? - Do you think that this initiative is interesting? - Do you think that this should move to a seperate mailing list? Would you participate in such a mailing list? - Can you suggest a project that could host such a mailing list without annoying anyone? :) - Any other suggestions? Thank you for reading me so far -- and for answering my questions if you did. ;) If you want me to ping you when I'll publish the answers, just drop me a mail. -- | Lucas Nussbaum | lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F | From alexl at redhat.com Thu Sep 20 07:11:08 2007 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 20 Sep 2007 09:11:08 +0200 Subject: mono Provides In-Reply-To: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1190272268.11057.1.camel@localhost.localdomain> On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote: > Is it intentional and safe for these packages to provide these Mono > capabilities? Are the pairs of packages, which provide exactly the > same things, interchangable at run-time? You know what can happen when > Yum resolves a dependency by pulling in the pkg with the shortest > name... I guess this is because some mono app ship dlls instead of depending on system versions of them? Ideally we shouldn't do this, but i'm sure there are cases where its not possible to avoid. Maybe the mono auto-provides should only be looking in the public directories for dlls to auto-provide? From jamatos at fc.up.pt Thu Sep 20 07:21:23 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 20 Sep 2007 08:21:23 +0100 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <1190218902.3418.0.camel@localhost.localdomain> References: <1190218648.2653.11.camel@mashtun.mt.att.com> <1190218902.3418.0.camel@localhost.localdomain> Message-ID: <200709200821.24266.jamatos@fc.up.pt> On Wednesday 19 September 2007 17:21:42 Tom "spot" Callaway wrote: > Not a bug, ajax just doesn't have all possible packages installed. You > really want to ask repoquery: > > [spot at localhost ~]$ repoquery -q --whatrequires chkfontpath > libdockapp-fonts-0:0.6.1-3.fc8.x86_64 > grace-0:5.1.21-2.fc8.x86_64 It is on my TODO to remove the dependency, unfortunately I had other issues coming in the way. :-( I intend to remove it soon. > ~spot -- Jos? Ab?lio From bbbush.yuan at gmail.com Thu Sep 20 07:46:17 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Thu, 20 Sep 2007 15:46:17 +0800 Subject: keyring primer? In-Reply-To: <1190186067.3904.151.camel@localhost.localdomain> References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <1190186067.3904.151.camel@localhost.localdomain> Message-ID: <76e72f800709200046r7d897af9jb211561b02bec37f@mail.gmail.com> 2007/9/19, Alexander Larsson : > > http://live.gnome.org/GnomeKeyring/Pam > This page says: in /etc/pam.d/gdm auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_start in /etc/pam.d/gnome-screensaver auth optional pam_gnome_keyring.so in /etc/pam.d/passwd password optional pam_gnome_keyring.so Actually installed on my system: auth optional pam_gnome_keyring.so auto_start session optional pam_gnome_keyring.so (the 'auto_start' is put to 'auth' line, not 'session', any difference?) and I can understand if /etc/pam.d/passwd is not changed. BTW, login.keyring is not set up automatically for me. -- bbbush ^_^ From johannbg at hi.is Thu Sep 20 08:06:13 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 20 Sep 2007 08:06:13 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <46F1CE96.7070308@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> Message-ID: <46F229F5.4070905@hi.is> David Boles wrote: > on 9/19/2007 6:09 PM, ? wrote: > >>> on 9/19/2007 4:29 PM, Matthias Clasen wrote: >>> >>>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: >>>> >>>>> Matthias Clasen redhat.com> writes: >>>>> >>>>>> Yeah, but then you don't walk away from your root session expecting >>>>>> the >>>>>> screensaver to kick in - which it doesn't for root. >>>>>> >>>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop >>>>> locking >>>>> for root work just fine in KDE. >>>>> >>>> And I assume that KDE users are just happy to run tons of unaudited >>>> toolkit code as root... >>>> >>>> Anyway, its a moot point, we'll re-enable root login for test3. >>>> >>> I have watched this thread since the beginning and I can no longer keep my >>> peace. >>> >>> A knowledgeable Linux user would know how to change this default. Or >>> figure out how to change. I know how and I am certainly not on the level >>> of many here. >>> >>> >> True so he know he can simply F1 and take it from there... >> >> >>> A 'not so knowledgeable Linux user' would use the 'enter Roots password' >>> windows to preform these tasks. >>> >>> >> And if the user manage to shoot himself in the foot so he cant login >> using his username and password how is he gonna manage to get to his >> "enter the root password dialog".... >> >> >>> Any user that can not do either of these things *does not* have any >>> business logging in as root in a GUI. Period. >>> >> Wrong he has a fighting chance to save himself log into familiar >> surroundings fix the situation with S-C-* tools, learn from his mistake >> instead of have to do clean install or bother advanced users given that they >> are some where around him. >> >> The alternitive "dropping him to terminal window" were he would be dead in >> the water... >> >> >>> Or do you want Fedora 8 to be like Windows? >>> >> No... >> >> >>> Where 'run as root' is the >>> default for the 'not so knowledgeable Windows user'? >>> >> Last time I used M$ windows it made dam sure that the user could harm >> the system ( windows it self ) and question every other move he did.. >> >> s/could/could\ not/ >> Maybe Windows is actually trusting user today but I doubt it... >> >> >>> You want them to be >>> able to shoot themselves in the foot? >>> >> Yes. the users will learn from there mistakes, adopt,evolve and move on.. >> >> Let's place the trust on the user always. >> >> >>> I hope not. >>> >>> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about >>> it first. More than downloading an ISO and burning it it Windows. >>> >> Nope get the user first into linux as hazle free and comfortable as >> possible... >> >> >From there he will start using, playing, fiddle around *expanding his >> knowledge about linux. etc.. >> > > > Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and > the so many other Windows games you will get a *lot* of 'new Linux users' > from Windows. Just as ignorant as you are looking for here. > There is nothing preventing games ( except maybe graphics driver, but that in fast process of changing due to AMD/ATI open up their drivers pouring some work in with help of others and fix the ATI driver... It *seems* NVIDIA is putting more efforts their drivers to answer ATI so my predection on that are we will ( have actually been with AMD/ATI ) be seeing some fast improvements on graphics driver in not so distant future..) in to be played on linux... and has not been for quite some time... Those who want to play games on Linux http://www.transgaming.com/ Wine Games have even been develope for Linux Rememberg Lokigames!!! > I give up. Logical thinking does not work when dealing with zealots. But I > still think that you are wrong. No default GUI root logins. > > > The ideal solution has already been mention. Default gui root login turned off, user gets an option in GDM/KDM/XDM/rest-of-DM to enable root login ( user tries to login as root get hinted to go to option where he can enable root login, types the root password, root gui login is now enabled, logs in as root to an stripped down administrative version of the gui AKA safe mode... Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From johannbg at hi.is Thu Sep 20 08:47:29 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 20 Sep 2007 08:47:29 +0000 Subject: Root login in rawhide and display managers In-Reply-To: <46F1EC0E.6020307@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <1190238192.12402.9.camel@localhost6.localdomain6> <46F1EC0E.6020307@gmail.com> Message-ID: <46F233A1.6010804@hi.is> David Boles wrote: > on 9/19/2007 5:43 PM, Richi Plana wrote: > >> On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote: >> >>> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about >>> it first. More than downloading an ISO and burning it it Windows. I did >>> that years ago. How about you? >>> >> Now that's not a nice mentality. >> >> I'm a self-professed computer geek, but it's my opinion that a person >> should be good at what they aim to accomplish. If they mean to write a >> great essay on a wordprocessor on Linux, then they don't need to be >> proficient with Linux. Just writing. OTOH, if you want to be a Linux >> machines system administrator, then that person should damn well know >> what the heck is going on under the hood of their machine (as opposed to >> just button-clicking). Even with grammar-correction, writers should know >> well the rules of grammar. >> >> The beauty in Linux is that as the software matures, people find >> themselves being more productive in whatever goal they set themselves >> out to use a computer for. Hopefully, it might even allow them to be >> creative about it in ways that weren't open to them before using Linux. >> (That's how I got hooked on code reusability and the Unix philosophy.) >> > > I did *not* say that you needed to be a 'geek' to use Linux for common > everyday tasks. What I said was that if you, the (any)user, wants to do > really, really strange things that the user should know more about Linux > than how to tie his shoes strings. > > No just to start to buy a loot of books about linux and read the wealth of information about linux before you start using it... > When I started with Linux 'docs' was a joke. Man pages was just about the > same. GUI configuration applications? What are those? Files, most of > which, are done 'for you' now had to be done by hand during the > installation or in text editors later. Firewalls. Port sentries. Lan > connections. Almost everything had to be done by hand. > > Which took - OH MY $deity - reading and more than 'click here dummy or > accept the default'. > > Oh the good old days :) We have come a long way since then.. > The *MAIN* fault with Windows is the 'user is root' situation. You want > that for Linux? Do you really want someone who thinks that a harddrive is > that 'big box on my desk that all of this stuff is connected to' to have > kill it in one shot abilities? > If the user is *chrooted* to his home directory and what he does cant affect the system or other users, then hell yeah.. he should have the power to shoot himself in the "foot" or commit otherwize user suicide... > Really? Then Linux is doomed to follow the same path. When 'you' make > Linux just like that - that is when the masses will/might convert to > Linux. Where have you been fella, the masses have already started to use GNU/Linux The number are increasing by the day... Welcome to the OpenSource Revolution.... ( We have to start creating T-Shirts and come up with some really cool songs and slogans. ) ( Any one open/up for the task to write an OpenSource musical :) .. ) > That will be when the guy in Russia starts writing the really kool > screen saver that the dummy you enticed to try Linux downloads. The on > that contacts the first major Linux Trojan/virus/ crap. > > I hope not. > As long as it affect the user and only the user then it does not matter... Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mschwendt.tmp0701.nospam at arcor.de Thu Sep 20 11:02:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Sep 2007 13:02:46 +0200 Subject: rpms/javasvn/FC-6 dead.package, NONE, 1.1 .cvsignore, 1.3, NONE Makefile, 1.1, NONE javasvn.spec, 1.5, NONE sources, 1.3, NONE In-Reply-To: <200709191548.l8JFmL8A025942@cvs-int.fedora.redhat.com> References: <200709191548.l8JFmL8A025942@cvs-int.fedora.redhat.com> Message-ID: <20070920130246.138f91fd.mschwendt.tmp0701.nospam@arcor.de> On Wed, 19 Sep 2007 11:48:21 -0400, Robert Marcano (robmv) wrote: > Author: robmv > > Update of /cvs/extras/rpms/javasvn/FC-6 > Added Files: > dead.package > Removed Files: > .cvsignore Makefile javasvn.spec sources > Log Message: > Dead package, remaned to svnkit svnkit contains Obsoletes: javasvn < 1.1.0 but javasvn is 1.1.0: find extras-tree/6 -name javasvn\*.src.rpm extras-tree/6/SRPMS/javasvn-1.1.0-0.3.beta4.fc6.src.rpm Please fix before the javasvn pkgs can be removed. From valent.turkovic at gmail.com Thu Sep 20 09:49:57 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 20 Sep 2007 11:49:57 +0200 Subject: is Miro (aka Democracy player) supported in Fedora ? In-Reply-To: <46F1A840.3090207@andrei.myip.org> References: <64b14b300709191049p729e7e96o72d0d6d9323d3075@mail.gmail.com> <46F1A840.3090207@andrei.myip.org> Message-ID: <64b14b300709200249l21d527c9uca78ab3f461dcebc@mail.gmail.com> On 9/20/07, Florin Andrei wrote: > Valent Turkovic wrote: > > Is Miro (aka Democracy player) supported under Fedora? > > I tried to install it but for weeks now it is not possible to install > > it under Rawhide. > > For a long time it didn't work on F7, but then after an update was > released it magically worked somehow. > > Rebuilding the "official" src.rpm on Fedora fails for what looks like > too narrow dependencies. > > > So I'm asking will Miro be supported in Fedora 8 - or if my question > > it not precise enough - will I be able to 'yum install Miro' and > > expect it to install and work? > > That would be very nice. > It certainly would because it currently doesn't work on Fedora Devel (rawhide). When will new Miro version be out that works on Fedora Devel? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From buildsys at fedoraproject.org Thu Sep 20 11:58:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 20 Sep 2007 07:58:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-20 Message-ID: <20070920115817.564BB15212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 10 fslint-2.24-1 NEW grsync-0.6-1.fc6 : A Gtk+ GUI for rsync jd-1.9.6-0.5.beta070918.fc6 kanatest-0.4.4-3 NEW mencal-2.3-1.fc6 : Menstruation calendar NEW perl-Test-Script-1.02-2 : Cross-platform basic tests for scripts NEW pguiman-0.0.1-3 : The PostgreSQL database server managing tool remind-03.01.02-2 NEW slingshot-0.8.1p-1.fc6 : A Newtonian strategy game util-vserver-0.30.214-2 Changes in Fedora Extras 6: fslint-2.24-1.fc6 ----------------- * Wed Sep 19 2007 P?draig Brady

- 2.24-1 - Update to 2.24 * Fri Aug 03 2007 P?draig Brady

- 2.22-2 - clarify license grsync-0.6-1.fc6 ---------------- * Thu Sep 13 2007 Sebastian Vahl - 0.6-1 - New upstream version: 0.6 - Change license to GPLv2 jd-1.9.6-0.5.beta070918.fc6 --------------------------- * Tue Sep 18 2007 Mamoru Tasaka - 1.9.6-0.5.beta070918 - 1.9.6 beta 070918 kanatest-0.4.4-3.fc6 -------------------- * Wed Sep 19 2007 Robert Marcano - 0.4.4-3 - Update to upstream release 0.4.4 * Wed Aug 29 2007 Fedora Release Engineering - 0.4.2-3 - Rebuild for selinux ppc32 issue. mencal-2.3-1.fc6 ---------------- * Sat Sep 01 2007 Marek Mahut - 2.3-1 - First build perl-Test-Script-1.02-2.fc6 --------------------------- * Tue Sep 18 2007 Ralf Cors?pius - 1.02-2 - Reflect license tag changes. - BR: perl(Test::More). - Remove BR: perl. - Add chmod -x Changes lib/Test/*pm pguiman-0.0.1-3.fc6 ------------------- * Tue Sep 18 2007 Ondrej Dvoracek 0.0.1-3 - added documentation link * Thu Sep 06 2007 Ondrej Dvoracek 0.0.1-2 - resolves #260441 at bugzilla.redhat.com - corrected spec file remind-03.01.02-2.fc6 --------------------- * Wed Sep 19 2007 Ray Van Dolson - 03.01.02-2 - Added tcllib requires per bz #290761 * Thu Sep 13 2007 Ray Van Dolson - 03.01.02-1 - Updated to version 03.01.02 * Thu Aug 23 2007 Ray Van Dolson - 03.01.01-1 - Updated to version 03.01.01 - Updated license tag to GPLv2 slingshot-0.8.1p-1.fc6 ---------------------- * Thu Sep 06 2007 Jon Ciesla - 0.8.1p-1 - create. util-vserver-0.30.214-2.fc6 --------------------------- * Wed Sep 19 2007 Enrico Scholz - 0.30.214-2 - fixed upgrade path from 0.30.213 to 0.30.214; rpm fails to handle when a directory becomes a symlink. Hence, remove the 'etch' directory in %pre From jima at beer.tclug.org Thu Sep 20 12:09:47 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 20 Sep 2007 07:09:47 -0500 (CDT) Subject: screen blanking considered useless In-Reply-To: <20070920014731.GA16760@jadzia.bu.edu> References: <46F1A64F.8030604@andrei.myip.org> <20070920014731.GA16760@jadzia.bu.edu> Message-ID: On Wed, 19 Sep 2007, Matthew Miller wrote: > On Wed, Sep 19, 2007 at 03:44:31PM -0700, Florin Andrei wrote: >> It would be nice to have an option somewhere in the installer allowing >> the sysadmin to set the blanking time, or disable it altogether. My >> preference would be to disable it by default and let the sysadmin >> override that in the installer, but I think it's fine if it's enabled by >> default as long as it can be changed in the installer (and it becomes a >> kickstart parameter too). > > Nah -- monitor burn-in is still a potential problem. +1 -- I'd consider a change that might damage my hardware to be a regression. Jima From fedora at camperquake.de Thu Sep 20 12:34:48 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Sep 2007 14:34:48 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <1190233782.4236.45.camel@localhost.localdomain> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> Message-ID: <20070920143448.1b30df86@banea.int.addix.net> Hi. On Wed, 19 Sep 2007 16:29:42 -0400, Matthias Clasen wrote: > > And I assume that KDE users are just happy to run tons of unaudited > toolkit code as root... They are running Gnome/KDE as root to begin with. Where exactly is the problem? From myfedora at richip.dhs.org Thu Sep 20 12:40:50 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 06:40:50 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <46F233A1.6010804@hi.is> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <1190238192.12402.9.camel@localhost6.localdomain6> <46F1EC0E.6020307@gmail.com> <46F233A1.6010804@hi.is> Message-ID: <1190292050.27526.19.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 08:47 +0000, "J?hann B. Gu?mundsson" wrote: > > The *MAIN* fault with Windows is the 'user is root' situation. You want > > that for Linux? Do you really want someone who thinks that a harddrive is > > that 'big box on my desk that all of this stuff is connected to' to have > > kill it in one shot abilities? > > > > If the user is *chrooted* to his home directory and what he does cant > affect the system or > other users, then hell yeah.. he should have the power to shoot himself > in the "foot" > or commit otherwize user suicide... I'm afraid I'm going to have to disagree on this one. Yes, I do agree that users should be given the freedom to shoot themselves in the foot IF shooting themselves in the foot is what they want. In this case, intent matters. I keep mentioning that the Fedora system should be made to be smart to aid the user in achieving what he/she wants to do (and is allowed to do, assuming there are restrictions in the institution he's in). It's not even about being root or user privileges. Some users will want to actually DO something (like start/stop system services, configure printers, etc.) while some users just WANT to be root because he knows he has a myriad of things to do requiring root privileges. Unfortunately, the latter situation is really a remnant of the Unix way of thinking. In truth, Administrators don't have to have root access for everything but have gotten so used to not having to authenticate themselves to the system as having the privilege to do what they want whenever they try something. So no, I don't believe in the Windows' "the user is root" philosophy, but until out system has gotten to the point where extended privileges can be given to the user WITHOUT HAVING TO TYPE THE ROOT PASSWORD EACH TIME, then "the user is root" makes sense for a lot of cases (not that I'm advocating it). Think about it this way: let's say Fedora is installed on a computer where only one person will use it (the owner). It's really cumbersome having to type the root password each time certain actions have to be performed. I've never been a big fan of the single-tiered "root is god" idea, anyway. It's certainly convenient for Unix users (including myself) who know exactly what they're doing, though. At the very least, there should be two user IDs: root and admin. admin gets power over some low to mid-level subsystems and could even be the first local account created, while root is root. I seem to recall that Novell (the network system) had a more complex privilege or access list system. Not too sure about Windows. -- Richi Plana From skvidal at fedoraproject.org Thu Sep 20 12:42:49 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 20 Sep 2007 08:42:49 -0400 Subject: Some questions about Fedora In-Reply-To: <20070920071108.GA2035@xanadu.blop.info> References: <20070920071108.GA2035@xanadu.blop.info> Message-ID: <1190292169.2142.43.camel@cutter> On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > Q1. Packages > How many "pieces of software" do you have in your distribution? In our development distribution: - 8232 compiled packages (binaries) - 4638 source packages > Do you distinguish between "source packages" and "binary packages"? (if yes, > give numbers for both). Source packages are what the binary packages are built from. > Are there subdivisions in the set of packages (by kind of support, by "freeness")? No. > Are all packages supported the same way, or are there different levels of > support? All packages are treated the same. > Are some packages imported from another distribution, or are most of your > packages done from scratch by your developers ? All packages are done from scratch by our developers. > Q2. Your developers > What's a "developer" in your distribution? Developers/Contributors are people who contribute something to the distribution. This includes: packages, art, documentation, leadership, time administering our servers, being an encourager of our distribution in various places. Pretty much anything that helps fedora and users of fedora. We derive the count of developers by looking in the Fedora Account System. That keeps track of people who have registered to have access to the resources we maintain. > How many developers do you have? 942 - I'm counting developers here based on people with access to (not necessarily using) www.fedorapeople.org - that means users who are in the Fedora Account System and who are a member of at least one other group. This may not list all of our contributors but it definitely covers all of the developers. > How many of these developers were active in 2007? Unfortunately, I don't have access to this information. (Does anyone else on this list?) > Does a company (which one?) employ a large number of developers? Red Hat, Inc employs a good number of developers. > Do you have different > "classes" of developers, or does everybody have the same access right to > all your packages? Everyone has the same access to all the packages. The only exception is that an individual package maintainer has the right to restrict access to his/her packages to a specific set of developers. > How do you integrate new developers? How do you > handle contributors who don't have access rights to the archive? (is > there some kind of sponsoring system?) Yes, contributing a package and going through the package review and approval process typically gets you sponsored. You then are able to help maintain that (and potentially other) packages in the distribution (anyone else want to give a better answer here??) > Q3. Developers and packages ownership > What's the relationship between developers and packages? Does each > package have an assigned developer, or can everybody modify all packages > without stepping on anyone's toes? Are packages mostly maintained by > teams, or by developers working alone? Each package has at least one assigned maintainer, unless it has been orphaned. However, in most every case any package maintainer can help out on someone else's packages. We recommend that no one just take over someone else's package without asking permission first. Packages are mostly maintained by one or two maintainers - but not in every case. > Other questions: > - Did I send that mail to the right mailing list? Sure, ultimately you could have sent this to the Fedora Board which could have provided the answers. The Fedora Project Board 'speaks' for Fedora in official ways. > - Which question should I have asked? What should I ask next? the order is fine. Ask about license rules of packages in distributions Ask about patent concerns and responsibilities of distributions. Ask about how much upstream development a distributions' developers do and in what ways does it help. > - Do you think that this initiative is interesting? Sure, why not? :) > - Do you think that this should move to a seperate mailing list? Would > you participate in such a mailing list? I'm not sure it needs its own mailing list. > - Can you suggest a project that could host such a mailing list without > annoying anyone? :) Maybe something at the linux foundation? good luck, -sv From sundaram at fedoraproject.org Thu Sep 20 12:52:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 18:22:02 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190251369.11618.160.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> Message-ID: <46F26CF2.2@fedoraproject.org> Ralf Corsepius wrote: talking about. > > You violently don't want to understand, don't you? I understand but completely disagree with you. I think you would find very few agreeing with you that Fedora and RHEL does not play any different roles. Rahul From myfedora at richip.dhs.org Thu Sep 20 13:05:42 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 07:05:42 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070920143448.1b30df86@banea.int.addix.net> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> Message-ID: <1190293542.27526.39.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 14:34 +0200, Ralf Ertzinger wrote: > Hi. > > On Wed, 19 Sep 2007 16:29:42 -0400, Matthias Clasen wrote: > > > > > And I assume that KDE users are just happy to run tons of unaudited > > toolkit code as root... > > They are running Gnome/KDE as root to begin with. Where exactly is the > problem? The problem lies in privileged code doing something unintentional either due to 1) a bug in the code, 2) malicious exploit or 3) user ignorance. Why would anyone want an application to run, anyway, that has the potential of bringing down the system or accessing other users' files? -- Richi Plana From jwboyer at jdub.homelinux.org Thu Sep 20 13:08:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 20 Sep 2007 08:08:59 -0500 Subject: Some questions about Fedora In-Reply-To: <1190292169.2142.43.camel@cutter> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> Message-ID: <20070920080859.270821d8@weaponx.rchland.ibm.com> On Thu, 20 Sep 2007 08:42:49 -0400 seth vidal wrote: > > On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > > Q1. Packages > > How many "pieces of software" do you have in your distribution? > In our development distribution: > - 8232 compiled packages (binaries) > - 4638 source packages > > > > Do you distinguish between "source packages" and "binary packages"? (if yes, > > give numbers for both). > > Source packages are what the binary packages are built from. > > > Are there subdivisions in the set of packages (by kind of support, by "freeness")? > > No. > > > Are all packages supported the same way, or are there different levels of > > support? > > All packages are treated the same. > > > Are some packages imported from another distribution, or are most of your > > packages done from scratch by your developers ? > > All packages are done from scratch by our developers. That's not 100% true. I would say the majority of packages are done from scratch, but I know I've used the spec files included with upstream projects as a starting point at least. So in that regard it wasn't "from scratch". What we don't do is take a package from another distribution and import it without any changes. All packages have to go through review to meet the Fedora review guidelines, and that typically means there are changes needed if you're starting with a package from another distribution. As for the rest of Seth's answers, I agree with them all :) josh From jwboyer at jdub.homelinux.org Thu Sep 20 13:13:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 20 Sep 2007 08:13:12 -0500 Subject: Some questions about Fedora In-Reply-To: <20070920080859.270821d8@weaponx.rchland.ibm.com> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> <20070920080859.270821d8@weaponx.rchland.ibm.com> Message-ID: <20070920081312.04addac8@weaponx.rchland.ibm.com> On Thu, 20 Sep 2007 08:08:59 -0500 Josh Boyer wrote: > On Thu, 20 Sep 2007 08:42:49 -0400 > seth vidal wrote: > > > > > On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > > > Q1. Packages > > > How many "pieces of software" do you have in your distribution? > > In our development distribution: > > - 8232 compiled packages (binaries) > > - 4638 source packages > > > > > > > Do you distinguish between "source packages" and "binary packages"? (if yes, > > > give numbers for both). > > > > Source packages are what the binary packages are built from. > > > > > Are there subdivisions in the set of packages (by kind of support, by "freeness")? > > > > No. > > > > > Are all packages supported the same way, or are there different levels of > > > support? > > > > All packages are treated the same. > > > > > Are some packages imported from another distribution, or are most of your > > > packages done from scratch by your developers ? > > > > All packages are done from scratch by our developers. > > That's not 100% true. I should have said "accurate" instead of "true" above. josh From sundaram at fedoraproject.org Thu Sep 20 13:13:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 18:43:51 +0530 Subject: Some questions about Fedora In-Reply-To: <20070920071108.GA2035@xanadu.blop.info> References: <20070920071108.GA2035@xanadu.blop.info> Message-ID: <46F2720F.5090608@fedoraproject.org> Lucas Nussbaum wrote: > I'll publish the answers on my blog[2], and, if this proves to raise > interest, move them to a wiki. > > [1] http://www.lucas-nussbaum.net/blog/?p=250 > [2] http://www.lucas-nussbaum.net/blog/ I have seen your blog posts but to be fair, cross level distribution co-ordination occurs in informal ways often but a formal place for this has been tried and didn't succeed well except for those with specific agendas like freedesktop.org. It would be good to keep trying however. How do you integrate new developers? How do you > handle contributors who don't have access rights to the archive? (is > there some kind of sponsoring system?) I am assuming, you are talking about someone wanting to put in packages without being a packager themselves. You might want to read http://andrewprice.me.uk/weblog/entry/pybackpack-051---towel-not-included http://andrewprice.me.uk/weblog/entry/the-person-got-sponsored In short, we don't have a special process for this though it has been discussed a couple of times. > Q3. Developers and packages ownership > What's the relationship between developers and packages? Does each > package have an assigned developer, or can everybody modify all packages > without stepping on anyone's toes? Are packages mostly maintained by > teams, or by developers working alone? Each package has a assigned primary package maintainer but can have many co-maintainers which we encourage http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership We have other related policies on modifying other packages which you don't maintain, what to do when package maintainer's don't respond etc http://fedoraproject.org/wiki/PackageMaintainers/Policy We also have many special interest groups where developers maintain packages together, These are listed in http://fedoraproject.org/wiki/SIGs I published some (probably outdated now) stats at http://rahulsundaram.livejournal.com/11669.html > Other questions: > - Did I send that mail to the right mailing list? Yes > - Which question should I have asked? What should I ask next? Governance models and differences between them can be interesting to know. Development policies, unique projects, upstream contributions. > - Do you think that this initiative is interesting? Yes > - Do you think that this should move to a seperate mailing list? Would > you participate in such a mailing list? If you want to create a forum for ongoing discussions between distributions, I would be interested. > - Can you suggest a project that could host such a mailing list without > annoying anyone? :) Linux Foundation, freedesktop.org > Thank you for reading me so far -- and for answering my questions if you > did. ;) If you want me to ping you when I'll publish the answers, just > drop me a mail. I would be interested. Rahul From valent.turkovic at gmail.com Thu Sep 20 10:35:15 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 20 Sep 2007 12:35:15 +0200 Subject: iwl3945 - kill switch issue - how do I contribute In-Reply-To: <46F18ABE.1050809@olen.net> References: <64b14b300709020202t33d25fcen5f7dbe920f3bd8bc@mail.gmail.com> <46DA8031.3050509@gmail.com> <64b14b300709020359j324d4821lb542724e08ab9d74@mail.gmail.com> <46DA9B9F.2050907@gmail.com> <64b14b300709020701s2b872e23t98b4472d6d222262@mail.gmail.com> <46DB0EFB.5080107@olen.net> <64b14b300709191142q60688f4dv4d04ca9f352d899d@mail.gmail.com> <46F18ABE.1050809@olen.net> Message-ID: <64b14b300709200335r39622585i2ed6d33897f938af@mail.gmail.com> On 9/19/07, Ola Thoresen wrote: > Valent Turkovic wrote: > > > Ok, I fixed the issue but only with using Windows :( > (...) > > > > > it this helpful? > > > > Why can't I overrule software RF_KILL switch within linux? > > > This sounds very much like my problem - except that I don't have any > windows partition to test with. > It is strange that it can't be controled from linux. I'm really puzzled and I can't find a fault in my steps - and I hope that someone finds an error in my doing things or suggests something else to try out because I have exhausted all of my ideas... Anybody? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From rc040203 at freenet.de Thu Sep 20 13:18:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Sep 2007 15:18:57 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F26CF2.2@fedoraproject.org> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> Message-ID: <1190294337.11618.232.camel@mccallum.corsepiu.local> On Thu, 2007-09-20 at 18:22 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > talking about. > > > > You violently don't want to understand, don't you? > > I understand but completely disagree with you. I think you would find > very few agreeing with you that Fedora and RHEL does not play any > different roles. Apparently you don't want to understand, that there is _NO_ fundamental technical difference in - Installing a desktop in an office/workplace or at home. - Installing fedora on a server or RHEL. The only real difference are * sys-administrational (service contracts) * money-flow wise (Fedora users invest in man-power, RHEL users into RH and man-power) * RHEL's longevity promise - This is an advantage and disadvantage at the same time. * RHEL being non-free. Ralf From kevin.kofler at chello.at Thu Sep 20 13:19:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 20 Sep 2007 13:19:25 +0000 (UTC) Subject: Root login in rawhide and display managers References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> <1190293542.27526.39.camel@localhost6.localdomain6> Message-ID: Richi Plana richip.dhs.org> writes: > Why would anyone want an application to run, anyway, that has the > potential of bringing down the system or accessing other users' files? Unfortunately, when you're the only user on the system, running your applications as your regular user won't help much, they can still eat all your files. You'd have to run applications like browsers as a different user to take advantage of the user-based security model, and I don't see many people doing that. Kevin Kofler From sundaram at fedoraproject.org Thu Sep 20 13:19:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 18:49:16 +0530 Subject: Is xulrunner going to remove firefox in tomorrow's rawhide? In-Reply-To: <46F19D0A.5030003@conversis.de> References: <1190150444.6908.19.camel@pc-notebook> <1190152499.13077.17.camel@tuxhugs> <1190153468.6908.26.camel@pc-notebook> <46F0B4A9.2050208@redhat.com> <1190185383.6908.34.camel@pc-notebook> <1190212198.2949.16.camel@localhost6.localdomain6> <46F132D0.4010304@fedoraproject.org> <46F19D0A.5030003@conversis.de> Message-ID: <46F27354.4020804@fedoraproject.org> Dennis Jacobfeuerborn wrote: > > If I understood the discussion regarding xulrunner correctly the whole > reason the Mozilla people aren't shipping a xulrunner based version of > Firefox is because they don't want to be limited by a runtime that needs > to be stable rather than cutting edge. If Fedora plans to ship a > xulrunner based Firefox anyway wouldn't that basically require a fork of > the code? Christopher Aillon is currently on vacation and this was my understanding based on the earlier IRC discussion we had. I guess he has to return to confirm and answer your question on this. I don't think we are forking anything. Rahul From sundaram at fedoraproject.org Thu Sep 20 13:22:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 18:52:02 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190294337.11618.232.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> Message-ID: <46F273FA.8050202@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2007-09-20 at 18:22 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: >> talking about. >>> You violently don't want to understand, don't you? >> I understand but completely disagree with you. I think you would find >> very few agreeing with you that Fedora and RHEL does not play any >> different roles. > Apparently you don't want to understand, that there is _NO_ > fundamental technical difference in > - Installing a desktop in an office/workplace or at home. > - Installing fedora on a server or RHEL. Sure there is. Update policies, lifecycle etc. What applies to RHEL does not necessarily apply to Fedora and vice versa. There are many technical solutions that are done on a routine basis in RHEL that are completely infeasible in Fedora. > * RHEL being non-free. It's not. Rahul From pertusus at free.fr Thu Sep 20 13:46:22 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 20 Sep 2007 15:46:22 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F273FA.8050202@fedoraproject.org> References: <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> Message-ID: <20070920132952.GA9756@free.fr> On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote: > > Sure there is. Update policies, lifecycle etc. What applies to RHEL does > not necessarily apply to Fedora and vice versa. There are many technical I use fedora rawhide and centos 4/5, and I don't see many differences, except of course for the 2 items you mentioned above. > solutions that are done on a routine basis in RHEL that are completely > infeasible in Fedora. An example? > >> * RHEL being non-free. > > It's not. At least there is openmotif. But openmotif, even if it is not OSI compatible is not that non free. -- Pat From rc040203 at freenet.de Thu Sep 20 13:49:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Sep 2007 15:49:20 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F273FA.8050202@fedoraproject.org> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> Message-ID: <1190296160.11618.249.camel@mccallum.corsepiu.local> On Thu, 2007-09-20 at 18:52 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > * RHEL being non-free. > > It's not. Send me the CD's or provide the URL where I can get the binary or better be quiet - You are spreading foul propaganda. Ralf From sundaram at fedoraproject.org Thu Sep 20 13:53:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 19:23:11 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920132952.GA9756@free.fr> References: <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> Message-ID: <46F27B47.8060305@fedoraproject.org> Patrice Dumas wrote: > On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote: >> Sure there is. Update policies, lifecycle etc. What applies to RHEL does >> not necessarily apply to Fedora and vice versa. There are many technical > > I use fedora rawhide and centos 4/5, and I don't see many differences, > except of course for the 2 items you mentioned above. These two are very significant technical differences. >> solutions that are done on a routine basis in RHEL that are completely >> infeasible in Fedora. > > An example? Majority of updates are backported patches to maintain ABI compatibility. > At least there is openmotif. But openmotif, even if it is not OSI > compatible is not that non free. This is just a side effect of Fedora having it when RHEL 5 was branched and doesn't really make RHEL non-free. Rahul From sundaram at fedoraproject.org Thu Sep 20 13:53:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 19:23:33 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190296160.11618.249.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <1190296160.11618.249.camel@mccallum.corsepiu.local> Message-ID: <46F27B5D.5090103@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2007-09-20 at 18:52 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: > >>> * RHEL being non-free. >> It's not. > Send me the CD's or provide the URL where I can get the binary or better > be quiet - You are spreading foul propaganda. The absence of free binaries does not make a software non-free. You better look up the definition of Free software. Rahul From myfedora at richip.dhs.org Thu Sep 20 12:57:40 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 06:57:40 -0600 Subject: mono Provides In-Reply-To: <1190272268.11057.1.camel@localhost.localdomain> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> Message-ID: <1190293060.27526.35.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 09:11 +0200, Alexander Larsson wrote: > On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote: > > Is it intentional and safe for these packages to provide these Mono > > capabilities? Are the pairs of packages, which provide exactly the > > same things, interchangable at run-time? You know what can happen when > > Yum resolves a dependency by pulling in the pkg with the shortest > > name... > > I guess this is because some mono app ship dlls instead of depending on > system versions of them? > > Ideally we shouldn't do this, but i'm sure there are cases where its not > possible to avoid. Maybe the mono auto-provides should only be looking > in the public directories for dlls to auto-provide? It's certainly not unheard of for different packages to provide the same implementation of an interface. In fact, we should probably start thinking of coming up for solutions for such a scenario. The alternatives system is an example. Multiple implementations should be allowed to co-exist on the system. Luckily mono seems to have a way to choose which DLL it wants to use (probably first in the GAC or whatever). The question is _"How should this be treated in package management?"_ (which is Fedora's concern). Perhaps the user should be given the option to choose which implementation or package to install? Maybe priorities can be assigned to packages whose sole purpose is to actually provide that interface implementation (as opposed to packages which happen to just use them). Let's take JVM's, for instance. I can have several packages which actually provide JVM implementations, and I can also have Java apps that might want to package a JVM along with the app. Unlike mono, the choice of which JVM or JAR file to use depends on the alternatives system or might be overridden by the application. Or take Firefox. Maybe a firefox package out there could come with it's own xulrunner implementation (which it currently does) or it could come without it and require one to already be on the system. On a slight tangent: I wonder how effective the alternatives system really is and if mono might not be coerced to use it. It's interesting from a systems administration POV to either centralize control at some level (be it low-level like that or abstracted at a GUI level). My thoughts are just rambling now. -- Richi Plana From jkeating at redhat.com Thu Sep 20 14:02:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 10:02:55 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190296160.11618.249.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <1190296160.11618.249.camel@mccallum.corsepiu.local> Message-ID: <20070920100255.1f63495f@localhost.localdomain> On Thu, 20 Sep 2007 15:49:20 +0200 Ralf Corsepius wrote: > > > * RHEL being non-free. > > > > It's not. > Send me the CD's or provide the URL where I can get the binary or > better be quiet - You are spreading foul propaganda. Again language problem. Ralf is speaking of "free" as in money, where Rahul is defending "free" as in software. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Sep 20 14:03:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 20 Sep 2007 16:03:27 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F27B47.8060305@fedoraproject.org> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> Message-ID: <20070920140327.GB9756@free.fr> On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: >> On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote: >>> Sure there is. Update policies, lifecycle etc. What applies to RHEL does >>> not necessarily apply to Fedora and vice versa. There are many technical >> I use fedora rawhide and centos 4/5, and I don't see many differences, >> except of course for the 2 items you mentioned above. > > These two are very significant technical differences. Indeed, but do they get into line with respect with non root/root login in dm issue? > Majority of updates are backported patches to maintain ABI compatibility. Ok, still the lifetime difference. > This is just a side effect of Fedora having it when RHEL 5 was branched and > doesn't really make RHEL non-free. I don't know exactly because I had no contact with the RHEL people in charge of openmotif, but it is not completly clear that RHEL 6 will use lesstif. As always I would apreciate more info on that, but... -- Pat From hughsient at gmail.com Wed Sep 19 22:54:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 19 Sep 2007 23:54:07 +0100 Subject: Odd failed dependency... Message-ID: <1190242447.2798.13.camel@hughsie-laptop> Does the printing config tool call into pirut to install something? [root at hughsie-laptop ~]# rpm -e pirut error: Failed dependencies: pirut is needed by (installed) system-config-printer-0.7.74.1-1.fc8.i386 Any ideas of the mechanism if this is the case? Thanks, Richard. From ssorce at redhat.com Thu Sep 20 14:06:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 20 Sep 2007 10:06:45 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190296160.11618.249.camel@mccallum.corsepiu.local> References: <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <46F11F4D.3060900@poolshark.org> <46F11F06.8030607@fedoraproject.org> <20070919141007.GB13393@jadzia.bu.edu> <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <1190296160.11618.249.camel@mccallum.corsepiu.local> Message-ID: <1190297205.2567.31.camel@localhost.localdomain> On Thu, 2007-09-20 at 15:49 +0200, Ralf Corsepius wrote: > Send me the CD's or provide the URL where I can get the binary or > better > be quiet - You are spreading foul propaganda. You better calm down Ralf. This is not the tone of a civil discussion, and you should also read the Free Software definition or the OSI guidelines, before accusing people. Simo. From rms at 1407.org Thu Sep 20 14:04:41 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 20 Sep 2007 15:04:41 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130008.GC7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> Message-ID: <20070920140441.GC21664@roque.1407.org> On Wed, Sep 19, 2007 at 09:00:08AM -0400, Alan Cox wrote: > Secondly the security argument here is simply peeing in the wind as you can > hit ctrl-alt-f1 and log in as root on a text console. That's not the security argument. The security argument is that GUI's mean a huge ammount of extra code running as root. Tipically extremely buggy code... Rui -- Keep the Lasagna flying! Today is Pungenday, the 44th day of Bureaucracy in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From myfedora at richip.dhs.org Thu Sep 20 13:09:31 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 07:09:31 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070920143448.1b30df86@banea.int.addix.net> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> Message-ID: <1190293772.27526.42.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 14:34 +0200, Ralf Ertzinger wrote: > Hi. > > On Wed, 19 Sep 2007 16:29:42 -0400, Matthias Clasen wrote: > > > > > And I assume that KDE users are just happy to run tons of unaudited > > toolkit code as root... > > They are running Gnome/KDE as root to begin with. Where exactly is the > problem? If that's no problem with you, then I have this "Love Letter" program you might want to see! Just click on the executable and watch the fancy graphics, ;). Sorry ... couldn't resist. -- Richi Plana From lucas at lucas-nussbaum.net Thu Sep 20 14:14:48 2007 From: lucas at lucas-nussbaum.net (Lucas Nussbaum) Date: Thu, 20 Sep 2007 16:14:48 +0200 Subject: Some questions about Fedora In-Reply-To: <1190292169.2142.43.camel@cutter> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> Message-ID: <20070920141448.GA8893@xanadu.blop.info> Hi Seth, Thanks a lot for your answers. On 20/09/07 at 08:42 -0400, seth vidal wrote: > On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > > Q1. Packages > > How many "pieces of software" do you have in your distribution? > In our development distribution: > - 8232 compiled packages (binaries) > - 4638 source packages Mmmh, If I'm a fedora user, and need a package for something that isn't in those 8232 binary packages, what should I do? Install from sources? Or is there some sort of organized way to look for RPMs in unofficial repositories? (I head of rpmfind, but I'm not sure it's what I think) -- | Lucas Nussbaum | lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F | From sundaram at fedoraproject.org Thu Sep 20 14:12:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 19:42:20 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920140327.GB9756@free.fr> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> Message-ID: <46F27FC4.5040405@fedoraproject.org> Patrice Dumas wrote: > On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote: >> These two are very significant technical differences. > > Indeed, but do they get into line with respect with non root/root login > in dm issue? Nope but Ralf claimed that there are no significant technical differences at all which is something I disagreed with. Besides the kind of customers you target a commercial product with is not merely a matter of technical differences. For various reasons, these distributions play different roles. >> Majority of updates are backported patches to maintain ABI compatibility. > > Ok, still the lifetime difference. I am not sure what you mean here. A distribution life cycle is not tied to ABI compatibility. > I don't know exactly because I had no contact with the RHEL people in > charge of openmotif, but it is not completly clear that RHEL 6 will use > lesstif. As always I would apreciate more info on that, but... I believe these sort of changes are discussed only closer to the release but you can ask Daniel Reik, riek AT redhat.com if this is something that you need to know urgently. Rahul From sundaram at fedoraproject.org Thu Sep 20 14:12:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 19:42:31 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920140327.GB9756@free.fr> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> Message-ID: <46F27FCF.1010000@fedoraproject.org> Patrice Dumas wrote: > On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote: >> These two are very significant technical differences. > > Indeed, but do they get into line with respect with non root/root login > in dm issue? Nope but Ralf claimed that there are no significant technical differences at all which is something I disagreed with. Besides the kind of customers you target a commercial product with is not merely a matter of technical differences. For various reasons, these distributions play different roles. >> Majority of updates are backported patches to maintain ABI compatibility. > > Ok, still the lifetime difference. I am not sure what you mean here. A distribution life cycle is not tied to ABI compatibility. > I don't know exactly because I had no contact with the RHEL people in > charge of openmotif, but it is not completly clear that RHEL 6 will use > lesstif. As always I would apreciate more info on that, but... I believe these sort of changes are discussed only closer to the release but you can ask Daniel Riek, riek AT redhat.com if this is something that you need to know urgently. Rahul From pertusus at free.fr Thu Sep 20 14:14:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 20 Sep 2007 16:14:54 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <1190296160.11618.249.camel@mccallum.corsepiu.local> References: <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <1190296160.11618.249.camel@mccallum.corsepiu.local> Message-ID: <20070920141454.GC9756@free.fr> On Thu, Sep 20, 2007 at 03:49:20PM +0200, Ralf Corsepius wrote: > On Thu, 2007-09-20 at 18:52 +0530, Rahul Sundaram wrote: > > Ralf Corsepius wrote: > > > > * RHEL being non-free. > > > > It's not. > Send me the CD's or provide the URL where I can get the binary or better > be quiet - You are spreading foul propaganda. Since it is free software, you can use respins like centos, although RHEL is not really free. -- Pat From jkeating at redhat.com Thu Sep 20 14:17:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 10:17:40 -0400 Subject: Some questions about Fedora In-Reply-To: <20070920141448.GA8893@xanadu.blop.info> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> <20070920141448.GA8893@xanadu.blop.info> Message-ID: <20070920101740.4d08ce95@localhost.localdomain> On Thu, 20 Sep 2007 16:14:48 +0200 Lucas Nussbaum wrote: > Mmmh, If I'm a fedora user, and need a package for something that > isn't in those 8232 binary packages, what should I do? Install from > sources? Or is there some sort of organized way to look for RPMs in > unofficial repositories? (I head of rpmfind, but I'm not sure it's > what I think) The great thing about Fedora is that anybody can become a contributor. If you find software that you want to use but it isn't in Fedora, you can actually bring it to Fedora and own it there. That or you can request (via wish lists) that somebody else do the packaging work. http://fedoraproject.org/wiki/PackageMaintainers/Join is a great starting point if you want to package software for Fedora. Other ways to join the project are outlined at http://fedoraproject.org/join-fedora.html -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Thu Sep 20 14:19:03 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 20 Sep 2007 10:19:03 -0400 Subject: Odd failed dependency... In-Reply-To: <1190242447.2798.13.camel@hughsie-laptop> References: <1190242447.2798.13.camel@hughsie-laptop> Message-ID: <20070920141903.GE25106@psilocybe.teonanacatl.org> Richard Hughes wrote: > Does the printing config tool call into pirut to install something? Print drivers, apparently. > [root at hughsie-laptop ~]# rpm -e pirut > error: Failed dependencies: > pirut is needed by (installed) system-config-printer-0.7.74.1-1.fc8.i386 > > Any ideas of the mechanism if this is the case? Thanks, * Mon Jul 9 2007 Tim Waugh 0.7.70-1 - Requires pirut for system-install-packages. - 0.7.70: - Increased GetReady->NewPrinter timeout. - More binary names mapped to package named. - Run system-install-packages to install missing drivers (bug #246726). - Less debug output. - Desktop file fixes for KDE (bug #247299). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dope will get you through times of no money better than money will get you through times of no dope. -- Freewheelin' Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at redhat.com Thu Sep 20 14:20:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 10:20:46 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070920141454.GC9756@free.fr> References: <46F12F83.80608@fedoraproject.org> <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <1190296160.11618.249.camel@mccallum.corsepiu.local> <20070920141454.GC9756@free.fr> Message-ID: <20070920102046.081cf755@localhost.localdomain> On Thu, 20 Sep 2007 16:14:54 +0200 Patrice Dumas wrote: > Since it is free software, you can use respins like centos, although > RHEL is not really free. There is additional software you have access to as a RHEL customer that is in fact non-free software. However this software is not part of the RHEL distribution, it is akin to an addon repository through RHN. The RHEL distribution (as it currently sits, say RHEL4/5) is in fact free software. Unless you had some other thoughts as to what makes rhel non-free. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Thu Sep 20 14:23:19 2007 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 20 Sep 2007 15:23:19 +0100 Subject: Odd failed dependency... In-Reply-To: <1190242447.2798.13.camel@hughsie-laptop> References: <1190242447.2798.13.camel@hughsie-laptop> Message-ID: <1190298199.11114.2.camel@cyberelk.elk> On Wed, 2007-09-19 at 23:54 +0100, Richard Hughes wrote: > Does the printing config tool call into pirut to install something? > > [root at hughsie-laptop ~]# rpm -e pirut > error: Failed dependencies: > pirut is needed by (installed) system-config-printer-0.7.74.1-1.fc8.i386 > > Any ideas of the mechanism if this is the case? Thanks, It forks system-install-packages. It's used for installing print drivers. 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 sundaram at fedoraproject.org Thu Sep 20 14:22:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 19:52:23 +0530 Subject: Some questions about Fedora In-Reply-To: <20070920141448.GA8893@xanadu.blop.info> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> <20070920141448.GA8893@xanadu.blop.info> Message-ID: <46F2821F.90306@fedoraproject.org> Lucas Nussbaum wrote: > Hi Seth, > > Thanks a lot for your answers. > > On 20/09/07 at 08:42 -0400, seth vidal wrote: >> On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: >>> Q1. Packages >>> How many "pieces of software" do you have in your distribution? >> In our development distribution: >> - 8232 compiled packages (binaries) >> - 4638 source packages > > Mmmh, If I'm a fedora user, and need a package for something that isn't > in those 8232 binary packages, what should I do? Install from sources? > Or is there some sort of organized way to look for RPMs in unofficial > repositories? (I head of rpmfind, but I'm not sure it's what I think) http://fedoratracker.org/ served this purpose previously but I don't think it's functional anymore. Mixing third party repositories with conflicting packages or ones that replace base packages can lead to dependency issues. Ideally, someone would step up and maintain those packages in the official repositories but Fedora does not distribute non-free software or Free software with potential patent issues. A few of the third party repositories that do distribute such software are recently attempting to merge in http://rpmfusion.org. Hopefully between the official repository and this we will have all the packages that end users usually need. If you want to search for individual packages, http://rpmfind.net and http://rpm.pbone.net/ but you can run into dependency issues for complex packages. Rahul From pertusus at free.fr Thu Sep 20 14:28:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 20 Sep 2007 16:28:52 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F27FC4.5040405@fedoraproject.org> References: <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FC4.5040405@fedoraproject.org> Message-ID: <20070920142852.GE9756@free.fr> On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote: > > I believe these sort of changes are discussed only closer to the release > but you can ask Daniel Reik, riek AT redhat.com if this is something that > you need to know urgently. Not urgently, but for packages in EPEL and fedora it would be nice to have consistent provides for Motif implementations, be it openmotif or lesstif. -- Pat From sundaram at fedoraproject.org Thu Sep 20 14:41:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 20:11:49 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920142852.GE9756@free.fr> References: <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FC4.5040405@fedoraproject.org> <20070920142852.GE9756@free.fr> Message-ID: <46F286AD.3060401@fedoraproject.org> Patrice Dumas wrote: > On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote: >> I believe these sort of changes are discussed only closer to the release >> but you can ask Daniel Reik, riek AT redhat.com if this is something that >> you need to know urgently. > > Not urgently, but for packages in EPEL and fedora it would be nice to > have consistent provides for Motif implementations, be it openmotif or > lesstif. It is very much unlikely that RHEL will switch to lesstif in an update so this is not going to happen in the short term atleast. RHEL 6 will likely just inherit the Fedora changes. Rahul From pertusus at free.fr Thu Sep 20 14:50:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 20 Sep 2007 16:50:45 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F286AD.3060401@fedoraproject.org> References: <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FC4.5040405@fedoraproject.org> <20070920142852.GE9756@free.fr> <46F286AD.3060401@fedoraproject.org> Message-ID: <20070920145045.GF9756@free.fr> On Thu, Sep 20, 2007 at 08:11:49PM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: >> On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote: >>> I believe these sort of changes are discussed only closer to the release >>> but you can ask Daniel Reik, riek AT redhat.com if this is something that >>> you need to know urgently. >> Not urgently, but for packages in EPEL and fedora it would be nice to >> have consistent provides for Motif implementations, be it openmotif or >> lesstif. > > It is very much unlikely that RHEL will switch to lesstif in an update so > this is not going to happen in the short term atleast. It is about providing consistent virtual provides, not real provides. In my opinion switching to openmotif in the middle of a RHEL release wouldn't be good (not to mention that openmotif and lesstif aren't ABI compatible). And this is something I care about only if lesstif isn't used in RHEL 6. > RHEL 6 will likely > just inherit the Fedora changes. That's what I would like to know. -- Pat From sb at monkey-mind.net Thu Sep 20 15:08:53 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Thu, 20 Sep 2007 17:08:53 +0200 Subject: /bin/tcsh not in default install anymore? In-Reply-To: <200709190326.l8J3QNbG003816@laptop13.inf.utfsm.cl> References: <1190144380.15361.40.camel@raptor.sr.unh.edu> <20070918194242.GA10121@nostromo.devel.redhat.com> <200709190326.l8J3QNbG003816@laptop13.inf.utfsm.cl> Message-ID: <20070920170853.05ebdaa5@cluestix.noc.ams-ix.net> On Tue, 18 Sep 2007 23:26:23 -0400 Horst H. von Brand wrote: > > It was done in August for rawhide/f8, mainly because nothing > > required it, and it is easy to add for new installs later. > > I seem to remember it was required for Perl's globbing operator. AFAIK, that dependency disappeared over 7 years ago, with the introduction of Perl 5.6.0 (March 2000). -- Steven From galibert at pobox.com Thu Sep 20 15:11:22 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 20 Sep 2007 17:11:22 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <20070919130008.GC7373@devserv.devel.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> Message-ID: <20070920151122.GC30050@dspnet.fr.eu.org> On Wed, Sep 19, 2007 at 09:00:08AM -0400, Alan Cox wrote: > It should not be. In an environment using single sign on systems, ldap, NIS > or yellow pages it makes no sense. > > Secondly the security argument here is simply peeing in the wind as you can > hit ctrl-alt-f1 and log in as root on a text console. Got an interesting situation recently: I just had installed a reasonably updated fc5 with a us keyboard with no (nis) users enabled yet, then moved the box to its final destination where the user has a french (azerty) keyboard. C-A-F1 didn't work, but the rest of the keyboard did, so I logged in as graphically as root. Then opened an xterm, did a chvt 1, login and loadkeys fr, but that's just me. So, amusingly, there are cases where C-A-F1 does not work. OG. From sundaram at fedoraproject.org Thu Sep 20 15:08:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 20:38:27 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920145045.GF9756@free.fr> References: <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FC4.5040405@fedoraproject.org> <20070920142852.GE9756@free.fr> <46F286AD.3060401@fedoraproject.org> <20070920145045.GF9756@free.fr> Message-ID: <46F28CEB.6080501@fedoraproject.org> Patrice Dumas wrote: > > It is about providing consistent virtual provides, not real provides. In > my opinion switching to openmotif in the middle of a RHEL release > wouldn't be good (not to mention that openmotif and lesstif aren't ABI > compatible). And this is something I care about only if lesstif isn't > used in RHEL 6. > >> RHEL 6 will likely >> just inherit the Fedora changes. > > That's what I would like to know. I will ask and get back to you. Rahul From mschwendt.tmp0701.nospam at arcor.de Thu Sep 20 15:15:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 20 Sep 2007 17:15:15 +0200 Subject: mono Provides In-Reply-To: <1190293060.27526.35.camel@localhost6.localdomain6> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> Message-ID: <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Sep 2007 06:57:40 -0600, Richi Plana wrote: > It's certainly not unheard of for different packages to provide the same > implementation of an interface. In fact, we should probably start > thinking of coming up for solutions for such a scenario. Technically, the different packages should only offer the same implementation of an interface if they make it available in a public place of the run-time environment where it is found by default by all components which may require a given implementation. General examples for such places are the dynamic linker's search paths for shared libraries [1], Perl/Python module directories, and most likely similar directories for Mono and other programming-language run-time environments. If, however, they store the implementation in a private directory, where it doesn't satisfy run-time requirements by default, they should not advertise the implemented interface [via the RPM system]. It bears the risk of breaking other packages like with this Perl module example: http://bugzilla.redhat.com/247113 -- [1] The automatic SONAME Provides are a smoldering fire, since by default the soname for any lib in a private path is provided by a pkg, leading to dangers like: https://bugzilla.redhat.com/278181 From rc040203 at freenet.de Thu Sep 20 15:14:44 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Sep 2007 17:14:44 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F27FCF.1010000@fedoraproject.org> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> Message-ID: <1190301284.11618.287.camel@mccallum.corsepiu.local> On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > > On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote: > >> These two are very significant technical differences. > > > > Indeed, but do they get into line with respect with non root/root login > > in dm issue? > > Nope but Ralf claimed that there are no significant technical > differences at all which is something I disagreed with. Besides the kind > of customers you target a commercial product with is not merely a matter > of technical differences. For various reasons, these distributions play > different roles. What is significantly different between the situation a secretary in an office desktop writing texts/browsing the web etc. is in and those of your Grandmother/ your 10 year old son doing the same @home? None. In both situations you will need a sysadmin. What is the difference between somebody archiving his photographs in a database-server @home and somebody archiving his photographs in a database-server @work? None. Both servers contain valuable data, both servers need a fairly high reliability. What is more valuable? Your digital wedding holiday's photographs @home or your latest RH work @RH? > >> Majority of updates are backported patches to maintain ABI compatibility. Irrelevant from a desktop USER's POV. To them, what matters is "their application simply works". Ralf From opensource at till.name Thu Sep 20 15:20:33 2007 From: opensource at till.name (Till Maas) Date: Thu, 20 Sep 2007 17:20:33 +0200 Subject: Some questions about Fedora In-Reply-To: <1190292169.2142.43.camel@cutter> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> Message-ID: <200709201720.41048.opensource@till.name> On Thursday 20 September 2007 14:42:49 seth vidal wrote: > On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > > Are there subdivisions in the set of packages (by kind of support, by > > "freeness")? > > No. The allowed licenses for Software, Content, Documentation, Fonts and Firmware vary, so imho there are package classes with different freeness available in Fedora. But afaik only firmware and font packages have a specific naming that allows to identify them. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Thu Sep 20 15:26:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 20:56:25 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190301284.11618.287.camel@mccallum.corsepiu.local> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> <1190301284.11618.287.camel@mccallum.corsepiu.local> Message-ID: <46F29121.3060800@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote: > What is significantly different between the situation > a secretary in an office desktop writing texts/browsing the web etc. is > in and those of your Grandmother/ your 10 year old son doing the same > @home? > > None. In both situations you will need a sysadmin. I don't see either situations needing a sysadmin. My grandmother does her work on her computer without requiring any sysadmin interaction for the kind of routine tasks you refer to. >>>> Majority of updates are backported patches to maintain ABI compatibility. > Irrelevant from a desktop USER's POV. > > To them, what matters is "their application simply works". Correct but the technical difference and the impact on the differences between the roles they provide still stand. One example of the impact of ABI compatibility is with ISV applications. In this instance, you can't expect them to simply work in any distribution without an additional explicit effort. I will leave the discussion at that. Rahul From fedora at leemhuis.info Thu Sep 20 15:29:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Sep 2007 17:29:58 +0200 Subject: Odd failed dependency... In-Reply-To: <1190298199.11114.2.camel@cyberelk.elk> References: <1190242447.2798.13.camel@hughsie-laptop> <1190298199.11114.2.camel@cyberelk.elk> Message-ID: <46F291F6.7020403@leemhuis.info> On 20.09.2007 16:23, Tim Waugh wrote: > On Wed, 2007-09-19 at 23:54 +0100, Richard Hughes wrote: >> Does the printing config tool call into pirut to install something? >> >> [root at hughsie-laptop ~]# rpm -e pirut >> error: Failed dependencies: >> pirut is needed by (installed) system-config-printer-0.7.74.1-1.fc8.i386 >> >> Any ideas of the mechanism if this is the case? Thanks, > > It forks system-install-packages. It's used for installing print > drivers. I thought there was a "unwritten" policy to install (nearly?) all drivers for hardware by default to make sure people can just configure hardware even in situations when they don't have a network connection or a install CD at hand. Cu knurd From myfedora at richip.dhs.org Thu Sep 20 14:37:22 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 08:37:22 -0600 Subject: Some questions about Fedora In-Reply-To: <20070920141448.GA8893@xanadu.blop.info> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> <20070920141448.GA8893@xanadu.blop.info> Message-ID: <1190299042.27526.66.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 16:14 +0200, Lucas Nussbaum wrote: > Mmmh, If I'm a fedora user, and need a package for something that isn't > in those 8232 binary packages, what should I do? Install from sources? > Or is there some sort of organized way to look for RPMs in unofficial > repositories? (I head of rpmfind, but I'm not sure it's what I think) There are third-party yum repositories. For various stuff (including multimedia applications, codecs, mythtv, asterisk, games) there's ATRPMS (http://www.atrpms.net/) and RPMFusion (http://rpmfusion.org/) (which is going to be a merging of 3rd-party repositories Dribble, Livna and FreshRPMS (which, I think, has Dag Wiers packages, as well)). Java packages for Fedora can be had from JPackage (http://www.jpackage.org/). There are several individual companies with their own repositories for Fedora like Google and Adobe. With a properly configured yum system (and some cooperation between some 3rd-party repos), all of these packages can be seamlessly and effortlessly be downloaded and installed on Fedora. You can also install from sources. Anyone can do the "./configure; make; make install" routine. Though, of course, those won't be managed by the package manager. Personally, if I can't find a repository with an RPM package for software I want installed, I write my own spec file (with the tools provided in the rpmdevtools package) and rpmbuild my own. RPMFind is a manual way of finding RPM packages and you're not guaranteed that the RPM you'll find will integrate well on Fedora systems. -- Richi Plana From rc040203 at freenet.de Thu Sep 20 15:40:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Sep 2007 17:40:40 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F29121.3060800@fedoraproject.org> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> <1190301284.11618.287.camel@mccallum.corsepiu.local> <46F29121.3060800@fedoraproject.org> Message-ID: <1190302840.11618.302.camel@mccallum.corsepiu.local> On Thu, 2007-09-20 at 20:56 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote: > > What is significantly different between the situation > > a secretary in an office desktop writing texts/browsing the web etc. is > > in and those of your Grandmother/ your 10 year old son doing the same > > @home? > > > > None. In both situations you will need a sysadmin. > > I don't see either situations needing a sysadmin. My grandmother does > her work on her computer without requiring any sysadmin interaction for > the kind of routine tasks you refer to. C'mon, you are really being rediculous. > >>>> Majority of updates are backported patches to maintain ABI compatibility. > > Irrelevant from a desktop USER's POV. > > > > To them, what matters is "their application simply works". > > Correct but the technical difference and the impact on the differences > between the roles they provide still stand. One example of the impact of > ABI compatibility is with ISV applications. ISV apps != RHEL desktop. > In this instance, you can't > expect them to simply work in any distribution without an additional > explicit effort. 1. We talked about desktops and freedom, not about ISVs. 2. They could do so easily, if they wanted to. Ralf From nigel.metheringham at dev.intechnology.co.uk Thu Sep 20 15:42:20 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 20 Sep 2007 16:42:20 +0100 Subject: /bin/tcsh not in default install anymore? In-Reply-To: <20070920170853.05ebdaa5@cluestix.noc.ams-ix.net> References: <1190144380.15361.40.camel@raptor.sr.unh.edu> <20070918194242.GA10121@nostromo.devel.redhat.com> <200709190326.l8J3QNbG003816@laptop13.inf.utfsm.cl> <20070920170853.05ebdaa5@cluestix.noc.ams-ix.net> Message-ID: <879B70E0-2DCC-4387-BADC-850C9CD6DAA7@dev.intechnology.co.uk> On 20 Sep 2007, at 16:08, Steven Bakker wrote: > On Tue, 18 Sep 2007 23:26:23 -0400 Horst H. von Brand wrote: > >>> It was done in August for rawhide/f8, mainly because nothing >>> required it, and it is easy to add for new installs later. >> >> I seem to remember it was required for Perl's globbing operator. > > AFAIK, that dependency disappeared over 7 years ago, with the > introduction of Perl 5.6.0 (March 2000). Thats what I thought... however a quick strings on libperl.so does throw up an instance of /bin/csh - no idea what its there for... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From bbbush.yuan at gmail.com Thu Sep 20 15:49:42 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Thu, 20 Sep 2007 23:49:42 +0800 Subject: Problems about xulrunner Message-ID: <76e72f800709200849m2513bd64g85baf09b476fb56d@mail.gmail.com> Hi, I have 3 questions 1. I want to rebuild chmsee against xulrunner, but to compile chmsee, in its configure script, it looks for xulrunner-gtkmozembed.pc. I don't know how to handle this. Only 3 .pc files are provided with xulrunner-devel (-js, -plugin, -xpcom). Any transition guide? 2. I downloaded chatzilla.zip from http://chatzilla.rdmsoft.com/xulrunner/ and have to install it in the following steps: * su - root * run xulrunner --register-global <= why not do it in RPM spec? * run xulrunner --install-app chatzilla.zip, then * goto /usr/lib/chatzilla and change files and directories' permissions, because original permissions are all 0400. <= isn't xulrunner supposed to install them properly? * run chatzilla, quit it, then copy ~/.mozilla/firefox/__.profile/prefs.js to ~/.chatzilla/__.profile/, overwrite existing one. <= Since firefox has been removed, I cannot export settings easily. 3. when using chatzilla, the font selection strategy seems to have something wrong. The chinese comma is displayed as "FF0C" if it is used after latin alnums. -- bbbush ^_^ From sundaram at fedoraproject.org Thu Sep 20 15:51:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 21:21:03 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190302840.11618.302.camel@mccallum.corsepiu.local> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> <1190301284.11618.287.camel@mccallum.corsepiu.local> <46F29121.3060800@fedoraproject.org> <1190302840.11618.302.camel@mccallum.corsepiu.local> Message-ID: <46F296E7.2080601@fedoraproject.org> Ralf Corsepius wrote: > On Thu, 2007-09-20 at 20:56 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: >>> On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote: >>> What is significantly different between the situation >>> a secretary in an office desktop writing texts/browsing the web etc. is >>> in and those of your Grandmother/ your 10 year old son doing the same >>> @home? >>> >>> None. In both situations you will need a sysadmin. >> I don't see either situations needing a sysadmin. My grandmother does >> her work on her computer without requiring any sysadmin interaction for >> the kind of routine tasks you refer to. > C'mon, you are really being rediculous. This is not a argument. >>>>>> Majority of updates are backported patches to maintain ABI compatibility. >>> Irrelevant from a desktop USER's POV. >>> >>> To them, what matters is "their application simply works". >> Correct but the technical difference and the impact on the differences >> between the roles they provide still stand. One example of the impact of >> ABI compatibility is with ISV applications. > ISV apps != RHEL desktop. RHEL desktop has ISV applications and an important technical feature enabling that to happen is ABI compatibility. I wasn't talking about any one product. This applies to Windows as well. >> In this instance, you can't >> expect them to simply work in any distribution without an additional >> explicit effort. > 1. We talked about desktops and freedom, not about ISVs. > 2. They could do so easily, if they wanted to. Without ABI compatibility ISV application have to continuously play catchup which is far from easy and there is no incentive for them to do so. Even not considering ISV applications, ABI compatibility can still result in breakage. This happens quite often for GPL kernel modules not merged upstream for example. We were talking about whether RHEL plays a different role from Fedora and whether there are significant technical differences in between them. I have given examples of the differences and the impact on the roles they play. Rahul From florin at andrei.myip.org Thu Sep 20 16:12:39 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 20 Sep 2007 09:12:39 -0700 Subject: screen blanking considered useless In-Reply-To: References: <46F1A64F.8030604@andrei.myip.org> <20070920014731.GA16760@jadzia.bu.edu> Message-ID: <46F29BF7.7010606@andrei.myip.org> Jima wrote: > > +1 -- I'd consider a change that might damage my hardware to be a > regression. That would be true if the installer would disable screen blanking without giving the option to change that. But that's not what I was talking about. What I'd like to see is the installer allowing the sysadmin to choose the screen blanking time, or even disable it altogether. I don't care very much about the default, as long as I can choose. -- Florin Andrei http://florin.myip.org/ From lamont at gurulabs.com Thu Sep 20 16:55:22 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 20 Sep 2007 10:55:22 -0600 Subject: Odd failed dependency... In-Reply-To: <46F291F6.7020403@leemhuis.info> References: <1190242447.2798.13.camel@hughsie-laptop> <1190298199.11114.2.camel@cyberelk.elk> <46F291F6.7020403@leemhuis.info> Message-ID: <20070920105522.00ea2b62@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 20 Sep 2007 17:29:58 +0200 Thorsten Leemhuis wrote: > On 20.09.2007 16:23, Tim Waugh wrote: > > On Wed, 2007-09-19 at 23:54 +0100, Richard Hughes wrote: > >> Does the printing config tool call into pirut to install something? > >> > >> [root at hughsie-laptop ~]# rpm -e pirut > >> error: Failed dependencies: > >> pirut is needed by (installed) > >> system-config-printer-0.7.74.1-1.fc8.i386 > >> > >> Any ideas of the mechanism if this is the case? Thanks, > > > > It forks system-install-packages. It's used for installing print > > drivers. > > I thought there was a "unwritten" policy to install (nearly?) all > drivers for hardware by default to make sure people can just configure > hardware even in situations when they don't have a network connection > or a install CD at hand. The use of the word "drivers" for printers has nothing to do with hardware drivers. Actually, for most printers, they're not really "drivers" in the same sense as for other hardware. There are some printers in the world that have no brains but are merely a collection of motors that need a computer to have a driver that knows how to send all the right signals to them at the right times in order to be able to print (kinda like a "winmodem"). Thankfully, there are very few of these. Most of the time, a printer "driver" isn't really a driver, but is a filter for the print subsystem (i.e. cupsd) to push the file to be printed through. Such filters convert, for example, PostScript or plain-text into whatever printer language (like PostScript or PCL) the printer it's headed for understands. It all boils down to the fact that printer "drivers" are not drivers as in what the kernel provides. Still, I thought we had lots of printer filter sets (like foomatic) installed by default with CUPS. Some questions: 1. What other things might be installed as a consequence of using system-config-printer to set up a printer? 2. Are they really all that big that it costs users anything significant to just have those installed too? 3. Or, should we go the other direction and not install quite so many to begin with? 4. Either way, can't system-config-printer just call yum or tell you to 'Have an admin run "yum install foo" if you want to setup that printer' if pirut isn't installed? Personally, I'm a fan of Provides: and would like to see more things not depend on otherwise optional components. If I don't have to have something installed just because I want to use another program but I'll never use the optional features, why be forced into it? We probably shouldn't talk about that last question in this thread as I think I'm starting to head off-topic for the thread. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8qX7+YBsl9wN1AkRAr3sAJ48ZNm5Yf6v+m4Z2EERV1ioEJDukwCeKsen iBUxDWjRv8Pcl1C7ByVwU4M= =8s8S -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Thu Sep 20 16:57:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 20 Sep 2007 18:57:20 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F296E7.2080601@fedoraproject.org> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> <1190301284.11618.287.camel@mccallum.corsepiu.local> <46F29121.3060800@fedoraproject.org> <1190302840.11618.302.camel@mccallum.corsepiu.local> <46F296E7.2080601@fedoraproject.org> Message-ID: <1190307440.13068.14.camel@rousalka.dyndns.org> Le jeudi 20 septembre 2007 ? 21:21 +0530, Rahul Sundaram a ?crit : > > We were talking about whether RHEL plays a different role from Fedora > and whether there are significant technical differences in between them. > I have given examples of the differences and the impact on the roles > they play. You have given differences on the support model; they do not have to translate in user interaction differences. Fedora does not aim to be the anti-RHEL, there is significant feature overlap or Red Hat would not be funding Fedora, so can we please stop using the RHEL scarecrow argument? If the enterprise and home space were so different, Microsoft would not have succeeded as wildly as it did. There are far more similarities than differences, home users like stability too, and enterprise users do not disdain pretty gui apps when they're done properly. And server-like home appliances are inundating the market now. Enterprise and home do not have the same priority order, but the items on their priority lists are the same, and good software will register on both (and likewise, bad software may be tolerated a bit longer in one context, but that it fails to pass on the other should raise alarms) Having narrow focus only leads to debacles like NetworkManager, where it's belately realised a feature needs to be deployed everywhere after all, but can't be because one set of constrains was deliberately ignored at project start. -- 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 mattdm at mattdm.org Thu Sep 20 17:02:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 Sep 2007 13:02:38 -0400 Subject: screen blanking considered useless In-Reply-To: <46F29BF7.7010606@andrei.myip.org> References: <46F1A64F.8030604@andrei.myip.org> <20070920014731.GA16760@jadzia.bu.edu> <46F29BF7.7010606@andrei.myip.org> Message-ID: <20070920170238.GA25524@jadzia.bu.edu> On Thu, Sep 20, 2007 at 09:12:39AM -0700, Florin Andrei wrote: > What I'd like to see is the installer allowing the sysadmin to choose > the screen blanking time, or even disable it altogether. I don't care > very much about the default, as long as I can choose. More choices in the installer doesn't seem like the way forward, especially about little things like this. I really, really don't want more questions there. And if you're using kickstart, you can already make the change. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Thu Sep 20 17:01:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Sep 2007 22:31:23 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <1190307440.13068.14.camel@rousalka.dyndns.org> References: <20070919142408.GA14757@jadzia.bu.edu> <46F13777.6040600@fedoraproject.org> <1190216819.11618.97.camel@mccallum.corsepiu.local> <46F15171.8070606@fedoraproject.org> <1190251369.11618.160.camel@mccallum.corsepiu.local> <46F26CF2.2@fedoraproject.org> <1190294337.11618.232.camel@mccallum.corsepiu.local> <46F273FA.8050202@fedoraproject.org> <20070920132952.GA9756@free.fr> <46F27B47.8060305@fedoraproject.org> <20070920140327.GB9756@free.fr> <46F27FCF.1010000@fedoraproject.org> <1190301284.11618.287.camel@mccallum.corsepiu.local> <46F29121.3060800@fedoraproject.org> <1190302840.11618.302.camel@mccallum.corsepiu.local> <46F296E7.2080601@fedoraproject.org> <1190307440.13068.14.camel@rousalka.dyndns.org> Message-ID: <46F2A763.4060403@fedoraproject.org> Nicolas Mailhot wrote: > Le jeudi 20 septembre 2007 ? 21:21 +0530, Rahul Sundaram a ?crit : >> We were talking about whether RHEL plays a different role from Fedora >> and whether there are significant technical differences in between them. >> I have given examples of the differences and the impact on the roles >> they play. > > You have given differences on the support model; they do not have to > translate in user interaction differences. Fedora does not aim to be the > anti-RHEL, there is significant feature overlap or Red Hat would not be > funding Fedora, so can we please stop using the RHEL scarecrow argument? ABI compatibility is not merely differences in support and definitely does affect user interaction depending on the applications. I agree with you however that Fedora does have overlap with RHEL and it is not anti anything. You seem to be reading things I haven't said. Rahul From wtogami at redhat.com Thu Sep 20 17:19:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 20 Sep 2007 13:19:53 -0400 Subject: Proposed changes to F8 Freeze Process Message-ID: <46F2ABB9.7040504@redhat.com> September 20th, 2007 Fedora Engineering Steering Committee ratified these changes to the final F8 freeze process. http://fedoraproject.org/wiki/Releases/8/Schedule 1) CHANGE: At F8 Development freeze currently scheduled for October 4th, the tree will be unlocked for new builds to be automatically tagged into dist-f8. We will be treating this as an "honor system" freeze, where participants are expected to commit only bug fixes and NOT threaten the release with new features or risky changes. The purpose of this new "freeze" policy is an experiment to smoothen the process of getting last-minute fixes in F8 without creating a large workload on rel-eng. This should reduce confusion of built but not tagged packages like during past freezes. HOWEVER, peer policing of proper adherence to freeze guidelines is essential. We will be advertising loudly expectations of package maintainers of acceptable changes during the freeze period. 2) REMINDER: If you screw up and add something to F8 that shouldn't be (horribly broken new version, ABI change, so-name bump, new features, etc.) we will NOT roll-back your build if it has already hit a daily rawhide push. Your only option to recover from this mistake will be to increase the version number or Epoch. 3) CHANGE: Prior to Final Freeze (October 17th) devel/ CVS branch will build into dist-f8. Some package maintainers will want to begin building packages with risky changes (ABI, new features, etc.) in preparation for F9. At their option they may request per-package CVS branch to F-8/ so they may do so without risking F-8 stability. Then devel/ can be used to target dist-f9. 4) CHANGE: Due to the definition of "Development freeze" changing, we are moving up the Final freeze date a week to October 17th. At this point builds will no longer be automatically tagged dist-f8 and will require rel-eng approval to be included in the F8 release. All remaining devel/ will be branched to F-8/, and devel/ will target builds to dist-f9. Warren Togami wtogami at redhat.com _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Thu Sep 20 17:26:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 13:26:52 -0400 Subject: Proposed changes to F8 Freeze Process In-Reply-To: <46F2ABB9.7040504@redhat.com> References: <46F2ABB9.7040504@redhat.com> Message-ID: <20070920132652.668851ad@localhost.localdomain> On Thu, 20 Sep 2007 13:19:53 -0400 Warren Togami wrote: > 3) CHANGE: Prior to Final Freeze (October 17th) devel/ CVS branch will > build into dist-f8. Some package maintainers will want to begin > building packages with risky changes (ABI, new features, etc.) in > preparation for F9. At their option they may request per-package CVS > branch to F-8/ so they may do so without risking F-8 stability. Then > devel/ can be used to target dist-f9. To clarify. We will be making Makefile.common a bit smarter so that when you request a tag or a build from the devel/ branch, it will check for the existence of an F-8/ branch in CVS for that package. If one exists, the dist tag and build target will be for Fedora 9. If no branch exists, the dist tag and build target will be for Fedora 8. This allows packages that aren't ready to branch yet to continue using devel, so that when it /is/ branched, history will follow over and all the tags will be on the right branches. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Sep 20 17:32:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 20 Sep 2007 19:32:00 +0200 Subject: Some questions about Fedora In-Reply-To: <1190292169.2142.43.camel@cutter> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> Message-ID: <1190309520.13068.42.camel@rousalka.dyndns.org> Le jeudi 20 septembre 2007 ? 08:42 -0400, seth vidal a ?crit : Some nitpicking :) > On Thu, 2007-09-20 at 09:11 +0200, Lucas Nussbaum wrote: > > Q1. Packages > > How many "pieces of software" do you have in your distribution? > In our development distribution: > - 8232 compiled packages (binaries) > - 4638 source packages This being for a single architecture. > > Do you distinguish between "source packages" and "binary packages"? (if yes, > > give numbers for both). > > Source packages are what the binary packages are built from. > > > Are there subdivisions in the set of packages (by kind of support, by "freeness")? > > No. Some packages may end up in derived distributions like RHEL which have their own support organisation separate from Fedora. Also, groups within the project can release spins composed of a subset of the distribution packages. Obviously these groups pay more QA attention to the subset they selected than to the rest of the distribution. But there is no formal separation in 1st-class and X-class packages within Fedora. Lastly Fedora packages only free software, but it may relax its rules for stuff with is not software or is borderline (firmware, fonts, etc). Relax meaning no requirement to be modifiable, or if it's modifiable, not requirement to build from sources. Several well-known third-party repositories specialise in stuff Fedora refuses to carry, and may get contributions from individual Fedora members. > > Are all packages supported the same way, or are there different levels of > > support? > > All packages are treated the same. > > > Are some packages imported from another distribution, or are most of your > > packages done from scratch by your developers ? > > All packages are done from scratch by our developers. All packages are build on Fedora infrastructure and must pass Fedora packaging guidelines. There is no requirement to redo them from scratch and indeed most Fedora packages were originally imported from other entities (RHL/FC, third-party RHEL/RHL/FC repositories, etc), by their original packager or someone else. This import is usually one-way because our strict QA process usually forces many changes, and there's little interest in keeping a package outside the project live once it's imported. However many Fedora Java packages live a double life at JPackage, with frequent two-way imports and adaptations. Another such example is OLPC which was forked from Fedora initially, and has come back @fedora lately. Everything OLPC packaged independently will probably be re-imported @fedora eventually. > > Do you have different > > "classes" of developers, or does everybody have the same access right to > > all your packages? > > Everyone has the same access to all the packages. The only exception is > that an individual package maintainer has the right to restrict access > to his/her packages to a specific set of developers. However even when access to a package is not restricted via technical means, each package has an owner and sometimes a co-owner list, and these people have special weight in conflicts, get auto-CCed on package bugs, etc -- 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 wtogami at redhat.com Thu Sep 20 17:28:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 20 Sep 2007 13:28:53 -0400 Subject: CORRECTION: Changes to F8 Freeze Process In-Reply-To: <46F2ABB9.7040504@redhat.com> References: <46F2ABB9.7040504@redhat.com> Message-ID: <46F2ADD5.3020604@redhat.com> Oops. The previous announcement incorrectly said "Proposed" in the subject. This correction is to be explicitly clear that the changes were ratified. That is all. Warren Togami wtogami at redhat.com _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From myfedora at richip.dhs.org Thu Sep 20 16:44:10 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 10:44:10 -0600 Subject: screen blanking considered useless In-Reply-To: <46F29BF7.7010606@andrei.myip.org> References: <46F1A64F.8030604@andrei.myip.org> <20070920014731.GA16760@jadzia.bu.edu> <46F29BF7.7010606@andrei.myip.org> Message-ID: <1190306650.31399.26.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 09:12 -0700, Florin Andrei wrote: > What I'd like to see is the installer allowing the sysadmin to choose > the screen blanking time, or even disable it altogether. I don't care > very much about the default, as long as I can choose. I doubt there's much demand for it, so who knows if resources will be allocated to it (if that's what you're asking for)? But volunteers should try to add it if they're interested. Otherwise, you're kinda stuck with good ol' command-line setterm(1). -- Richi Plana From ndbecker2 at gmail.com Thu Sep 20 18:06:43 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Sep 2007 14:06:43 -0400 Subject: plague error Message-ID: How do I fix this error? make build /usr/bin/plague-client build mercurial mercurial-0_9_4-2_el4 el4 Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 85, in __init__ self._check_api_version(self._server) File "/usr/bin/plague-client", line 90, in _check_api_version server_ver = server.api_version() File "/usr/lib64/python2.5/xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.5/xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "/usr/lib64/python2.5/xmlrpclib.py", line 1183, in request self.send_content(h, request_body) File "/usr/lib64/python2.5/xmlrpclib.py", line 1297, in send_content connection.endheaders() File "/usr/lib64/python2.5/httplib.py", line 856, in endheaders self._send_output() File "/usr/lib64/python2.5/httplib.py", line 728, in _send_output self.send(msg) File "/usr/lib64/python2.5/httplib.py", line 707, in send self.sock.sendall(str) File "/usr/lib/python2.5/site-packages/plague/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [plague] Error 1 From jkeating at redhat.com Thu Sep 20 18:17:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 14:17:29 -0400 Subject: plague error In-Reply-To: References: Message-ID: <20070920141729.3089d68e@localhost.localdomain> On Thu, 20 Sep 2007 14:06:43 -0400 Neal Becker wrote: > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] You get a new cert because yours expired. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu Sep 20 18:18:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Sep 2007 20:18:34 +0200 Subject: Proposed changes to F8 Freeze Process In-Reply-To: <20070920132652.668851ad@localhost.localdomain> References: <46F2ABB9.7040504@redhat.com> <20070920132652.668851ad@localhost.localdomain> Message-ID: <46F2B97A.3070900@hhs.nl> Jesse Keating wrote: > On Thu, 20 Sep 2007 13:19:53 -0400 > Warren Togami wrote: > >> 3) CHANGE: Prior to Final Freeze (October 17th) devel/ CVS branch will >> build into dist-f8. Some package maintainers will want to begin >> building packages with risky changes (ABI, new features, etc.) in >> preparation for F9. At their option they may request per-package CVS >> branch to F-8/ so they may do so without risking F-8 stability. Then >> devel/ can be used to target dist-f9. > > To clarify. We will be making Makefile.common a bit smarter so that > when you request a tag or a build from the devel/ branch, it will check > for the existence of an F-8/ branch in CVS for that package. If one > exists, the dist tag and build target will be for Fedora 9. If no > branch exists, the dist tag and build target will be for Fedora 8. > This allows packages that aren't ready to branch yet to continue using > devel, so that when it /is/ branched, history will follow over and all > the tags will be on the right branches. > Sounds like a sweet plan to me, kudos to rel-eng for this good plan! Regards, Hans From mr.ecik at gmail.com Thu Sep 20 17:33:56 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Thu, 20 Sep 2007 19:33:56 +0200 Subject: Closing FEver bugs In-Reply-To: <3170f42f0709172312j23ea8a12x6c852f6e8c44c166@mail.gmail.com> References: <3170f42f0709172312j23ea8a12x6c852f6e8c44c166@mail.gmail.com> Message-ID: <668bb39a0709201033y4ed202e4pa688c73c6af35e46@mail.gmail.com> In my opinion the best solution is to close it when you build it in rawhide. But there's no rule - you can do that whenever you want to. 2007/9/18, Debarshi 'Rishi' Ray : > When should we close the bugs generated by FEver > (http://fedoraproject.org/wiki/PackageMaintainers/FEver) to indicate > availability of new upstream releases? The bugs are filed against the > 'devel' branch, so should we close it when it is available in Rawhide > or wait for it to be available in the stable branches too? Should we > close it as CURRENTRELEASE or NEXTRELEASE? > > Happy hacking, > Debarshi > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Micha? Bentkowski mr.ecik at gmail.com From myfedora at richip.dhs.org Thu Sep 20 13:40:02 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 07:40:02 -0600 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> <1190293542.27526.39.camel@localhost6.localdomain6> Message-ID: <1190295602.27526.47.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 13:19 +0000, Kevin Kofler wrote: > Richi Plana richip.dhs.org> writes: > > Why would anyone want an application to run, anyway, that has the > > potential of bringing down the system or accessing other users' files? > > Unfortunately, when you're the only user on the system, running your > applications as your regular user won't help much, they can still eat all your > files. You'd have to run applications like browsers as a different user to take > advantage of the user-based security model, and I don't see many people doing > that. Yeah. And a user-based, micro-level SELinux policy would probably be overkill. I suppose there's no point in restricting access of media players to only multimedia files or write access to files not marked for editing. There comes a point when the only solution is to fix the application. -- Richi Plana From sundaram at fedoraproject.org Thu Sep 20 18:46:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 00:16:07 +0530 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> <1190293542.27526.39.camel@localhost6.localdomain6> Message-ID: <46F2BFEF.6070106@fedoraproject.org> Kevin Kofler wrote: > Richi Plana richip.dhs.org> writes: >> Why would anyone want an application to run, anyway, that has the >> potential of bringing down the system or accessing other users' files? > > Unfortunately, when you're the only user on the system, running your > applications as your regular user won't help much, they can still eat all your > files. You'd have to run applications like browsers as a different user to take > advantage of the user-based security model, and I don't see many people doing > that. Note that we have SELinux policies by default for Firefox from Fedora 7 onwards which can be further tuned to limit damage. There is also a guest user functionality in rawhide which can quite useful http://danwalsh.livejournal.com/11913.html Rahul From myfedora at richip.dhs.org Thu Sep 20 17:46:07 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 11:46:07 -0600 Subject: mono Provides In-Reply-To: <1190304365.31399.18.camel@localhost6.localdomain6> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> <1190304365.31399.18.camel@localhost6.localdomain6> Message-ID: <1190310367.31399.32.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 10:06 -0600, Richi Plana wrote: > There was a certain beauty and elegance to the /opt//(bin|lib) > system of yore. Too bad it was abandoned rather than > integrated/improved. Come to think of it, if I were going to do things all over again, I'd probably allow for both system-wide installs into /usr as well as per-package installs in /opt//(bin|lib|perl5|python2.5| java-classpath|mono-libs). Off-topic: is there a way to change a process's environment variables from a different process (but with the same UID or UID=root)? -- Richi Plana From fedora at camperquake.de Thu Sep 20 20:20:09 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 20 Sep 2007 22:20:09 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <1190293772.27526.42.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> <1190293772.27526.42.camel@localhost6.localdomain6> Message-ID: <20070920222009.7b516b56@lain.camperquake.de> Hi. On Thu, 20 Sep 2007 07:09:31 -0600, Richi Plana wrote > If that's no problem with you, then I have this "Love Letter" program > you might want to see! Just click on the executable and watch the > fancy graphics, ;). Maybe I misunderstood Matthias' original comment, but I was under the impression that he did not want to run screensavers as root because of unaudited code. Which I found quite odd, given that we were talking about running KDE/Gnome as root in the first place, so having a screensaver on top could not make things much worse. From bcrl at kvack.org Thu Sep 20 20:24:00 2007 From: bcrl at kvack.org (Benjamin LaHaise) Date: Thu, 20 Sep 2007 16:24:00 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070918095149.7481105c@localhost.localdomain> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070918095149.7481105c@localhost.localdomain> Message-ID: <20070920202400.GC29951@kvack.org> On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote: > My suggested method was that you were presented with a user add option > in anaconda, but the ability to opt out (for say network login > systems). If you opt-out then the no root login policy could be > lifted, but if you opt-in and create a local user then only that local > user would be allowed to graphical log in upon boot (unless you > manually change policy through a gui tool or a hand edit.) But... how do you plan on fixing a system when networking is broken and one cannot login as root anymore? -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: . From sundaram at fedoraproject.org Thu Sep 20 20:26:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 01:56:00 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070920202400.GC29951@kvack.org> References: <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070918095149.7481105c@localhost.localdomain> <20070920202400.GC29951@kvack.org> Message-ID: <46F2D758.2000903@fedoraproject.org> Benjamin LaHaise wrote: > On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote: >> My suggested method was that you were presented with a user add option >> in anaconda, but the ability to opt out (for say network login >> systems). If you opt-out then the no root login policy could be >> lifted, but if you opt-in and create a local user then only that local >> user would be allowed to graphical log in upon boot (unless you >> manually change policy through a gui tool or a hand edit.) > > But... how do you plan on fixing a system when networking is broken and > one cannot login as root anymore? Login as regular user and use su or switch to a VT. Ctl+Alt+F1 Rahul From mclasen at redhat.com Thu Sep 20 20:34:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 20 Sep 2007 16:34:29 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <20070920222009.7b516b56@lain.camperquake.de> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <46F11332.2040708@poolshark.org> <46F114BA.6010308@fedoraproject.org> <46F117D3.70102@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <20070920143448.1b30df86@banea.int.addix.net> <1190293772.27526.42.camel@localhost6.localdomain6> <20070920222009.7b516b56@lain.camperquake.de> Message-ID: <1190320469.4556.15.camel@localhost.localdomain> On Thu, 2007-09-20 at 22:20 +0200, Ralf Ertzinger wrote: > Hi. > > On Thu, 20 Sep 2007 07:09:31 -0600, Richi Plana wrote > > > If that's no problem with you, then I have this "Love Letter" program > > you might want to see! Just click on the executable and watch the > > fancy graphics, ;). > > Maybe I misunderstood Matthias' original comment, but I was under the > impression that he did not want to run screensavers as root because of > unaudited code. Which I found quite odd, given that we were talking about > running KDE/Gnome as root in the first place, so having a screensaver on > top could not make things much worse. > No, I was commenting on the fact that making screensavers work for root is not really helping at all; considering that the entire desktop session runs as root. From buildsys at redhat.com Thu Sep 20 20:50:23 2007 From: buildsys at redhat.com (Build System) Date: Thu, 20 Sep 2007 16:50:23 -0400 Subject: rawhide report: 20070920 changes Message-ID: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> New package nabi Hangul X Input Method New package qimageblitz Interim image effect library for KDE 4.0 New package roxterm A fast terminal emulator New package sos A set of tools to gather troubleshooting information from a system Removed package javasvn Removed package micq Removed package xulrunner Updated Packages: GConf2-2.20.0-1.fc8 ------------------- * Wed Sep 19 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 NetworkManager-1:0.7.0-0.2.svn2833.fc8 -------------------------------------- * Thu Sep 20 2007 Dan Williams - 1:0.7.0-0.2.svn2833 - New SVN snapshot of 0.7 that sucks less * Thu Aug 30 2007 Dan Williams - 1:0.7.0-0.1.svn2736 - Update to SVN snapshot of 0.7 acl-2.2.39-10.fc8 ----------------- * Thu Sep 20 2007 Jiri Moskovcak 2.2.39-10 - Rewriten path_max patch to support long UTF8 names - Resolves #287701, #183181 * Fri Aug 31 2007 Steve Dickson - 2.2.39-9 - Removed NFS4 ACL patch since it was rejected by upstream. aiccu-2007.01.15-2.fc8 ---------------------- * Wed Sep 19 2007 Matt Domsch 2007.01.15-2 - rebuild alsa-lib-1.0.15-0.2.rc2.fc8 --------------------------- * Thu Sep 20 2007 Matthias Saou 1.0.15-0.2.rc2 - Update License field. - Use configdir instead of sysconfdir hacks (cleaner). - Remove redundant optflags overriding. - Switch to using main "version", and merge "postver" since this is the right way of doing things (see NamingGuidelines#NonNumericRelease). - Remove static library. - Mark all of /etc/alsa as config, but not "noreplace". - Remove useless rpath on 64bit archs. * Wed Sep 19 2007 Martin Stransky 1.0.15-0.1.rc2 - updated to 1.0.15rc2 alsa-utils-1.0.15-0.1.rc1.fc8 ----------------------------- * Wed Sep 19 2007 Martin Stransky 1.0.15-0.1.rc1 - new upstream - moved saved volume settings to /var/lib (#293301) - patched alsactl for that (#255421) anaconda-11.3.0.32-1 -------------------- * Wed Sep 19 2007 Jeremy Katz 11.3.0.32-1 - spec file cleanups (dcantrell) - lots of pychecker fixes (clumens) - revert writing out anaconda-ks.cfg earlier; breaks live installs (clumens) - Fix upgrade traceback (clumens, #296571) - Few live install fixes authd-1.4.3-10 -------------- * Wed Sep 19 2007 Ondrej Dvoracek - 1.4.3-10 - corrected illegal identifier in longopt enumeration (#245436) - corrected summary and license bcel-0:5.2-2jpp.1.fc8 --------------------- * Wed Sep 19 2007 Permaine Cheung 0:5.2-2jpp.1 - Update to 5.2 in Fedora * Tue Sep 04 2007 Jason Corley 0:5.2-2jpp - use official 5.2 release tarballs and location - change vendor and distribution to macros - add missing requires on and maven-plugin-test, maven-plugins-base, and maven-plugin-xdoc - macro bracket fixes - remove demo subpackage (examples are not included in the distribution tarball) - build in mock * Wed Jun 27 2007 Ralph Apel 0:5.2-1jpp - Upgrade to 5.2 - Drop bootstrap option: not necessary any more - Add pom and depmap frags bluez-gnome-0.14-5.fc8 ---------------------- * Thu Sep 20 2007 - Bastien Nocera - 0.14-5 - Don't allow class of the device to be changed if HAL is being used (#244261) * Thu Sep 20 2007 - Bastien Nocera - 0.14-4 - Only show and start the bluez-gnome bits in GNOME (#258721) boost-1.34.1-5.fc8 ------------------ * Wed Sep 19 2007 Benjamin Kosnik 1.34.1-5 - (#283771: Linking against boost libraries fails). claws-mail-plugins-3.0.0-2.fc8 ------------------------------ * Mon Sep 10 2007 Andreas Bierfert - 3.0.0-2 - fix typo compiz-fusion-0.5.2-6.fc8 ------------------------- * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 - Add animation to plugin list cups-1:1.3.2-1.fc8 ------------------ * Wed Sep 19 2007 Tim Waugh 1:1.3.2-1 - Include Till Kamppeter's dnssd backend. - 1.3.2. - No longer need str2512 patches. darcs-1.0.9-5.fc8 ----------------- * Thu Sep 20 2007 Jens Petersen - 1.0.9-5 - set selinux file-context for /usr/bin/darcs (reported by Jim Radford, #295351) digikam-0.9.2-5.fc8 ------------------- * Tue Sep 18 2007 Marcin Garski 0.9.2-5 - Rebuild * Wed Aug 29 2007 Rex Dieter 0.9.3-4 - License: GPLv2+ - lcms patch (kde bug #148930) * Wed Aug 29 2007 Fedora Release Engineering - 0.9.2-3 - Rebuild for selinux ppc32 issue. dkms-2.0.17.4-1.fc8 ------------------- * Wed Sep 19 2007 Matt Domsch 2.0.17.4 - upgrade to latest upstream * Wed Jun 20 2007 Matt Domsch 2.0.16.2 - updated for Ubuntu support, other bugfixes. * Tue Mar 20 2007 Matt Domsch 2.0.16.1 - spec file cleanups per re-review in Fedora - add bash completion, rpmbuild check, pinit, pass-arch patches from Mandriva. These are generic. The other Mandriva patches appear to be distro-specific. - Look for /etc/sysconfig/module-init-tools to get some values. eclipse-egit-0.2.99-0.git20070919.fc8 ------------------------------------- * Wed Sep 19 2007 Ben Konrath 0.2.99-0.git20070919.fc8 - 0.2.99 git20070919 em8300-kmod-0.16.3-5.2.6.23_0.187.rc6.git7.fc8 ---------------------------------------------- * Wed Sep 19 2007 Ville Skytt?? - Rebuild for kernel 2.6.23-0.187.rc6.git7.fc8. * Tue Sep 18 2007 Ville Skytt?? - Rebuild for kernel 2.6.23-0.186.rc6.git7.fc8. epiphany-extensions-2.20.0-1.fc8 -------------------------------- * Tue Sep 18 2007 Peter Gordon - 2.20.0-1 - Update to new upstream release (2.20.0). esound-1:0.2.38-5.fc8 --------------------- * Wed Sep 19 2007 Matthias Clasen - 1:0.2.38-5 - Don't spew confusing warnings to stdout evolution-2.12.0-3.fc8 ---------------------- * Wed Sep 19 2007 Matthew Barnes - 2.12.0-3.fc8 - Re-enable the inline audio plugin since it now uses GStreamer 0.10. * Wed Sep 19 2007 Matthew Barnes - 2.12.0-2.fc8 - Revise patch for GNOME bug #477045 (less-zealous icon renaming). * Mon Sep 17 2007 Matthew Barnes - 2.12.0-1.fc8 - Update to 2.12.0 - Remove patch for RH bug #182247 (fixed upstream). fedora-logos-7.92.4-1.fc8 ------------------------- * Wed Sep 19 2007 Matthias Clasen - 7.92.4-1 - Acutally install the gdm theme * Wed Sep 19 2007 Matthias Clasen - 7.92.3-1 - Add infinity gdm theme * Wed Sep 19 2007 Matthias Clasen - 7.92.2-1 - Add infinity lock dialog fslint-2.24-1.fc8 ----------------- * Wed Sep 19 2007 P??draig Brady

- 2.24-1 - Update to 2.24 galeon-2.0.3-12.fc8 ------------------- * Wed Sep 19 2007 Denis Leroy - 2.0.3-12 - Added patch to fix image load preference (#292361) - Added patch to fix print dialog crash (#285661) gdm-1:2.20.0-3.fc8 ------------------ * Wed Sep 19 2007 Matthias Clasen - 1:2.20.0-3 - Change default theme to FedoraInfinity * Wed Sep 19 2007 Matthias Clasen - 1:2.20.0-2 - Fix a hang on restart (#240853) glibc-2.6.90-15 --------------- * Thu Sep 20 2007 Jakub Jelinek 2.6.90-15 - $5$ (SHA-256) and $6$ (SHA-512) support in crypt (#228697, #249477, #173834) gmp-4.2.2-2.fc8 --------------- * Thu Sep 20 2007 Ivana Varekova 4.2.2-2 - fix check tag * Wed Sep 19 2007 Ivana Varekova 4.2.2-1 - update to 4.2.2 * Mon Aug 20 2007 Ivana Varekova 4.2.1-3 - spec file cleanup (#253439) gnash-0.8.1-4.fc8 ----------------- * Thu Sep 20 2007 Patrice Dumas 0.8.1-4 - omf/scrollkeeper doc is broken, remove it gnome-applets-1:2.20.0-2.fc8 ---------------------------- * Thu Sep 20 2007 - Bastien Nocera - 1:2.20.0-2 - Add patch to avoid the volume scale getting out-of sync with the real hardware volume gnome-media-2.20.0-2.fc8 ------------------------ * Wed Sep 19 2007 Matthias Clasen - 2.20.0-2 - Don't add extra categories to volume control, since upstream has moved it to Hardware (#295251) - Make icons show up again (#295171) gnome-themes-2.20.0-1.fc8 ------------------------- * Wed Sep 19 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 gnome-vfsmm26-2.20.0-1.fc8 -------------------------- * Mon Sep 17 2007 Denis Leroy - 2.20.0-1 - Update to new stable tree 2.20.0 gnomebaker-0.6.2-2.fc8 ---------------------- * Wed Sep 19 2007 Tomas Smetana - 0.6.2-2 - fix wrong genisoimage call when using cdrkit backend gnumeric-1:1.6.3-12.fc8 ----------------------- * Wed Sep 19 2007 Hans de Goede 1:1.6.3-12 - Replace GPL incompatible licensed md5 code with GPL compatible code from gnulib gphoto2-2.4.0-3.fc8 ------------------- * Tue Sep 18 2007 Jindrich Novy 2.4.0-3 - avoid tagging mass storage devices as cameras (#295051) - add missing BR popt-devel gsl-1.10-2.fc8 -------------- * Wed Sep 19 2007 Ivana Varekova - 1.10-2 - update license tag * Wed Sep 19 2007 Ivana Varekova - 1.10-1 - update to 1.10 - change license tag iptables-1.3.8-3.fc8 -------------------- * Wed Sep 19 2007 Thomas Woerner 1.3.8-3 - do not depend on local_fs in lsb header - this delayes start after network - fixed exit code for initscript usage jakarta-commons-daemon-1:1.0.1-6jpp.3.fc8 ----------------------------------------- * Mon Sep 17 2007 James Ralston - 1:1.0.1-6jpp.3 - update License tag to reflect new acceptable licenses - update main Group tag (old value "System/Boot" is invalid) - update jsvc Group tag as well - update javadoc Group tag as well - building jsvc is no longer mutually exclusive with building javadoc - jsvc is built by default (use "--without native" to disable) - build jsvc man page from DocBook source via xmlto; install - move jsvc from sbindir to bindir (man page is section 1) kanatest-0.4.4-3.fc8 -------------------- * Wed Sep 19 2007 Robert Marcano - 0.4.4-3 - Update to upstream release 0.4.4 kernel-2.6.23-0.189.rc6.git8.fc8 -------------------------------- * Thu Sep 20 2007 Dave Airlie - drm-mm-git.patch - pull in DRM git queue - nouveau-drm.patch - update nouveau patch on top of drm git queue * Wed Sep 19 2007 Chuck Ebbert - Linux 2.6.23-rc6-git8 - Enable Secure Computing (CONFIG_SECCOMP) (#295841) * Tue Sep 18 2007 Eric Sandeen - ext3 bugfixes: fix potential corruption in do_split dx leaf split (#28650), handle dx directory corruption gracefully, w/o BUG (#236464). - xfs bugfixes: setfattr/getfattr/getversion 32-bit compat fixes (#291981), log replay vs. filesize update fixes from sgi. kinput2-v3.1-35.fc8 ------------------- * Thu Sep 20 2007 Akira TAGOH - v3.1-35 - Add the versioned dependency for im-chooser. kipi-plugins-0.1.4-4.fc8 ------------------------ * Wed Sep 19 2007 Rex Dieter 0.1.4-4 - rebuild against libkdcraw libkexiv2 * Sat Aug 25 2007 Rex Dieter 0.1.4-3 - License: GPLv2+ libdhcp-1.27-3.fc8 ------------------ * Wed Sep 19 2007 David Cantrell - 1.27-3 - static package Requires libdhcp6client-static libdrm-2.3.0-7.fc8 ------------------ * Thu Sep 20 2007 Dave Airlie - 2.3.0-7 - Update nouveau patch. libgnomecanvasmm26-2.20.0-1.fc8 ------------------------------- * Mon Sep 17 2007 Denis Leroy - 2.20.0-1 - Update to new stable branch 2.20 libgnomemm26-2.20.0-1 --------------------- * Thu Sep 20 2007 Denis Leroy - 2.20.0-1 - Update to new stable branch 2.20 libgnomeui-2.20.0-1.fc8 ----------------------- * Wed Sep 19 2007 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 * Thu Aug 23 2007 Adam Jackson - 2.19.1-3 - Rebuild for ppc toolchain bug * Tue Aug 07 2007 Matthias Clasen - 2.19.1-2 - Update the license field libsndfile-1.0.17-2.fc8 ----------------------- * Thu Sep 20 2007 Andreas Thienemann - 1.0.17-2 - Adding FLAC support to libsndfile courtesy of gentoo, #237575 - Fixing CVE-2007-4974. Thanks to the gentoo people for the patch, #296221 libxml++-2.20.0-1.fc8 --------------------- * Thu Sep 20 2007 Denis Leroy - 2.20.0-1 - Update to new 2.20 stable branch lilypond-2.10.33-1.fc8 ---------------------- * Thu Sep 20 2007 Quentin Spencer 2.10.33-1 - New release. - Fix source URL. - Change licence from GPL to GPLv2. mkinitrd-6.0.17-1.fc8 --------------------- * Wed Sep 19 2007 Peter Jones - 6.0.17-1 - Fix missing quotes causing failure to detect erroneous "--with" command line arguments (#249163) - Use open64 in losetup so large files work (#220687) - Fix sysfs paths for fw-sbp2 (#231708) - Handle spaces in kernel command line better (#240785) - Fix handling of --omit-lvm-modules and --omit-dmraid mpfr-2.3.0-1.fc8 ---------------- nut-2.2.0-3.fc8 --------------- * Thu Sep 06 2007 Tomas Smetana 2.2.0-3 - fix wrong libssl flags in devel, fix devel package dependencies * Wed Aug 15 2007 Tomas Smetana 2.2.0-2 - fix #249028 - usb udev rules - update initscript and sysconfig file - fix calls to open() for compatibility with the new glibc * Fri Jul 13 2007 Tomas Smetana 2.2.0-1.1 - rebuild ocaml-libvirt-0.3.2.7-1.fc8 --------------------------- * Thu Sep 20 2007 Richard W.M. Jones - 0.3.2.7-1 - New upstream release 0.3.2.7. - Ship the upstream ChangeLog file. pam-0.99.8.1-8.fc8 ------------------ * Wed Sep 19 2007 Tomas Mraz 0.99.8.1-8 - add pam_selinux_permit module - pam_succeed_if: fix in operator (#295151) * Tue Sep 18 2007 Tomas Mraz 0.99.8.1-7 - when SELinux enabled always run the helper binary instead of direct shadow access (#293181) * Fri Aug 24 2007 Tomas Mraz 0.99.8.1-6 - do not ask for blank password when SELinux confined (#254044) - initialize homedirs in namespace init script (original patch by dwalsh) perl-Test-Inline-2.207-1.fc8 ---------------------------- * Wed Sep 19 2007 Ralf Cors??pius - 2.207-1 - Upstream update. - Disable AUTOMATED_TESTING. * Tue Aug 07 2007 Ralf Cors??pius - 2.205-1 - Upstream update. * Tue Jul 10 2007 Ralf Cors??pius - 2.202-1 - Upstream update. pgp-tools-0.4.12-1.fc8 ---------------------- * Wed Sep 19 2007 Matt Domsch 0.4.12-1 - upgrade to 0.4.12 - cleanup doc installation (BZ#246433) php-5.2.4-2 ----------- * Sun Sep 16 2007 Joe Orton 5.2.4-2 - update to 5.2.4 * Sun Sep 02 2007 Joe Orton 5.2.3-9 - rebuild for fixed APR * Tue Aug 28 2007 Joe Orton 5.2.3-8 - add ldconfig post/postun for -embedded (Hans de Goede) pm-utils-0.99.4-3.fc8 --------------------- * Thu Sep 20 2007 Till Maas - 0.99.4-3 - remove unused patch (vidhooks) - add patch to keep logfile (RH #237840 (f7), #238068 (devel)), to keep selinux context - simplify spec - restore selinux context of logfile in %post - use rpmmacros more often python-virtinst-0.300.0-4.fc8 ----------------------------- * Wed Sep 19 2007 Daniel P. Berrange - 0.300.0-4.fc8 - Fix post install CDROM config for KVM guests ragel-5.24-1.fc8 ---------------- * Tue Sep 18 2007 Jeremy Hinegardner - 5.24-1 - update to 5.24 - update License tag referencer-1.0.4-5.fc8 ---------------------- * Wed Sep 19 2007 Deji Akingunola - 1.0.4-5 - Patch to build against newer poppler library * Wed Sep 05 2007 Deji Akingunola - 1.0.4-4 - Rebuild against newer poppler library remind-03.01.02-2.fc8 --------------------- * Wed Sep 19 2007 Ray Van Dolson - 03.01.02-2 - Added tcllib requires per bz #290761 rlwrap-0.28-3.fc8 ----------------- scim-1.4.7-5.fc8 ---------------- * Thu Sep 20 2007 Jens Petersen - 1.4.7-5 - /etc/X11/xinit/xinput.d is now owned by im-chooser - no longer require xorg-x11-xinit * Tue Sep 18 2007 Jens Petersen - 1.4.7-4 - source none.conf in xinput script when skipping scim startup * Thu Sep 13 2007 Jens Petersen - 1.4.7-3 - add scim-1.4.7-ja-sinhala-236715.patch to add Japanese translation of Sinhala (#236715) - gtk2 now owns /usr/lib/gtk-2.0/immodules - add Nepali meta package - specify full paths in xinput script and use SHORT_DESC selinux-policy-3.0.8-3.fc8 -------------------------- * Wed Sep 19 2007 Dan Walsh 3.0.8-3 - Allow xserver to search devpts_t - Dontaudit ldconfig output to homedir svnkit-1.1.4-2.fc8 ------------------ * Thu Sep 20 2007 Robert Marcano - 1.1.4-2 - Fix Obsoletes to include javasvn = 1.1.0 system-config-boot-0.2.17-1.fc8 ------------------------------- * Thu Sep 20 2007 Harald Hoyer - 0.2.17-1 - translation update system-config-language-1.2.10-1.fc8 ----------------------------------- * Thu Sep 20 2007 Lingning Zhang - 1.2.10 - fix bug288851 and bug297461. - add the Nepali support. system-config-printer-0.7.74.2-1.fc8 ------------------------------------ * Wed Sep 19 2007 Tim Waugh 0.7.74.2-1 - Updated pycups to 1.9.27. - 0.7.74.2: - When a class is removed on the server, remove it from the UI. - When deleting a printer, select the default printer again. - Select newly-copied printer. - Updated translation (fi). - Better --help message. - Use strcoll to sort manufacturer names. - Avoid duplicate 'recommended' marks. - Remove duplicate device URIs. - Handle IPP_TAG_NOVALUE attributes (for CUPS 1.3.x). * Wed Sep 12 2007 Tim Waugh - Updated pycups to 1.9.26. - Build requires epydoc. Ship HTML documentation. telnet-1:0.17-40.fc8 -------------------- * Thu Sep 20 2007 Adam Tkac 1:0.17-40 - improved patch to #274991 texinfo-4.11-1.fc8 ------------------ * Wed Sep 19 2007 Vitezslav Crhonek - 4.11-1 - Rebase to upstream texinfo-4.11 (update zlib.patch, drop texindex.patch and 0xA0.patch -- both included in upstream) Resolves: #295441 tig-0.9-1.fc8 ------------- * Thu Sep 20 2007 James Bowes - 0.9-1 - tig-0.9 ttywatch-0.14-10.fc8 -------------------- * Wed Sep 19 2007 Matt Domsch 0.14-10 - add LSB initscript header (BZ#247080) - BR: popt-devel instead of popt now that it's split out udev-115-3.20070920git.fc8 -------------------------- * Thu Sep 20 2007 Harald Hoyer - 115-3 - some upstream fixes from git - removed last_rule for loop rules - added "udevinfo udevtrace" kernel command line options for better debugging uim-1.4.1-8.fc8 --------------- * Thu Sep 20 2007 Akira TAGOH - 1.4.1-8 - Add Requires: im-chooser and drop xorg-x11-xinit dependency. (#297231) - Correct License tag. (Todd Zullinger) util-vserver-0.30.214-2.fc8 --------------------------- * Wed Sep 19 2007 Enrico Scholz - 0.30.214-2 - fixed upgrade path from 0.30.213 to 0.30.214; rpm fails to handle when a directory becomes a symlink. Hence, remove the 'etch' directory in %pre uucp-1.07-16.fc8 ---------------- * Wed Sep 19 2007 Radek Brich 1.07-16 - updated license tag uw-imap-2006k-0.1.0709171900.fc8 -------------------------------- * Wed Sep 19 2007 Rex Dieter 2006k-0.1.0709171900 - imap-2006k.DEV.SNAP-0709171900 wdaemon-0.12-1.fc8 ------------------ * Wed Sep 19 2007 Aristeu Rozanski 0.12-1 - Updated to version 0.12 wireshark-0.99.6-3.fc8 ---------------------- * Wed Sep 19 2007 Radek Vok??l 0.99.6-3 - fixed URL xen-3.1.0-6.fc8 --------------- * Wed Sep 19 2007 Daniel P. Berrange - 3.1.0-6.fc8 - Don't clobber the VIF type attribute in FV guests (rhbz #296061) xine-lib-1.1.8-4.fc8 -------------------- * Wed Sep 19 2007 Ville Skytt?? - 1.1.8-4 - Fix "--without wavpack" build. * Sat Sep 15 2007 Ville Skytt?? - 1.1.8-3 - Move XCB plugins to the main package. - Make aalib, caca, pulseaudio, jack, and wavpack support optional at build time in preparation for the first EPEL build. xmlto-0.0.18-15 --------------- * Wed Sep 19 2007 Ondrej Vasik - 0.0.18-15 - fixed wrong source URL xorg-x11-drv-ati-6.7.193-1.fc8 ------------------------------ * Thu Sep 20 2007 Dave Airlie 6.7.193-1 - xf86-video-ati 6.7.193 xorg-x11-drv-nv-2.1.3-2.fc8 --------------------------- * Thu Sep 20 2007 Dave Airlie 2.1.3-2 - update nouveau Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE maniadrive - 1.2-2.fc8.i386 requires libphp5-5.2.3.so maniadrive-track-editor - 1.2-2.fc8.i386 requires libphp5-5.2.3.so moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.i386 requires libgmpxx.so.3 raydium - 1.2-2.fc8.i386 requires libphp5-5.2.3.so syck-php - 0.61-1.fc8.i386 requires php = 0:5.2.3 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 maniadrive - 1.2-2.fc8.x86_64 requires libphp5-5.2.3.so()(64bit) maniadrive-track-editor - 1.2-2.fc8.x86_64 requires libphp5-5.2.3.so()(64bit) moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) raydium - 1.2-2.fc8.x86_64 requires libphp5-5.2.3.so()(64bit) raydium - 1.2-2.fc8.i386 requires libphp5-5.2.3.so syck-php - 0.61-1.fc8.x86_64 requires php = 0:5.2.3 Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8smp maniadrive - 1.2-2.fc8.ppc requires libphp5-5.2.3.so maniadrive-track-editor - 1.2-2.fc8.ppc requires libphp5-5.2.3.so moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 ppl - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.ppc requires libgmpxx.so.3 python-vcpx - 0.9.28-4.fc8.noarch requires monotone raydium - 1.2-2.fc8.ppc64 requires libphp5-5.2.3.so()(64bit) raydium - 1.2-2.fc8.ppc requires libphp5-5.2.3.so syck-php - 0.61-1.fc8.ppc requires php = 0:5.2.3 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8kdump maniadrive - 1.2-2.fc8.ppc64 requires libphp5-5.2.3.so()(64bit) maniadrive-track-editor - 1.2-2.fc8.ppc64 requires libphp5-5.2.3.so()(64bit) moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) raydium - 1.2-2.fc8.ppc64 requires libphp5-5.2.3.so()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display syck-php - 0.61-1.fc8.ppc64 requires php = 0:5.2.3 xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From martin.sourada at seznam.cz Thu Sep 20 21:28:59 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 20 Sep 2007 23:28:59 +0200 Subject: xulrunner(-devel) file provides (.pc and .so files) Message-ID: <1190323739.19809.12.camel@pc-notebook> Hi, As was already noted in this list, current xulrunner-devel package miss some of the *.pc files firefox-devel package had. I played with it a little about a week ago and it seems that slight modification of the analogical files from firefox-devel package might solve the issue, unless the stuff that is being linked through this is broken, in which case it would help discover bugs, when apps building against it fails. Any thoughts? Another issue is rather a request. Could you symlink the xulrunner shared libraries into the /usr/lib folder and run ldconfig there? It would ease a lot the maintenance of packages that are built against it (which currently needs rebuild every time the xulrunner/firefox version changes, in vast majority of cases only because it changes location...). The files I have in mind are libmozjs.so, libsqlite3.so libxpcom.so and libxul.so. Comments? Thanks, Martin -------------- 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 walters at redhat.com Thu Sep 20 21:31:55 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 20 Sep 2007 17:31:55 -0400 Subject: xulrunner(-devel) file provides (.pc and .so files) In-Reply-To: <1190323739.19809.12.camel@pc-notebook> References: <1190323739.19809.12.camel@pc-notebook> Message-ID: On 9/20/07, Martin Sourada wrote: > Another issue is rather a request. Could you symlink the xulrunner > shared libraries into the /usr/lib folder and run ldconfig there? Let's try hard to make these changes upstream rather than specific to our spec file too. From katzj at redhat.com Thu Sep 20 21:39:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 17:39:33 -0400 Subject: xulrunner(-devel) file provides (.pc and .so files) In-Reply-To: <1190323739.19809.12.camel@pc-notebook> References: <1190323739.19809.12.camel@pc-notebook> Message-ID: <1190324373.4850.37.camel@localhost.localdomain> On Thu, 2007-09-20 at 23:28 +0200, Martin Sourada wrote: > The files I have in mind are libmozjs.so, libsqlite3.so libxpcom.so and > libxul.so. Comments? It'd be even better if the system sqlite library were used rather than an embedded copy... Jeremy From orion at cora.nwra.com Thu Sep 20 21:49:36 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 20 Sep 2007 15:49:36 -0600 Subject: Linking to libjava.so Message-ID: <46F2EAF0.8050003@cora.nwra.com> I'm trying to package up a java package for octave that links to libjava.so. Problem I'm having is that when octave tries to load the module at run time it can't find libjava.so. How should this be remedied? libjava.so is installed in: /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/i386/libjava.so -- 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 hughsient at gmail.com Thu Sep 20 17:00:54 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 Sep 2007 18:00:54 +0100 Subject: Odd failed dependency... In-Reply-To: <20070920105522.00ea2b62@reaver.lamontpeterson.net> References: <1190242447.2798.13.camel@hughsie-laptop> <1190298199.11114.2.camel@cyberelk.elk> <46F291F6.7020403@leemhuis.info> <20070920105522.00ea2b62@reaver.lamontpeterson.net> Message-ID: <1190307654.2933.9.camel@hughsie-laptop> On Thu, 2007-09-20 at 10:55 -0600, Lamont Peterson wrote: > > > It forks system-install-packages. It's used for installing print > > > drivers. > > > > I thought there was a "unwritten" policy to install (nearly?) all > > drivers for hardware by default to make sure people can just > configure > > hardware even in situations when they don't have a network > connection > > or a install CD at hand. Sure. So in this circumstance the printer driver installer could just issue a dbus method to PackageKit to install a package... That's what I needed to know, thanks. RIchard. From jamatos at fc.up.pt Thu Sep 20 22:24:54 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 20 Sep 2007 23:24:54 +0100 Subject: gsl - license change: GPLv3 In-Reply-To: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> Message-ID: <200709202324.55981.jamatos@fc.up.pt> On Thursday 20 September 2007 21:50:23 Build System wrote: > gsl-1.10-2.fc8 > -------------- > * Wed Sep 19 2007 Ivana Varekova - 1.10-2 > - update license tag > > * Wed Sep 19 2007 Ivana Varekova - 1.10-1 > - update to 1.10 > - change license tag FWIW, with this version gsl is now licensed under GPL version 3 (there are other licenses as specified in the spec file, but almost all the code falls under GPL). -- Jos? Ab?lio From dwmw2 at infradead.org Thu Sep 20 23:03:57 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Sep 2007 00:03:57 +0100 Subject: Some questions about Fedora In-Reply-To: <1190299042.27526.66.camel@localhost6.localdomain6> References: <20070920071108.GA2035@xanadu.blop.info> <1190292169.2142.43.camel@cutter> <20070920141448.GA8893@xanadu.blop.info> <1190299042.27526.66.camel@localhost6.localdomain6> Message-ID: <1190329437.31928.45.camel@pmac.infradead.org> On Thu, 2007-09-20 at 08:37 -0600, Richi Plana wrote: > Personally, if I can't find a repository with an RPM > package for software I want installed, I write my own spec file (with > the tools provided in the rpmdevtools package) and rpmbuild my own. I'd go a little further than that. If there's something I need which isn't in Fedora or Livna, then I'll consider packaging it myself and _putting_ it there. I wouldn't pull packages in from various other arbitrary repositories. Stuff that's in Livna has a good reason for not being in Fedora, and other than that, Livna is handled with the same packaging rules that Fedora is. I've never quite seen the reason for the existence of the other repositories, to be honest. Especially those which replace Fedora packages. Admittedly, I do it myself to a certain extent -- I have a private repository with slightly improved versions of evolution and openssh, and although I periodically attempt to get my patches upstream it's taking a very long time to get there. But I don't actually go out of my way to encourage other people to use my repository. -- dwmw2 From tibbs at math.uh.edu Thu Sep 20 23:51:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Sep 2007 18:51:01 -0500 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: <1190208110.7686.271.camel@localhost.localdomain> References: <46F05C41.7010708@codewiz.org> <20070919012611.GA21989@nostromo.devel.redhat.com> <46F0D947.8040202@codewiz.org> <1190208110.7686.271.camel@localhost.localdomain> Message-ID: Sorry to resurrect an old thread, but... >>>>> "AJ" == Adam Jackson writes: AJ> rpm -q --whatrequires chkfontpath AJ> no package requires chkfontpath Well, > repoquery --whatrequires chkfontpath libdockapp-fonts-0:0.6.1-3.fc8.i386 grace-0:5.1.21-2.fc8.i386 Are these bugs, perhaps? - J< From ndbecker2 at gmail.com Fri Sep 21 00:09:23 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Sep 2007 20:09:23 -0400 Subject: diff between Fedora + EPEL builds (python) Message-ID: I'm having trouble updating mecurial. I pushed an update to F-7 and devel. It doesn't build on EL-4 though. The problem seems to be, that python setup.py build/install creates .pyc/.pyo on F-7 and devel, but not on EL-4. Then, I get 'file not found by glob' for the missing files. I also tried %ghost on them, but EL-4 still complains they're missing. Anyone know what this is about and maybe how to fix it? I'd like to make mercurial for EL-4. From tibbs at math.uh.edu Fri Sep 21 00:18:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Sep 2007 19:18:01 -0500 Subject: CHKFONTPATH depends on xfs (Was: chkconfig depens on xfs) In-Reply-To: References: <46F05C41.7010708@codewiz.org> <20070919012611.GA21989@nostromo.devel.redhat.com> <46F0D947.8040202@codewiz.org> <1190208110.7686.271.camel@localhost.localdomain> Message-ID: Bah, someone broke threading and so the rest of the replies were further down. Please ignore me. - J< From darrellpf at gmail.com Fri Sep 21 00:40:12 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Thu, 20 Sep 2007 17:40:12 -0700 Subject: rawhide report: 20070920 changes In-Reply-To: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> Message-ID: > compiz-fusion-0.5.2-6.fc8 > ------------------------- > * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 > - Add animation to plugin list > Should compiz-fusion obsolete compiz? darrell From sundaram at fedoraproject.org Fri Sep 21 00:42:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 06:12:34 +0530 Subject: rawhide report: 20070920 changes In-Reply-To: References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> Message-ID: <46F3137A.1070909@fedoraproject.org> darrell pfeifer wrote: >> compiz-fusion-0.5.2-6.fc8 >> ------------------------- >> * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 >> - Add animation to plugin list >> > > Should compiz-fusion obsolete compiz? It should obsolete both compiz as well as beryl in fact. Rahul From katzj at redhat.com Fri Sep 21 00:58:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 20:58:55 -0400 Subject: rawhide report: 20070920 changes In-Reply-To: References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> Message-ID: <1190336335.4318.0.camel@localhost.localdomain> On Thu, 2007-09-20 at 17:40 -0700, darrell pfeifer wrote: > > compiz-fusion-0.5.2-6.fc8 > > ------------------------- > > * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 > > - Add animation to plugin list > > Should compiz-fusion obsolete compiz? Not at all -- in fact, it _requires_ compiz. compiz-fusion is additional plugins on top of the compiz core Jeremy From katzj at redhat.com Fri Sep 21 01:01:24 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Sep 2007 21:01:24 -0400 Subject: diff between Fedora + EPEL builds (python) In-Reply-To: References: Message-ID: <1190336484.4318.3.camel@localhost.localdomain> On Thu, 2007-09-20 at 20:09 -0400, Neal Becker wrote: > I'm having trouble updating mecurial. I pushed an update to F-7 and devel. > It doesn't build on EL-4 though. The problem seems to be, that python > setup.py build/install creates .pyc/.pyo on F-7 and devel, but not on > EL-4. Then, I get 'file not found by glob' for the missing files. I also > tried %ghost on them, but EL-4 still complains they're missing. Anyone > know what this is about and maybe how to fix it? I'd like to make > mercurial for EL-4. RHEL4 doesn't do automatic byte-compiling of .py files. You can change the invocation of the setup install to be -O2 instead of -O1 to get the .pyo files generated as well Jeremy From sundaram at fedoraproject.org Fri Sep 21 01:06:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 06:36:08 +0530 Subject: rawhide report: 20070920 changes In-Reply-To: <46F3137A.1070909@fedoraproject.org> References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> <46F3137A.1070909@fedoraproject.org> Message-ID: <46F31900.2030805@fedoraproject.org> Rahul Sundaram wrote: > darrell pfeifer wrote: >>> compiz-fusion-0.5.2-6.fc8 >>> ------------------------- >>> * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 >>> - Add animation to plugin list >>> >> >> Should compiz-fusion obsolete compiz? > > It should obsolete both compiz as well as beryl in fact. Ugh. Jeremy is correct. It should just obsolete beryl. I thought the core package is now called Compis fusion. Rahul From myfedora at richip.dhs.org Thu Sep 20 16:06:05 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 20 Sep 2007 10:06:05 -0600 Subject: mono Provides In-Reply-To: <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1190304365.31399.18.camel@localhost6.localdomain6> On Thu, 2007-09-20 at 17:15 +0200, Michael Schwendt wrote: > On Thu, 20 Sep 2007 06:57:40 -0600, Richi Plana wrote: > > > It's certainly not unheard of for different packages to provide the same > > implementation of an interface. In fact, we should probably start > > thinking of coming up for solutions for such a scenario. > > Technically, the different packages should only offer the same > implementation of an interface if they make it available in a public > place of the run-time environment where it is found by default by all > components which may require a given implementation. General examples > for such places are the dynamic linker's search paths for shared > libraries [1], Perl/Python module directories, and most likely similar > directories for Mono and other programming-language run-time > environments. If, however, they store the implementation in a private > directory, where it doesn't satisfy run-time requirements by default, > they should not advertise the implemented interface [via the RPM > system]. It bears the risk of breaking other packages like with this > Perl module example: http://bugzilla.redhat.com/247113 Storing resources in non-systemwide defaults CAN work assuming that the underlying selection system supports it. For example, Java implementations can be stored in various subdirectories, but must be activated with alternatives. Libraries can be stored in private subdirectories if the package updates all user processes LD_LIBRARY_PATH environment variables to include them. One advantage of the latter approach is that the dynamic loader will search all the paths in LD_LIBRARY_PATH for the needed library whereas alternatives uses just one. It would be nice if some kind of priority system could be adopted (conceptually by rearranging the paths in the variable). So I would agree with your statement with the slight modification that the package must actually enable said provisions system-wide. I think in Windows (I haven't used Windows in ages so I'm just guessing), some packages use the approach where the library directory is added to the library search path. If that's what's used in mono and the mono packages, then it's probably safe to allow the Provide:. Disclaimer: I don't actually use mono and am just guessing at the packages' implementation. There was a certain beauty and elegance to the /opt//(bin|lib) system of yore. Too bad it was abandoned rather than integrated/improved. -- Richi Plana From ndbecker2 at gmail.com Fri Sep 21 01:45:09 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 20 Sep 2007 21:45:09 -0400 Subject: diff between Fedora + EPEL builds (python) References: <1190336484.4318.3.camel@localhost.localdomain> Message-ID: Jeremy Katz wrote: > On Thu, 2007-09-20 at 20:09 -0400, Neal Becker wrote: >> I'm having trouble updating mecurial. I pushed an update to F-7 and >> devel. >> It doesn't build on EL-4 though. The problem seems to be, that python >> setup.py build/install creates .pyc/.pyo on F-7 and devel, but not on >> EL-4. Then, I get 'file not found by glob' for the missing files. I >> also >> tried %ghost on them, but EL-4 still complains they're missing. Anyone >> know what this is about and maybe how to fix it? I'd like to make >> mercurial for EL-4. > > RHEL4 doesn't do automatic byte-compiling of .py files. You can change > the invocation of the setup install to be -O2 instead of -O1 to get > the .pyo files generated as well > > Jeremy > Thanks - but still fails. Acutally, it doesn't generate .pyc or .pyo. Still not sure how to fix this. See: http://buildsys.fedoraproject.org/logs/fedora-4-epel/36416-mercurial-0.9.4-7.el4/i386/build.log From mattdm at mattdm.org Fri Sep 21 01:51:10 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 20 Sep 2007 21:51:10 -0400 Subject: c/ppc32 programming help wanted: calc ppc32 build bug Message-ID: <20070921015110.GA8159@jadzia.bu.edu> Since I don't have a ppc machine of my own, it's hard to track this down. I kind of suspect something is wrong in the "longbits.h" code, but it could be somewhere else entirely. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kevin at scrye.com Fri Sep 21 02:01:06 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 20 Sep 2007 20:01:06 -0600 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <20070921015110.GA8159@jadzia.bu.edu> References: <20070921015110.GA8159@jadzia.bu.edu> Message-ID: <20070920200106.33b75519@ghistelwchlohm.scrye.com> On Thu, 20 Sep 2007 21:51:10 -0400 mattdm at mattdm.org (Matthew Miller) wrote: > Since I don't have a ppc machine of my own, it's hard to track this > down. I kind of suspect something is wrong in the "longbits.h" code, > but it could be somewhere else entirely. > > Odd. Not sure whats going on there... I do however have a ppc32 machine. Email me a ssh key and I'd be happy to give you access so you can try and track this down. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sandeen at redhat.com Fri Sep 21 02:04:31 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 20 Sep 2007 21:04:31 -0500 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <20070921015110.GA8159@jadzia.bu.edu> References: <20070921015110.GA8159@jadzia.bu.edu> Message-ID: <46F326AF.3090903@redhat.com> Matthew Miller wrote: > Since I don't have a ppc machine of my own, it's hard to track this down. I > kind of suspect something is wrong in the "longbits.h" code, but it could be > somewhere else entirely. > > > > Looking at the preprocessed source might help? (gcc -E) -Eric From orion at cora.nwra.com Fri Sep 21 02:49:25 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 20 Sep 2007 20:49:25 -0600 (MDT) Subject: keyring primer? KDE? In-Reply-To: <1190186067.3904.151.camel@localhost.localdomain> References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <1190186067.3904.151.camel@localhost.localdomain> Message-ID: <1366.71.208.55.155.1190342965.squirrel@www.cora.nwra.com> > On Tue, 2007-09-18 at 20:10 -0400, Thomas J. Baker wrote: >> Seems gnome-keyring-pam is installed by default and according to the rpm >> info, it can unlock the "login" keyring on the gnome keyring. Problem I >> find so far is that nothing seems to use the "login" keyring. On one >> test desktop, Evolution uses the "default" keyring.of >> >> Anyone know how this is all supposed to work? Also I've seen references >> to gnome-keyring-manager being able to change the password of a keyring >> but the F8 version doesn't seem to have the option anywhere. > > http://live.gnome.org/GnomeKeyring/Pam > Anything for KDE and Kwallet? From dimitris at glezos.com Fri Sep 21 03:24:57 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Fri, 21 Sep 2007 04:24:57 +0100 Subject: [Long] Do we need a font SIG ? In-Reply-To: <46F337B2.9000104@redhat.com> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46F337B2.9000104@redhat.com> Message-ID: <1190345097.7976.33.camel@shuttle> ???? 20-09-2007, ????? ???, ??? ??? 23:17 -0400, ?/? M?ir?n Duffy ??????: > Nicolas Mailhot wrote: > > I created a mockup wiki page to try to make all this clear > > http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix > > It's far from complete, but I hope it's complete enough to give > > everyone an idea of the potential SIG scope. > > > > So, who wants to play? Is Fedora ready for a font SIG or should I ask > > again next year? > > I'm in! Let's not let this thread die! Who else is in? I'm definitely in. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From cjdahlin at ncsu.edu Fri Sep 21 03:39:49 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 20 Sep 2007 23:39:49 -0400 Subject: [RFC] /var versus /srv Message-ID: <46F33D05.4020701@ncsu.edu> Fedora has had the /srv directory in its default configuration for awhile now, and I think its high time we used it. Under the latest FHS specifications this is the correct place for /var/www and /var/ftp/pub and the like. Personally I think this is a long overdue change and its about time we followed through on it. Service-provided files are very much on the fringe of /var 's purpose (which tends to be application state info that requires extended persistence). The location was no doubt chosen since the media performance requirements tend to align (though after this shift the average /var partition could probably be substantially smaller). The counter argument is that we might well break some conventions associated with individual packages. On this end the individual maintainers will have to weigh in. httpd is a good choice for the first thing to move, since the current directory structure supporting it already deviate's widely from Apache's (horrifically awful) defaults. Thoughts? Comments? Flames? -C From jkeating at redhat.com Fri Sep 21 03:51:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 23:51:22 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F33D05.4020701@ncsu.edu> References: <46F33D05.4020701@ncsu.edu> Message-ID: <20070920235122.67ed5d19@localhost.localdomain> On Thu, 20 Sep 2007 23:39:49 -0400 Casey Dahlin wrote: > Thoughts? Comments? Flames? We talked about this in the Packaging Committee a while ago. The FHS docs are contradictory on the use of /srv, in that a vendor can't create any layout as the local admin has full rights to use whatever layout they want and we can't clobber it with our software. Therefor we leave /srv/ blank and let the sysadmin adjust configs if need be. However we /do/ have some apps that drop content in there, namely lighttpd and I think some torrent software. Someone from the Packaging team was going to engage the FHS on this matter, but I don't recall seeing any outcome of that. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sean.bruno at dsl-only.net Fri Sep 21 03:55:59 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 20 Sep 2007 20:55:59 -0700 Subject: dmraid triage Message-ID: <1190346959.4408.14.camel@home-desk> Is anyone doing dmraid breakage triage for test 2? If not, I'd like to help out. Sean From petersen at redhat.com Fri Sep 21 04:05:59 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 21 Sep 2007 14:05:59 +1000 Subject: [Long] Do we need a font SIG ? In-Reply-To: <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> Message-ID: <46F34327.5090506@redhat.com> I noticed there is already http://fedoraproject.org/wiki/Fonts. Should we create http://fedoraproject.org/wiki/SIGs/Fonts or use Fonts? -Jens From jreiser at BitWagon.com Fri Sep 21 04:07:50 2007 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 20 Sep 2007 21:07:50 -0700 Subject: [RFC] /var versus /srv In-Reply-To: <20070920235122.67ed5d19@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <20070920235122.67ed5d19@localhost.localdomain> Message-ID: <46F34396.5000508@BitWagon.com> > However we /do/ have some apps that drop content in there [/srv], namely > lighttpd and I think some torrent software. And pungi, and revisor. -- John Reiser, jreiser at BitWagon.com From sundaram at fedoraproject.org Fri Sep 21 04:22:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Sep 2007 09:52:26 +0530 Subject: [Long] Do we need a font SIG ? In-Reply-To: <46F34327.5090506@redhat.com> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> <46F34327.5090506@redhat.com> Message-ID: <46F34702.9020901@fedoraproject.org> Jens Petersen wrote: > I noticed there is already http://fedoraproject.org/wiki/Fonts. > > Should we create http://fedoraproject.org/wiki/SIGs/Fonts or use Fonts? The latter. Also list it in the root page. Rahul From petersen at redhat.com Fri Sep 21 04:32:51 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 21 Sep 2007 14:32:51 +1000 Subject: Fonts SIG In-Reply-To: <46F34702.9020901@fedoraproject.org> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> <46F34327.5090506@redhat.com> <46F34702.9020901@fedoraproject.org> Message-ID: <46F34973.4040608@redhat.com> Rahul Sundaram ????????: > Jens Petersen wrote: >> I noticed there is already http://fedoraproject.org/wiki/Fonts. >> Should we create http://fedoraproject.org/wiki/SIGs/Fonts or use Fonts? > > The latter. Also list it in the root page. Ok, I just asked since I noticed a lot of the other groups on the SIGs page also seem to be using root pages... but I agree since the Fonts SIGs is closely related to packaging and package collections. :) Thanks, Jens From j.w.r.degoede at hhs.nl Fri Sep 21 06:02:40 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Sep 2007 08:02:40 +0200 Subject: Linking to libjava.so In-Reply-To: <46F2EAF0.8050003@cora.nwra.com> References: <46F2EAF0.8050003@cora.nwra.com> Message-ID: <46F35E80.2020102@hhs.nl> Orion Poplawski wrote: > I'm trying to package up a java package for octave that links to > libjava.so. Problem I'm having is that when octave tries to load the > module at run time it can't find libjava.so. How should this be remedied? > > libjava.so is installed in: > > /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/i386/libjava.so > > Or preferably use /usr/lib/jvm/java/jre/lib/$JAVA_ARCH/libjava.so So that it will work with gcj too, I currently ise %ifarch's in my spec to set $JAVA_ARCH, as for example x86_64 is called amd64 in java terms. Regards, Hans From david at lovesunix.net Fri Sep 21 06:44:05 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 21 Sep 2007 08:44:05 +0200 Subject: dmraid triage In-Reply-To: <1190346959.4408.14.camel@home-desk> References: <1190346959.4408.14.camel@home-desk> Message-ID: <1190357045.3446.1.camel@dawkins> tor, 20 09 2007 kl. 20:55 -0700, skrev Sean Bruno: > Is anyone doing dmraid breakage triage for test 2? > > If not, I'd like to help out. If you can call it triaging to install on my dmraid then yes. I try to hit every test release to see if it blows up and I file day to day breakage. However the QA team always welcomes more testers. - David From ville.skytta at iki.fi Fri Sep 21 06:50:09 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 21 Sep 2007 09:50:09 +0300 Subject: [RFC] /var versus /srv In-Reply-To: <46F34396.5000508@BitWagon.com> References: <46F33D05.4020701@ncsu.edu> <20070920235122.67ed5d19@localhost.localdomain> <46F34396.5000508@BitWagon.com> Message-ID: <200709210950.09554.ville.skytta@iki.fi> On Friday 21 September 2007, John Reiser wrote: > > However we /do/ have some apps that drop content in there [/srv], namely > > lighttpd and I think some torrent software. > > And pungi, and revisor. And vdr. From pemboa at gmail.com Fri Sep 21 06:58:07 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Sep 2007 01:58:07 -0500 Subject: [RFC] /var versus /srv In-Reply-To: <46F33D05.4020701@ncsu.edu> References: <46F33D05.4020701@ncsu.edu> Message-ID: <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> On 9/20/07, Casey Dahlin wrote: > Fedora has had the /srv directory in its default configuration for > awhile now, and I think its high time we used it. Under the latest FHS > specifications this is the correct place for /var/www and /var/ftp/pub > and the like. > > Personally I think this is a long overdue change and its about time we > followed through on it. Service-provided files are very much on the > fringe of /var 's purpose (which tends to be application state info that > requires extended persistence). The location was no doubt chosen since > the media performance requirements tend to align (though after this > shift the average /var partition could probably be substantially smaller). I use it on my CentOS box for files i server via subversion or http+smb. It seems like an ideal location for what is currently /var/www and /var/ftp -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rc040203 at freenet.de Fri Sep 21 07:39:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Sep 2007 09:39:23 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> Message-ID: <1190360363.31022.114.camel@mccallum.corsepiu.local> On Fri, 2007-09-21 at 01:58 -0500, Arthur Pemberton wrote: > On 9/20/07, Casey Dahlin wrote: > > Fedora has had the /srv directory in its default configuration for > > awhile now, and I think its high time we used it. Under the latest FHS > > specifications this is the correct place for /var/www and /var/ftp/pub > > and the like. > > > > Personally I think this is a long overdue change and its about time we > > followed through on it. Service-provided files are very much on the > > fringe of /var 's purpose (which tends to be application state info that > > requires extended persistence). The location was no doubt chosen since > > the media performance requirements tend to align (though after this > > shift the average /var partition could probably be substantially smaller). > > > I use it on my CentOS box for files i server via subversion or > http+smb. It seems like an ideal location for what is currently > /var/www and /var/ftp This is what other distros use /var for. Nevertheless the answers others had provided also are correct. The FHS is ambivalent. /me thinks, FPC is overinterpreting the FHS due to lack of familiarity with exiting practice on other distros. Ralf From mschwendt.tmp0701.nospam at arcor.de Fri Sep 21 08:14:47 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Sep 2007 10:14:47 +0200 Subject: soname Provides In-Reply-To: <1190304365.31399.18.camel@localhost6.localdomain6> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> <1190304365.31399.18.camel@localhost6.localdomain6> Message-ID: <20070921101447.27f323d9.mschwendt.tmp0701.nospam@arcor.de> On Thu, 20 Sep 2007 10:06:05 -0600, Richi Plana wrote: > Storing resources in non-systemwide defaults CAN work assuming that the > underlying selection system supports it. For example, Java > implementations can be stored in various subdirectories, but must be > activated with alternatives. Libraries can be stored in private > subdirectories if the package updates all user processes LD_LIBRARY_PATH > environment variables to include them. One advantage of the latter > approach is that the dynamic loader will search all the paths in > LD_LIBRARY_PATH for the needed library whereas alternatives uses just > one. It would be nice if some kind of priority system could be adopted > (conceptually by rearranging the paths in the variable). And then you end up with competing implementations of the same library interface. One with vulnerabilities, the other one with security-fixes. One with customisations and several minor releases behind, the other the latest release with bug-fixes. One built with a complete feature set, the other stripped down to upstream defaults. RPM dependencies would need to get much more complex if to cover such differences in implementations. That's not something I'd like to see, at least not for system libraries. Using /etc/ld.so.conf.d/ (not LD_LIBRARY_PATH, which is empty by default btw) already is dangerous enough, since it can be used to avoid file conflicts and still insert competing libs into run-time linker's view. Further, there's no difference between "Provides" of libs in private paths and system-wide paths. It's too easy to disable/move the private paths and pull away the libs from the run-time env. > So I would agree with your statement with the slight modification that > the package must actually enable said provisions system-wide. Only then it may announce itself as being a provider of "something". From darrellpf at gmail.com Fri Sep 21 00:54:37 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Thu, 20 Sep 2007 17:54:37 -0700 Subject: rawhide report: 20070920 changes In-Reply-To: <46F3137A.1070909@fedoraproject.org> References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> <46F3137A.1070909@fedoraproject.org> Message-ID: On 9/20/07, Rahul Sundaram wrote: > darrell pfeifer wrote: > >> compiz-fusion-0.5.2-6.fc8 > >> ------------------------- > >> * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 > >> - Add animation to plugin list > >> > > > > Should compiz-fusion obsolete compiz? > > It should obsolete both compiz as well as beryl in fact. > > Rahul I should have been a bit more explanatory. I had compiz installed. Just yum installed compiz-fusion and compiz wasn't removed. Now rpm -qa shows both. So yes, glad to hear that my suspicion was correct. darrell From dwmw2 at infradead.org Fri Sep 21 09:26:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Sep 2007 10:26:17 +0100 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <46F326AF.3090903@redhat.com> References: <20070921015110.GA8159@jadzia.bu.edu> <46F326AF.3090903@redhat.com> Message-ID: <1190366777.7150.12.camel@pmac.infradead.org> On Thu, 2007-09-20 at 21:04 -0500, Eric Sandeen wrote: > Matthew Miller wrote: > > Since I don't have a ppc machine of my own, it's hard to track this down. I > > kind of suspect something is wrong in the "longbits.h" code, but it could be > > somewhere else entirely. > > > > > > > > > > Looking at the preprocessed source might help? (gcc -E) No, it just makes your eyes bleed. I have no idea what's going on here, or why it might have built on other systems -- it looks horridly broken. It seems to be trying to treat the fpos_t data type (which is an opaque structure and must be accessed with fgetpos()) as if it was a scalar integer, along the lines of: unsigned long foo; fpos_t bar; foo = bar; If that builds on i386, I have no clue why. And I also have no clue what all this SWAP_HALF_IN_FOO() is all about, either. I'll keep poking at it, for as long as I can stand before I have to kill myself. But first, let's start by fixing this unrelated (unless it was done while smoking the same batch of crack) gem... --- endian.c~ 2007-09-01 23:01:25.000000000 +0100 +++ endian.c 2007-09-21 10:06:05.000000000 +0100 @@ -53,10 +53,8 @@ char byte[8] = { (char)0x12, (char)0x36, int main(void) { -#if !defined(LITTLE_ENDIAN) && !defined(BIG_ENDIAN) /* pointers into the byte order array */ int *intp = (int *)byte; -#endif #if defined(DEBUG) short *shortp = (short *)byte; long *longp = (long *)byte; @@ -76,11 +74,17 @@ main(void) printf("#define BIG_ENDIAN\t4321\n"); printf("#define LITTLE_ENDIAN\t1234\n"); + /* Yes. We _know_ they're the standard endian.h defines. + They're both going to be defined. + Always. + So what, for the love of $DEITY, made anyone think + _this_ was a good idea.... #if defined(LITTLE_ENDIAN) printf("#define CALC_BYTE_ORDER\tLITTLE_ENDIAN\n"); #elif defined(BIG_ENDIAN) printf("#define CALC_BYTE_ORDER\tBIG_ENDIAN\n"); #else + */ /* Determine byte order */ if (intp[0] == 0x12364859) { /* Most Significant Byte first */ @@ -93,7 +97,7 @@ main(void) "Unknown int Byte Order, set CALC_BYTE_ORDER in Makefile\n"); exit(1); } -#endif +//#endif /* exit(0); */ return 0; } -- dwmw2 From alexl at redhat.com Fri Sep 21 09:30:25 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 21 Sep 2007 11:30:25 +0200 Subject: mono Provides In-Reply-To: <1190293060.27526.35.camel@localhost6.localdomain6> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> Message-ID: <1190367025.11057.53.camel@localhost.localdomain> On Thu, 2007-09-20 at 06:57 -0600, Richi Plana wrote: > On Thu, 2007-09-20 at 09:11 +0200, Alexander Larsson wrote: > > On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote: > > > Is it intentional and safe for these packages to provide these Mono > > > capabilities? Are the pairs of packages, which provide exactly the > > > same things, interchangable at run-time? You know what can happen when > > > Yum resolves a dependency by pulling in the pkg with the shortest > > > name... > > > > I guess this is because some mono app ship dlls instead of depending on > > system versions of them? > > > > Ideally we shouldn't do this, but i'm sure there are cases where its not > > possible to avoid. Maybe the mono auto-provides should only be looking > > in the public directories for dlls to auto-provide? > > It's certainly not unheard of for different packages to provide the same > implementation of an interface. In fact, we should probably start > thinking of coming up for solutions for such a scenario. The > alternatives system is an example. Multiple implementations should be > allowed to co-exist on the system. Luckily mono seems to have a way to > choose which DLL it wants to use (probably first in the GAC or > whatever). The question is _"How should this be treated in package > management?"_ (which is Fedora's concern). I'm not sure these packages *actually* provide the things they say they do though. (Although I haven't looked at it.) I think they keep local per-app versions of some dlls in non-public directories. This means other apps will never pick up these dlls. However, the auto-provides finds them and marks the rpm. From alan at redhat.com Fri Sep 21 09:37:46 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 21 Sep 2007 05:37:46 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F33D05.4020701@ncsu.edu> References: <46F33D05.4020701@ncsu.edu> Message-ID: <20070921093746.GB5037@devserv.devel.redhat.com> On Thu, Sep 20, 2007 at 11:39:49PM -0400, Casey Dahlin wrote: > Fedora has had the /srv directory in its default configuration for > awhile now, and I think its high time we used it. Under the latest FHS > specifications this is the correct place for /var/www and /var/ftp/pub > and the like. I disagree. It is also impossible for a distribution to use /srv for anything because "Distributions must take care not to remove locally placed files in these directories without administrator permission." Which would cause updates to fail. Very simply "/srv" is a mistake in the FHS spec and treated as that by pretty much everyone on the planet. From nicolas.mailhot at laposte.net Fri Sep 21 09:48:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 11:48:48 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190360363.31022.114.camel@mccallum.corsepiu.local> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> Message-ID: <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 09:39, Ralf Corsepius a ?crit : > On Fri, 2007-09-21 at 01:58 -0500, Arthur Pemberton wrote: >> I use it on my CentOS box for files i server via subversion or >> http+smb. It seems like an ideal location for what is currently >> /var/www and /var/ftp > This is what other distros use /var for. And the FHS clearly states creating new /var roots is a no-go, so /var is a dead-end for new protocol/serving needs (like bittorent) > Nevertheless the answers others had provided also are correct. The FHS > is ambivalent. As usual the FHS tries to catter to everyone by not closing the door on existing non-streamlined practices. IMHO interested people @fedora should just agree on a new clean all-encompassing /srv layout, and get it stamped at FHS (keeping in mind the FHS will still allow older practices, which is ok as long as there is a good preferred layout in the standard) /srv being: any variable data which primary purpose is being exposed to other systems via a network interface (can include webapp variable data) > /me thinks, FPC is overinterpreting the FHS due to lack of familiarity > with exiting practice on other distros. /me thinks the FHS is intentionaly written in such a way it can be interpreted at minima by laggards, but we should not block needed changes just because there are escape clauses in the FHS. -- Nicolas Mailhot From dwmw2 at infradead.org Fri Sep 21 09:49:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Sep 2007 10:49:29 +0100 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <1190366777.7150.12.camel@pmac.infradead.org> References: <20070921015110.GA8159@jadzia.bu.edu> <46F326AF.3090903@redhat.com> <1190366777.7150.12.camel@pmac.infradead.org> Message-ID: <1190368169.7150.15.camel@pmac.infradead.org> On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote: > which is an opaque structure and must be accessed with fgetpos()) As the first cup of tea of the morning takes effect I realise that bit's nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque type. I just don't know how to deal with it. I hate userspace. -- dwmw2 From alan at redhat.com Fri Sep 21 10:08:59 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 21 Sep 2007 06:08:59 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> Message-ID: <20070921100859.GA6032@devserv.devel.redhat.com> On Fri, Sep 21, 2007 at 11:48:48AM +0200, Nicolas Mailhot wrote: > And the FHS clearly states creating new /var roots is a no-go, so /var > is a dead-end for new protocol/serving needs (like bittorent) And nobody cares because the FHS is broken > As usual the FHS tries to catter to everyone by not closing the door > on existing non-streamlined practices. IMHO interested people @fedora No. What happened is that the FHS put things to a vote. Unfortunately the FHS towards the end of its existance contained more random people who had no clue about distribution building and software management than distro people so the wrong side won. The people who mattered and actually do know what they are doing therefore considered parts of the FHS silly and ignored them. > /srv being: any variable data which primary purpose is being exposed > to other systems via a network interface (can include webapp variable > data) That clashes with /home in many cases. The right answer is to delete /srv (or obsolete it) and remove the silly statements about /var (which mostly exist to try and force the /srv stupidity into being) From buc at odusz.so-cdu.ru Fri Sep 21 10:51:31 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 21 Sep 2007 14:51:31 +0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921100859.GA6032@devserv.devel.redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> Message-ID: <46F3A233.2010107@odu.neva.ru> Alan Cox wrote: > No. What happened is that the FHS put things to a vote. Unfortunately > the FHS towards the end of its existance contained more random people who > had no clue about distribution building and software management than distro > people so the wrong side won. > > The people who mattered and actually do know what they are doing therefore > considered parts of the FHS silly and ignored them. > +1 ~buc From johannbg at hi.is Fri Sep 21 11:18:13 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 21 Sep 2007 11:18:13 +0000 Subject: Possible RFE for what packages ( rpm -qa ) are include in live cd. Message-ID: <46F3A875.10602@hi.is> Maybe it's there somewhere but I surfed and searched and didnt find it... If not RFE for... Package list in live cd releases made availible on "http://fedoraproject.org/wiki/FedoraLiveCD" "Included in this release" --> complete package list Needles to say why... Oh by the way the whole image release process.. are the images updated after x time ( week(s)/month ) which then have "latest fixes"... Best regards.. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From denis at poolshark.org Fri Sep 21 11:24:44 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 21 Sep 2007 13:24:44 +0200 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <1190368169.7150.15.camel@pmac.infradead.org> References: <20070921015110.GA8159@jadzia.bu.edu> <46F326AF.3090903@redhat.com> <1190366777.7150.12.camel@pmac.infradead.org> <1190368169.7150.15.camel@pmac.infradead.org> Message-ID: <46F3A9FC.9010400@poolshark.org> David Woodhouse wrote: > On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote: >> which is an opaque structure and must be accessed with fgetpos()) > > As the first cup of tea of the morning takes effect I realise that bit's > nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque > type. I just don't know how to deal with it. > > I hate userspace. Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() instead of fseek(),ftell(), but the code that tries to autodetect the size of fpos_t is broken. Looks like the easiest solution is to force it to use fseek(), ftell() with -DHAVE_NO_FPOS. The code compiles with this, but I still get a linking error at the end of rpmbuild: collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: warning: powerpc:common64 architecture of input file `addop.o' is incompatible with powerpc:common output From dwmw2 at infradead.org Fri Sep 21 11:32:32 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Sep 2007 12:32:32 +0100 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <46F3A9FC.9010400@poolshark.org> References: <20070921015110.GA8159@jadzia.bu.edu> <46F326AF.3090903@redhat.com> <1190366777.7150.12.camel@pmac.infradead.org> <1190368169.7150.15.camel@pmac.infradead.org> <46F3A9FC.9010400@poolshark.org> Message-ID: <1190374352.7150.35.camel@pmac.infradead.org> On Fri, 2007-09-21 at 13:24 +0200, Denis Leroy wrote: > David Woodhouse wrote: > > On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote: > >> which is an opaque structure and must be accessed with fgetpos()) > > > > As the first cup of tea of the morning takes effect I realise that bit's > > nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque > > type. I just don't know how to deal with it. > > > > I hate userspace. > > Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() > instead of fseek(),ftell(), but the code that tries to autodetect the > size of fpos_t is broken. > > Looks like the easiest solution is to force it to use fseek(), ftell() > with -DHAVE_NO_FPOS. > > The code compiles with this, but I still get a linking error at the end > of rpmbuild: > > collect2: ld terminated with signal 11 [Segmentation fault] > /usr/bin/ld: warning: powerpc:common64 architecture of input file > `addop.o' is incompatible with powerpc:common output It works here. Use 'ppc make ppc' to build 32-bit packages from CVS, not just 'make ppc'. Autocrap tends to get confused otherwise, and you end up mixing 64-bit and 32-bit objects. Not that this really excuses a SEGV from the linker -- can you show exactly what you did to provoke that? -- dwmw2 From denis at poolshark.org Fri Sep 21 11:37:52 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 21 Sep 2007 13:37:52 +0200 Subject: c/ppc32 programming help wanted: calc ppc32 build bug In-Reply-To: <1190374352.7150.35.camel@pmac.infradead.org> References: <20070921015110.GA8159@jadzia.bu.edu> <46F326AF.3090903@redhat.com> <1190366777.7150.12.camel@pmac.infradead.org> <1190368169.7150.15.camel@pmac.infradead.org> <46F3A9FC.9010400@poolshark.org> <1190374352.7150.35.camel@pmac.infradead.org> Message-ID: <46F3AD10.3070107@poolshark.org> David Woodhouse wrote: > On Fri, 2007-09-21 at 13:24 +0200, Denis Leroy wrote: >> David Woodhouse wrote: >>> On Fri, 2007-09-21 at 10:26 +0100, David Woodhouse wrote: >>>> which is an opaque structure and must be accessed with fgetpos()) >>> As the first cup of tea of the morning takes effect I realise that bit's >>> nonsense, but the rest seems still vaguely relevant -- it _is_ an opaque >>> type. I just don't know how to deal with it. >>> >>> I hate userspace. >> Just updated the bugzilla. It's trying to use fgetpos(),fsetpos() >> instead of fseek(),ftell(), but the code that tries to autodetect the >> size of fpos_t is broken. >> >> Looks like the easiest solution is to force it to use fseek(), ftell() >> with -DHAVE_NO_FPOS. >> >> The code compiles with this, but I still get a linking error at the end >> of rpmbuild: >> >> collect2: ld terminated with signal 11 [Segmentation fault] >> /usr/bin/ld: warning: powerpc:common64 architecture of input file >> `addop.o' is incompatible with powerpc:common output > > It works here. Use 'ppc make ppc' to build 32-bit packages from CVS, not > just 'make ppc'. Autocrap tends to get confused otherwise, and you end > up mixing 64-bit and 32-bit objects. Not that this really excuses a SEGV > from the linker -- can you show exactly what you did to provoke that? I just did a rpmbuild -bb calc.spec, from the F-7 SRPM currently in CVS. The only change to the spec file os the -DHAVE_NO_FPOS above. From nicolas.mailhot at laposte.net Fri Sep 21 11:55:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 13:55:33 +0200 (CEST) Subject: Fonts SIG In-Reply-To: <46F34973.4040608@redhat.com> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> <46F34327.5090506@redhat.com> <46F34702.9020901@fedoraproject.org> <46F34973.4040608@redhat.com> Message-ID: <41111.192.54.193.51.1190375733.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 06:32, Jens Petersen a ?crit : > Rahul Sundaram ????????: >> Jens Petersen wrote: >>> I noticed there is already http://fedoraproject.org/wiki/Fonts. >>> Should we create http://fedoraproject.org/wiki/SIGs/Fonts or use >>> Fonts? >> >> The latter. Also list it in the root page. > > Ok, I just asked since I noticed a lot of the other groups on the SIGs > page also seem to be using root pages... but I agree since the Fonts > SIGs is closely related to packaging and package collections. :) I guess that means the font SIG is a go, and I'll work on it tomorrow. Can we squat one of the existing fedora irc channels to coordinate, or should a new one be created ? (alternatively ##fonts is low traffic and used by other floss font groups) -- Nicolas Mailhot From chitlesh at fedoraproject.org Thu Sep 20 14:40:40 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 20 Sep 2007 16:40:40 +0200 Subject: lvm issues with rawhide Message-ID: <13dbfe4f0709200740p3c2d74c4ta1b6b122dd2c78ab@mail.gmail.com> Hello there, yesterday I spinned a FEL live image based on rawhide. During the installation from the live image, just before formatting HDD liveinst spits the following exception: http://chitlesh.fedorapeople.org/FEL/lvmcrash.txt The rpms installed are listed here: http://chitlesh.fedorapeople.org/FEL/rpmlist Thus before the exception occurs the KDE pops a dialog to mount /boot. Any idea how to disable this at the same time, allowing the dialog if one plugs a USB stick ? Once the exception occurs, there is no other way to use the HDD again other than reformatting the hdd with a F7 KDE live cd. Also any idea when the Avahi service failure will be corrected ? regards, Chitlesh PS: I may not reply to this email till monday. -- http://clunixchit.blogspot.com From che666 at gmail.com Thu Sep 20 07:11:44 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Sep 2007 09:11:44 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F1CE96.7070308@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> Message-ID: 2007/9/20, David Boles : > on 9/19/2007 6:09 PM, ? wrote: > >> on 9/19/2007 4:29 PM, Matthias Clasen wrote: > >>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote: > >>>> Matthias Clasen redhat.com> writes: > >>>>> Yeah, but then you don't walk away from your root session expecting > >>>>> the > >>>>> screensaver to kick in - which it doesn't for root. > >>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop > >>>> locking > >>>> for root work just fine in KDE. > >>> And I assume that KDE users are just happy to run tons of unaudited > >>> toolkit code as root... > >>> > >>> Anyway, its a moot point, we'll re-enable root login for test3. > >> > >> I have watched this thread since the beginning and I can no longer keep my > >> peace. > >> > >> A knowledgeable Linux user would know how to change this default. Or > >> figure out how to change. I know how and I am certainly not on the level > >> of many here. > >> > > > > True so he know he can simply F1 and take it from there... > > > >> A 'not so knowledgeable Linux user' would use the 'enter Roots password' > >> windows to preform these tasks. > >> > > > > And if the user manage to shoot himself in the foot so he cant login > > using his username and password how is he gonna manage to get to his > > "enter the root password dialog".... > > > >> Any user that can not do either of these things *does not* have any > >> business logging in as root in a GUI. Period. > > > > Wrong he has a fighting chance to save himself log into familiar > > surroundings fix the situation with S-C-* tools, learn from his mistake > > instead of have to do clean install or bother advanced users given that they > > are some where around him. > > > > The alternitive "dropping him to terminal window" were he would be dead in > > the water... > > > >> Or do you want Fedora 8 to be like Windows? > > > > No... > > > >> Where 'run as root' is the > >> default for the 'not so knowledgeable Windows user'? > > > > Last time I used M$ windows it made dam sure that the user could harm > > the system ( windows it self ) and question every other move he did.. > > > > Maybe Windows is actually trusting user today but I doubt it... > > > >> You want them to be > >> able to shoot themselves in the foot? > > > > Yes. the users will learn from there mistakes, adopt,evolve and move on.. > > > > Let's place the trust on the user always. > > > >> I hope not. > >> > >> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about > >> it first. More than downloading an ISO and burning it it Windows. > > > > Nope get the user first into linux as hazle free and comfortable as > > possible... > > > >>From there he will start using, playing, fiddle around *expanding his > > knowledge about linux. etc.. > > > Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and > the so many other Windows games you will get a *lot* of 'new Linux users' > from Windows. Just as ignorant as you are looking for here. well please do your homework: http://appdb.winehq.com sof even has a native linux port. regards, Rudolf Kastl > > I give up. Logical thinking does not work when dealing with zealots. But I > still think that you are wrong. No default GUI root logins. > > > -- > > David > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From mattdm at mattdm.org Fri Sep 21 12:59:49 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Sep 2007 08:59:49 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921100859.GA6032@devserv.devel.redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> Message-ID: <20070921125949.GA25572@jadzia.bu.edu> On Fri, Sep 21, 2007 at 06:08:59AM -0400, Alan Cox wrote: > No. What happened is that the FHS put things to a vote. Unfortunately > the FHS towards the end of its existance contained more random people who > had no clue about distribution building and software management than distro > people so the wrong side won. > The people who mattered and actually do know what they are doing therefore > considered parts of the FHS silly and ignored them. Well, so much for rational discourse. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Sep 21 13:11:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 09:11:10 -0400 Subject: rawhide report: 20070920 changes In-Reply-To: References: <200709202050.l8KKoNsS023042@porkchop.devel.redhat.com> <46F3137A.1070909@fedoraproject.org> Message-ID: <20070921091110.50190d6a@localhost.localdomain> On Thu, 20 Sep 2007 17:54:37 -0700 "darrell pfeifer" wrote: > I should have been a bit more explanatory. > > I had compiz installed. Just yum installed compiz-fusion and compiz > wasn't removed. Now rpm -qa shows both. > > So yes, glad to hear that my suspicion was correct. Actually it's not. compiz-fusion adds more plugins to the base compiz. They go hand in hand. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Sep 21 13:13:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 09:13:29 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F34396.5000508@BitWagon.com> References: <46F33D05.4020701@ncsu.edu> <20070920235122.67ed5d19@localhost.localdomain> <46F34396.5000508@BitWagon.com> Message-ID: <20070921091329.730f00ac@localhost.localdomain> On Thu, 20 Sep 2007 21:07:50 -0700 John Reiser wrote: > And pungi, and revisor. Pungi does not actually create any files in /srv. The configs default to your local directory, the cache is in /var/cache/pungi. I personally use /srv/pungi for a lot of output, and some of that leaked into earlier versions of pungi but was since fixed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Fri Sep 21 13:19:43 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Sep 2007 09:19:43 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921100859.GA6032@devserv.devel.redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> Message-ID: <1190380783.2142.52.camel@cutter> On Fri, 2007-09-21 at 06:08 -0400, Alan Cox wrote: > On Fri, Sep 21, 2007 at 11:48:48AM +0200, Nicolas Mailhot wrote: > > And the FHS clearly states creating new /var roots is a no-go, so /var > > is a dead-end for new protocol/serving needs (like bittorent) > > And nobody cares because the FHS is broken > > > As usual the FHS tries to catter to everyone by not closing the door > > on existing non-streamlined practices. IMHO interested people @fedora > > No. What happened is that the FHS put things to a vote. Unfortunately > the FHS towards the end of its existance contained more random people who > had no clue about distribution building and software management than distro > people so the wrong side won. > > The people who mattered and actually do know what they are doing therefore > considered parts of the FHS silly and ignored them. > > > /srv being: any variable data which primary purpose is being exposed > > to other systems via a network interface (can include webapp variable > > data) > > That clashes with /home in many cases. > > The right answer is to delete /srv (or obsolete it) and remove the silly > statements about /var (which mostly exist to try and force the /srv > stupidity into being) As a sysadmin /srv is a useful thing - it's what most sysadmins do anyway - create a top level path where they mount the large, local disks and put all their data. So they know on every system if they hit /etc and /srv with the backups they'll have what they should be worried about. All admins may not call it /srv but they do something like it: /fs, /local, /data, /srv it's all the same result. so while your argument for not using it in the distro is fine -the reality is that this is what is actually done by sysadmins all over the world. -sv From jkeating at redhat.com Fri Sep 21 13:39:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 09:39:24 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190380783.2142.52.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> Message-ID: <20070921093924.123e483b@localhost.localdomain> On Fri, 21 Sep 2007 09:19:43 -0400 seth vidal wrote: > so while your argument for not using it in the distro is fine -the > reality is that this is what is actually done by sysadmins all over > the world. In fact, that evidence makes it even /more/ important that we as a distro don't put anything in /srv/ that would disrupt what a local admin may be using it for. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Fri Sep 21 13:51:55 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Sep 2007 09:51:55 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921093924.123e483b@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> Message-ID: <1190382715.2142.56.camel@cutter> On Fri, 2007-09-21 at 09:39 -0400, Jesse Keating wrote: > On Fri, 21 Sep 2007 09:19:43 -0400 > seth vidal wrote: > > > so while your argument for not using it in the distro is fine -the > > reality is that this is what is actually done by sysadmins all over > > the world. > > In fact, that evidence makes it even /more/ important that we as a > distro don't put anything in /srv/ that would disrupt what a local > admin may be using it for. that's fine by me - but I don't think removing /srv from filesystem pkg makes any sense. -sv From jkeating at redhat.com Fri Sep 21 13:56:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 09:56:01 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190382715.2142.56.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> Message-ID: <20070921095601.035cc74d@localhost.localdomain> On Fri, 21 Sep 2007 09:51:55 -0400 seth vidal wrote: > that's fine by me - but I don't think removing /srv from filesystem > pkg makes any sense. Doesn't make sense to me either, I hope I didn't sound otherwise. +1 to keeping /srv -1 to allowing any package to put any content in /srv -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at redhat.com Fri Sep 21 14:00:18 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 21 Sep 2007 16:00:18 +0200 Subject: Does anyone have gnome-keyring problems? Message-ID: <1190383219.11057.87.camel@localhost.localdomain> The new gnome-keyring has a small change in behaviour. When you look for a key that doesn't exist it used to return a DENIED error. This is somewhat wrong (as it seems to indicate that there is a permissions error). This was changed to return OK, with a list of zero hits. Bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=298871 This caused problems for at least network manager, where nm-applet would crash. We have a patch for this, so that will be fixed. However, this could affect other applications too. Has anyone seen any strange behaviour with the keyring? From dgboles at gmail.com Fri Sep 21 13:53:28 2007 From: dgboles at gmail.com (David Boles) Date: Fri, 21 Sep 2007 09:53:28 -0400 Subject: Root login in rawhide and display managers In-Reply-To: References: <46F038AC.9010503@fedoraproject.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> Message-ID: <46F3CCD8.4090404@gmail.com> on 9/20/2007 3:11 AM, Rudolf Kastl wrote: > 2007/9/20, David Boles : >> on 9/19/2007 6:09 PM, ??? wrote: >> >> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and >> the so many other Windows games you will get a *lot* of 'new Linux users' >> from Windows. Just as ignorant as you are looking for here. > > well please do your homework: > > http://appdb.winehq.com > > sof even has a native linux port. > > regards, > Rudolf Kastl You should have looked a little harder before you jumped to defend Windows games for Linux. ;-) I mentioned those games only because they came to mind late at night. Those are all old, by gaming standards very old, games. SOF is from 2000 for example and basically abandoned. It will run because it is OpenGL and could be ported. Oblivion and Half-Life are written 'in' DirectX. Those would not, and many others I would think, run in Wine. Ever. Nor will they run in VMware. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From clydekunkel7734 at cox.net Fri Sep 21 13:57:12 2007 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 21 Sep 2007 09:57:12 -0400 Subject: [Fwd: FC8T2 fails to install when root on LV over software raid] Message-ID: <46F3CDB8.7050107@cox.net> Pardon this cross posting, but I am a bit confused now on the use of Fedora Test lists for these issues. Saw another msg indicating that this type of msg belonged on the development list. Anyway, help on resolving this issue much appreciated. -------- Original Message -------- Subject: FC8T2 fails to install when root on LV over software raid Date: Thu, 20 Sep 2007 13:30:52 -0400 From: Clyde E. Kunkel Reply-To: clydekunkel7734 at cox.mungednet.redhat.com, For testers of Fedora Core development releases To: For testers of Fedora Core development releases BZ 298661 This is an ongoing issue that has been around for awhile. For whatever reason, during an install of FC on my test system and one other production system with promise raid controllers set to individual drives and NOT raid, you have to use a NOMPATH parm for the installer to detect all of the software raidsets. And this is then the only way the installer sees all the raidsets that are PVs for the LVs. Even then, the system will not switchroot since during initrd the raidsets are not started causing the LVs to not be detected. Would really like to get this fixed. Had to install FC7 on one of the few raidsets that survived during install. Interesting thing: FC5 installed nicely on an LV and have kept it updated as a rawhide system (tho many current kernel initrds won't switchroot). -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From mattdm at mattdm.org Fri Sep 21 14:17:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Sep 2007 10:17:22 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190380783.2142.52.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> Message-ID: <20070921141722.GA32111@jadzia.bu.edu> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > As a sysadmin /srv is a useful thing - it's what most sysadmins do > anyway - create a top level path where they mount the large, local disks > and put all their data. So they know on every system if they hit /etc > and /srv with the backups they'll have what they should be worried > about. All admins may not call it /srv but they do something like > it: /fs, /local, /data, /srv > > it's all the same result. > > so while your argument for not using it in the distro is fine -the > reality is that this is what is actually done by sysadmins all over the > world. +1 Thank you Seth. /var is transient data. There should be nothing there that needs backups. And users shouldn't look there for files they might edit. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rcritten at redhat.com Fri Sep 21 14:23:38 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Sep 2007 10:23:38 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F3CCD8.4090404@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> Message-ID: <46F3D3EA.4080208@redhat.com> David Boles wrote: > on 9/20/2007 3:11 AM, Rudolf Kastl wrote: >> 2007/9/20, David Boles : >>> on 9/19/2007 6:09 PM, ??? wrote: >>> >>> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and >>> the so many other Windows games you will get a *lot* of 'new Linux users' >>> from Windows. Just as ignorant as you are looking for here. >> well please do your homework: >> >> http://appdb.winehq.com >> >> sof even has a native linux port. >> >> regards, >> Rudolf Kastl > > You should have looked a little harder before you jumped to defend Windows > games for Linux. ;-) > > I mentioned those games only because they came to mind late at night. > Those are all old, by gaming standards very old, games. SOF is from 2000 > for example and basically abandoned. It will run because it is OpenGL and > could be ported. Oblivion and Half-Life are written 'in' DirectX. Those > would not, and many others I would think, run in Wine. Ever. Nor will they > run in VMware. > Half-Life (and friends) has an OpenGL renderer and has worked for ages in Linux using wine. Half-Life 2 and Oblivion are DirectX only but do work somewhat in wine (have some rendering glitches, water reflections can be odd, performance is decreased). Both run very well in Cedega, including copy protection. As do a slew of other modern games. It still isn't at the point where you can grab any game off the shelf and have it work but I've got a large stack of games that say you're wrong that DirectX games will never, ever be playable on Linux. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pemboa at gmail.com Fri Sep 21 14:27:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Sep 2007 09:27:00 -0500 Subject: [RFC] /var versus /srv In-Reply-To: <20070921141722.GA32111@jadzia.bu.edu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> Message-ID: <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> On 9/21/07, Matthew Miller wrote: > > so while your argument for not using it in the distro is fine -the > > reality is that this is what is actually done by sysadmins all over the > > world. That's a high order, a lot of apps whose data need backing up go there. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From tcallawa at redhat.com Fri Sep 21 14:25:26 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 21 Sep 2007 10:25:26 -0400 Subject: Does anyone have gnome-keyring problems? In-Reply-To: <1190383219.11057.87.camel@localhost.localdomain> References: <1190383219.11057.87.camel@localhost.localdomain> Message-ID: <1190384726.3418.82.camel@localhost.localdomain> On Fri, 2007-09-21 at 16:00 +0200, Alexander Larsson wrote: > The new gnome-keyring has a small change in behaviour. When you look for > a key that doesn't exist it used to return a DENIED error. This is > somewhat wrong (as it seems to indicate that there is a permissions > error). This was changed to return OK, with a list of zero hits. > > Bug for this: > https://bugzilla.redhat.com/show_bug.cgi?id=298871 > > This caused problems for at least network manager, where nm-applet would > crash. We have a patch for this, so that will be fixed. However, this > could affect other applications too. Has anyone seen any strange > behaviour with the keyring? Evolution was doing this for a while, but it doesn't seem to be having that problem anymore. ~spot From snecklifter at gmail.com Thu Sep 20 10:30:08 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 20 Sep 2007 11:30:08 +0100 Subject: usb hotplug stopped working on Fedora Core 6 - any ideas how to troubleshoot? In-Reply-To: <64b14b300709191131p7d4b93feoa490954a78099618@mail.gmail.com> References: <64b14b300709120552p408cc5a9x37cba21ce008a0cf@mail.gmail.com> <46E7E303.9000208@zianet.com> <64b14b300709130652o57dcde66k1b528df40be5ed84@mail.gmail.com> <46E953AF.8080007@zianet.com> <64b14b300709140712j6b289e37jbb41a25e6494b85e@mail.gmail.com> <64b14b300709191131p7d4b93feoa490954a78099618@mail.gmail.com> Message-ID: <364d303b0709200330j243543audf9c8b67e0bf8e0e@mail.gmail.com> On 19/09/2007, Valent Turkovic wrote: Anybody? Is udev dead on Fedora Core 6? > No, it just doesn't seem to be working for you. Please file a bug with as much information as possible. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcantrell at redhat.com Fri Sep 21 14:26:20 2007 From: dcantrell at redhat.com (David Cantrell) Date: Fri, 21 Sep 2007 10:26:20 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921095601.035cc74d@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> Message-ID: <20070921102620.5bb9ff5a.dcantrell@redhat.com> On Fri, 21 Sep 2007 09:56:01 -0400 Jesse Keating wrote: > On Fri, 21 Sep 2007 09:51:55 -0400 > seth vidal wrote: > > > that's fine by me - but I don't think removing /srv from filesystem > > pkg makes any sense. > > Doesn't make sense to me either, I hope I didn't sound otherwise. > > +1 to keeping /srv > -1 to allowing any package to put any content in /srv Whether or not you agree with the FHS, it does make some useful points. Following it as a recommendation or guideline seems like the best idea. I've viewed /srv as another /usr/local, but without a vendor-provided directory structure. Other than it existing as a top level directory, we shouldn't do anything with it. The only argument I can see to that is where do we stop we top level provided directories? I think /srv is reasonable as an example and admins can take it from there. Packages shouldn't dump anything in there. On another note, could we please stop the +1 and -1 garbage replies to people? Just say you agree or disagree. Where did the +1 and -1 trend come from because it's really freaking annoying. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 21 14:29:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Sep 2007 10:29:44 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070921141722.GA32111@jadzia.bu.edu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> Message-ID: <46F3D558.3000703@redhat.com> Matthew Miller wrote: > On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: >> As a sysadmin /srv is a useful thing - it's what most sysadmins do >> anyway - create a top level path where they mount the large, local disks >> and put all their data. So they know on every system if they hit /etc >> and /srv with the backups they'll have what they should be worried >> about. All admins may not call it /srv but they do something like >> it: /fs, /local, /data, /srv >> >> it's all the same result. >> >> so while your argument for not using it in the distro is fine -the >> reality is that this is what is actually done by sysadmins all over the >> world. > > +1 > > Thank you Seth. > > /var is transient data. There should be nothing there that needs backups. > And users shouldn't look there for files they might edit. > Transient and not backed up? What about /var/mail, /var/spool/cron and /var/log? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at fedoraproject.org Fri Sep 21 14:32:48 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Sep 2007 10:32:48 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D558.3000703@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> Message-ID: <1190385168.2142.60.camel@cutter> On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > Matthew Miller wrote: > > On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > >> As a sysadmin /srv is a useful thing - it's what most sysadmins do > >> anyway - create a top level path where they mount the large, local disks > >> and put all their data. So they know on every system if they hit /etc > >> and /srv with the backups they'll have what they should be worried > >> about. All admins may not call it /srv but they do something like > >> it: /fs, /local, /data, /srv > >> > >> it's all the same result. > >> > >> so while your argument for not using it in the distro is fine -the > >> reality is that this is what is actually done by sysadmins all over the > >> world. > > > > +1 > > > > Thank you Seth. > > > > /var is transient data. There should be nothing there that needs backups. > > And users shouldn't look there for files they might edit. > > > > Transient and not backed up? What about /var/mail, /var/spool/cron and > /var/log? - /var/log - shouldn't matter - it's being sent to centralized log hosts which I've always had put files in /srv/logs - /var/mail has no data - all your mail should be in your central mail server and not in /var/mail but in another path /srv/mail or /srv/mqueue often - /var/spool/cron doesn't have any files in it b/c users are not allowed to add cron jobs except on highly specific systems. Moreover, if you're adding root or system-controlled cron jobs they should go in /etc/cron.d or in the /etc/cron.hourly, /etc/cron.daily, etc directories. never in /var/spool/cron and NEVER add by such a cumbersome tool as cron -e -sv From myfedora at richip.dhs.org Fri Sep 21 14:39:25 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 08:39:25 -0600 Subject: soname Provides In-Reply-To: <20070921101447.27f323d9.mschwendt.tmp0701.nospam@arcor.de> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> <1190304365.31399.18.camel@localhost6.localdomain6> <20070921101447.27f323d9.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1190385565.23728.12.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 10:14 +0200, Michael Schwendt wrote: > And then you end up with competing implementations of the same library > interface. One with vulnerabilities, the other one with security-fixes. > One with customisations and several minor releases behind, the other > the latest release with bug-fixes. One built with a complete feature > set, the other stripped down to upstream defaults. RPM dependencies > would need to get much more complex if to cover such differences in > implementations. I don't see that as a problem of the system but the installed software. If anything, that's where the underlying selection mechanism might be useful. Vulnerabilities and other bugs are problems that need to be fixed. If an update arrives to fix a vulnerability, then I suggest it be installed with a higher priority than any other on the system, but if applications insist on using their buggy version, then that should be taken up with the application provider. Why throw out the baby with the bathwater? > That's not something I'd like to see, at least not for system > libraries. Using /etc/ld.so.conf.d/ (not LD_LIBRARY_PATH, which is > empty by default btw) already is dangerous enough, since it can be > used to avoid file conflicts and still insert competing libs into > run-time linker's view. Further, there's no difference between > "Provides" of libs in private paths and system-wide paths. It's too > easy to disable/move the private paths and pull away the libs from the > run-time env. No, I didn't say it should be the only mechanism, but I believe there's a certain place for it. Support for it just has to be good. So far, the scenarios you've painted are due more to buggy implementations than anything to do with the strategy or philosophy of having multiple implementations on the system. Having alternative code (whether it be several different JVM's on a machine, or several implementations of an MP3 codec) isn't bad per se. They just have to be supported properly by the system because anything it can't handle, the user ends up tweaking. Depending on how advanced the system is that's handling the multiple implementation subsystem, some users (advanced ones) might actually be alright (and in fact be more productive) with it, but others might not. But, again, that's a problem with the implementation that we, as software developers, can work on. -- Richi Plana From rcritten at redhat.com Fri Sep 21 14:42:48 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Sep 2007 10:42:48 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190385168.2142.60.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> Message-ID: <46F3D868.1020108@redhat.com> seth vidal wrote: > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: >> Matthew Miller wrote: >>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: >>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do >>>> anyway - create a top level path where they mount the large, local disks >>>> and put all their data. So they know on every system if they hit /etc >>>> and /srv with the backups they'll have what they should be worried >>>> about. All admins may not call it /srv but they do something like >>>> it: /fs, /local, /data, /srv >>>> >>>> it's all the same result. >>>> >>>> so while your argument for not using it in the distro is fine -the >>>> reality is that this is what is actually done by sysadmins all over the >>>> world. >>> +1 >>> >>> Thank you Seth. >>> >>> /var is transient data. There should be nothing there that needs backups. >>> And users shouldn't look there for files they might edit. >>> >> Transient and not backed up? What about /var/mail, /var/spool/cron and >> /var/log? > > - /var/log - shouldn't matter - it's being sent to centralized log hosts > which I've always had put files in /srv/logs > - /var/mail has no data - all your mail should be in your central mail > server and not in /var/mail but in another path /srv/mail or /srv/mqueue > often > > - /var/spool/cron doesn't have any files in it b/c users are not allowed > to add cron jobs except on highly specific systems. Moreover, if you're > adding root or system-controlled cron jobs they should go in /etc/cron.d > or in the /etc/cron.hourly, /etc/cron.daily, etc directories. > > never in /var/spool/cron and NEVER add by such a cumbersome tool as cron > -e Not everyone in the world sets things up like you do. The FHS explicitly sets these paths for these purposes. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From lfarkas at bppiac.hu Fri Sep 21 14:45:46 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 21 Sep 2007 16:45:46 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190385168.2142.60.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> Message-ID: <46F3D91A.3050002@bppiac.hu> seth vidal wrote: > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: >> Matthew Miller wrote: >>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: >>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do >>>> anyway - create a top level path where they mount the large, local disks >>>> and put all their data. So they know on every system if they hit /etc >>>> and /srv with the backups they'll have what they should be worried >>>> about. All admins may not call it /srv but they do something like >>>> it: /fs, /local, /data, /srv >>>> >>>> it's all the same result. >>>> >>>> so while your argument for not using it in the distro is fine -the >>>> reality is that this is what is actually done by sysadmins all over the >>>> world. >>> +1 >>> >>> Thank you Seth. >>> >>> /var is transient data. There should be nothing there that needs backups. >>> And users shouldn't look there for files they might edit. >>> >> Transient and not backed up? What about /var/mail, /var/spool/cron and >> /var/log? > > - /var/log - shouldn't matter - it's being sent to centralized log hosts > which I've always had put files in /srv/logs > - /var/mail has no data - all your mail should be in your central mail > server and not in /var/mail but in another path /srv/mail or /srv/mqueue > often > > - /var/spool/cron doesn't have any files in it b/c users are not allowed > to add cron jobs except on highly specific systems. Moreover, if you're > adding root or system-controlled cron jobs they should go in /etc/cron.d > or in the /etc/cron.hourly, /etc/cron.daily, etc directories. > > never in /var/spool/cron and NEVER add by such a cumbersome tool as cron i agree with you about /srv, but not with the above. do you have any system with real users? why don't you allow cron jobs for normal users??? -- Levente "Si vis pacem para bellum!" From skvidal at fedoraproject.org Fri Sep 21 14:45:29 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Sep 2007 10:45:29 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D868.1020108@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D868.1020108@redhat.com> Message-ID: <1190385929.2142.62.camel@cutter> On Fri, 2007-09-21 at 10:42 -0400, Rob Crittenden wrote: > seth vidal wrote: > > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > >> Matthew Miller wrote: > >>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > >>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do > >>>> anyway - create a top level path where they mount the large, local disks > >>>> and put all their data. So they know on every system if they hit /etc > >>>> and /srv with the backups they'll have what they should be worried > >>>> about. All admins may not call it /srv but they do something like > >>>> it: /fs, /local, /data, /srv > >>>> > >>>> it's all the same result. > >>>> > >>>> so while your argument for not using it in the distro is fine -the > >>>> reality is that this is what is actually done by sysadmins all over the > >>>> world. > >>> +1 > >>> > >>> Thank you Seth. > >>> > >>> /var is transient data. There should be nothing there that needs backups. > >>> And users shouldn't look there for files they might edit. > >>> > >> Transient and not backed up? What about /var/mail, /var/spool/cron and > >> /var/log? > > > > - /var/log - shouldn't matter - it's being sent to centralized log hosts > > which I've always had put files in /srv/logs > > - /var/mail has no data - all your mail should be in your central mail > > server and not in /var/mail but in another path /srv/mail or /srv/mqueue > > often > > > > - /var/spool/cron doesn't have any files in it b/c users are not allowed > > to add cron jobs except on highly specific systems. Moreover, if you're > > adding root or system-controlled cron jobs they should go in /etc/cron.d > > or in the /etc/cron.hourly, /etc/cron.daily, etc directories. > > > > never in /var/spool/cron and NEVER add by such a cumbersome tool as cron > > -e > > Not everyone in the world sets things up like you do. The FHS explicitly > sets these paths for these purposes. They may not, but they should. :) -sv From skvidal at fedoraproject.org Fri Sep 21 14:53:00 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 21 Sep 2007 10:53:00 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D91A.3050002@bppiac.hu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> Message-ID: <1190386380.2142.64.camel@cutter> On Fri, 2007-09-21 at 16:45 +0200, Farkas Levente wrote: > seth vidal wrote: > > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > >> Matthew Miller wrote: > >>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > >>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do > >>>> anyway - create a top level path where they mount the large, local disks > >>>> and put all their data. So they know on every system if they hit /etc > >>>> and /srv with the backups they'll have what they should be worried > >>>> about. All admins may not call it /srv but they do something like > >>>> it: /fs, /local, /data, /srv > >>>> > >>>> it's all the same result. > >>>> > >>>> so while your argument for not using it in the distro is fine -the > >>>> reality is that this is what is actually done by sysadmins all over the > >>>> world. > >>> +1 > >>> > >>> Thank you Seth. > >>> > >>> /var is transient data. There should be nothing there that needs backups. > >>> And users shouldn't look there for files they might edit. > >>> > >> Transient and not backed up? What about /var/mail, /var/spool/cron and > >> /var/log? > > > > - /var/log - shouldn't matter - it's being sent to centralized log hosts > > which I've always had put files in /srv/logs > > - /var/mail has no data - all your mail should be in your central mail > > server and not in /var/mail but in another path /srv/mail or /srv/mqueue > > often > > > > - /var/spool/cron doesn't have any files in it b/c users are not allowed > > to add cron jobs except on highly specific systems. Moreover, if you're > > adding root or system-controlled cron jobs they should go in /etc/cron.d > > or in the /etc/cron.hourly, /etc/cron.daily, etc directories. > > > > never in /var/spool/cron and NEVER add by such a cumbersome tool as cron > > i agree with you about /srv, but not with the above. do you have any > system with real users? why don't you allow cron jobs for normal users??? systems get reinstalled frequently. Therefore cron jobs get nuked and end up causing pain. There are central servers they can install cron jobs on - but not any random box on the network. -sv From johannbg at hi.is Fri Sep 21 14:54:36 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 21 Sep 2007 14:54:36 +0000 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D91A.3050002@bppiac.hu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> Message-ID: <46F3DB2C.9030503@hi.is> Farkas Levente wrote: > seth vidal wrote: > >> On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: >> >>> Matthew Miller wrote: >>> >>>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: >>>> >>>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do >>>>> anyway - create a top level path where they mount the large, local disks >>>>> and put all their data. So they know on every system if they hit /etc >>>>> and /srv with the backups they'll have what they should be worried >>>>> about. All admins may not call it /srv but they do something like >>>>> it: /fs, /local, /data, /srv >>>>> >>>>> it's all the same result. >>>>> >>>>> so while your argument for not using it in the distro is fine -the >>>>> reality is that this is what is actually done by sysadmins all over the >>>>> world. >>>>> >>>> +1 >>>> >>>> Thank you Seth. >>>> >>>> /var is transient data. There should be nothing there that needs backups. >>>> And users shouldn't look there for files they might edit. >>>> >>>> >>> Transient and not backed up? What about /var/mail, /var/spool/cron and >>> /var/log? >>> >> - /var/log - shouldn't matter - it's being sent to centralized log hosts >> which I've always had put files in /srv/logs >> - /var/mail has no data - all your mail should be in your central mail >> server and not in /var/mail but in another path /srv/mail or /srv/mqueue >> often >> >> - /var/spool/cron doesn't have any files in it b/c users are not allowed >> to add cron jobs except on highly specific systems. Moreover, if you're >> adding root or system-controlled cron jobs they should go in /etc/cron.d >> or in the /etc/cron.hourly, /etc/cron.daily, etc directories. >> >> never in /var/spool/cron and NEVER add by such a cumbersome tool as cron >> > > i agree with you about /srv, but not with the above. do you have any > system with real users? why don't you allow cron jobs for normal users??? > > Disagree with keeping /srv ( -1 :) ) All admins should be able to use the mkdir command to create the directory. If it's not used by the System remove-it ..... Oh and by the way we allow all our user to run cron jobs.... Kv. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mario at targetdevelopment.at Fri Sep 21 14:58:55 2007 From: mario at targetdevelopment.at (DI Mario Bruckschwaiger) Date: Fri, 21 Sep 2007 16:58:55 +0200 Subject: new behavior of Logitech diNovo Edge keyboard Message-ID: <1190386735.2780.12.camel@rock> When not moving the cursor (touching the touch disk) during startup, the keyboard won't work (red bluetooth light on the keyboard). Either the cursor is moved during the startup process or the bluetooth usb receiver for the keyboard is unplugged and plugged in again when in gdm will make the keyboard work. This is not so in Fedora 7. I noticed this behavior with the last three or four kernels from rawhide, don't know if this behavior also showed up before. It's also the same with the current xen-kernel. So I don't think it's a kernel problem. But it is strange and it is not very comfortable. For information: I did not do a clean install, instead I upgraded a former Fedora 7 installation. Mario. From johannbg at hi.is Fri Sep 21 15:10:24 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 21 Sep 2007 15:10:24 +0000 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <1190386735.2780.12.camel@rock> References: <1190386735.2780.12.camel@rock> Message-ID: <46F3DEE0.4070903@hi.is> DI Mario Bruckschwaiger wrote: > When not moving the cursor (touching the touch disk) during startup, the > keyboard won't work (red bluetooth light on the keyboard). Either the > cursor is moved during the startup process or the bluetooth usb receiver > for the keyboard is unplugged and plugged in again when in gdm will make > the keyboard work. This is not so in Fedora 7. I noticed this behavior > with the last three or four kernels from rawhide, don't know if this > behavior also showed up before. It's also the same with the current > xen-kernel. So I don't think it's a kernel problem. But it is strange > and it is not very comfortable. > > For information: I did not do a clean install, instead I upgraded a > former Fedora 7 installation. > > Mario. > > > Could you provide some HardWare details.. Other than the keyboard... Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From rc040203 at freenet.de Fri Sep 21 14:49:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Sep 2007 16:49:05 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190385168.2142.60.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> Message-ID: <1190386145.31022.180.camel@mccallum.corsepiu.local> On Fri, 2007-09-21 at 10:32 -0400, seth vidal wrote: > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > > Matthew Miller wrote: > > > On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > > >> As a sysadmin /srv is a useful thing - it's what most sysadmins do > > >> anyway - create a top level path where they mount the large, local disks > > >> and put all their data. So they know on every system if they hit /etc > > >> and /srv with the backups they'll have what they should be worried > > >> about. All admins may not call it /srv but they do something like > > >> it: /fs, /local, /data, /srv > > >> > > >> it's all the same result. > > >> > > >> so while your argument for not using it in the distro is fine -the > > >> reality is that this is what is actually done by sysadmins all over the > > >> world. > > > > > > +1 > > > > > > Thank you Seth. > > > > > > /var is transient data. There should be nothing there that needs backups. > > > And users shouldn't look there for files they might edit. > > > > > > > Transient and not backed up? What about /var/mail, /var/spool/cron and > > /var/log? >From the FHS: Chapter 5. The /var Hierarchy Purpose /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. Ralf From nicolas.mailhot at laposte.net Fri Sep 21 15:17:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 17:17:47 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190380783.2142.52.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> Message-ID: <64384.192.54.193.51.1190387867.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 15:19, seth vidal a ?crit : > As a sysadmin /srv is a useful thing ... > so while your argument for not using it in the distro is fine -the > reality is that this is what is actually done by sysadmins all over > the world. Right. Also using /home for anything but actual humans is a receipe for collisions in environments where /home is network-shared between systems that may have the same human users but not the same software services installed. Regards, -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Fri Sep 21 15:05:59 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Sep 2007 17:05:59 +0200 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <1190386735.2780.12.camel@rock> References: <1190386735.2780.12.camel@rock> Message-ID: <46F3DDD7.60905@hhs.nl> DI Mario Bruckschwaiger wrote: > When not moving the cursor (touching the touch disk) during startup, the > keyboard won't work (red bluetooth light on the keyboard). Either the > cursor is moved during the startup process or the bluetooth usb receiver > for the keyboard is unplugged and plugged in again when in gdm will make > the keyboard work. This is not so in Fedora 7. I noticed this behavior > with the last three or four kernels from rawhide, don't know if this > behavior also showed up before. It's also the same with the current > xen-kernel. So I don't think it's a kernel problem. But it is strange > and it is not very comfortable. > > For information: I did not do a clean install, instead I upgraded a > former Fedora 7 installation. > Sounds like the new usb autosuspend code is biting you, the device gets suspended because it isn't used for a while, you could try doing: echo "on" > /sys/bus/usb/devices/1-1/power/level From /etc/rc.d/rc.local replacing 1-1 with the actual place where your usb receiver is. Regards, Hans From nicolas.mailhot at laposte.net Fri Sep 21 15:20:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 17:20:58 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <20070921093924.123e483b@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> Message-ID: <12072.192.54.193.51.1190388058.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 15:39, Jesse Keating a ?crit : > On Fri, 21 Sep 2007 09:19:43 -0400 > seth vidal wrote: > >> so while your argument for not using it in the distro is fine -the >> reality is that this is what is actually done by sysadmins all over >> the world. > > In fact, that evidence makes it even /more/ important that we as a > distro don't put anything in /srv/ that would disrupt what a local > admin may be using it for. That evidence makes it even /more/ important we either reserve part of /srv for default services or create a distro-managed srv-equivalent alongside. It's ridiculous to argue the same data should be managed differently depending on whether the admin touched the server default config files or not. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Sep 21 15:25:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 17:25:07 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <46F3D868.1020108@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D868.1020108@redhat.com> Message-ID: <25779.192.54.193.51.1190388307.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 16:42, Rob Crittenden a ?crit : > Not everyone in the world sets things up like you do. The FHS > explicitly sets these paths for these purposes. The FHS codified existing linux/bsd practices, including existing messes and inconsistent choices. And the FHS is a moving target -- Nicolas Mailhot From mario at targetdevelopment.at Fri Sep 21 15:28:09 2007 From: mario at targetdevelopment.at (DI Mario Bruckschwaiger) Date: Fri, 21 Sep 2007 17:28:09 +0200 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <46F3DEE0.4070903@hi.is> References: <1190386735.2780.12.camel@rock> <46F3DEE0.4070903@hi.is> Message-ID: <1190388489.2780.22.camel@rock> On Fri, 2007-09-21 at 15:10 +0000, "J?hann B. Gu?mundsson" wrote: > Could you provide some HardWare details.. > Other than the keyboard... > Of course, the cpu (from /proc/cpuinfo of a Fedora 7 installation) is an Intel dual core vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) D CPU 2.66GHz stepping : 7 cpu MHz : 2676.291 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monito r ds_cpl tm2 cid cx16 xtpr lahf_lm bogomips : 5355.71 clflush size : 64 and from /proc/bus/usb/devices (also from the Fedora 7 installation) T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 3 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=0b04 Rev=49.00 S: Manufacturer=Logitech S: Product=Logitech BT Mini-Receiver C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=02 Lev=02 Prnt=03 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c713 Rev=49.00 S: Manufacturer=Logitech S: Product=Logitech BT Mini-Receiver S: SerialNumber=00076172342B C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=02 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c714 Rev=49.00 S: Manufacturer=Logitech S: Product=Logitech BT Mini-Receiver S: SerialNumber=00076172342B C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=2ms Hope this helps, I can give you more info if needed. Mario. From nicolas.mailhot at laposte.net Fri Sep 21 15:36:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 17:36:56 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <46F3DB2C.9030503@hi.is> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> <46F3DB2C.9030503@hi.is> Message-ID: <61839.192.54.193.51.1190389016.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 16:54, "J?hann B. Gu?mundsson" a ?crit : > Disagree with keeping /srv ( -1 :) ) > > All admins should be able to use the mkdir command to create the > directory. And every server config file we ship should contain gems like: # Sample config file # Brought to you by Fedora, your secure admin-friendly distribution! # # This is where you'll usually want data to be # Since we won't touch /srv, create these directories yourself # P.S. Sample content can be copied from %doc # P.P.S. Do not forget to use the right unix permissions # P.P.P.S. Do not forget to label them with the right selinux rules # # datadir=/srv/foo Or alternatively # Default config file # Brought to you by Fedora, your secure admin-friendly distribution! # # We use the /var/somelonginsanepath/foo for our default config. # Most admins prefer to have it somewhere under /srv # But we won't do so, nah # Please create your /srv roots yourself # P.S. Sample content can be copied from /var/somelonginsanepath/foo # P.P.S. Do not forget to use the right unix permissions # P.P.P.S. Do not forget to label them with the right selinux rules datadir=/var/somelonginsanepath/foo Progress! Fedora, the distro formerly known as "just works"! -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Sep 21 15:38:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 17:38:32 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190386145.31022.180.camel@mccallum.corsepiu.local> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> Message-ID: <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 16:49, Ralf Corsepius a ?crit : >>From the FHS: > Chapter 5. The /var Hierarchy > Purpose > /var contains variable data files. This includes spool directories and > files, administrative and logging data, and transient and temporary > files. And some transient files like spools may be backed up, but /var is not for long-term data -- Nicolas Mailhot From myfedora at richip.dhs.org Fri Sep 21 15:40:33 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 09:40:33 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> Message-ID: <1190389233.23728.16.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 09:27 -0500, Arthur Pemberton wrote: > On 9/21/07, Matthew Miller wrote: > > > so while your argument for not using it in the distro is fine -the > > > reality is that this is what is actually done by sysadmins all over the > > > world. > > > That's a high order, a lot of apps whose data need backing up go there. Whenever I move services from one machine to another (say for a server upgrade), I never backup /var. The only thing I backup out of it is /var/www. It would be nice if a policy like that were made consistent (ie. nothing that needs backup'ing in /var and /srv ALWAYS has to be backed-up) instead of having to keep track of all of these little things. As a rule, that is. If you want to store data in a different place, that's definitely an admin's prerogative. -- Richi Plana From pemboa at gmail.com Fri Sep 21 15:47:28 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Sep 2007 10:47:28 -0500 Subject: [RFC] /var versus /srv In-Reply-To: <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> Message-ID: <16de708d0709210847u5f2b290ajd1caa735f7619c2b@mail.gmail.com> On 9/21/07, Nicolas Mailhot wrote: > > Le Ven 21 septembre 2007 16:49, Ralf Corsepius a ?crit : > > >>From the FHS: > > Chapter 5. The /var Hierarchy > > Purpose > > /var contains variable data files. This includes spool directories and > > files, administrative and logging data, and transient and temporary > > files. > > And some transient files like spools may be backed up, but /var is not > for long-term data It _is not_ or it _shouldn't be_ ? Because right now, I can't imagine not backing up most (not all) of /var -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From myfedora at richip.dhs.org Fri Sep 21 15:46:23 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 09:46:23 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D558.3000703@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> Message-ID: <1190389583.23728.23.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > > /var is transient data. There should be nothing there that needs backups. > > And users shouldn't look there for files they might edit. > > > > Transient and not backed up? What about /var/mail, /var/spool/cron and > /var/log? /var/spool/mail is another thing that needs moving. Most of the time, I either use $HOME/Maildir/ or database storage for mail user's mail (assuming that mail services is what the box is offering). root mail and /var/log/* stuff are definitely transient. While some institutions might make it their policy to back-up information like that for track-record keeping for future review purposes (forensics), they most certainly aren't crucial nor relevant for _continued service use_. -- Richi Plana From rc040203 at freenet.de Fri Sep 21 15:52:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Sep 2007 17:52:10 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> Message-ID: <1190389930.31022.184.camel@mccallum.corsepiu.local> On Fri, 2007-09-21 at 17:38 +0200, Nicolas Mailhot wrote: > Le Ven 21 septembre 2007 16:49, Ralf Corsepius a ?crit : > > >>From the FHS: > > Chapter 5. The /var Hierarchy > > Purpose > > /var contains variable data files. This includes spool directories and > > files, administrative and logging data, and transient and temporary > > files. > > And some transient files like spools may be backed up, but /var is not > for long-term data I should have been more explict: Unlike Seth said, /var not for transient and temporary only. e.g. /var/lib/ is full of non-transient data, which, if you loose them due to not having backed up, will let you "appear pretty old". Ralf From alex at tvtransilvania.ro Fri Sep 21 15:52:42 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Fri, 21 Sep 2007 18:52:42 +0300 Subject: gnomebaker 0.6.1-4 oddity In-Reply-To: <20070917132853.540696a5.tsmetana@redhat.com> References: <46EAC1A8.3090005@tvtransilvania.ro> <20070917132853.540696a5.tsmetana@redhat.com> Message-ID: <46F3E8CA.6050802@tvtransilvania.ro> Tom?? Smetana wrote: > So please upgrade > liboil and let me know (even off-list) whether it helps. > Upgrading liboil did the trick. From mschwendt.tmp0701.nospam at arcor.de Fri Sep 21 16:06:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 21 Sep 2007 18:06:25 +0200 Subject: soname Provides In-Reply-To: <1190385565.23728.12.camel@localhost6.localdomain6> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> <1190304365.31399.18.camel@localhost6.localdomain6> <20070921101447.27f323d9.mschwendt.tmp0701.nospam@arcor.de> <1190385565.23728.12.camel@localhost6.localdomain6> Message-ID: <20070921180625.487aa814.mschwendt.tmp0701.nospam@arcor.de> On Fri, 21 Sep 2007 08:39:25 -0600, Richi Plana wrote: > > And then you end up with competing implementations of the same library > > interface. One with vulnerabilities, the other one with security-fixes. > > One with customisations and several minor releases behind, the other > > the latest release with bug-fixes. One built with a complete feature > > set, the other stripped down to upstream defaults. RPM dependencies > > would need to get much more complex if to cover such differences in > > implementations. > > I don't see that as a problem of the system but the installed software. > If anything, that's where the underlying selection mechanism might be > useful. Vulnerabilities and other bugs are problems that need to be > fixed. If an update arrives to fix a vulnerability, then I suggest it be > installed with a higher priority than any other on the system, but if > applications insist on using their buggy version, then that should be > taken up with the application provider. > > Why throw out the baby with the bathwater? You want to insert another layer between installing system components and making them available system-wide after installation? Or a layer between the depsolver and the transaction set? Like "repo offers libfoo-2.0-1 and libfoo2-2.0-1, and user can choose either one or even both, and decide which to make available to apps"? Or you want packages to switch back and forth automatically between alternative implementations of the same interface? Redundancy instead of reuse. We don't talk about the same problem, I'm afraid. It is beyond my time to extend this thread much further and in pure text form into something completely theoretical that would require fundamental changes to the RPM dependencies system. From mario at targetdevelopment.at Fri Sep 21 16:06:22 2007 From: mario at targetdevelopment.at (DI Mario Bruckschwaiger) Date: Fri, 21 Sep 2007 18:06:22 +0200 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <46F3DDD7.60905@hhs.nl> References: <1190386735.2780.12.camel@rock> <46F3DDD7.60905@hhs.nl> Message-ID: <1190390782.2732.1.camel@rock> On Fri, 2007-09-21 at 17:05 +0200, Hans de Goede wrote: > Sounds like the new usb autosuspend code is biting you, the device gets > suspended because it isn't used for a while, you could try doing: > echo "on" > /sys/bus/usb/devices/1-1/power/level > > From /etc/rc.d/rc.local > replacing 1-1 with the actual place where your usb receiver is. No, did not work. Same behavior as before. From johannbg at hi.is Fri Sep 21 16:07:41 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 21 Sep 2007 16:07:41 +0000 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <1190388489.2780.22.camel@rock> References: <1190386735.2780.12.camel@rock> <46F3DEE0.4070903@hi.is> <1190388489.2780.22.camel@rock> Message-ID: <46F3EC4D.9020409@hi.is> DI Mario Bruckschwaiger wrote: > On Fri, 2007-09-21 at 15:10 +0000, "J?hann B. Gu?mundsson" wrote: > >> Could you provide some HardWare details.. >> Other than the keyboard... >> >> > > Of course, > > the cpu (from /proc/cpuinfo of a Fedora 7 installation) > is an Intel dual core > > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Pentium(R) D CPU 2.66GHz > stepping : 7 > cpu MHz : 2676.291 > cache size : 1024 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat > pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monito > r ds_cpl tm2 cid cx16 xtpr lahf_lm > bogomips : 5355.71 > clflush size : 64 > > > and from /proc/bus/usb/devices (also from the Fedora 7 installation) > > > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 3 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=046d ProdID=0b04 Rev=49.00 > S: Manufacturer=Logitech > S: Product=Logitech BT Mini-Receiver > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms > > T: Bus=02 Lev=02 Prnt=03 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=046d ProdID=c713 Rev=49.00 > S: Manufacturer=Logitech > S: Product=Logitech BT Mini-Receiver > S: SerialNumber=00076172342B > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid > E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms > > T: Bus=02 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=046d ProdID=c714 Rev=49.00 > S: Manufacturer=Logitech > S: Product=Logitech BT Mini-Receiver > S: SerialNumber=00076172342B > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid > E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=2ms > > > Hope this helps, I can give you more info if needed. > > Mario. > > > > Did you try what Hans suggested... > Sounds like the new usb autosuspend code is biting you, the device > gets suspended because it isn't used for a while, you could try doing: > echo "on" > /sys/bus/usb/devices/1-1/power/level > > From /etc/rc.d/rc.local > replacing 1-1 with the actual place where your usb receiver is. > > Regards, > > Hans Good to know what motherboard you running. And report if what Hans suggestsed fixes things... Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From myfedora at richip.dhs.org Fri Sep 21 16:14:19 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 10:14:19 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <46F3D91A.3050002@bppiac.hu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> Message-ID: <1190391259.23728.34.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 16:45 +0200, Farkas Levente wrote: > i agree with you about /srv, but not with the above. do you have any > system with real users? why don't you allow cron jobs for normal users??? It's important to take this discussion in context with FHS and their intended audience and machines for their intended purposes. For the most part, FHS discusses /srv in the context of machines that act as servers. As with machines that act as servers, multi-user desktops should keep their data together. In this case, people's data should be kept together. Instead of in /src, however, mail and cron information should be placed inside their $HOME directories. What does FHS say about multi-user systems? The point is to make backing up machines easier by finding one common point for each service (whether it's mail, web or multi-user desktop). Keeping some things in /var means you either have to know which subdirectories in /var to back-up AS WELL AS user home directories, or you back up the whole /var directory, unneeded data and all. So again, it's important to separate files used by the system and files used by the services, and it would go a long way for systems administration to group them together. -- Richi Plana From che666 at gmail.com Thu Sep 20 07:10:28 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Sep 2007 09:10:28 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F13E9E.4070209@hi.is> References: <46F11332.2040708@poolshark.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <46F11BC8.8070700@fedoraproject.org> <20070919130058.GD7373@devserv.devel.redhat.com> <20070919135800.GB10005@devserv.devel.redhat.com> <20070919141153.GA11025@devserv.devel.redhat.com> <46F13E9E.4070209@hi.is> Message-ID: 2007/9/19, "J?hann B. Gu?mundsson" : > Alan Cox wrote: > > On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote: > > > >> As the desktop spin is designed for home users on laptops, I don't > >> think it should offer remote authentication as an option during > >> installation at all, so there is no failure scenario here. For people > >> who want to set up labs of Fedora desktop machines - that's what the > >> DVD and kickstart files are for. > >> > > > > Insert clue: > > > > I have a laptop and desktop boxes. I have better things to do that download > > two sets of media. (and no the laptop doesn't have a DVD drive, and yes its > > less than 12 months old) > > > > Alan > > > > > +1 > Plus too many option for users means too many things can go wrong.... > So keeping simple set of installation-images ( we should not start to > release fedora-desktop, fedora-server,fedora-laptop, > fedora-blue,fedora-black etc etc.. ) > and rather let the user choose what *type* of fedora he wants in Anaconda... +10 having 20 different official spins with completly different selectable options and settings not only cofuses the users... it especially confuses the people that try to support the newcomers e.g. on irc. if one wanted to help one had to really try out all of those spins to be able to help properly.... cant become more confusing in my eyes... regards, Rudolf Kastl > > Best regards > Johann B. > > -- > > > Johann B. Gudmundsson. RHCE,CCSA > Unix System Engineer. > IT Management. > Reiknistofnun University of Iceland. > Taeknigardi, Dunhaga 5. Email: johannbg at hi.is > IS-107 Reykjavik. Phone: +354-525-4267 > Iceland. Fax: +354-552-8801 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mario at targetdevelopment.at Fri Sep 21 16:21:42 2007 From: mario at targetdevelopment.at (DI Mario Bruckschwaiger) Date: Fri, 21 Sep 2007 18:21:42 +0200 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <46F3EC4D.9020409@hi.is> References: <1190386735.2780.12.camel@rock> <46F3DEE0.4070903@hi.is> <1190388489.2780.22.camel@rock> <46F3EC4D.9020409@hi.is> Message-ID: <1190391702.2924.2.camel@rock> On Fri, 2007-09-21 at 16:07 +0000, "J?hann B. Gu?mundsson" wrote: > Did you try what Hans suggested... Yes, and it did not work. > Good to know what motherboard you running. It's an ASUS P5LD2 Deluxe Mario. From myfedora at richip.dhs.org Fri Sep 21 16:22:46 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 10:22:46 -0600 Subject: [RFC] /var versus /srv (Off-topic) In-Reply-To: <20070921102620.5bb9ff5a.dcantrell@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> Message-ID: <1190391766.23728.42.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 10:26 -0400, David Cantrell wrote: > On another note, could we please stop the +1 and -1 garbage replies to > people? Just say you agree or disagree. Where did the +1 and -1 > trend come from because it's really freaking annoying. -1 to stopping the use of +1 and -1, but +1 to stopping garbage replies, ;). My earliest encounter with feedback mechanisms that use +num and -num as a means of communication would probably be slashdot. Polls and voting systems are kind of like that, but they were only ever used in sentences when forums became popular. It actually has a nice mathematical ring to it. More accurate and pure rather than just saying "I agree" (+1) or "I strongly agree" (+100). As much as I like to see grammar and proper use of the language maintained, I would value effective communication above it. +1/-1 gets the message across while saving bytes. Same goes for smileys, ;). -- Richi Plana From dgboles at gmail.com Fri Sep 21 15:33:53 2007 From: dgboles at gmail.com (David Boles) Date: Fri, 21 Sep 2007 11:33:53 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F3D3EA.4080208@redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11881.6030103@fedoraproject.org> <46F11ACF.40302@poolshark.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> Message-ID: <46F3E461.80709@gmail.com> on 9/21/2007 10:23 AM, Rob Crittenden wrote: > David Boles wrote: >> on 9/20/2007 3:11 AM, Rudolf Kastl wrote: >> You should have looked a little harder before you jumped to defend Windows >> games for Linux. ;-) >> >> I mentioned those games only because they came to mind late at night. >> Those are all old, by gaming standards very old, games. SOF is from 2000 >> for example and basically abandoned. It will run because it is OpenGL and >> could be ported. Oblivion and Half-Life are written 'in' DirectX. Those >> would not, and many others I would think, run in Wine. Ever. Nor will they >> run in VMware. >> > > Half-Life (and friends) has an OpenGL renderer and has worked for ages > in Linux using wine. Half-Life 2 and Oblivion are DirectX only but do > work somewhat in wine (have some rendering glitches, water reflections > can be odd, performance is decreased). > > Both run very well in Cedega, including copy protection. As do a slew of > other modern games. It still isn't at the point where you can grab any > game off the shelf and have it work but I've got a large stack of games > that say you're wrong that DirectX games will never, ever be playable on > Linux. I don't play games myself but there is someone on this list that I know and will not name (if he wishes he can say) who is a Fedora user that has two siblings that are Windows only because of the games. Games are closed source and the executables that you can use to run some of them in Linux are closed source and supplied by the game developers. They are not developed by Linux developers. I was thinking of Half-Life II actually. My point is that real Windows like game performance will be a long time coming to Linux. If ever. And since some (estimated) 90% of the computers use Windows in some form or another I don't see game producers doing much with Linux. No money in it. This thread has really drifted OT from the Subject: To say it once more. I think it is a good thing to *not* allow, by default, root GUI logins. Those that want to do that can enable it. Those that can not figure out how to enable it probably should not be doing it anyway. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From dwmw2 at infradead.org Fri Sep 21 16:40:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Sep 2007 17:40:39 +0100 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <1190386735.2780.12.camel@rock> References: <1190386735.2780.12.camel@rock> Message-ID: <1190392839.7150.71.camel@pmac.infradead.org> On Fri, 2007-09-21 at 16:58 +0200, DI Mario Bruckschwaiger wrote: > When not moving the cursor (touching the touch disk) during startup, the > keyboard won't work (red bluetooth light on the keyboard). Either the > cursor is moved during the startup process or the bluetooth usb receiver > for the keyboard is unplugged and plugged in again when in gdm will make > the keyboard work. This is not so in Fedora 7. I noticed this behavior > with the last three or four kernels from rawhide, don't know if this > behavior also showed up before. It's also the same with the current > xen-kernel. So I don't think it's a kernel problem. But it is strange > and it is not very comfortable. > > For information: I did not do a clean install, instead I upgraded a > former Fedora 7 installation. Is the host-side part of this hardware actually operating in Bluetooth mode? Is hcid running? Is the input service running? Are there interesting messages in /var/log/messages? What does 'hcidump -VX' show when you start typing? -- dwmw2 From myfedora at richip.dhs.org Fri Sep 21 16:50:48 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 10:50:48 -0600 Subject: soname Provides In-Reply-To: <20070921180625.487aa814.mschwendt.tmp0701.nospam@arcor.de> References: <20070920012929.132dec84.mschwendt.tmp0701.nospam@arcor.de> <1190272268.11057.1.camel@localhost.localdomain> <1190293060.27526.35.camel@localhost6.localdomain6> <20070920171515.da3fd997.mschwendt.tmp0701.nospam@arcor.de> <1190304365.31399.18.camel@localhost6.localdomain6> <20070921101447.27f323d9.mschwendt.tmp0701.nospam@arcor.de> <1190385565.23728.12.camel@localhost6.localdomain6> <20070921180625.487aa814.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1190393448.23728.59.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 18:06 +0200, Michael Schwendt wrote: > You want to insert another layer between installing system components > and making them available system-wide after installation? Or a layer > between the depsolver and the transaction set? Like "repo offers > libfoo-2.0-1 and libfoo2-2.0-1, and user can choose either one or even > both, and decide which to make available to apps"? Or you want > packages to switch back and forth automatically between alternative > implementations of the same interface? Redundancy instead of reuse. We > don't talk about the same problem, I'm afraid. It is beyond my time to > extend this thread much further and in pure text form into something > completely theoretical that would require fundamental changes to the > RPM dependencies system. You're right. I wasn't talking about the general case. I was postulating things for people who actually might find systems like that useful. I'm actually thankful that alternatives exist and am glad that no one has argued to have it removed with the argument that only one system should ever exist. I am not arguing for time and effort be contributed to catering to this particular endeavor. I just ask that if something is useful to other people and not to others, then people should refrain from making non-constructive remarks. If people actually find it useful and worth discussing, then the thread will grow at its pace. If not, then just let it die out. As for myself, I asked if anyone knows how to change a process's environment variable from outside that process. Or if there are other ways to effect a change in the run-time linker behavior for currently running processes (like shells) that might spawn new processes. Perhaps fedora-devel isn't the appropriate list, but it does have the best people to answer. I've seen worse off-topic and non-technical discussions grow on the list. At least the questions I ask might be useful to some people or the general public sometime down the line. -- Richi Plana From ssorce at redhat.com Fri Sep 21 17:05:23 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 21 Sep 2007 13:05:23 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190385929.2142.62.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D868.1020108@redhat.com> <1190385929.2142.62.camel@cutter> Message-ID: <1190394323.2567.169.camel@localhost.localdomain> On Fri, 2007-09-21 at 10:45 -0400, seth vidal wrote: > On Fri, 2007-09-21 at 10:42 -0400, Rob Crittenden wrote: > > seth vidal wrote: > > > On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: > > >> Matthew Miller wrote: > > >>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: > > >>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do > > >>>> anyway - create a top level path where they mount the large, local disks > > >>>> and put all their data. So they know on every system if they hit /etc > > >>>> and /srv with the backups they'll have what they should be worried > > >>>> about. All admins may not call it /srv but they do something like > > >>>> it: /fs, /local, /data, /srv > > >>>> > > >>>> it's all the same result. > > >>>> > > >>>> so while your argument for not using it in the distro is fine -the > > >>>> reality is that this is what is actually done by sysadmins all over the > > >>>> world. > > >>> +1 > > >>> > > >>> Thank you Seth. > > >>> > > >>> /var is transient data. There should be nothing there that needs backups. > > >>> And users shouldn't look there for files they might edit. > > >>> > > >> Transient and not backed up? What about /var/mail, /var/spool/cron and > > >> /var/log? > > > > > > - /var/log - shouldn't matter - it's being sent to centralized log hosts > > > which I've always had put files in /srv/logs > > > - /var/mail has no data - all your mail should be in your central mail > > > server and not in /var/mail but in another path /srv/mail or /srv/mqueue > > > often > > > > > > - /var/spool/cron doesn't have any files in it b/c users are not allowed > > > to add cron jobs except on highly specific systems. Moreover, if you're > > > adding root or system-controlled cron jobs they should go in /etc/cron.d > > > or in the /etc/cron.hourly, /etc/cron.daily, etc directories. > > > > > > never in /var/spool/cron and NEVER add by such a cumbersome tool as cron > > > -e > > > > Not everyone in the world sets things up like you do. The FHS explicitly > > sets these paths for these purposes. > > They may not, but they should. :) Delete my /var/lib/samba and I'll strangle you :-) Simo. From ssorce at redhat.com Fri Sep 21 17:15:30 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 21 Sep 2007 13:15:30 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> Message-ID: <1190394930.2567.173.camel@localhost.localdomain> On Fri, 2007-09-21 at 17:38 +0200, Nicolas Mailhot wrote: > Le Ven 21 septembre 2007 16:49, Ralf Corsepius a ?crit : > > >>From the FHS: > > Chapter 5. The /var Hierarchy > > Purpose > > /var contains variable data files. This includes spool directories and > > files, administrative and logging data, and transient and temporary > > files. > > And some transient files like spools may be backed up, but /var is not > for long-term data B******t. :-) 2 Directory Servers put data in there: /var/lib/dirsrv /var/lib/ldap IIRC also MySQL and PostsgreSQL put data under /var/lib I guess you care about your databases contents, do you? :-) From mario at targetdevelopment.at Fri Sep 21 17:39:26 2007 From: mario at targetdevelopment.at (DI Mario Bruckschwaiger) Date: Fri, 21 Sep 2007 19:39:26 +0200 Subject: new behavior of Logitech diNovo Edge keyboard In-Reply-To: <1190392839.7150.71.camel@pmac.infradead.org> References: <1190386735.2780.12.camel@rock> <1190392839.7150.71.camel@pmac.infradead.org> Message-ID: <1190396366.2880.6.camel@rock> On Fri, 2007-09-21 at 17:40 +0100, David Woodhouse wrote: > Is the host-side part of this hardware actually operating in Bluetooth > mode? Is hcid running? Is the input service running? Are there > interesting messages in /var/log/messages? What does 'hcidump -VX' show > when you start typing? Ok, bluetooth service is started but says "hcid is dead". And in the /var/log/messages there is the following: The first part is the normal recognition of the bluetooth receiver, the second part are the warnings, and the last part is my unplugging and plugging-in of the receiver. Sep 21 19:09:29 rock kernel: usb 3-2.2: configuration #1 chosen from 1 choice Sep 21 19:09:29 rock kernel: input: Logitech Logitech BT Mini-Receiver as /class/input/input1 Sep 21 19:09:29 rock kernel: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.1-2.2 Sep 21 19:09:29 rock kernel: ata1.00: configured for UDMA/33 Sep 21 19:09:29 rock kernel: usb 3-2.3: new full speed USB device using uhci_hcd and address 4 Sep 21 19:09:29 rock kernel: ata1.01: configured for UDMA/33 Sep 21 19:09:29 rock kernel: usb 3-2.3: configuration #1 chosen from 1 choice Sep 21 19:09:29 rock kernel: input: Logitech Logitech BT Mini-Receiver as /class/input/input2 Sep 21 19:09:29 rock kernel: input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.1-2.3 ..... Sep 21 19:09:29 rock kernel: Bluetooth: Core ver 2.11 Sep 21 19:09:29 rock kernel: NET: Registered protocol family 31 Sep 21 19:09:29 rock kernel: Bluetooth: HCI device and connection manager initialized Sep 21 19:09:29 rock kernel: Bluetooth: HCI socket layer initialized Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Not tainted) Sep 21 19:09:29 rock kernel: [] show_trace_log_lvl+0x1a/0x2f Sep 21 19:09:29 rock kernel: [] show_trace+0x12/0x14 Sep 21 19:09:29 rock kernel: [] dump_stack+0x16/0x18 Sep 21 19:09:29 rock kernel: [] hid_output_report+0x22b/0x2c3 Sep 21 19:09:29 rock kernel: [] hid_submit_ctrl+0x57/0x1cf Sep 21 19:09:29 rock kernel: [] usbhid_submit_report +0x145/0x168 Sep 21 19:09:29 rock kernel: [] hiddev_ioctl+0x360/0x8d6 Sep 21 19:09:29 rock kernel: [] do_ioctl+0x51/0x68 Sep 21 19:09:29 rock kernel: [] vfs_ioctl+0x249/0x25c Sep 21 19:09:29 rock kernel: [] sys_ioctl+0x49/0x64 Sep 21 19:09:29 rock kernel: [] syscall_call+0x7/0xb Sep 21 19:09:29 rock kernel: ======================= Sep 21 19:09:29 rock kernel: Bluetooth: L2CAP ver 2.8 Sep 21 19:09:29 rock kernel: Bluetooth: L2CAP socket layer initialized Sep 21 19:09:29 rock kernel: Bluetooth: RFCOMM socket layer initialized Sep 21 19:09:29 rock kernel: Bluetooth: RFCOMM TTY layer initialized Sep 21 19:09:29 rock kernel: Bluetooth: RFCOMM ver 1.8 Sep 21 19:09:29 rock kernel: usb 3-2.1: new full speed USB device using uhci_hcd and address 5 Sep 21 19:09:29 rock kernel: usb 3-2.1: configuration #1 chosen from 1 choice Sep 21 19:09:29 rock kernel: Bluetooth: HCI USB driver ver 2.9 Sep 21 19:09:29 rock kernel: usbcore: registered new interface driver hci_usb ..... Sep 21 19:09:58 rock kernel: usb 3-2: USB disconnect, address 2 Sep 21 19:09:58 rock kernel: usb 3-2.1: USB disconnect, address 5 Sep 21 19:09:58 rock kernel: usb 3-2.2: USB disconnect, address 3 Sep 21 19:09:58 rock kernel: usb 3-2.3: USB disconnect, address 4 Sep 21 19:10:01 rock kernel: usb 3-2: new full speed USB device using uhci_hcd and address 6 Sep 21 19:10:01 rock kernel: usb 3-2: configuration #1 chosen from 1 choice Sep 21 19:10:01 rock kernel: hub 3-2:1.0: USB hub found Sep 21 19:10:01 rock kernel: hub 3-2:1.0: 3 ports detected Sep 21 19:10:01 rock kernel: usb 3-2.2: new full speed USB device using uhci_hcd and address 7 Sep 21 19:10:01 rock kernel: usb 3-2.2: configuration #1 chosen from 1 choice Sep 21 19:10:01 rock kernel: input: Logitech Logitech BT Mini-Receiver as /class/input/input5 Sep 21 19:10:01 rock kernel: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.1-2.2 Sep 21 19:10:02 rock kernel: usb 3-2.3: new full speed USB device using uhci_hcd and address 8 Sep 21 19:10:02 rock kernel: usb 3-2.3: configuration #1 chosen from 1 choice Sep 21 19:10:02 rock kernel: input: Logitech Logitech BT Mini-Receiver as /class/input/input6 Sep 21 19:10:02 rock kernel: input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.1-2.3 Sep 21 19:10:08 rock gdm-binary[2729]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed Sep 21 19:10:08 rock gdm-binary[2729]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed Sep 21 19:10:08 rock gdm-binary[2729]: GLib-CRITICAL: g_key_file_free: assertion `key_file != NULL' failed From myfedora at richip.dhs.org Fri Sep 21 17:42:53 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 11:42:53 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <1190394930.2567.173.camel@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> Message-ID: <1190396573.23728.70.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 13:15 -0400, Simo Sorce wrote: > On Fri, 2007-09-21 at 17:38 +0200, Nicolas Mailhot wrote: > > Le Ven 21 septembre 2007 16:49, Ralf Corsepius a ?crit : > > > > >>From the FHS: > > > Chapter 5. The /var Hierarchy > > > Purpose > > > /var contains variable data files. This includes spool directories and > > > files, administrative and logging data, and transient and temporary > > > files. > > > > And some transient files like spools may be backed up, but /var is not > > for long-term data > > B******t. :-) > 2 Directory Servers put data in there: > /var/lib/dirsrv > /var/lib/ldap > IIRC also MySQL and PostsgreSQL put data under /var/lib > > I guess you care about your databases contents, do you? :-) Unless I miss my guess, they're only there because someone packaging things for Fedora put them there. I sincerely doubt that those individual applications actually recommend a default location for their database. Even if they did make a recommendation, that's what packagers like Fedora have to decide on and override if need be. The discussion is about coming up with a policy for where to place data files and not backing up (though certainly with an eye out for back-up policies, as well). Again, things to consider when deciding where to place things: 1) Back-up policy and convenience 2) Storage concerns 3) That this is just a default and can be overridden by anyone, but it makes it easy for any person who knows Fedora to administer any other Fedora box 4) FHS guidelines (what is Fedora's policy? Interpretation of certain vague statements) -- Richi Plana From rvinyard at cs.nmsu.edu Fri Sep 21 17:51:31 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 21 Sep 2007 11:51:31 -0600 Subject: [LICENSE CHANGE] tetex-IEEEtran Artistic->LPPL Message-ID: <46F404A3.9010204@cs.nmsu.edu> This doesn't provide any libraries and AFAIK there are no package dependencies downstream. From jam at zoidtechnologies.com Fri Sep 21 18:18:10 2007 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Fri, 21 Sep 2007 14:18:10 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <46F3E461.80709@gmail.com> References: <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> <46F3E461.80709@gmail.com> Message-ID: <20070921181810.GH21379@zoidtechnologies.com> On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote: > To say it once more. > > I think it is a good thing to *not* allow, by default, root GUI logins. > Those that want to do that can enable it. Those that can not figure out > how to enable it probably should not be doing it anyway. > -- > > David > I agree. +1. -- http://zoidtechnologies.com/ -- software that sucks less From ianburrell at gmail.com Fri Sep 21 18:14:13 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Fri, 21 Sep 2007 11:14:13 -0700 Subject: [RFC] /var versus /srv In-Reply-To: <1190396573.23728.70.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> Message-ID: On 9/21/07, Richi Plana wrote: > On Fri, 2007-09-21 at 13:15 -0400, Simo Sorce wrote: > > > > B******t. :-) > > 2 Directory Servers put data in there: > > /var/lib/dirsrv > > /var/lib/ldap > > IIRC also MySQL and PostsgreSQL put data under /var/lib > > > > I guess you care about your databases contents, do you? :-) > > Unless I miss my guess, they're only there because someone packaging > things for Fedora put them there. I sincerely doubt that those > individual applications actually recommend a default location for their > database. Even if they did make a recommendation, that's what packagers > like Fedora have to decide on and override if need be. > /var/lib/pgsql/data is the default location for PostgreSQL database when compiled with localstatedir as /var. /var isn't just for temporary files. It is all local writable data. Some of it is temporary and doesn't need to be backed up. Some it is your most critical data and better be backed up. - Ian From myfedora at richip.dhs.org Fri Sep 21 18:26:06 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 12:26:06 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <20070921181810.GH21379@zoidtechnologies.com> References: <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> <46F3E461.80709@gmail.com> <20070921181810.GH21379@zoidtechnologies.com> Message-ID: <1190399166.23728.77.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 14:18 -0400, jam at zoidtechnologies.com wrote: > On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote: > > To say it once more. > > > > I think it is a good thing to *not* allow, by default, root GUI logins. > > Those that want to do that can enable it. Those that can not figure out > > how to enable it probably should not be doing it anyway. > > -- > > > > David > > > > I agree. +1. I agree, as well. The important thing is for users to have access to GUI applications that would allow them to do their admin work. A lot of that is accomplished by accessing the same apps from System->Administration and authenticating themselves, or "su -"'ing from a terminal and executing X applications from there. They don't need a whole X session to achieve their goal of administering the machine. If they really want an X session as root for other reasons, then they can log on a console VT and "startx :1". But again, if root must be allowed to start an X session from gdm as policy, then let it be a stripped down session. -- Richi Plana From kwizart at gmail.com Fri Sep 21 15:08:02 2007 From: kwizart at gmail.com (KH KH) Date: Fri, 21 Sep 2007 17:08:02 +0200 Subject: [FHS] Directory for icc color profiles Message-ID: Hello! I've found that bug on http://www.pathname.com/fhs/ (given from man 7 hier ) http://bugs.freestandards.org/show_bug.cgi?id=77 The problem is: most profiles are installed with oyranos (currently in review ), but oyranos has an optionnal requires (xcalib), which also bundle icc profiles... The easy way would be to have xcalib to own icc profile directory (meant /usr/share/color/icc ) but if not installed, then the dir wouldn't be own... Another way would be to have it own by lcms. But the same problem appears, if ever lcms is getting uninstalled (icc profiles will be unusefull on the system then), packages that only bundle icc profiles won't have the directory owns by any package... So, i'm wondering if that directory could be own by filesystem...? oyranos have others directories in /usr/share/color /usr/share/color/cmms contains .xml file for backend with other apps /usr/share/color/settings/ contains xml profiles setting Anyway, oyranos is still in an alpha state, so when it will be stable, that might be desirable to have it with a FC-8-updates (if possible).. R?f?rences: xcalib review: https://bugzilla.redhat.com/show_bug.cgi?id=285351 oyranos review: https://bugzilla.redhat.com/show_bug.cgi?id=239936 From mattdm at mattdm.org Fri Sep 21 18:58:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Sep 2007 14:58:42 -0400 Subject: [RFC] /var versus /srv In-Reply-To: References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> Message-ID: <20070921185842.GA27796@jadzia.bu.edu> On Fri, Sep 21, 2007 at 11:14:13AM -0700, Ian Burrell wrote: > /var isn't just for temporary files. It is all local writable data. /var/home, eh? > Some of it is temporary and doesn't need to be backed up. Some it is > your most critical data and better be backed up. And there's the problem. That's a huge flaw. Worse, some of it is very space-consuming temporary data which should never be backed up. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Sep 21 18:59:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Sep 2007 14:59:48 -0400 Subject: [FHS] Directory for icc color profiles In-Reply-To: References: Message-ID: <20070921185948.GB27796@jadzia.bu.edu> On Fri, Sep 21, 2007 at 05:08:02PM +0200, KH KH wrote: > The easy way would be to have xcalib to own icc profile directory > (meant /usr/share/color/icc ) but if not installed, then the dir > wouldn't be own... > Another way would be to have it own by lcms. > But the same problem appears, if ever lcms is getting uninstalled (icc > profiles will be unusefull on the system then), packages that only > bundle icc profiles won't have the directory owns by any package... Can't they both own it? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Fri Sep 21 19:21:47 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 21 Sep 2007 15:21:47 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-09-21 Message-ID: <20070921192147.142F3152134@buildsys.fedoraproject.org> Broken upgrade path report for repositories From buildsys at fedoraproject.org Fri Sep 21 19:22:01 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 21 Sep 2007 15:22:01 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-09-21 Message-ID: <20070921192201.ECF37152134@buildsys.fedoraproject.org> Broken upgrade path report for repositories From buildsys at fedoraproject.org Fri Sep 21 19:23:25 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 21 Sep 2007 15:23:25 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-09-21 Message-ID: <20070921192325.C9AA01BDB7@buildsys.fedoraproject.org> Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6, FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8 apr-util: F7-updates-testing > F8 (0:1.2.10-1.fc7 > 0:1.2.10-1) aspell-fo: FC5 > F8 (50:0.51-4.2.1 > 50:0.2.16-6.fc8) FC6 > F8 (50:0.51-4.2.2 > 50:0.2.16-6.fc8) F7 > F8 (50:0.51-6.fc7 > 50:0.2.16-6.fc8) balsa: FE6 > F7-updates (0:2.3.20-1.fc6 > 0:2.3.17-2.fc7) clamav: F7-updates > F8 (0:0.91.2-2.fc7 > 0:0.91.2-1.fc8) cyrus-imapd: FE6 > F7 (0:2.3.9-6.fc6 > 0:2.3.8-3.fc7) eclipse-subclipse: FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8) F7-updates > F8 (0:1.2.4-1.fc7 > 0:1.2.2-6.fc8) fedora-usermgmt: FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) fslint: FE6 > F7-updates (0:2.24-1 > 0:2.22-1.fc7) gammu: FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcstar: FE6 > F7 (0:1.2.2-1.fc6 > 0:1.1.1-2.fc7) gtranslator: F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jrtplib: FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kanatest: FE6 > F7-updates (0:0.4.4-3 > 0:0.4.2-2.fc7) libextractor: FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgtop2: FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) lostirc: FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) mimetic: FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) monotone: FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) nethack-vultures: FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) nsd: F7-updates > F8 (0:3.0.6-3.fc7 > 0:3.0.6-2.fc8) nss_ldap: FC6-updates > F7 (0:257-3.fc6 > 0:254-2) perl-Net-Libdnet: F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) postgresql-pgpool-II: FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) python-cheetah: FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) python-setuptools: FE6 > F8 (0:0.6c7-1.fc6 > 0:0.6c6-2.fc8) F7-updates-testing > F8 (0:0.6c7-1.fc7 > 0:0.6c6-2.fc8) remind: FE6 > F7-updates-testing (0:03.01.02-2 > 0:03.01.02-1.fc7) specto: FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) tcptraceroute: FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) util-vserver: FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7) xmlrpc-c: FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7) From ville.skytta at iki.fi Fri Sep 21 19:37:48 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 21 Sep 2007 22:37:48 +0300 Subject: Package EVR problems in Fedora 2007-09-21 In-Reply-To: <20070921192325.C9AA01BDB7@buildsys.fedoraproject.org> References: <20070921192325.C9AA01BDB7@buildsys.fedoraproject.org> Message-ID: <200709212237.49090.ville.skytta@iki.fi> On Friday 21 September 2007, buildsys at fedoraproject.org wrote: > Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6, > FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8 Trimmed list of things affecting F8 is included below; with the F8 freeze looming, maintainers of these packages below should probably take action ASAP. In many cases F8/devel lags behind in upstream versions, not only minor revision bumps or disttag snafus or the like. Sorry about the two empty mails a few minutes ago, that was me running the script with wrong options (twice). Some preventive measures against this are already in CVS. > apr-util: > F7-updates-testing > F8 (0:1.2.10-1.fc7 > 0:1.2.10-1) > > aspell-fo: > FC5 > F8 (50:0.51-4.2.1 > 50:0.2.16-6.fc8) > FC6 > F8 (50:0.51-4.2.2 > 50:0.2.16-6.fc8) > F7 > F8 (50:0.51-6.fc7 > 50:0.2.16-6.fc8) > > clamav: > F7-updates > F8 (0:0.91.2-2.fc7 > 0:0.91.2-1.fc8) > > eclipse-subclipse: > FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8) > F7-updates > F8 (0:1.2.4-1.fc7 > 0:1.2.2-6.fc8) > > gammu: > FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) > F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) > > gtranslator: > F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) > > lostirc: > FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) > FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) > > nsd: > F7-updates > F8 (0:3.0.6-3.fc7 > 0:3.0.6-2.fc8) > > perl-Net-Libdnet: > F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) > > perl-Nmap-Parser: > F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) > > python-gammu: > FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) > FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) > > python-setuptools: > FE6 > F8 (0:0.6c7-1.fc6 > 0:0.6c6-2.fc8) > F7-updates-testing > F8 (0:0.6c7-1.fc7 > 0:0.6c6-2.fc8) > > specto: > FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) > F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) From lamont at gurulabs.com Fri Sep 21 19:49:40 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 21 Sep 2007 13:49:40 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <20070921185842.GA27796@jadzia.bu.edu> References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> <20070921185842.GA27796@jadzia.bu.edu> Message-ID: <20070921134940.608dcaaa@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 21 Sep 2007 14:58:42 -0400 Matthew Miller wrote: > On Fri, Sep 21, 2007 at 11:14:13AM -0700, Ian Burrell wrote: > > /var isn't just for temporary files. It is all local writable data. > > /var/home, eh? > > > Some of it is temporary and doesn't need to be backed up. Some it > > is your most critical data and better be backed up. > > And there's the problem. That's a huge flaw. > > Worse, some of it is very space-consuming temporary data which should > never be backed up. Not that I'm anyone of note, but I do teach Linux to lots of people every year. Most are from medium to gargantuan companies (including most of the Global 200/Fortune 500/some-other-third-self-important-category). I would say that at least 50% of my students (and their organizations) move things to /srv/ for the very reason of separating the "important to back up and keep" stuff from the "transitory, if we lose this its OK" parts. I put things like web, FTP, named and database under /srv/ and it does make life easier on a day-to-day basis. Some people might not think it would be easier for them. That's fine, let them use whatever other location they want. Seth was right though that many people create something even if they don't call it/use /srv/ as the path. Personally, I would like to see things like web, FTP, email, database, etc. that use /var/ currently be split out into /srv/. I understand that the FHS makes things confusing about some items. Either way, we defiantly don't want to get rid of something like /srv/ (even empty) that so many people find so useful. Sure, I can recreate the directory, but it's better to have a standard location so that we don't have everyone doing their own thing outside what the distribution provides in the first place. I might even go so far as to suggest that Fedora "officially" state that the /srv/ directory is meant for stuff you care about (please, don't ask me right now for final verbage). - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG9CBU+YBsl9wN1AkRAquiAJ9OYUu9G7gZrByerJb5HKw09zxNWQCgoU49 zyUnLGcnxp4bDiCSW1/OlgU= =QkYc -----END PGP SIGNATURE----- From lfarkas at bppiac.hu Fri Sep 21 19:51:02 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 21 Sep 2007 21:51:02 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190386380.2142.64.camel@cutter> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> <1190386380.2142.64.camel@cutter> Message-ID: <46F420A6.8000201@bppiac.hu> seth vidal ?rta: > On Fri, 2007-09-21 at 16:45 +0200, Farkas Levente wrote: >> seth vidal wrote: >>> On Fri, 2007-09-21 at 10:29 -0400, Rob Crittenden wrote: >>>> Matthew Miller wrote: >>>>> On Fri, Sep 21, 2007 at 09:19:43AM -0400, seth vidal wrote: >>>>>> As a sysadmin /srv is a useful thing - it's what most sysadmins do >>>>>> anyway - create a top level path where they mount the large, local disks >>>>>> and put all their data. So they know on every system if they hit /etc >>>>>> and /srv with the backups they'll have what they should be worried >>>>>> about. All admins may not call it /srv but they do something like >>>>>> it: /fs, /local, /data, /srv >>>>>> >>>>>> it's all the same result. >>>>>> >>>>>> so while your argument for not using it in the distro is fine -the >>>>>> reality is that this is what is actually done by sysadmins all over the >>>>>> world. >>>>> +1 >>>>> >>>>> Thank you Seth. >>>>> >>>>> /var is transient data. There should be nothing there that needs backups. >>>>> And users shouldn't look there for files they might edit. >>>>> >>>> Transient and not backed up? What about /var/mail, /var/spool/cron and >>>> /var/log? >>> - /var/log - shouldn't matter - it's being sent to centralized log hosts >>> which I've always had put files in /srv/logs >>> - /var/mail has no data - all your mail should be in your central mail >>> server and not in /var/mail but in another path /srv/mail or /srv/mqueue >>> often >>> >>> - /var/spool/cron doesn't have any files in it b/c users are not allowed >>> to add cron jobs except on highly specific systems. Moreover, if you're >>> adding root or system-controlled cron jobs they should go in /etc/cron.d >>> or in the /etc/cron.hourly, /etc/cron.daily, etc directories. >>> >>> never in /var/spool/cron and NEVER add by such a cumbersome tool as cron >> i agree with you about /srv, but not with the above. do you have any >> system with real users? why don't you allow cron jobs for normal users??? > > systems get reinstalled frequently. Therefore cron jobs get nuked and > end up causing pain. There are central servers they can install cron > jobs on - but not any random box on the network. ohh nooo! first of all we talk about workstation or server? if you reinstall servers frequantly then probably you're a good sysadm and can desing your servers in an advance way:-). what's more you probably don't save /var/lib/mysql just dump it and don't save /var/named neither /var/spool/postfix (probably all of your mails on a real server can delivered right at send time and all of you queues are empty) your /var/cache/samba don't contains any useful info (have you ever use samba?). so imho you write it too fast or you've a bad day like me:-( From dgboles at gmail.com Fri Sep 21 19:08:42 2007 From: dgboles at gmail.com (David Boles) Date: Fri, 21 Sep 2007 15:08:42 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190399166.23728.77.camel@localhost6.localdomain6> References: <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> <46F3E461.80709@gmail.com> <20070921181810.GH21379@zoidtechnologies.com> <1190399166.23728.77.camel@localhost6.localdomain6> Message-ID: <46F416BA.6070908@gmail.com> on 9/21/2007 2:26 PM, Richi Plana wrote: > On Fri, 2007-09-21 at 14:18 -0400, jam at zoidtechnologies.com wrote: >> On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote: >>> To say it once more. >>> >>> I think it is a good thing to *not* allow, by default, root GUI logins. >>> Those that want to do that can enable it. Those that can not figure out >>> how to enable it probably should not be doing it anyway. >>> -- >>> >>> David >>> >> I agree. +1. > > I agree, as well. The important thing is for users to have access to GUI > applications that would allow them to do their admin work. A lot of that > is accomplished by accessing the same apps from System->Administration > and authenticating themselves, or "su -"'ing from a terminal and > executing X applications from there. They don't need a whole X session > to achieve their goal of administering the machine. > > If they really want an X session as root for other reasons, then they > can log on a console VT and "startx :1". > > But again, if root must be allowed to start an X session from gdm as > policy, then let it be a stripped down session. The stripped down session that you propose would be ok. But then you will start a 'flame' about just what this session should contain. ;-) -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From myfedora at richip.dhs.org Fri Sep 21 20:11:39 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 14:11:39 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <46F416BA.6070908@gmail.com> References: <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> <46F3E461.80709@gmail.com> <20070921181810.GH21379@zoidtechnologies.com> <1190399166.23728.77.camel@localhost6.localdomain6> <46F416BA.6070908@gmail.com> Message-ID: <1190405499.23728.81.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 15:08 -0400, David Boles wrote: > The stripped down session that you propose would be ok. But then you will > start a 'flame' about just what this session should contain. ;-) Well, we can always start with X and twm then slowly change or add things, ;). There's already a proposal to give them at least metacity and lxpanel. I dunno ... that seems a lot, ;). In effect, it would be like kids asking for a little bit more at a time proving along the way that it's needed. :) -- Richi From myfedora at richip.dhs.org Fri Sep 21 20:32:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 14:32:26 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <20070921134940.608dcaaa@reaver.lamontpeterson.net> References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> <20070921185842.GA27796@jadzia.bu.edu> <20070921134940.608dcaaa@reaver.lamontpeterson.net> Message-ID: <1190406746.23728.99.camel@localhost6.localdomain6> On Fri, 2007-09-21 at 13:49 -0600, Lamont Peterson wrote: > I might even go so far as to suggest that Fedora "officially" state > that the /srv/ directory is meant for stuff you care about (please, > don't ask me right now for final verbage). Same thing I've been saying, but it's only now that I realized that I've been assuming the wrong thing. When I read FHS, in my mind, I was thinking LSB. So here I was thinking that Fedora was simply following some guidelines set up by the FSB for its directory hierarchy. Now that I know that FHS refers to the Fedora Hierarchy Structure, this changes a few things. As I said, I thought it referred to an LSB guideline which made me think Fedora could be flexible with its interpretation and implementation. Now that I've read up on the FHS, I have to say that it needs reworking if only because some of the things it states contradict others. For instance, it states that /srv is for "Data for services provided by this system". Unfortunately, FHS isn't too comprehensive. It doesn't separate, for instance, mail services as used by the system from mail services provided to clients of the server (which could be provided as one-to-one Unix user to email account or just as a virtual user on top of the email system). There's a distinction between the two that's being left to people to argue over. As I read more of what FHS stipulates, it gives me the impression that it was designed for a particular use-case scenario (it talks about some directories being shareable and some not, obviously with a certain scenario in mind ... traditional Unix). Personally, I think this discussion should be brought back to FHS and a recommendation be made that it narrow down its guidelines to first what is common in all Fedora systems, and if it must add additional uses (like multi-user desktops, email services, database, web, ftp, DNS, NTP, etc.) that it tack those on separately and on top of the core filesystem use. From dgboles at gmail.com Fri Sep 21 20:38:20 2007 From: dgboles at gmail.com (David Boles) Date: Fri, 21 Sep 2007 16:38:20 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190405499.23728.81.camel@localhost6.localdomain6> References: <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> <46F3D3EA.4080208@redhat.com> <46F3E461.80709@gmail.com> <20070921181810.GH21379@zoidtechnologies.com> <1190399166.23728.77.camel@localhost6.localdomain6> <46F416BA.6070908@gmail.com> <1190405499.23728.81.camel@localhost6.localdomain6> Message-ID: <46F42BBC.3000006@gmail.com> on 9/21/2007 4:11 PM, Richi Plana wrote: > On Fri, 2007-09-21 at 15:08 -0400, David Boles wrote: >> The stripped down session that you propose would be ok. But then you will >> start a 'flame' about just what this session should contain. ;-) > > Well, we can always start with X and twm then slowly change or add > things, ;). There's already a proposal to give them at least metacity > and lxpanel. I dunno ... that seems a lot, ;). > > In effect, it would be like kids asking for a little bit more at a time > proving along the way that it's needed. :) Which is pretty much what I said. ;-) I don't know why it is but most Linux users, not *ALL* of us, have this mindset that Linux, and the developers, owe us this great debt of gratitude because we use the software that they so generously work on for next to nothing and give to us for free. 8-) -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From greno at verizon.net Fri Sep 21 20:34:37 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 21 Sep 2007 16:34:37 -0400 Subject: iptables: rate limiting problem Message-ID: <46F42ADD.1000509@verizon.net> I've been trying to get some rate limiting working with my Fedora firewall. I needed to open up SSH externally on one machine so I wanted to put some rate limiting into my Fedora 7 iptables for SSH, but it refuses to work. Here's what I have: # iptables -L -n --line-numbers ... Chain RH-Firewall-1-INPUT (1 references) ... 16 tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 recent: SET name: DEFAULT side: source 17 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source 18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 19 REJECT 0 -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited If I take out the two 'recent' rules then I can login via SSH on port 33322. But with the rules in I get a timeout and 'connection closed' when I try to login via ssh on port 33322. Here's the rules: iptables -I RH-Firewall-1-INPUT 16 -i eth0 -m state --state NEW -p tcp --dport 33322 -m recent --set iptables -I RH-Firewall-1-INPUT 17 -i eth0 -m state --state NEW -p tcp --dport 33322 -m recent --update --seconds 60 --hitcount 4 -j DROP iptables -I RH-Firewall-1-INPUT 18 -i eth0 -m state --state NEW -p tcp --dport 33322 -j ACCEPT Ok, what I've found is that if I set the 'hit_count' high to say 100 then I can login but the connection dies very quickly (actually it just hangs). So I think the limit rule is applying to more than just NEW packets. The higher that I set 'hit_count' the longer the connection will last. So is there something wrong with the way I've implemented this or is this a bug in iptables? ???? Gerry From kevin.kofler at chello.at Fri Sep 21 20:47:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 21 Sep 2007 20:47:37 +0000 (UTC) Subject: Package EVR problems in Fedora 2007-09-21 References: <20070921192325.C9AA01BDB7@buildsys.fedoraproject.org> <200709212237.49090.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > > aspell-fo: > > FC5 > F8 (50:0.51-4.2.1 > 50:0.2.16-6.fc8) > > FC6 > F8 (50:0.51-4.2.2 > 50:0.2.16-6.fc8) > > F7 > F8 (50:0.51-6.fc7 > 50:0.2.16-6.fc8) This one needs an Epoch bump. By the way, the current version is 0.2.30 according to Freshmeat. Kevin Kofler From johan at x-tnd.be Fri Sep 21 21:26:51 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Fri, 21 Sep 2007 23:26:51 +0200 Subject: SELinux for BackupPC In-Reply-To: <46F003AA.4060207@redhat.com> References: <46EAEFE4.1080403@x-tnd.be> <46F003AA.4060207@redhat.com> Message-ID: <46F4371B.4050600@x-tnd.be> Hello, First of all, thanks for your advices. It seems that I've not used the right approach for this policy module. I was using the following : grep http /var/log/audit/audit.log | audit2allow -M mybackuppc But this command also catches SELinux denies which are not relevant to BackupPC. So, I've restarted from scratch, and now use : audit2allow -m BackupPC -l -i /var/log/audit/audit.log > BackupPC.te Which only takes the latests entries. This way, I've removed some entries I did not understand (such as iso9660_t), and were not appropriate here. Daniel J Walsh a ?crit : > No alot of these rules are not good. Could you attach the audit log you > used to create this. These rules were build on two different machines (my laptop and the one were BackupPC is installed for backups). So as I've rebuild my rules from scratch, the log file is available on my web server (see links below). > > You probably need a context for this > > allow httpd_t etc_t:dir write; > and these > allow httpd_t usr_t:dir { write add_name }; > allow httpd_t usr_t:file { write create }; > > Could be as simple as > > chcon -t httpd_sys_content_rw_t PATHTODIR These one gives me an invalid argument... I've used "httpd_sys_script_rw_t" instead, am I right ? Also, I were able to remove these three 'allow' entries from my .te and put only the context in .fc file. > > I take it this is the socket file that BackupPC is creating. I think > you need a policy for this, and then BackupPC could label it > appropriately and allow httpd to communicate with it. > > allow httpd_t initrc_t:unix_stream_socket connectto; > allow httpd_t var_log_t:sock_file write; Indeed, these ones are for the .sock file BackupPC creates at startup. I don't understand what exactly you mean by 'a policy for this'... > Not sure what these are either. > > allow httpd_t httpd_log_t:sock_file write; > allow httpd_t httpd_sys_content_t:sock_file write; It's only a mistake, I had first to put 'sock_file write' for the .sock file, and then I've changed its context. Doing this, the first rule becomes obsolete, and audit2allow gave me the second... New file are here : - audit.log : http://odysseus.x-tnd.be/fedora/backuppc/audit.log - .te file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te - .fc file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.fc - old .te and .fc (from my preceding message) : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te.old - spec file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec All seems to work correctly with these rules, I wish I made no mistakes this time... :-) Regards, Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From mjs at CLEMSON.EDU Fri Sep 21 21:38:22 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 21 Sep 2007 17:38:22 -0400 Subject: Experiences with F8T2 on Thinkpad T61 Message-ID: <1190410702.5762.26.camel@valkyrie.localdomain> My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64 live dvd and installed the x86_64 DVD. This message covers platform-specific issues that I encountered. Live DVD: - The DVD won't boot into X. If I boot to runlevel 3 and attempt to system-config-display, there are two problems. (1) The Monitor section of xorg.conf is missing. (2) The nv driver hangs with a black screen. The keyboard is still functional and I can reboot with -- --. Hand-editing xorg.conf to create a Monitor section and using the vesa driver restores X functionality. - I used gparted to resize NTFS partitions and partition the drive. It hung at the end of the resize operation without confirming it is finished (although the operation appears to have completed). Also, gparted quits after the rescan step after each operation set. Installation: - Have to install with "vesa" kernel option. The nv driver boots to a black screen. - On the Disk Druid screen, the screen is not repainted after opening and closing popups. - The display is only configured for 800x600. Post-Installation: - Display issues (as above--nv driver and Monitor detection don't work). The new nv drivers don't help. - Screen brightness is erratic. The screen brightness applet appears, but whatever controls I hit, brightness changes randomly up or down and does not get fully bright or dim. If I switch to a VC, I can control the brightness, but ^@ characters appear on the display. - X server doesn't terminate on logout--I have to -- to kill it. - Suspend doesn't work at all. Select Suspend from the power applet and the machine starts to suspend, the light comes on, then the light goes off and the machine is live, except that the display is black. I can reboot as above. - Hibernate appears to work, but on resume I get a message that hibernate failed. - Stopping the bluetooth service on reboot or shutdown fails, although starting on bootup succeeds. Have not tested bluetooth functionality otherwise. Can anyone confirm these behaviors and that they are bugs? I'll file them, if so. Workarounds welcome too. There are some other issues I'll post later, but they don't seem hardware related. From otto_rey at yahoo.com.ar Fri Sep 21 21:40:48 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Fri, 21 Sep 2007 14:40:48 -0700 (PDT) Subject: Root login in rawhide and display managers Message-ID: <487649.73721.qm@web52409.mail.re2.yahoo.com> Since Fedora 3 (in some configurations) post-installation wizard (Anaconda?) have a keyboard bug (garbage characters), when ask names to add users. So, cannot add users in wizard. Need to log in as root and add users "manually". If we disable root login in graphical enviroment, we can add using command line, like a workaround, but not all users have strong skills in console. ----- Mensaje original ---- De: David Boles Para: Development discussions related to Fedora Enviado: viernes 21 de septiembre de 2007, 17:38:20 Asunto: Re: Root login in rawhide and display managers on 9/21/2007 4:11 PM, Richi Plana wrote: > On Fri, 2007-09-21 at 15:08 -0400, David Boles wrote: >> The stripped down session that you propose would be ok. But then you will >> start a 'flame' about just what this session should contain. ;-) > > Well, we can always start with X and twm then slowly change or add > things, ;). There's already a proposal to give them at least metacity > and lxpanel. I dunno ... that seems a lot, ;). > > In effect, it would be like kids asking for a little bit more at a time > proving along the way that it's needed. :) Which is pretty much what I said. ;-) I don't know why it is but most Linux users, not *ALL* of us, have this mindset that Linux, and the developers, owe us this great debt of gratitude because we use the software that they so generously work on for next to nothing and give to us for free. 8-) -- David Los referentes m?s importantes en compra/ venta de autos se juntaron: Demotores y Yahoo! Ahora comprar o vender tu auto es m?s f?cil. Vist? ar.autos.yahoo.com/ From jkeating at redhat.com Fri Sep 21 21:45:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 17:45:56 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <487649.73721.qm@web52409.mail.re2.yahoo.com> References: <487649.73721.qm@web52409.mail.re2.yahoo.com> Message-ID: <20070921174556.0462081b@redhat.com> On Fri, 21 Sep 2007 14:40:48 -0700 (PDT) Otto Rey wrote: > Since Fedora 3 (in some configurations) post-installation wizard > (Anaconda?) have a keyboard bug (garbage characters), when ask names > to add users. So, cannot add users in wizard. Need to log in as root > and add users "manually". If we disable root login in graphical > enviroment, we can add using command line, like a workaround, but not > all users have strong skills in console. Have you filed a bug or tracked down what configuration this happens in? (specific language/keyboard layout?) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Sep 21 21:55:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 23:55:21 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <46F420A6.8000201@bppiac.hu> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <46F3D91A.3050002@bppiac.hu> <1190386380.2142.64.camel@cutter> <46F420A6.8000201@bppiac.hu> Message-ID: <1190411721.9470.11.camel@rousalka.dyndns.org> Le vendredi 21 septembre 2007 ? 21:51 +0200, Farkas Levente a ?crit : > ohh nooo! first of all we talk about workstation or server? if you > reinstall servers frequantly then probably you're a good sysadm and can > desing your servers in an advance way:-). what's more you probably don't > save /var/lib/mysql just dump it and don't save /var/named neither > /var/spool/postfix (probably all of your mails on a real server can > delivered right at send time and all of you queues are empty) your > /var/cache/samba don't contains any useful info (have you ever use samba?). > so imho you write it too fast or you've a bad day like me:-( Get real, very few systems are under 24/24 replication to some other remote or secure system. Most of them get backuped daily or weekly. Right now /var mixes : 1. data that can be safely lost/erased at any time (caches) 2. data that the admin should work a little harder to protect (for example, it should never be erased on reboot) but is transient by nature. For example mail/print spools. It's pretty useless to backup them because their state is almost certain to have changed by the time the system has crashed, and if your restore the nightly/weekly backup you'll probably only re-queue data that was already moved somewhere else 3. long-term data. That's what people move to /srv or a separate root - it absolutely requires specific backup policies, and because it's served from this particular system you won't find it anywhere else in case of problem -- 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 martin.sourada at seznam.cz Fri Sep 21 22:12:58 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 22 Sep 2007 00:12:58 +0200 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190410702.5762.26.camel@valkyrie.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> Message-ID: <1190412778.19809.109.camel@pc-notebook> On Fri, 2007-09-21 at 23:38 +0200, Matthew Saltzman wrote: > - Hibernate appears to work, but on resume I get a message that > hibernate failed. > I get the same on Acer TM2490. I do it though with NetworkManager turned off, because last time I tried it with it (a month ago or so) it got frozen in resume... -------------- 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 johannbg at hi.is Fri Sep 21 22:40:41 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Fri, 21 Sep 2007 22:40:41 -0000 (GMT) Subject: [RFC] /var versus /srv In-Reply-To: <20070921134940.608dcaaa@reaver.lamontpeterson.net> References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> <20070921185842.GA27796@jadzia.bu.edu> <20070921134940.608dcaaa@reaver.lamontpeterson.net> Message-ID: <11847.88.149.97.225.1190414441.squirrel@webmail.hi.is> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 21 Sep 2007 14:58:42 -0400 > Matthew Miller wrote: > >> On Fri, Sep 21, 2007 at 11:14:13AM -0700, Ian Burrell wrote: >> > /var isn't just for temporary files. It is all local writable data. >> >> /var/home, eh? >> >> > Some of it is temporary and doesn't need to be backed up. Some it >> > is your most critical data and better be backed up. >> >> And there's the problem. That's a huge flaw. >> >> Worse, some of it is very space-consuming temporary data which should >> never be backed up. > > Not that I'm anyone of note, but I do teach Linux to lots of people every > year. Most are from medium to gargantuan companies (including most of the > Global 200/Fortune 500/some-other-third-self-important-category). I would > say that at least 50% of my students (and their organizations) move things > to /srv/ for the very reason of separating the "important to back up and > keep" stuff from the "transitory, if we lose this its OK" parts. > > I put things like web, FTP, named and database under /srv/ and it does > make life easier on a day-to-day basis. Some people might not think it > would be easier for them. That's fine, let them use whatever other > location they want. Seth was right though that many people create > something even if they don't call it/use /srv/ as the path. > > Personally, I would like to see things like web, FTP, email, database, > etc. that use /var/ currently be split out into /srv/. I understand that > the FHS makes things confusing about some items. Either way, we defiantly > don't want to get rid of something like /srv/ (even empty) that so many > people find so useful. Sure, I can recreate the directory, but it's > better to have a standard location so that we don't have everyone doing > their own thing outside what the distribution provides in the first place. > > I might even go so far as to suggest that Fedora "officially" state that > the /srv/ directory is meant for stuff you care about (please, don't ask > me right now for final verbage). > - -- > Lamont Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > > NOTE: All messages from this email address should be digitally signed > with my > 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as > well as other keyservers that sync with MIT's. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFG9CBU+YBsl9wN1AkRAquiAJ9OYUu9G7gZrByerJb5HKw09zxNWQCgoU49 > zyUnLGcnxp4bDiCSW1/OlgU= > =QkYc > -----END PGP SIGNATURE----- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > If it's not needed/used by the system remove it PERIOD! Is Fedora hatching M$ admins now if it's not there for them they cant create it, let the admins or the people that use it manually create the directory. just in case admins have forgotten it man mkdir .... ****sight**** Best regards Johann B. From myfedora at richip.dhs.org Fri Sep 21 22:47:37 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 16:47:37 -0600 Subject: iptables: rate limiting problem In-Reply-To: <46F42ADD.1000509@verizon.net> References: <46F42ADD.1000509@verizon.net> Message-ID: <1190414857.23728.109.camel@localhost6.localdomain6> At first I was going to reply off-list thinking it had nothing to do with fedora, but afterwards I thought that Gerry might be using rawhide and something there might be causing it. On Fri, 2007-09-21 at 16:34 -0400, Gerry Reno wrote: > I needed to open up SSH externally on one machine so I wanted to put > some rate limiting into my Fedora 7 iptables for SSH, but it refuses to > work. > > Here's what I have: > > # iptables -L -n --line-numbers > ... > Chain RH-Firewall-1-INPUT (1 references) > ... > 16 tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 recent: SET > name: DEFAULT side: source > 17 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 recent: > UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source > 18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:33322 > 19 REJECT 0 -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited > > > If I take out the two 'recent' rules then I can login via SSH on port > 33322. But with the rules in I get a timeout and 'connection closed' > when I try to login via ssh on port 33322. > > Here's the rules: > iptables -I RH-Firewall-1-INPUT 16 -i eth0 -m state --state NEW -p tcp > --dport 33322 -m recent --set > iptables -I RH-Firewall-1-INPUT 17 -i eth0 -m state --state NEW -p tcp > --dport 33322 -m recent --update --seconds 60 --hitcount 4 -j DROP > iptables -I RH-Firewall-1-INPUT 18 -i eth0 -m state --state NEW -p tcp > --dport 33322 -j ACCEPT > > Ok, what I've found is that if I set the 'hit_count' high to say 100 > then I can login but the connection dies very quickly (actually it just > hangs). So I think the limit rule is applying to more than just NEW > packets. The higher that I set 'hit_count' the longer the connection > will last. So is there something wrong with the way I've implemented > this or is this a bug in iptables? If packet-dropping is indeed what you're experiencing, it either has nothing to do with those rules, or there's a bug in the IPv4 packet filtering implementation. I use pretty much the same rules as you do except that I name the list of IP addresses using "--name" as opposed to using the DEFAULT (in case it collides with other rules that use "-m recent"). Try to eliminate other possibilities (like faulty network conditions) then list down all the rules. If everything's alright, you might want to try the LOG or ULOG target for all rules that DROP and find out what's 'causing it. -- Richi Plana From kevin.kofler at chello.at Fri Sep 21 23:31:59 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 21 Sep 2007 23:31:59 +0000 (UTC) Subject: keyring primer? KDE? References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <1190186067.3904.151.camel@localhost.localdomain> <1366.71.208.55.155.1190342965.squirrel@www.cora.nwra.com> Message-ID: cora.nwra.com> writes: > Anything for KDE and Kwallet? KWallet allows passwordless keyrings. If you don't want to enter a password to unlock the keyring, that's the way. It's not for the paranoid of course, but a keyring with the same password as your user account and unlocked automatically as you log in is hardly any more secure. Kevin Kofler From snecklifter at gmail.com Fri Sep 21 23:57:22 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 22 Sep 2007 00:57:22 +0100 Subject: dmraid triage In-Reply-To: <1190357045.3446.1.camel@dawkins> References: <1190346959.4408.14.camel@home-desk> <1190357045.3446.1.camel@dawkins> Message-ID: <364d303b0709211657q32389e1eq89160d08b817150c@mail.gmail.com> On 21/09/2007, David Nielsen wrote: > > > tor, 20 09 2007 kl. 20:55 -0700, skrev Sean Bruno: > > Is anyone doing dmraid breakage triage for test 2? > > > > If not, I'd like to help out. > > If you can call it triaging to install on my dmraid then yes. I try to > hit every test release to see if it blows up and I file day to day > breakage. However the QA team always welcomes more testers. Here's a start from your friendly Kernel Triage Team :) https://bugzilla.redhat.com/show_bug.cgi?id=250177 Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngompa13 at gmail.com Sat Sep 22 00:02:10 2007 From: ngompa13 at gmail.com (King InuYasha) Date: Fri, 21 Sep 2007 19:02:10 -0500 Subject: Need to be responsored for package review of OggConvert (bugid: 244623) Message-ID: <8278b1b0709211702p117e7b40oa2ea623ffdcf99d6@mail.gmail.com> Hello, I had a conversation with Brian Pepple last week, which he stated he may not be able to continue sponsorship of my package to get it through to be accepted in Fedora. Can someone else take up sponsorship for me? Thanks, Neal Gompa (King InuYasha) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rnicholsNOSPAM at comcast.net Sat Sep 22 01:14:33 2007 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Fri, 21 Sep 2007 20:14:33 -0500 Subject: [RFC] /var versus /srv In-Reply-To: <20070921185842.GA27796@jadzia.bu.edu> References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> <20070921185842.GA27796@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Fri, Sep 21, 2007 at 11:14:13AM -0700, Ian Burrell wrote: >> /var isn't just for temporary files. It is all local writable data. > > /var/home, eh? Yes. # mount | grep home /var/home on /home type none (rw,bind) # -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From a.badger at gmail.com Sat Sep 22 02:47:28 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 21 Sep 2007 19:47:28 -0700 Subject: diff between Fedora + EPEL builds (python) In-Reply-To: References: <1190336484.4318.3.camel@localhost.localdomain> Message-ID: <46F48240.1020604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neal Becker wrote: > Jeremy Katz wrote: > >> On Thu, 2007-09-20 at 20:09 -0400, Neal Becker wrote: >>> I'm having trouble updating mecurial. I pushed an update to F-7 and >>> devel. >>> It doesn't build on EL-4 though. The problem seems to be, that python >>> setup.py build/install creates .pyc/.pyo on F-7 and devel, but not on >>> EL-4. Then, I get 'file not found by glob' for the missing files. I >>> also >>> tried %ghost on them, but EL-4 still complains they're missing. Anyone >>> know what this is about and maybe how to fix it? I'd like to make >>> mercurial for EL-4. >> RHEL4 doesn't do automatic byte-compiling of .py files. You can change >> the invocation of the setup install to be -O2 instead of -O1 to get >> the .pyo files generated as well >> don't use -O2. -O1 is sufficient to generate optimized files. -O2 compiles the extensions without docstrings. This can cause runtime problems if the code depends on the existence of docstrings. > > Thanks - but still fails. Acutally, it doesn't generate .pyc or .pyo. > Still not sure how to fix this. > > See: > http://buildsys.fedoraproject.org/logs/fedora-4-epel/36416-mercurial-0.9.4-7.el4/i386/build.log > - From the build log it looks like there's a couple things going on: 1) Unrelated, you should specify CFLAGS to the build so that you pick up FORTIFY_SOURCE and other Fedora standard cflags:: CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build 2) The main portion of the package appears to be installed with byte compiled files just fine. It's only files in /usr/share/mercurial/contrib/ that seem to have the problem. I highly suspect that you should be moving that whole directory into %doc and globbing the whole thing. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9IJAX6yAic2E7kgRAhIcAJ9E83orR3BEu2JXUL0TFQz5U9rb8wCfenFr DPO+MiR+9/4rCQkR7zRJwVA= =2lub -----END PGP SIGNATURE----- From myfedora at richip.dhs.org Sat Sep 22 05:13:13 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 21 Sep 2007 23:13:13 -0600 Subject: lesswatts.org Message-ID: <1190437993.9010.5.camel@localhost6.localdomain6> Hi, Of the several projects hosted on http://www.lesswatts.org/ (PowerTOP, Tickless Idle, Processor Power Management, Battery Life Toolkit, Power Policy Manager, Power QoS, Display and Graphics Power Savings, Device and Bus Power Management, ACPICA) how many are currently packages for Fedora? What are they called? How are they identified? Do they belong in any particular software group? Some are kernel patches so are they in any existing Fedora kernel? -- Richi Plana From skvidal at fedoraproject.org Sat Sep 22 06:23:05 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 22 Sep 2007 02:23:05 -0400 Subject: lesswatts.org In-Reply-To: <1190437993.9010.5.camel@localhost6.localdomain6> References: <1190437993.9010.5.camel@localhost6.localdomain6> Message-ID: <1190442185.2166.16.camel@cutter> On Fri, 2007-09-21 at 23:13 -0600, Richi Plana wrote: > Hi, > > Of the several projects hosted on http://www.lesswatts.org/ (PowerTOP, > Tickless Idle, Processor Power Management, Battery Life Toolkit, Power > Policy Manager, Power QoS, Display and Graphics Power Savings, Device > and Bus Power Management, ACPICA) how many are currently packages for > Fedora? What are they called? How are they identified? Do they belong in > any particular software group? Some are kernel patches so are they in > any existing Fedora kernel? yum search thing_you_want_to_find try it. -sv From buildsys at fedoraproject.org Sat Sep 22 06:56:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 22 Sep 2007 02:56:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-22 Message-ID: <20070922065630.A2E4C1BDB7@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 10 cacti-0.8.6j-9.fc6 NEW flpsed-0.5.0-3.fc6 : WYSIWYG pseudo PostScript editor fuse-2.7.0-5.fc6 NEW haproxy-1.3.12.2-2.fc6 : HA-Proxy is a TCP/HTTP reverse proxy for high availability environments NEW jlint-1.23-1.fc6 : Java program checker libsndfile-1.0.17-2.fc6 ntfs-3g-1.913-2.fc6 svnkit-1.1.4-2.fc6 tetex-IEEEtran-1.7.1-1.fc6 zabbix-1.4.2-2.fc6 Changes in Fedora Extras 6: cacti-0.8.6j-9.fc6 ------------------ * Fri Sep 21 2007 Mike McGrath - 0.8.6j-9 - Added rest of official patches flpsed-0.5.0-3.fc6 ------------------ * Wed Sep 05 2007 Nicholas Boyle - 0.5.0-3 -Corrected license version to match source -Added dependency for ghostscript -Built files are now globbed, rather than specified explicitly by name fuse-2.7.0-5.fc6 ---------------- * Fri Sep 21 2007 Tom "spot" Callaway 2.7.0-5 - revert udev rules change * Thu Sep 20 2007 Tom "spot" Callaway 2.7.0-4 - change udev rules so that /dev/fuse is chmod 666 (bz 298651) haproxy-1.3.12.2-2.fc6 ---------------------- * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-2 - update License field * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-1 - update to 1.3.12.2 - remove the upstream patch * Tue Sep 18 2007 Jeremy Hinegardner - 1.3.12.1-1 - switch to 1.3.12.1 branch - add patch from upstream with O'Reilly licensing updates. - convert ISO-8859-1 doc files to UTF-8 jlint-1.23-1.fc6 ---------------- * Tue Sep 18 2007 Jerry James - 1.23-1 - Initial RPM after rescuing jlint from its orphaned state libsndfile-1.0.17-2.fc6 ----------------------- * Thu Sep 20 2007 Andreas Thienemann - 1.0.17-2 - Adding FLAC support to libsndfile courtesy of gentoo, #237575 - Fixing CVE-2007-4974. Thanks to the gentoo people for the patch, #296221 ntfs-3g-1.913-2.fc6 ------------------- * Thu Sep 20 2007 Tom "spot" Callaway 2:1.913-2 - don't set /sbin/mount.ntfs-3g setuid svnkit-1.1.4-2.fc6 ------------------ * Thu Sep 20 2007 Robert Marcano - 1.1.4-2 - Fix Obsoletes to include javasvn = 1.1.0 tetex-IEEEtran-1.7.1-1.fc6 -------------------------- * Thu Sep 20 2007 Rick L Vinyard Jr - 1.7.1-1 - New upstream release 1.7a reversioned to 1.7.1 (missed 1.7.0 rel) - Changed download URL to generic CTAN - Don't need to move tux.eps for it to be included in docs - removed - Added changelog.txt to docs - Updated license to LPPL zabbix-1.4.2-2.fc6 ------------------ * Thu Sep 20 2007 Dan Horak 1.4.2-2 - Fix paths (%_bindir -> %_sbindir) in init scripts (#297061) - Add a patch to clean a warning during compile - Add a patch to fix cpu load computations From dwalsh at redhat.com Sat Sep 22 10:46:39 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 22 Sep 2007 06:46:39 -0400 Subject: SELinux for BackupPC In-Reply-To: <46F4371B.4050600@x-tnd.be> References: <46EAEFE4.1080403@x-tnd.be> <46F003AA.4060207@redhat.com> <46F4371B.4050600@x-tnd.be> Message-ID: <46F4F28F.9080708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johan Cwiklinski wrote: > Hello, > > First of all, thanks for your advices. > > It seems that I've not used the right approach for this policy module. I > was using the following : > > grep http /var/log/audit/audit.log | audit2allow -M mybackuppc > > But this command also catches SELinux denies which are not relevant to BackupPC. > > So, I've restarted from scratch, and now use : > audit2allow -m BackupPC -l -i /var/log/audit/audit.log > BackupPC.te > > Which only takes the latests entries. > > This way, I've removed some entries I did not understand (such as iso9660_t), and were not appropriate here. > > > Daniel J Walsh a ?crit : >> No alot of these rules are not good. Could you attach the audit log you >> used to create this. > These rules were build on two different machines (my laptop and the one > were BackupPC is installed for backups). > So as I've rebuild my rules from scratch, the log file is available on > my web server (see links below). >> You probably need a context for this >> >> allow httpd_t etc_t:dir write; >> and these >> allow httpd_t usr_t:dir { write add_name }; >> allow httpd_t usr_t:file { write create }; >> >> Could be as simple as >> >> chcon -t httpd_sys_content_rw_t PATHTODIR > These one gives me an invalid argument... I've used > "httpd_sys_script_rw_t" instead, am I right ? > Also, I were able to remove these three 'allow' entries from my .te and > put only the context in .fc file. Yes, sorry about that. >> I take it this is the socket file that BackupPC is creating. I think >> you need a policy for this, and then BackupPC could label it >> appropriately and allow httpd to communicate with it. >> >> allow httpd_t initrc_t:unix_stream_socket connectto; >> allow httpd_t var_log_t:sock_file write; > Indeed, these ones are for the .sock file BackupPC creates at startup. > I don't understand what exactly you mean by 'a policy for this'... >> Not sure what these are either. >> >> allow httpd_t httpd_log_t:sock_file write; >> allow httpd_t httpd_sys_content_t:sock_file write; > It's only a mistake, I had first to put 'sock_file write' for the .sock > file, and then I've changed its context. Doing this, the first rule > becomes obsolete, and audit2allow gave me the second... > > New file are here : > - audit.log : http://odysseus.x-tnd.be/fedora/backuppc/audit.log > - .te file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te > - .fc file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.fc > - old .te and .fc (from my preceding message) : > http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te.old > - spec file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec > > All seems to work correctly with these rules, I wish I made no mistakes > this time... :-) > > Regards, > Johan > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9PKPrlYvE4MpobMRAnSxAJ9Cb0KjXEEw6wnD0l+ajUWuIR0AVwCgyNfU PRiI845fHgQHlfEy/31GyZY= =J+Md -----END PGP SIGNATURE----- From laurent.rineau__fedora at normalesup.org Sat Sep 22 10:57:56 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Sat, 22 Sep 2007 12:57:56 +0200 Subject: keyring primer? KDE? In-Reply-To: References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <1366.71.208.55.155.1190342965.squirrel@www.cora.nwra.com> Message-ID: <200709221257.57037@rineau.tsetse> On Saturday 22 September 2007 01:31:59 Kevin Kofler wrote: > cora.nwra.com> writes: > > Anything for KDE and Kwallet? > > KWallet allows passwordless keyrings. If you don't want to enter a password > to unlock the keyring, that's the way. It's not for the paranoid of course, > but a keyring with the same password as your user account and unlocked > automatically as you log in is hardly any more secure. Yes it is. As least it protects you from somebody that manage to steal your KWallet store, without knowing your password. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From laroche at redhat.com Sat Sep 22 11:09:57 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 22 Sep 2007 13:09:57 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F11039.3020802@fedoraproject.org> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> Message-ID: <20070922110957.GA27345@dudweiler.stuttgart.redhat.com> > See fedora-desktop list discussions. The goal IIUC was to discourage > root login via display managers since there isn't normally a reason to > do that and it presents a higher security risk. This has also been a Hello Rahul, default should be to allow root login for convenience and keep it up to sysadmins to lock down a machine completely if this is desired as local security policy. regards, Florian La Roche From buildsys at redhat.com Sat Sep 22 11:11:37 2007 From: buildsys at redhat.com (Build System) Date: Sat, 22 Sep 2007 07:11:37 -0400 Subject: rawhide report: 20070922 changes Message-ID: <200709221111.l8MBBbvj007188@porkchop.devel.redhat.com> New package biosdevname Udev helper for naming devices per BIOS names New package gmyth MythTV remote access libraries New package haproxy HA-Proxy is a TCP/HTTP reverse proxy for high availability environments New package jlint Java program checker New package kdebase4 K Desktop Environment 4 - Core Files New package kdelibs4 K Desktop Environment 4 - Libraries New package kdepimlibs K Desktop Environment 4 - PIM Libraries New package ladspa-blop-plugins Bandlimited LADSPA Oscillator Plugins New package ladspa-cmt-plugins A collection of LADSPA plugins New package sdljava Java binding to the SDL API New package solarwolf A Python port of SolarFox Removed package dhcdbd Removed package gkrellm-themes Removed package php-extras Updated Packages: ImageMagick-6.3.5.9-1.fc8 ------------------------- * Fri Sep 21 2007 Norm Murray 6.3.5.9-1.fc8 - rebase to 6.3.5.9 - fix build with missing open() arg - add build require of jasper-devel, remove windows font dir - update multilib patch NetworkManager-1:0.7.0-0.3.svn2852.fc8 -------------------------------------- * Fri Sep 21 2007 Dan Williams - 1:0.7.0-0.3.svn2852 - New snapshot (fix unencrypted & 40 bit WEP) * Fri Sep 21 2007 Dan Williams - 1:0.7.0-0.3.svn2849 - New snapshot * Fri Sep 21 2007 Dan Williams - 1:0.7.0-0.3.svn2844 - New snapshot QuantLib-0.8.1-3.fc8 -------------------- * Thu Sep 20 2007 Tom "spot" Callaway 0.8.1-3 - another conflicting man page (resolves bugzilla 297161) aiccu-2007.01.15-3.fc8 ---------------------- * Fri Sep 21 2007 Matt Domsch 2007.01.15-3 - add LSB initscript header (BZ#246861) alsa-utils-1.0.15-0.2.rc1.fc8 ----------------------------- * Thu Sep 20 2007 Matthias Saou 1.0.15-0.2.rc1 - Update License field. - Mark udev rule as config. - Use find_lang macro again to include translations (why was it removed?). aria2-0.11.3-1.fc8 ------------------ * Thu Sep 20 2007 Micha?? Bentkowski - 0.11.3-1 - 0.11.3 asm2-0:2.1-2jpp.2.fc8 --------------------- * Fri Sep 21 2007 Permaine Cheung - 0:2.1-2jpp.2 - Fix Source0 URL, License tag bigboard-0.5.18-1.fc8 --------------------- * Fri Sep 21 2007 Colin Walters - 0.5.18-1 - new upstream * Thu Sep 20 2007 Colin Walters - 0.5.17-1 - new upstream - add br cacti-0.8.6j-9.fc8 ------------------ * Fri Sep 21 2007 Mike McGrath - 0.8.6j-9 - Added rest of official patches calc-2.12.2.1-10.fc8 -------------------- cdrkit-1.1.6-5.fc8 ------------------ * Fri Sep 21 2007 Harald Hoyer - 1.1.6-5 - fixed rhbz#255001 - icedax --devices segfaults - fixed rhbz#249357 - Typo in wodim output * Fri Sep 21 2007 Harald Hoyer - 1.1.6-4 - play stupid tricks, to let alternatives make the links and rpm not removing them afterwards - removed bogus warning for "." and ".." * Thu Sep 20 2007 Harald Hoyer - 1.1.6-3 - fixed rhbz#248262 - switched to alternatives cernlib-2006-19.fc8 ------------------- * Mon Aug 27 2007 Patrice Dumas 2006-19 - pass --build-id when linking, this is needed for debuginfo generation - use g77 binaries, paw with gfortran is broken on x86_64 (#241416) - add virtual provides for devel, utils and static packages, packages (like kuipc) may need the cernlib, but accept g77 or gfortran compiled cernlib - don't set the environment. It only hurts parallel installations. * Mon Aug 27 2007 Patrice Dumas 2006-18 - correct license - use the right debian patch source cernlib-g77-2006-19.fc8 ----------------------- * Mon Aug 27 2007 Patrice Dumas 2006-19 - pass --build-id when linking, this is needed for debuginfo generation - use g77 binaries, paw with gfortran is broken on x86_64 (#241416) - add virtual provides for devel, utils and static packages, packages (like kuipc) may need the cernlib, but accept g77 or gfortran compiled cernlib - don't set the environment. It only hurts parallel installations. * Mon Aug 27 2007 Patrice Dumas 2006-18 - correct license - use the right debian patch source claws-mail-3.0.1-1.fc8 ---------------------- * Fri Sep 21 2007 Andreas Bierfert - 3.0.1-1 - version upgrade compiz-0.5.2-12.6b86f3.fc8 -------------------------- * Thu Sep 20 2007 Kristian H??gsberg - 0.5.2-12 - Update to more recent 0.6 branch snapshot (fixes #253575). * Fri Sep 14 2007 Warren Togami - 0.5.2-11 - compiz-gnome: install core schema so it actually works - remove unnecessary gconf stuff from %install * Tue Aug 28 2007 Kristian H??gsberg - 0.5.2-9 - Make compiz-gnome Obsolete the older compiz package so yum/anaconda will pull it in (thans to Adel Gadllah). cups-1:1.3.2-2.fc8 ------------------ * Fri Sep 21 2007 Tim Waugh 1:1.3.2-2 - Write printcap when remote printers have timed out (bug #290831). * Wed Sep 19 2007 Tim Waugh 1:1.3.2-1 - Include Till Kamppeter's dnssd backend. - 1.3.2. - No longer need str2512 patches. * Tue Sep 18 2007 Tim Waugh 1:1.3.1-3 - Write printcap when a remote queue is deleted (bug #290831). darcs-1.0.9-6.fc8 ----------------- * Fri Sep 21 2007 Jens Petersen - 1.0.9-6 - fix the "|| :" quoting in the post install script (#295351) deluge-0.5.5-2.fc8 ------------------ * Thu Sep 20 2007 Peter Gordon - 0.5.5-2 - Fix release on previous %changelog entry. - Disable the version update notifications by default: + default-prefs-no-release-notifications.patch (Resolves bug 299601: Deluge alerts of new versions) * Wed Sep 12 2007 Peter Gordon - 0.5.5-1 - Update to new upstream release (0.5.5) * Mon Sep 03 2007 Peter Gordon - 0.5.4.1.95-1 - Update to new upstream release candidate (0.5.5 RC1) eclipse-mylyn-2.0.0-9.fc8 ------------------------- * Fri Sep 21 2007 Andrew Overholt 2.0.0-9 - Really remove all mylar references in mylyn feature - courtesy Mandriva package. * Wed Sep 19 2007 Andrew Overholt 2.0.0-8 - Add patch and source to have common bugzilla servers by default. eclipse-pydev-1:1.3.9-1.fc8 --------------------------- * Thu Sep 20 2007 Ben Konrath 1:1.3.9-1 - 1.3.9 foomatic-3.0.2-51.fc8 --------------------- * Fri Sep 21 2007 Tim Waugh 3.0.2-51 - Build requires perl(ExtUtils::MakeMaker). - Updated filters to 3.0-20070919. - Updated db to 20070919. fuse-2.7.0-7.fc8 ---------------- * Fri Sep 21 2007 Tom "spot" Callaway 2.7.0-7 - revert udev rules change * Thu Sep 20 2007 Tom "spot" Callaway 2.7.0-6 - change udev rules so that /dev/fuse is chmod 666 (bz 298651) * Wed Aug 29 2007 Tom "spot" Callaway 2.7.0-5 - fix open issue (bz 265321) gcin-1.3.4-3.fc8 ---------------- * Thu Sep 20 2007 Chung-Yen Chang - 1.3.4-3 - update license field to LGPLv2 - add im-chooser to require gconfmm26-2.20.0-1.fc8 ---------------------- * Mon Sep 17 2007 Denis Leroy - 2.20.0-1 - Update to new stable 2.20.0 gdm-1:2.20.0-4.fc8 ------------------ * Thu Sep 20 2007 Matthias Clasen - 1:2.20.0-4 - Reenable root login due to popular demand gettext-0.16.1-12.fc8 --------------------- * Fri Sep 21 2007 Jens Petersen - 0.16.1-12 - add a libs subpackage (suggested by Dwayne Bailey, #294891) - move preloadable_libintl.so to the devel subpackage ghex-2.20.0-1 ------------- * Fri Sep 21 2007 Thorsten Leemhuis - 2.20.0-1 - Update to 2.20.0 gnash-0.8.1-5.fc8 ----------------- * Thu Sep 20 2007 Patrice Dumas 0.8.1-5 - info files are empty, don't install them gnome-panel-2.20.0.1-2.fc8 -------------------------- * Fri Sep 21 2007 Matthias Clasen - 2.20.0.1-2 - Don't pop up an error if an applet from the default configuration is missing gnome-screensaver-2.20.0-3.fc8 ------------------------------ * Fri Sep 21 2007 Ray Strode - 2.20.0-3 - hide xscreensaver menu if gnome-screensaver is installed (bug 300401) * Thu Sep 20 2007 Matthias Clasen - 2.20.0-2 - Make the default theme setting work grub-0.97-19 ------------ * Thu Sep 20 2007 Peter Jones - 0.97-19 - Fix dmraid detection on Intel (isw) controllers in grub-install . gtk-nodoka-engine-0.6-2.fc8 --------------------------- * Thu Sep 20 2007 Martin Sourada - 0.6-2 - Add user specified tooltips coloring - Fix colours in unfocused GTKTreeView (rhbz #297271) gtk2-2.12.0-3.fc8 ----------------- * Thu Sep 20 2007 Matthias Clasen - 2.12.0-3 - Fix a problem with swt and tooltips gtk2-engines-2.12.0-2.fc8 ------------------------- * Thu Sep 20 2007 Matthias Clasen - 2.12.0-2 - Fix a typo in the Crux gtkrc hsqldb-1:1.8.0.8-1jpp.2.fc8 --------------------------- * Thu Sep 20 2007 Deepak Bhole 1:1.8.0.8-1jpp.2 - Added %{?dist} to release, as per Fedora policy im-chooser-0.5.2-2.fc8 ---------------------- * Fri Sep 21 2007 Akira TAGOH - 0.5.2-2 - Bring up IM by default again, except the session is on Live CD. (#250226) ipsec-tools-0.7-3.fc8 --------------------- * Thu Sep 20 2007 Steve Conklin - 0.7-3 - Applied the following patches from Gabriel Somlo - Patches for connecting to Cisco ASA in remote-access (road-warrior) mode - Added phase1_up_down mode config script - Including our own .h files (ipsec, pfkeyv2, xfrm, udp) no longer necessary - Added init script for racoon daemon jakarta-commons-dbcp-0:1.2.1-10jpp.2.fc8 ---------------------------------------- * Thu Sep 20 2007 Deepak Bhole 0:1.2.1-10jpp.2 - Rebuild jakarta-commons-logging-0:1.0.4-6jpp.4.fc8 ------------------------------------------ * Thu Sep 20 2007 Deepak Bhole 0:1.0.4-6jpp.4 - Add %{?dist} to release as per policy jakarta-commons-pool-0:1.3-9jpp.3.fc8 ------------------------------------- * Thu Sep 20 2007 Deepak Bhole 0:1.3-9jpp.3 - Rebuild * Wed Apr 25 2007 Matt Wringe 0:1.3-9jpp.2 - A couple of minor spec file changes for Fedora review * Wed Mar 07 2007 Matt Wringe 0:1.3-9jpp.1 - Merge with updated jpp version - Updated commons-build, no longer need patchs to get around local building. jakarta-commons-validator-0:1.1.4-5jpp.2.fc8 -------------------------------------------- * Thu Sep 20 2007 Deepak Bhole - 0:1.1.4-5jpp.2 - Rebuild jdom-0:1.0-4jpp.2.fc8 --------------------- * Thu Sep 20 2007 Deepak Bhole - 0:1.0-4jpp.2 - Add %{?dist} as per policy jrefactory-0:2.8.9-6jpp.4.fc8 ----------------------------- * Thu Sep 20 2007 Deepak Bhole - 0:2.8.9-6jpp.4 - Add %{?dist} as per new policy jsch-0:0.1.31-1jpp.2.fc8 ------------------------ * Thu Sep 20 2007 Deepak Bhole - 0:0.1.31-1jpp.2 - Added %{?dist} as per new policy junit-3.8.2-3jpp.3.fc8 ---------------------- * Thu Sep 20 2007 Deepak Bhole - 3.8.2-3jpp.3 - Fix location of stylesheet for javadocs * Thu Sep 20 2007 Deepak Bhole - 3.8.2-3jpp.2 - Rebuild for ppc32 execmem issue and new build-id * Mon Feb 12 2007 Thomas Fitzsimmons - 3.8.2-3jpp.1.fc7 - Add dist tag kdegames-6:3.5.7-4.fc8 ---------------------- * Thu Sep 20 2007 Than Ngo 3.5.7-4 - bz248343, remove the Tron and Sokoban trademarks, thanks to Kevin Kofler kernel-2.6.23-0.193.rc7.git1.fc8 -------------------------------- * Thu Sep 20 2007 Chuck Ebbert - 2.6.23-rc7-git1 * Thu Sep 20 2007 Dave Jones - Enable tcrypt module for crypto testing. * Thu Sep 20 2007 Dave Jones - Enable SECMARK by default. kernel-xen-2.6-2.6.21-2942.fc8 ------------------------------ * Thu Sep 20 2007 Eduardo Habkost - Fix sleazy-fpu implementation to actually avoid on fpu-intensive programs * Thu Sep 20 2007 Eduardo Habkost - Add fix for bug #294011 (floating point corruption) (changeset 8c24767501ff from Xen 3.1.1) ksudoku-0.4-1.fc8 ----------------- * Mon Sep 17 2007 Rafa?? Psota - 0.4-1 - update to 0.4 libFS-1.0.0-6.fc8 ----------------- * Thu Sep 20 2007 Adam Jackson 1.0.0-6 - Update xtrans dep and rebuild. libICE-1.0.3-5.fc8 ------------------ * Thu Sep 20 2007 Adam Jackson 1.0.3-5 - Update xtrans dep and rebuild. libSM-1.0.2-4.fc8 ----------------- * Thu Sep 20 2007 Adam Jackson 1.0.2-4 - Update xtrans dep and rebuild. libX11-1.1.2-4.fc8 ------------------ * Thu Sep 20 2007 Adam Jackson 1.1.2-4 - Update xtrans dep and rebuild. libXfont-1.2.9-5.fc8 -------------------- * Thu Sep 20 2007 Adam Jackson 1.2.9-5 - Update xtrans dep and rebuild. libgnomeuimm26-2.20.0-1.fc8 --------------------------- * Fri Sep 21 2007 Denis Leroy - 2.20.0-1 - Update to new upstream stable 2.20 libzzub-0.2.3-8.fc8 ------------------- * Thu Sep 20 2007 Alexander Kahl - 0.2.3-8 - included patch to install missing documentation to the right place - removed move macro instead - moved all plugin files *.{cpp,h,xml} back to get the lunar plugin loading right lucene-0:1.9.1-1jpp.5.fc8 ------------------------- * Fri Sep 21 2007 Deepak Bhole 1.9.1-1jpp.5 - Disable tests due to random hangs (see FIXME comment above ant call) * Thu Sep 20 2007 Deepak Bhole 0:1.9.1-1jpp.4 - Rebuild for ppc32 execmem issue and new build-id maniadrive-1.2-3.fc8 -------------------- mash-0.2.7-1.fc8 ---------------- * Fri Sep 21 2007 Bill Nottingham 0.2.7-1 - disable repoview for now * Thu Sep 20 2007 Bill Nottingham 0.2.6-1 - repoview cleanups/fixes - fix gtkimmodules typo (#295371, ) maven-doxia-0:1.0-0.1.a7.3jpp.5.fc8 ----------------------------------- * Fri Sep 21 2007 Deepak Bhole 1.0-0.1.a7.3jpp.5 - Build with maven - ExcludeArch ppc64 maven-jxr-0:1.0-2jpp.4.fc8 -------------------------- * Fri Sep 21 2007 Deepak Bhole 1.0-2jpp.4 - Build without maven - ExcludeArch ppc64 maven-scm-0:1.0-0.1.b3.2jpp.2.fc8 --------------------------------- * Fri Sep 21 2007 Deepak Bhole 0:1.0-0.1.b3.2jpp.2 - Rebuild with excludearch for ppc64 maven-shared-0:1.0-4jpp.3.fc8 ----------------------------- * Fri Sep 21 2007 Deepak Bhole 0:1.0-4jpp.3 - Rebuild with ppc64 excludearch'd - Removed 'jpp' from a BR version maven-surefire-0:1.5.3-2jpp.4.fc8 --------------------------------- * Fri Sep 21 2007 Deepak Bhole 1.5.3-2jpp.4 - Build with maven - ExcludeArch ppc64 maven2-0:2.0.4-10jpp.8.fc8 -------------------------- * Fri Sep 21 2007 Deepak Bhole 0:2.0.4-10jpp.8 - Rebuild without bootstrap * Fri Sep 07 2007 Deepak Bhole 0:2.0.4-10jpp.7 - Exclude ppc64 build - Add patch to build with ant 1.7 - Build with bootstrap (First build on F8/ppc) * Tue Mar 20 2007 Deepak Bhole 0:2.0.4-10jpp.6 - Build without bootstrap mercurial-0.9.4-7.fc8 --------------------- * Thu Sep 20 2007 Neal Becker - 0.9.4-7 - Change setup.py install to -O2 to get bytecompile on EL-4 * Thu Sep 20 2007 Neal Becker - 0.9.4-6 - Revert last change. * Thu Sep 20 2007 Neal Becker - 0.9.4-5 - Use %ghost on contrib, otherwise EL-4 build fails mrtg-2.15.1-5.fc8 ----------------- * Thu Sep 20 2007 Vitezslav Crhonek 2.15.1-5 - Fix bad provides mugshot-1.1.53-1.fc8 -------------------- * Thu Sep 20 2007 Colin Walters - 1.1.53-1 - new upstream neon-0.27.0-3 ------------- * Thu Sep 20 2007 Joe Orton 0.27.0-3 - fix Negotiate response verification nip2-7.12.5-1.fc8 ----------------- * Fri Sep 21 2007 Adam Goode - 7.12.5-1 - New upstream release nspluginwrapper-0.9.91.5-3.fc8 ------------------------------ * Fri Sep 21 2007 Martin Stransky 0.9.91.5-3 - added original plugin dir to the package nss_compat_ossl-0.9.2-1.fc8 --------------------------- * Thu Sep 20 2007 Rob Crittenden 0.9.2-1 - update to 0.9.2 - Enable loading the NSS PKCS#11 pem module - Add a URL - Specify the license as LGPLv2+ instead of just LGPL ntfs-3g-2:1.913-2.fc8 --------------------- * Thu Sep 20 2007 Tom "spot" Callaway 2:1.913-2 - don't set /sbin/mount.ntfs-3g setuid online-desktop-0.2.16-1.fc8 --------------------------- * Fri Sep 21 2007 Colin Walters - 0.2.16-1 - new upstream * Thu Sep 20 2007 Colin Walters - 0.2.15-1 - new upstream - dbus service * Thu Sep 20 2007 Colin Walters - 0.2.14-1 - new upstream - become an arch package since we have binaries - add some brs - use pythonsitearch openct-0.6.14-2.fc8 ------------------- * Fri Sep 21 2007 Ville Skytt?? - 0.6.14-2 - Drop "sleep 0.1" from udev rule (#287871). pam-0.99.8.1-9.fc8 ------------------ * Fri Sep 21 2007 Tomas Mraz 0.99.8.1-9 - do not preserve contexts when copying skel and other namespace.init fixes (#298941) - do not free memory sent to putenv (#231698) * Wed Sep 19 2007 Tomas Mraz 0.99.8.1-8 - add pam_selinux_permit module - pam_succeed_if: fix in operator (#295151) * Tue Sep 18 2007 Tomas Mraz 0.99.8.1-7 - when SELinux enabled always run the helper binary instead of direct shadow access (#293181) perl-Archive-Extract-0.24-1.fc8 ------------------------------- * Thu Sep 20 2007 Steven Pritchard 0.24-1 - Update to 0.24. - BR Test::More. plexus-ant-factory-0:1.0-0.1.a1.2jpp.5.fc8 ------------------------------------------ * Fri Sep 21 2007 Deepak Bhole 1.0-0.1.a1.2jpp.5 - ExcludeArch ppc64 * Mon Sep 10 2007 Deepak Bhole 1.0-0.1.a1.2jpp.4 - Build with maven plexus-appserver-0:1.0-0.1.a5.3jpp.3.fc8 ---------------------------------------- * Fri Sep 21 2007 Deepak Bhole 0:1.0-0.1.a5.3jpp.3 - ExcludeArch ppc64 plexus-bsh-factory-0:1.0-0.1.a7s.2jpp.5.fc8 ------------------------------------------- * Fri Sep 21 2007 Deepak Bhole 1.0-0.1.a7s.2jpp.5 - ExcludeArch ppc64 * Mon Sep 10 2007 Deepak Bhole 1.0-0.1.a7s.2jpp.4 - Build with maven plexus-cdc-0:1.0-0.1.a4.2jpp.3.fc8 ---------------------------------- * Fri Sep 21 2007 Deepak Bhole 0:1.0-0.1.a4.2jpp.3 - ExcludeArch ppc64 plexus-maven-plugin-0:1.2-2jpp.2.fc8 ------------------------------------ * Fri Sep 21 2007 Deepak Bhole 0:1.2-2jpp.2 - ExcludeArch ppc64 plexus-runtime-builder-0:1.0-0.1.a9.2jpp.2.fc8 ---------------------------------------------- * Fri Sep 21 2007 Deepak Bhole 0:1.0-0.1.a9.2jpp.2 - ExcludeArch ppc64 plexus-xmlrpc-0:1.0-0.1.b4.3jpp.6.fc8 ------------------------------------- * Fri Sep 21 2007 Deepak Bhole 1.0-0.1.b4.3jpp.6 - ExcludeArch ppc64 postgresql-8.2.5-1.fc8 ---------------------- * Thu Sep 20 2007 Tom Lane 8.2.5-1 - Update to PostgreSQL 8.2.5 and pgtcl 1.6.0 * Tue Sep 04 2007 Tom Lane 8.2.4-6 - Fix multilib problem for /usr/include/ecpg_config.h (which is new in 8.2.x) * Sat Aug 25 2007 Tom Lane 8.2.4-5 - Use nicer solution for tzdata file substitution: upstream discussion concluded that hardwiring the path was better than a symlink after all. pygsl-0.9.1-6.fc8 ----------------- * Fri Sep 21 2007 Jos?? Matos - 0.9.1-6 - License clarification. - Use swig to regenerate the wrappers. - Rebuild with gsl-1.10. - Add explicit dependency on gsl version. pygtk2-2.12.0-2.fc8 ------------------- * Fri Sep 21 2007 Jeremy Katz - 2.12.0-2.fc8 - fix crash using TreeView.convert_widget_to_bin_window_coords rcs-5.7-31 ---------- * Tue Jul 17 2007 Jiri Moskovcak - 5.7-31 - Addded support for new svn syntax. - Resolves: #247998 rhythmbox-0.11.2-6.fc8 ---------------------- * Thu Sep 20 2007 - Bastien Nocera - 0.11.2-6 - Init pygobject threads early (GNOME #469852) sabayon-2.20.1-1.fc8 -------------------- * Thu Sep 20 2007 Matthias Clasen - 2.20.1-1 - Update to 2.20.1 selinux-policy-3.0.8-8.fc8 -------------------------- * Fri Sep 21 2007 Dan Walsh 3.0.8-8 - Allow also to search var_lib - New context for dbus launcher * Fri Sep 21 2007 Dan Walsh 3.0.8-7 - Allow cupsd_config_t to read/write usb_device_t - Support for finger print reader, - Many fixes for clvmd - dbus starting networkmanager * Thu Sep 20 2007 Dan Walsh 3.0.8-5 - Fix java and mono to run in xguest account smolt-0.9.8.4-5.fc8 ------------------- * Fri Sep 21 2007 Mike McGrath 0.9.8.4-5 - Fixed firstboot issues sound-juicer-2.20.0-2.fc8 ------------------------- * Thu Sep 20 2007 - Bastien Nocera - 2.20.0-2 - Fix crasher when editing profiles and the profile gets unref'ed (#278861) syck-0.61-2.fc8 --------------- * Thu Sep 20 2007 Oliver Falk - 0.61-2 - Rebuild against new PHP system-config-language-1.2.11-1.fc8 ----------------------------------- * Fri Sep 21 2007 Lingning Zhang - 1.2.11 - fix bug294571. system-config-printer-0.7.74.2-2.fc8 ------------------------------------ * Fri Sep 21 2007 Tim Waugh 0.7.74.2-2 - Pull in SVN patch from stable branch for 'Allow printing from the Internet' check-box (bug #221003). tetex-IEEEtran-1.7.1-1.fc8 -------------------------- * Thu Sep 20 2007 Rick L Vinyard Jr - 1.7.1-1 - New upstream release 1.7a reversioned to 1.7.1 (missed 1.7.0 rel) - Changed download URL to generic CTAN - Don't need to move tux.eps for it to be included in docs - removed - Added changelog.txt to docs - Updated license to LPPL tetex-tex4ht-1.0.2007_09_04_0340-1.fc8 -------------------------------------- * Fri Sep 21 2007 Patrice Dumas 1.0.2007_09_04_0340-1 - update to 1.0.2007_09_04_0340 - use all the debian patches - install correctly the scripts out of bindir - prefix ht with tex4ht- to avoid name collisions tomboy-0.8.0-2.fc8 ------------------ * Thu Sep 20 2007 Matthias Clasen - 0.8.0-2 - Don't show the start here note on login udev-115-4.20070921git.fc8 -------------------------- * Fri Sep 21 2007 Harald Hoyer - 115-4 - more upstream fixes from git vdradmin-am-3.6.0-1.fc8 ----------------------- * Fri Sep 21 2007 Ville Skytt?? - 3.6.0-1 - 3.6.0. vips-7.12.5-1.fc8 ----------------- * Fri Sep 21 2007 Adam Goode - 7.12.5-1 - New upstream release vpnc-0.5.1-1.fc8 ---------------- * Thu Sep 20 2007 Tomas Mraz - 0.5.1-1 - upgrade to latest upstream wpa_supplicant-1:0.5.7-8.fc8 ---------------------------- * Thu Sep 20 2007 Dan Williams - 0.5.7-8 - Change system bus activation file name to work around D-Bus bug that fails to launch services unless their .service file is named the same as the service itself wsdl4j-0:1.5.2-4jpp.2.fc8 ------------------------- * Thu Sep 20 2007 Deepak Bhole 1.5.2-4jpp.2 - Rebuild for ppc32 execmem issue and new build-id - Add %{?dist} as per new policy xjavadoc-0:1.1-4jpp.3.fc8 ------------------------- * Thu Sep 20 2007 Deepak Bhole 1.1-4jpp.3 - Rebuild for ppc32 execmem issue and new build-id - Add %{?dist} as per policy xorg-x11-xtrans-devel-1.0.3-4.fc8 --------------------------------- * Thu Sep 20 2007 Adam Jackson 1.0.3-4 - Fix a bug in automatic port generation for abstract sockets. Fixes fast user switching, among other things. xournal-0.4.1-2.fc8 ------------------- * Fri Sep 21 2007 Rick L Vinyard Jr 0.4.1-2 - Added freetype to build requires - Created patch to add freetype to configure.in pkgconfig * Thu Sep 20 2007 Rick L Vinyard Jr 0.4.1-1 - New upstream release - Changed source to use name and version variables - Updated xournal.desktop to reflect upstream changes - Updated x-xoj.desktop to reflect upstream changes - Updated license to reflect specific GPL version zabbix-1.4.2-3.fc8 ------------------ * Thu Sep 20 2007 Dan Horak 1.4.2-3 - Add a patch to clean a warning during compile - Add a patch to fix cpu load computations Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.i386 requires libgmpxx.so.3 sepostgresql - 8.2.4-1.0.fc8.i386 requires postgresql-server = 0:8.2.4 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) sepostgresql - 8.2.4-1.0.fc8.x86_64 requires postgresql-server = 0:8.2.4 Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 ppl - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.ppc requires libgmpxx.so.3 python-vcpx - 0.9.28-4.fc8.noarch requires monotone sepostgresql - 8.2.4-1.0.fc8.ppc requires postgresql-server = 0:8.2.4 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display sepostgresql - 8.2.4-1.0.fc8.ppc64 requires postgresql-server = 0:8.2.4 xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From fedora at camperquake.de Sat Sep 22 11:15:46 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 22 Sep 2007 13:15:46 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190394930.2567.173.camel@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> Message-ID: <20070922131546.466fd509@lain.camperquake.de> Hi. On Fri, 21 Sep 2007 13:15:30 -0400, Simo Sorce wrote > I guess you care about your databases contents, do you? :-) Speaking of which, I think it's fascinating that noone has noted so far that the RPM database lives in /var, too. Which I rather hate to lose, and so I do backup it. From rhlists at bellsouth.net Sat Sep 22 11:16:48 2007 From: rhlists at bellsouth.net (Bob) Date: Sat, 22 Sep 2007 07:16:48 -0400 Subject: lesswatts.org In-Reply-To: <1190437993.9010.5.camel@localhost6.localdomain6> References: <1190437993.9010.5.camel@localhost6.localdomain6> Message-ID: <1190459808.2893.2.camel@J4RDV21> On Fri, 2007-09-21 at 23:13 -0600, Richi Plana wrote: > Hi, > > Of the several projects hosted on http://www.lesswatts.org/ (PowerTOP, > Tickless Idle, Processor Power Management, Battery Life Toolkit, Power > Policy Manager, Power QoS, Display and Graphics Power Savings, Device > and Bus Power Management, ACPICA) how many are currently packages for > Fedora? What are they called? How are they identified? Do they belong in > any particular software group? Some are kernel patches so are they in > any existing Fedora kernel? > -- > > Richi Plana There is a push to try and improve the power management with Fedora. Here is a link to the archives of this list of a post by Bill Nottingham regarding PowerTop and a request for users to help pinpoint problematic apps... https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00544.html Bob From sundaram at fedoraproject.org Sat Sep 22 11:14:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 22 Sep 2007 16:44:15 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <20070922110957.GA27345@dudweiler.stuttgart.redhat.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070922110957.GA27345@dudweiler.stuttgart.redhat.com> Message-ID: <46F4F907.2070005@fedoraproject.org> Florian La Roche wrote: >> See fedora-desktop list discussions. The goal IIUC was to discourage >> root login via display managers since there isn't normally a reason to >> do that and it presents a higher security risk. This has also been a > > > Hello Rahul, > > default should be to allow root login for convenience and keep > it up to sysadmins to lock down a machine completely if this is > desired as local security policy. Security by default works better but this argument is irrelevant now since it has enabled again in GDM as per the last Desktop SIG meeting. The plan is to tackle this in a more comprehensive way in Fedora 9. Rahul From kanarip at kanarip.com Sat Sep 22 11:35:01 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 22 Sep 2007 13:35:01 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <20070922131546.466fd509@lain.camperquake.de> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <20070922131546.466fd509@lain.camperquake.de> Message-ID: <46F4FDE5.1090407@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Ertzinger wrote: > Hi. > > On Fri, 21 Sep 2007 13:15:30 -0400, Simo Sorce wrote > >> I guess you care about your databases contents, do you? :-) > > Speaking of which, I think it's fascinating that noone has noted > so far that the RPM database lives in /var, too. > Which could be explained by the fact that it is useless to name each bit of what is in /var in this thread :/ > Which I rather hate to lose, and so I do backup it. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9P3lKN6f2pNCvwgRAnybAKDLB78z0zLGZjoTK2PDVSKZst+G5wCfcs5U E6Aad5zeC85/c3Rq5HWocAY= =rnEO -----END PGP SIGNATURE----- From fedora at camperquake.de Sat Sep 22 11:42:01 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 22 Sep 2007 13:42:01 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <46F4FDE5.1090407@kanarip.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <20070922131546.466fd509@lain.camperquake.de> <46F4FDE5.1090407@kanarip.com> Message-ID: <20070922134201.632d994f@lain.camperquake.de> Hi. On Sat, 22 Sep 2007 13:35:01 +0200, Jeroen van Meeuwen wrote > Which could be explained by the fact that it is useless to name each > bit of what is in /var in this thread :/ Yes, but is is present in each and every Fedora/RHEL system. From nicolas.mailhot at laposte.net Sat Sep 22 11:42:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 22 Sep 2007 13:42:36 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <20070922131546.466fd509@lain.camperquake.de> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <20070922131546.466fd509@lain.camperquake.de> Message-ID: <1190461356.19562.2.camel@rousalka.dyndns.org> Le samedi 22 septembre 2007 ? 13:15 +0200, Ralf Ertzinger a ?crit : > Hi. > > On Fri, 21 Sep 2007 13:15:30 -0400, Simo Sorce wrote > > > I guess you care about your databases contents, do you? :-) > > Speaking of which, I think it's fascinating that noone has noted > so far that the RPM database lives in /var, too. > > Which I rather hate to lose, and so I do backup it. The rpm db has not got the same criticity level. You lose it you just reinstall (and properly organised entities have default system templates). /srv is for stuff you can't rebuild this way, and affects more than a single system (because data is served to others) -- 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 che666 at gmail.com Sat Sep 22 11:53:40 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Sat, 22 Sep 2007 13:53:40 +0200 Subject: Root login in rawhide and display managers In-Reply-To: <46F3CCD8.4090404@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <20070919130008.GC7373@devserv.devel.redhat.com> <1190207198.4236.5.camel@localhost.localdomain> <1190233782.4236.45.camel@localhost.localdomain> <46F18F71.5070900@gmail.com> <27759.88.149.97.225.1190239758.squirrel@webmail.hi.is> <46F1CE96.7070308@gmail.com> <46F3CCD8.4090404@gmail.com> Message-ID: 2007/9/21, David Boles : > on 9/20/2007 3:11 AM, Rudolf Kastl wrote: > > 2007/9/20, David Boles : > >> on 9/19/2007 6:09 PM, ??? wrote: > >> > >> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and > >> the so many other Windows games you will get a *lot* of 'new Linux users' > >> from Windows. Just as ignorant as you are looking for here. > > > > well please do your homework: > > > > http://appdb.winehq.com > > > > sof even has a native linux port. > > > > regards, > > Rudolf Kastl > > You should have looked a little harder before you jumped to defend Windows > games for Linux. ;-) i didnt defend anything here, just stated the facts. > > I mentioned those games only because they came to mind late at night. > Those are all old, by gaming standards very old, games. SOF is from 2000 > for example and basically abandoned. It will run because it is OpenGL and > could be ported. Oblivion and Half-Life are written 'in' DirectX. Those > would not, and many others I would think, run in Wine. Ever. Nor will they > run in VMware. wine does run directx based games. just to get the facts straight again. wine is not an emulator in the traditional sense but actually for the large part an abstraction layer for the windows api. again: www.winehq.org and appdb.winehq.org will show you. regards, Rudolf Kastl > > -- > > David > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From kevin.kofler at chello.at Sat Sep 22 12:11:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Sep 2007 12:11:16 +0000 (UTC) Subject: keyring primer? KDE? References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <1366.71.208.55.155.1190342965.squirrel@www.cora.nwra.com> <200709221257.57037@rineau.tsetse> Message-ID: Laurent Rineau normalesup.org> writes: > Yes it is. As least it protects you from somebody that manage to steal your > KWallet store, without knowing your password. But where's the added security over plain old *nix permissions? If you're trying to protect against someone with root privileges, that someone can easily plant a keylogger or something to get your passwords. Otherwise, any attacker who can read the file also has access to your account somehow, so what's keeping them from using the regular gnome-keyring API from a process running as you to read all your passwords as soon as pam_keyring unlocks it for you? (Root can do that one too, by the way, as they can su to any account.) Am I missing something? Kevin Kofler From bloch at verdurin.com Sat Sep 22 12:17:07 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Sat, 22 Sep 2007 13:17:07 +0100 (BST) Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <46F1AF30.8090308@redhat.com> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> <46F1AF30.8090308@redhat.com> Message-ID: <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> > bloch at verdurin.com wrote: >> With the latest batch of rawhide updates >> (kernel-2.6.23-0.185.rc6.git7.fc8 >> etc.) there seems to be something wrong with D-Bus and/or HAL. The >> brightness applet reports that it can't connect to gnome-power-manager >> and >> the NetworkManager applet doesn't appear. >> >> I restarted HAL and D-Bus and eventually the NM applet appeared but it >> would not connect to my network: >> >> Sep 19 21:23:36 vaio NetworkManager: Activation (wlan0) failed. >> >> Upon rebooting to the 2.6.23-0.184.rc6.git4.fc8 kernel, I had the same >> symptoms and had to restart the same services, but I was able to connect >> to the network. >> >> The wireless hardware is ipw3945, though I'm not sure whether this is a >> kernel problem or a problem with other packages. >> > > I am experiencing the same problem. Uncertain what component exactly is > broken. Makes it difficult to file a bug or query for it. > It seems to be a combination of problems with the iwl3945 driver, SELinux and NetworkManager. Sep 22 12:20:47 vaio kernel: dnsmasq[2785]: segfault at 00000000ffffffff rip 00002aaaaaf7b020 rsp 00007fff5f523968 error 4 Sep 22 12:20:51 vaio setroubleshoot: #012 SELinux is preventing /usr/sbin/dnsmasq (dnsmasq_t) "write" to libvirt (virt_var_lib_t).#012 For complete SELinux messages. run sealert -l 1d14856c-6cae-44d0-84a5-ea69f3f71223 Sep 22 12:21:04 vaio kernel: named[2914]: segfault at 0000000000000061 rip 00002aaaaab09f2a rsp 0000000041400f10 error 4 Sep 22 12:25:12 vaio kernel: named[3788]: segfault at 0000000000000004 rip 00002aaaae015f20 rsp 00000000409ffc08 error 6 Sep 22 12:25:12 vaio kernel: named[3789] general protection rip:2aaaaab09d52 rsp:41400ee0 error:0 With the newest kernel, which has the 0.1.15 iwl3945 driver, no wireless association is made. From andy at warmcat.com Sat Sep 22 12:41:07 2007 From: andy at warmcat.com (Andy Green) Date: Sat, 22 Sep 2007 13:41:07 +0100 Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> <46F1AF30.8090308@redhat.com> <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> Message-ID: <46F50D63.2020201@warmcat.com> Somebody in the thread at some point said: > It seems to be a combination of problems with the iwl3945 driver, SELinux > and NetworkManager. Not sure one should blame iwl3945 for this. I updated a friend's machine to development yesterday, on rt73usb. Development wpa_supplicant crapped out during initscripts with a dbus error (dbus doesn't seem to get started until ordinal 26 in the initscripts?). NetworkManager was completely unable to authenticate to a WPA AP. I downgraded NetworkManage and wpa_supplicant to the F7 versions and it worked as usual. -Andy From dtimms at iinet.net.au Sat Sep 22 12:42:57 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 22 Sep 2007 22:42:57 +1000 Subject: Possible RFE for what packages ( rpm -qa ) are include in live cd. In-Reply-To: <46F3A875.10602@hi.is> References: <46F3A875.10602@hi.is> Message-ID: <46F50DD1.5030405@iinet.net.au> J?hann B. Gu?mundsson wrote: ... > Oh by the way the whole image release process.. are the images > updated after x time ( week(s)/month ) which then have "latest fixes"... No. Paraphrasing other information presented in the list form time to time: Preparing a build for release is a time intensive, QA process, that needs wide testing to even be considered for release; this effort is best directed into preparing the next release. for an example see: http://fedoraproject.org/wiki/FWN/Issue91#head-c6ec232e7c7bc21c9a6575157eb029826cc737a3 However, you can do it yourself with the fedora tools that are integrated into revisor: http://revisor.fedoraunity.org/ You can make it whenever/watever you want it to be ;) DaveT. From jkeating at redhat.com Sat Sep 22 12:50:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Sep 2007 08:50:29 -0400 Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <46F50D63.2020201@warmcat.com> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> <46F1AF30.8090308@redhat.com> <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> <46F50D63.2020201@warmcat.com> Message-ID: <20070922085029.62400f5f@redhat.com> On Sat, 22 Sep 2007 13:41:07 +0100 Andy Green wrote: > Not sure one should blame iwl3945 for this. I updated a friend's > machine to development yesterday, on rt73usb. Development > wpa_supplicant crapped out during initscripts with a dbus error (dbus > doesn't seem to get started until ordinal 26 in the initscripts?). > NetworkManager was completely unable to authenticate to a WPA AP. I > downgraded NetworkManage and wpa_supplicant to the F7 versions and it > worked as usual. I think that uses the same underlying wifi stack as the iwl3945. Regardless we're fixing this bugs as fast as we can as they come up. Each new day's NetworkManager should improve upon the last. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 22 12:52:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Sep 2007 08:52:15 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070922131546.466fd509@lain.camperquake.de> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <20070922131546.466fd509@lain.camperquake.de> Message-ID: <20070922085215.2d3b10c5@redhat.com> On Sat, 22 Sep 2007 13:15:46 +0200 Ralf Ertzinger wrote: > Speaking of which, I think it's fascinating that noone has noted > so far that the RPM database lives in /var, too. > > Which I rather hate to lose, and so I do backup it. I consider the rpm database to be transient on the system as well. When I'm restoring the system, I'm not restoring an exact copy, most often I'm doing a fresh install with the same /manifest/ and dropping the backed up data in place. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sat Sep 22 12:58:04 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 22 Sep 2007 08:58:04 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070922131546.466fd509@lain.camperquake.de> References: <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <46F3D558.3000703@redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <20070922131546.466fd509@lain.camperquake.de> Message-ID: <20070922125804.GA10763@jadzia.bu.edu> On Sat, Sep 22, 2007 at 01:15:46PM +0200, Ralf Ertzinger wrote: > Speaking of which, I think it's fascinating that noone has noted > so far that the RPM database lives in /var, too. > Which I rather hate to lose, and so I do backup it. Not important. It gets recreated on reinstall. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From email.ahmedkamal at googlemail.com Sat Sep 22 13:04:07 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 22 Sep 2007 15:04:07 +0200 Subject: hpet timer patch for powertop Message-ID: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> Hi, I just tried powertop (amazing tool), however I was shocked that around 70% of my laptop's wake ups are from " 67.5% (756.5) : extra timer interrupt" Google told me, I am not running tickless (although, my kernel is 2.6.22.4-45_1.cubbi_suspend2.fc6) and the chipset on my toshiba A105 satellite laptop seem to be ICH6 Family. Do I need that patch that forces enabling hpet timers?! If so, is there any (un)official fedora kernel that includes the patch, as I don't like to manually track kernel upgrades. I hope that patch will be integrated in mainstream fedora kernels soon. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at warmcat.com Sat Sep 22 13:06:13 2007 From: andy at warmcat.com (Andy Green) Date: Sat, 22 Sep 2007 14:06:13 +0100 Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <20070922085029.62400f5f@redhat.com> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> <46F1AF30.8090308@redhat.com> <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> <46F50D63.2020201@warmcat.com> <20070922085029.62400f5f@redhat.com> Message-ID: <46F51345.10708@warmcat.com> Somebody in the thread at some point said: > On Sat, 22 Sep 2007 13:41:07 +0100 > Andy Green wrote: > >> Not sure one should blame iwl3945 for this. I updated a friend's >> machine to development yesterday, on rt73usb. Development >> wpa_supplicant crapped out during initscripts with a dbus error (dbus >> doesn't seem to get started until ordinal 26 in the initscripts?). >> NetworkManager was completely unable to authenticate to a WPA AP. I >> downgraded NetworkManage and wpa_supplicant to the F7 versions and it >> worked as usual. > > I think that uses the same underlying wifi stack as the iwl3945. > Regardless we're fixing this bugs as fast as we can as they come up. > Each new day's NetworkManager should improve upon the last. Just adding my experience wrt iwl3945 getting the blame. I don't think mac80211 should get the blame either since I didn't change the kernel during this. But don't get me wrong, it's fine if NetworkManager (which has gotten a LOT better for me in the last months) is broken in Development at any particular time. The fact the F7 one was "stable" enough to replace it is fine too. -Andy From jwboyer at jdub.homelinux.org Sat Sep 22 13:36:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Sep 2007 08:36:51 -0500 Subject: hpet timer patch for powertop In-Reply-To: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> References: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> Message-ID: <20070922083651.104fa094@vader.jdub.homelinux.org> On Sat, 22 Sep 2007 15:04:07 +0200 "Ahmed Kamal" wrote: > Hi, > I just tried powertop (amazing tool), however I was shocked that around 70% > of my laptop's wake ups are from > " 67.5% (756.5) : extra timer interrupt" > Google told me, I am not running tickless (although, my kernel is > 2.6.22.4-45_1.cubbi_suspend2.fc6) and the chipset on my toshiba A105 > satellite laptop seem to be ICH6 Family. Do I need that patch that forces > enabling hpet timers?! If so, is there any (un)official fedora kernel that > includes the patch, as I don't like to manually track kernel upgrades. I > hope that patch will be integrated in mainstream fedora kernels soon. > Regards I have no idea where the kernel you have came from, but if you're running x86_64 and you want tickless you'll need to upgrade to Fedora 8. I don't recall if F7 has tickless for i686 or not, but F8 does for sure. josh From sgrubb at redhat.com Sat Sep 22 13:44:32 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Sep 2007 09:44:32 -0400 Subject: yum pulling in 386 packages Message-ID: <200709220944.33124.sgrubb@redhat.com> Hi, This morning I checked rawhide. My x86_64 machine has no 386 packages on it. Doing yum update suddenly wanted to pull in 386 packages to my system. I updated packages 1 by 1 until I was down to updating NetworkManager.x86_64. If I type "yum update NetworkManager.x86_64" or "yum update NetworkManager", I get only 64 bit packages. If I type "yum update", it pulls in the 386 version of NetworkManager and all its dependencies. So, those of you with pristine 64 bit machines, watch out for this or 32 bit packages will start creeping back into your system. Is this a known problem or should a bz be filed? Thanks, -Steve From email.ahmedkamal at googlemail.com Sat Sep 22 13:45:52 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 22 Sep 2007 15:45:52 +0200 Subject: hpet timer patch for powertop In-Reply-To: <20070922083651.104fa094@vader.jdub.homelinux.org> References: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> <20070922083651.104fa094@vader.jdub.homelinux.org> Message-ID: <3da3b5b40709220645v55e83108y4300d2367c49b922@mail.gmail.com> actually I'm still on FC6, and I'm using i686 CPU. The kernel is from tuxonice (suspend2) which is basically the same fedora kernel with suspend2 patches. Anyway, I thought all .22 kernels had tickless, dont they. If all of this + hpet patches will be in fedora8, I will be a happy fedorian ;) On 9/22/07, Josh Boyer wrote: > > On Sat, 22 Sep 2007 15:04:07 +0200 > "Ahmed Kamal" wrote: > > > Hi, > > I just tried powertop (amazing tool), however I was shocked that around > 70% > > of my laptop's wake ups are from > > " 67.5% (756.5) : extra timer interrupt" > > Google told me, I am not running tickless (although, my kernel is > > 2.6.22.4-45_1.cubbi_suspend2.fc6) and the chipset on my toshiba A105 > > satellite laptop seem to be ICH6 Family. Do I need that patch that > forces > > enabling hpet timers?! If so, is there any (un)official fedora kernel > that > > includes the patch, as I don't like to manually track kernel upgrades. I > > hope that patch will be integrated in mainstream fedora kernels soon. > > Regards > > I have no idea where the kernel you have came from, but if you're > running x86_64 and you want tickless you'll need to upgrade to Fedora > 8. I don't recall if F7 has tickless for i686 or not, but F8 does for > sure. > > josh > > -- > 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 laurent.rineau__fedora at normalesup.org Sat Sep 22 14:29:32 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Sat, 22 Sep 2007 16:29:32 +0200 Subject: keyring primer? KDE? In-Reply-To: References: <1190160624.3268.3.camel@continuity.bakerconsulting.com> <200709221257.57037@rineau.tsetse> Message-ID: <200709221629.33133@rineau.tsetse> On Saturday 22 September 2007 14:11:16 Kevin Kofler wrote: > If you're trying to protect against someone with root privileges, that > someone can easily plant a keylogger or something to get your passwords. I agree. > Otherwise, any attacker who can read the file also has access to your > account somehow, so what's keeping them from using the regular > gnome-keyring API from a process running as you to read all your passwords > as soon as pam_keyring unlocks it for you? (Root can do that one too, by > the way, as they can su to any account.) With the configuration I chose, KWallet does not allow a connection to itself without a confirmation, given from a popup on my screen (an idea that KDE had before Microsoft Vista). So, even if the wallet has been opened with my password, an attacker having access to my account needs at least to intercept my connection to the X11 server. It is doable, but not as easy as copying a file. What is more, it prevents me from leaking very sensitive information with a badly chosen recursive chmod. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From skvidal at fedoraproject.org Sat Sep 22 14:30:24 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 22 Sep 2007 10:30:24 -0400 Subject: yum pulling in 386 packages In-Reply-To: <200709220944.33124.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> Message-ID: <1190471424.2166.18.camel@cutter> On Sat, 2007-09-22 at 09:44 -0400, Steve Grubb wrote: > Hi, > > This morning I checked rawhide. My x86_64 machine has no 386 packages on it. > Doing yum update suddenly wanted to pull in 386 packages to my system. I > updated packages 1 by 1 until I was down to updating NetworkManager.x86_64. > If I type "yum update NetworkManager.x86_64" or "yum update NetworkManager", > I get only 64 bit packages. If I type "yum update", it pulls in the 386 > version of NetworkManager and all its dependencies. > > So, those of you with pristine 64 bit machines, watch out for this or 32 bit > packages will start creeping back into your system. Is this a known problem > or should a bz be filed? what ver of yum is this? and can you post to a bug the yum -d 6 update output? -sv From sgrubb at redhat.com Sat Sep 22 15:04:34 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Sep 2007 11:04:34 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190471424.2166.18.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> Message-ID: <200709221104.35264.sgrubb@redhat.com> On Saturday 22 September 2007 10:30:24 seth vidal wrote: > what ver of yum is this? current rawhide: 3.2.5-3 > and can you post to a bug the yum -d 6 update > output? Sure, bz 301661. One thing I found, its related to dhcdbd getting deleted. If you delete by hand, it works fine. If yum does the delete, it pulls in 386 packages. -Steve From dwmw2 at infradead.org Sat Sep 22 15:14:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 22 Sep 2007 16:14:02 +0100 Subject: yum pulling in 386 packages In-Reply-To: <200709220944.33124.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> Message-ID: <1190474042.27926.1.camel@shinybook.infradead.org> On Sat, 2007-09-22 at 09:44 -0400, Steve Grubb wrote: > Hi, > > This morning I checked rawhide. My x86_64 machine has no 386 packages on it. > Doing yum update suddenly wanted to pull in 386 packages to my system. I > updated packages 1 by 1 until I was down to updating NetworkManager.x86_64. > If I type "yum update NetworkManager.x86_64" or "yum update NetworkManager", > I get only 64 bit packages. If I type "yum update", it pulls in the 386 > version of NetworkManager and all its dependencies. > > So, those of you with pristine 64 bit machines, watch out for this or 32 bit > packages will start creeping back into your system. Is this a known problem > or should a bz be filed? Hm, how did you get a pristine 64-bit machine? Did bug #235756 get fixed? -- dwmw2 From sgrubb at redhat.com Sat Sep 22 16:14:18 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Sep 2007 12:14:18 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190474042.27926.1.camel@shinybook.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> Message-ID: <200709221214.19184.sgrubb@redhat.com> On Saturday 22 September 2007 11:14:02 David Woodhouse wrote: > > So, those of you with pristine 64 bit machines, watch out for this or 32 > > bit packages will start creeping back into your system. Is this a known > > problem or should a bz be filed? > > Hm, how did you get a pristine 64-bit machine? One day a couple months ago, I noticed I was about to download > 100 Mb of packages that I would never use (I think it was all the 386 kde packages), so I did a yum remove of every 386 or 686 package I could find. Doing "yum update" has not pulled any 386 packages back in until today. > Did bug #235756 get fixed? no idea.... -Steve From dwmw2 at infradead.org Sat Sep 22 16:40:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 22 Sep 2007 17:40:49 +0100 Subject: yum pulling in 386 packages In-Reply-To: <200709221214.19184.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> <200709221214.19184.sgrubb@redhat.com> Message-ID: <1190479249.22181.1.camel@shinybook.infradead.org> On Sat, 2007-09-22 at 12:14 -0400, Steve Grubb wrote: > On Saturday 22 September 2007 11:14:02 David Woodhouse wrote: > > > So, those of you with pristine 64 bit machines, watch out for this or 32 > > > bit packages will start creeping back into your system. Is this a known > > > problem or should a bz be filed? > > > > Hm, how did you get a pristine 64-bit machine? > > One day a couple months ago, I noticed I was about to download > 100 Mb of > packages that I would never use (I think it was all the 386 kde packages), so > I did a yum remove of every 386 or 686 package I could find. Doing "yum > update" has not pulled any 386 packages back in until today. Yeah, I think the bug only trips when you pull in something by name. If you invoke 'yum install foo' that will pull in both versions, and I think it also happens if some package is listed in Requires: by name. > > Did bug #235756 get fixed? > > no idea.... Evidently not. It would be _really_ good if we could get that fixed for F8. -- dwmw2 From abo at kth.se Sat Sep 22 16:42:06 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 22 Sep 2007 18:42:06 +0200 Subject: Disable IPv6 by default. In-Reply-To: <46E982F2.1030600@BitWagon.com> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> Message-ID: <1190479326.26487.354.camel@home.alexander.bostrom.net> On Thu, 2007-09-13 at 11:35 -0700, John Reiser wrote: > For such users, leaving IPv6 enabled is a security risk. The default ip6tables are pretty restrictive, so if you leave them unchanged because you don't think they matter or don't know about them it's fairly safe. (Except for ssh port, see below. And yes, I understand that the filter rules are not the only complaint regarding IPv6 and security.) There are other more low-hanging fruits, I think. My personal pet peeve is the default enabled sshd. It's off on the live CD thankfully, but will it be off on the Desktop spin too? A desktop machine with sshd enabled by default without telling the user and the user having no idea that their crappy password can be exploited remotely is a really bad idea IMO. Besides, I think even if you don't have IPv6 routed to your machine, there are probably interesting use cases for the link local addresse. Really -1 for disabling IPv6, Fedora is about progress, not workarounds. /abo From abo at kth.se Sat Sep 22 16:54:49 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 22 Sep 2007 18:54:49 +0200 Subject: Disable IPv6 by default. In-Reply-To: <1190479326.26487.354.camel@home.alexander.bostrom.net> References: <46E9447E.9080105@hi.is> <46E94BD2.5080506@BitWagon.com> <46E950C5.301@hi.is> <200709131012.18983.dennis@ausil.us> <46E968A1.8090603@BitWagon.com> <1189707065.18288.4.camel@localhost.localdomain> <46E982F2.1030600@BitWagon.com> <1190479326.26487.354.camel@home.alexander.bostrom.net> Message-ID: <1190480089.26487.356.camel@home.alexander.bostrom.net> On Sat, 2007-09-22 at 18:42 +0200, Alexander Bostr?m wrote: > It's off on the live CD thankfully, but > will it be off on the Desktop spin too? Eh, please ignore my confusion. My point still stands though, but I've been voted down before about that... /abo From snecklifter at gmail.com Sat Sep 22 16:58:54 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 22 Sep 2007 17:58:54 +0100 Subject: hpet timer patch for powertop In-Reply-To: <3da3b5b40709220645v55e83108y4300d2367c49b922@mail.gmail.com> References: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> <20070922083651.104fa094@vader.jdub.homelinux.org> <3da3b5b40709220645v55e83108y4300d2367c49b922@mail.gmail.com> Message-ID: <364d303b0709220958y42ac3701tee997b993ad3028d@mail.gmail.com> On 22/09/2007, Ahmed Kamal wrote: > > actually I'm still on FC6, and I'm using i686 CPU. The kernel is from > tuxonice (suspend2) which is basically the same fedora kernel with suspend2 > patches. Anyway, I thought all .22 kernels had tickless, dont they. > If all of this + hpet patches will be in fedora8, I will be a happy > fedorian ;) Yes, all kernels >= 2.6.22 for x86 are tickless. x86_64 are not for f7 but will be for f8. http://fedoraproject.org/wiki/Releases/FeatureTicklessKernel Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abo at kth.se Sat Sep 22 17:09:27 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 22 Sep 2007 19:09:27 +0200 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <20070914000724.GB2213@jadzia.bu.edu> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> <20070914000724.GB2213@jadzia.bu.edu> Message-ID: <1190480967.26487.367.camel@home.alexander.bostrom.net> On Thu, 2007-09-13 at 20:07 -0400, Matthew Miller wrote: > Why not just get the gecos name field right? One problem with the GECOS field is that if the information comes from LDAP, it will be ASCII only. (The cn field in LDAP is a UTF-8 string, but nss_ldap doesn't care about it.) In /etc/passwd you can put arbitrary bytes so UTF-8 works there, but not with LDAP. Hmm... Maybe I can configure nss_ldap to actually use cn instead... /abo From dimitris at glezos.com Sat Sep 22 17:50:13 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Sat, 22 Sep 2007 18:50:13 +0100 Subject: desc and summary In-Reply-To: <27834210.1539991189604591702.JavaMail.www@wwinf8403> References: <27834210.1539991189604591702.JavaMail.www@wwinf8403> Message-ID: <1190483413.3234.23.camel@shuttle> ???? 12-09-2007, ????? ???, ??? ??? 15:43 +0200, ?/? nicolas.mailhot at laposte.net ??????: > > De : "Jeremy Katz" > > > Actually, nothing says that additional repos can't have their own > > specspo-type package as well. > > This is considerably upping the bar to creation of a new repository, > and making impossible the common "collect rpms, launch createrepo" > workflow Is it that bad really? It's a step that could be done by a script and have the POs hosted at the repo's own VCS, reached by transifex. > > All of the above said, specspo probably _isn't_ the > > right answer... > > Yes, it was hyped as necessary to make translator work easy, and now > you have translators complaining of it. Is there a way to have these PO files cut into more "logical" pieces? Translators for example would like to work incrementally from the most to the less important ones. Or, have a PO with packages that will (most likely) show up in the main screens of pirut, etc. Maybe specspo is a good opportunity to start thinking about installing a pootle server. If the strings don't change very often, the maintenance cost (merging, etc) could be bearable. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From adam at spicenitz.org Sat Sep 22 18:28:47 2007 From: adam at spicenitz.org (Adam Goode) Date: Sat, 22 Sep 2007 14:28:47 -0400 Subject: Trying to fix gcc bz247407 Message-ID: <46F55EDF.1060307@spicenitz.org> Hi, My package MLton is broken on architectures other than x86 and x86_64. MLton is a compiler with native x86/x86_64 backends, and a C backend. The output of its C backend is crashing gcc. https://bugzilla.redhat.com/show_bug.cgi?id=247407 There appears to be a simple fix: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694 I've been trying to get the attention of the gcc maintainer, without luck. Any ideas? Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Sat Sep 22 18:59:46 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 22 Sep 2007 14:59:46 -0400 Subject: Possible account information APIs? (lookupd etc) In-Reply-To: <1190480967.26487.367.camel@home.alexander.bostrom.net> References: <939dd5750709131341r5c0c3c87k157fe6f9ffd272cc@mail.gmail.com> <20070913204532.GA29167@nostromo.devel.redhat.com> <939dd5750709131429x46c09bd0y316246afb399676@mail.gmail.com> <20070914000724.GB2213@jadzia.bu.edu> <1190480967.26487.367.camel@home.alexander.bostrom.net> Message-ID: <1190487586.21505.10.camel@localhost.localdomain> On Sat, 2007-09-22 at 19:09 +0200, Alexander Bostr?m wrote: > On Thu, 2007-09-13 at 20:07 -0400, Matthew Miller wrote: > > Why not just get the gecos name field right? > > One problem with the GECOS field is that if the information comes from > LDAP, it will be ASCII only. (The cn field in LDAP is a UTF-8 string, > but nss_ldap doesn't care about it.) In /etc/passwd you can put > arbitrary bytes so UTF-8 works there, but not with LDAP. Unfortunately the homeDirectory attribute too is IA5String, I wonder if servers really enforce this today. Simo. From email.ahmedkamal at googlemail.com Sat Sep 22 19:00:31 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 22 Sep 2007 21:00:31 +0200 Subject: hpet timer patch for powertop In-Reply-To: <364d303b0709220958y42ac3701tee997b993ad3028d@mail.gmail.com> References: <3da3b5b40709220604g68f194baue66de4675255f6ed@mail.gmail.com> <20070922083651.104fa094@vader.jdub.homelinux.org> <3da3b5b40709220645v55e83108y4300d2367c49b922@mail.gmail.com> <364d303b0709220958y42ac3701tee997b993ad3028d@mail.gmail.com> Message-ID: <3da3b5b40709221200w7308c2fbi661449fcf3acd2f5@mail.gmail.com> Cool, but it seems that my tickless kernel is ticking! Also since "grep -i hpet /proc/timer_list" returns nothing, it seems my BIOS is disabling hpet, so the hpet force-enable patch is needed. I guess the question now is, will F8 kernel contain that patch? Since the powertop guys say that *lots* of BIOSs disable hpet, I think it's beneficial to merge that. On 9/22/07, Christopher Brown wrote: > > On 22/09/2007, Ahmed Kamal wrote: > > > > actually I'm still on FC6, and I'm using i686 CPU. The kernel is from > > tuxonice (suspend2) which is basically the same fedora kernel with suspend2 > > patches. Anyway, I thought all .22 kernels had tickless, dont they. > > If all of this + hpet patches will be in fedora8, I will be a happy > > fedorian ;) > > > Yes, all kernels >= 2.6.22 for x86 are tickless. x86_64 are not for f7 but > will be for f8. > > http://fedoraproject.org/wiki/Releases/FeatureTicklessKernel > > Cheers > Chris > > -- > http://www.chruz.com > -- > 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 abo at kth.se Sat Sep 22 19:02:17 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 22 Sep 2007 21:02:17 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <20070921093746.GB5037@devserv.devel.redhat.com> References: <46F33D05.4020701@ncsu.edu> <20070921093746.GB5037@devserv.devel.redhat.com> Message-ID: <1190487737.26487.375.camel@home.alexander.bostrom.net> I back up everything in /var except /var/cache. I also back up /srv, though it's usually empty. So I really don't mind if important data is kept in /var, I've always thought that's what it's for. If someone wants to start moving things around, then that's perhaps ok, though I would consider it confusing and unnecessary. And the new location can't be /srv because it has no structure. So you need to come up with a new directory instead. Then everyone needs to add that directory to their backup set. See... This is pointless. Let's keep important stuff in /var/lib/, it works. /abo From mszpak at wp.pl Sat Sep 22 19:36:32 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sat, 22 Sep 2007 21:36:32 +0200 Subject: Calling any text editor for any text file Message-ID: Hi, Some time ago I asked [1] about calling default text editor from an application (here for isomaster). I can't use editor assigned to specified mime type, because any (text) file (even html) should be opened in a text editor (not e.g. web browser). I wrote a small script for that purpose and before its upload I would like to ask for comments. [1] - https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00698.html Regards Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: text-editor.sh Type: application/x-shellscript Size: 511 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Sep 22 20:18:14 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 22 Sep 2007 23:18:14 +0300 Subject: Calling any text editor for any text file In-Reply-To: References: Message-ID: <200709222318.15391.ville.skytta@iki.fi> On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > Some time ago I asked [1] about calling default text editor from an > application (here for isomaster). I can't use editor assigned to > specified mime type, because any (text) file (even html) should be > opened in a text editor (not e.g. web browser). > > I wrote a small script for that purpose and before its upload I would > like to ask for comments. - emacs is missing from the list - Should take current desktop environment into account, eg. prefer kate over gedit if running KDE even if gedit is installed - Should provide a way for users to set their preferred editor and not do any detection, eg. in a sourced ~/.somefile - Should probably be quiet by default, output stuff to stdout only on request - Would be nice to have this kind of a tool in xdg-utils, eg. as "xdg-edit" or "xdg-open --edit". Ask xdg-utils upstream? From mszpak at wp.pl Sat Sep 22 20:42:19 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Sat, 22 Sep 2007 22:42:19 +0200 Subject: Calling any text editor for any text file In-Reply-To: <200709222318.15391.ville.skytta@iki.fi> References: <200709222318.15391.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > >> Some time ago I asked [1] about calling default text editor from an >> application (here for isomaster). I can't use editor assigned to >> specified mime type, because any (text) file (even html) should be >> opened in a text editor (not e.g. web browser). >> >> I wrote a small script for that purpose and before its upload I would >> like to ask for comments. > > - emacs is missing from the list Does emacs graphical interface (doesn't need a console)? > - Should take current desktop environment into account, eg. prefer kate over > gedit if running KDE even if gedit is installed In a version for iso master it was created to be a default editor (it's better to open in any editor than doesn't open at all). User can change it from GUI. But if you know more programs (packagers) that have similar problem a script could be enhanced to be more "powerful" :) Btw, is there a simple way to determine already running desktop environment? > - Should provide a way for users to set their preferred editor and not do any > detection, eg. in a sourced ~/.somefile For the second version of that script it's a good idea. In Fedora I don't know a way to call default text editor on any file. > - Should probably be quiet by default, output stuff to stdout only on request Yes, debug output could be disabled by default. > - Would be nice to have this kind of a tool in xdg-utils, eg. as "xdg-edit" or > "xdg-open --edit". Ask xdg-utils upstream? Why not. I wrote it because that option was missing in xdg-utils. But maybe I'm the only one who needs that functionality? Thanks for you comments. Marcin From ville.skytta at iki.fi Sat Sep 22 20:59:53 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 22 Sep 2007 23:59:53 +0300 Subject: Calling any text editor for any text file In-Reply-To: References: <200709222318.15391.ville.skytta@iki.fi> Message-ID: <200709222359.54262.ville.skytta@iki.fi> On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > Ville Skytt? wrote: > Does emacs graphical interface (doesn't need a console)? Yes. It also starts faster than XEmacs and integrates better with the desktop (at least look and feel wise) so I suggest trying it before XEmacs in the script. Also, I don't know if XFCE comes with a text editor or a few, they could also be added to the mix. > But if you know more programs (packagers) that have similar problem a > script could be enhanced to be more "powerful" :) I do see some general purpose use cases for such a script. > Btw, is there a simple way to determine already running desktop > environment? One way is in /usr/bin/xdg-open, see detectDE() in it. > > - Would be nice to have this kind of a tool in xdg-utils, eg. as > > "xdg-edit" or "xdg-open --edit". Ask xdg-utils upstream? > > Why not. I wrote it because that option was missing in xdg-utils. > > But maybe I'm the only one who needs that functionality? I don't think so. Additionally, I think this would be useful for other file types besides text files for viewing vs editing, eg. image files. From jkeating at redhat.com Sat Sep 22 21:14:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Sep 2007 17:14:22 -0400 Subject: yum pulling in 386 packages In-Reply-To: <200709221104.35264.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> Message-ID: <20070922171422.77bf3eac@redhat.com> On Sat, 22 Sep 2007 11:04:34 -0400 Steve Grubb wrote: > Sure, bz 301661. One thing I found, its related to dhcdbd getting > deleted. If you delete by hand, it works fine. If yum does the > delete, it pulls in 386 packages. Ah right, it's being obsoleted by multiple packages in the repo, both the x86_64 versions and the i386 versions. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sat Sep 22 20:29:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 22 Sep 2007 16:29:20 -0400 Subject: [Policy Change] Kernel Module packages no longer permitted Message-ID: <1190492961.3966.4.camel@localhost.localdomain> At one point (pre Fedora 8), packages containing "addon" kernel modules were permitted. This is no longer the case. Fedora strongly encourages kernel module packagers to submit their code into the upstream kernel tree. Existing kernel module packages must be removed (or merged into the main kernel package) before Fedora 9. The reference documentation on how to package kernel modules in the "kmod" style has been preserved http://fedoraproject.org/wiki/Obsolete/KernelModules This change was ratified by FESCo. Thanks, ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From louisg00 at bellsouth.net Sat Sep 22 21:20:51 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sat, 22 Sep 2007 17:20:51 -0400 Subject: boot.iso with stage2 Message-ID: <1190496051.9745.4.camel@sonlaptop> If I placed stage2.img inside the boot.iso from rawhide and burned it would it act like a rescuecd? would the installer find stage2 in the cd instead of downloading it. -Thanks From kevin at scrye.com Sat Sep 22 21:23:09 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Sat, 22 Sep 2007 15:23:09 -0600 Subject: Calling any text editor for any text file In-Reply-To: <200709222359.54262.ville.skytta@iki.fi> References: <200709222318.15391.ville.skytta@iki.fi> <200709222359.54262.ville.skytta@iki.fi> Message-ID: <20070922152309.0871780d@ghistelwchlohm.scrye.com> On Sat, 22 Sep 2007 23:59:53 +0300 ville.skytta at iki.fi (Ville Skytt?) wrote: > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > > Ville Skytt? wrote: > > > Does emacs graphical interface (doesn't need a console)? > > Yes. It also starts faster than XEmacs and integrates better with > the desktop (at least look and feel wise) so I suggest trying it > before XEmacs in the script. > > Also, I don't know if XFCE comes with a text editor or a few, they > could also be added to the mix. The Xfce text editor is 'mousepad'. It's a very simple editor, but it starts really fast... ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mszpak at wp.pl Sat Sep 22 21:31:35 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Sat, 22 Sep 2007 23:31:35 +0200 Subject: Calling any text editor for any text file In-Reply-To: <200709222359.54262.ville.skytta@iki.fi> References: <200709222318.15391.ville.skytta@iki.fi> <200709222359.54262.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: >> Ville Skytt? wrote: > >> Does emacs graphical interface (doesn't need a console)? > > Yes. It also starts faster than XEmacs and integrates better with the desktop > (at least look and feel wise) so I suggest trying it before XEmacs in the > script. Ok. I don't know them. I prefer Vim :) > Also, I don't know if XFCE comes with a text editor or a few, they could also > be added to the mix. I asked my friend and he told me that mousepad (already on the list) is a good choice for a try with Xfce. But, Xfce users, other propositions for Xfce are welcome. >> But if you know more programs (packagers) that have similar problem a >> script could be enhanced to be more "powerful" :) > > I do see some general purpose use cases for such a script. Thanks :) >> Btw, is there a simple way to determine already running desktop >> environment? > > One way is in /usr/bin/xdg-open, see detectDE() in it. A nice hack :). But it probably works. I will think about some optimizations. >>> - Would be nice to have this kind of a tool in xdg-utils, eg. as >>> "xdg-edit" or "xdg-open --edit". Ask xdg-utils upstream? >> Why not. I wrote it because that option was missing in xdg-utils. >> >> But maybe I'm the only one who needs that functionality? > > I don't think so. Additionally, I think this would be useful for other file > types besides text files for viewing vs editing, eg. image files. xdg-open for open operation uses mime types and assigned application. I'm not sure how application for edit operation should be defined/choose. Marcin From myfedora at richip.dhs.org Sat Sep 22 22:37:54 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 22 Sep 2007 16:37:54 -0600 Subject: yum pulling in 386 packages In-Reply-To: <1190479249.22181.1.camel@shinybook.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> <200709221214.19184.sgrubb@redhat.com> <1190479249.22181.1.camel@shinybook.infradead.org> Message-ID: <1190500674.27608.1.camel@localhost6.localdomain6> On Sat, 2007-09-22 at 17:40 +0100, David Woodhouse wrote: > Yeah, I think the bug only trips when you pull in something by name. If > you invoke 'yum install foo' that will pull in both versions, and I > think it also happens if some package is listed in Requires: by name. I've been using "exclude=*.i386" in my /etc/yum.conf for a while, but I DO have nspluginwrapper (and it's requirements) installed. So "yum update"s would miss updates to that. -- Richi Plana From skvidal at fedoraproject.org Sat Sep 22 23:33:30 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 22 Sep 2007 19:33:30 -0400 Subject: yum pulling in 386 packages In-Reply-To: <20070922171422.77bf3eac@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> Message-ID: <1190504010.2166.22.camel@cutter> On Sat, 2007-09-22 at 17:14 -0400, Jesse Keating wrote: > On Sat, 22 Sep 2007 11:04:34 -0400 > Steve Grubb wrote: > > > Sure, bz 301661. One thing I found, its related to dhcdbd getting > > deleted. If you delete by hand, it works fine. If yum does the > > delete, it pulls in 386 packages. > > Ah right, it's being obsoleted by multiple packages in the repo, both > the x86_64 versions and the i386 versions. Ding- you got it - well done. Steve, If you want to avoid this behavior in the future add: exclude=*.?86 to your yum.conf. -sv From michael.wiktowy at gmail.com Sat Sep 22 23:42:58 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Sat, 22 Sep 2007 19:42:58 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190504010.2166.22.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> Message-ID: <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> On 9/22/07, seth vidal wrote: > If you want to avoid this behavior in the future add: exclude=*.?86 to > your yum.conf. Is this something that anaconda should add to all x86_64 installations or is this just a workaround that might hide bugs and prevent Steve from being the canary in the coal mine? /Mike From skvidal at fedoraproject.org Sat Sep 22 23:44:19 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 22 Sep 2007 19:44:19 -0400 Subject: yum pulling in 386 packages In-Reply-To: <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> Message-ID: <1190504659.2166.24.camel@cutter> On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote: > On 9/22/07, seth vidal wrote: > > If you want to avoid this behavior in the future add: exclude=*.?86 to > > your yum.conf. > > Is this something that anaconda should add to all x86_64 installations > or is this just a workaround that might hide bugs and prevent Steve > from being the canary in the coal mine? > There isn't a bug here.Yum is doing exactly what it says to do. If steve wants an x86_64-pure system then in order to avoid obsoletes coming in like this he needs to add an exclude. -sv From mattdm at mattdm.org Sat Sep 22 23:55:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 22 Sep 2007 19:55:54 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190504659.2166.24.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> Message-ID: <20070922235554.GA24020@jadzia.bu.edu> On Sat, Sep 22, 2007 at 07:44:19PM -0400, seth vidal wrote: > There isn't a bug here.Yum is doing exactly what it says to do. If steve > wants an x86_64-pure system then in order to avoid obsoletes coming in > like this he needs to add an exclude. The problem comes in when people want a mostly-pure system. The current infrastructure isn't designed to handle that. There's a simple plugin in yum-utils to work towards this behavior, but it needs a lot of work. People who are interested in this should work on it. (yum-basearchonly). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From michael.wiktowy at gmail.com Sun Sep 23 00:14:42 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Sat, 22 Sep 2007 20:14:42 -0400 Subject: yum pulling in 386 packages In-Reply-To: <20070922235554.GA24020@jadzia.bu.edu> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <20070922235554.GA24020@jadzia.bu.edu> Message-ID: <3e4ec4600709221714i3b027a64y40d628f72636d19b@mail.gmail.com> On 9/22/07, Matthew Miller wrote: > On Sat, Sep 22, 2007 at 07:44:19PM -0400, seth vidal wrote: > > There isn't a bug here.Yum is doing exactly what it says to do. If steve > > wants an x86_64-pure system then in order to avoid obsoletes coming in > > like this he needs to add an exclude. > > The problem comes in when people want a mostly-pure system. The current > infrastructure isn't designed to handle that. > > There's a simple plugin in yum-utils to work towards this behavior, but it > needs a lot of work. People who are interested in this should work on it. > (yum-basearchonly). I am now just starting to administer x86_64 arch boxen and not finding much info (or rather a lot of very sparce info) after Googling around on what the pros and cons are of having a "pure" x86_64 system vs. installing a mix with i?86 packages. So while yum is blameless here, I thought that the package obsoletes were the bug here. Or is the only con here wasted disk space? /Mike From jkeating at redhat.com Sun Sep 23 00:48:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Sep 2007 20:48:49 -0400 Subject: boot.iso with stage2 In-Reply-To: <1190496051.9745.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> Message-ID: <20070922204849.2a734281@redhat.com> On Sat, 22 Sep 2007 17:20:51 -0400 Louis E Garcia II wrote: > If I placed stage2.img inside the boot.iso from rawhide and burned it > would it act like a rescuecd? would the installer find stage2 in the > cd instead of downloading it. Why not just download the rescue cd? The boot.iso may need more bits on it to act like a rescue image. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sgrubb at redhat.com Sun Sep 23 01:55:50 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 22 Sep 2007 21:55:50 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190504010.2166.22.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> Message-ID: <200709222155.50750.sgrubb@redhat.com> On Saturday 22 September 2007 19:33:30 seth vidal wrote: > If you want to avoid this behavior in the future add: exclude=*.?86 to > your yum.conf. Doesn't "yum update" mean update the packages I have installed? I do not have i386 packages installed. No packages selected REQUIRES 32 bit only packages. Typing "yum update NetworkManager" selected only x64_64 packages even though I didn't specify an architecture. Why can't "yum update" follow the same behavior? Why does the obsolete cause it to decide to pull in 32 bit packages? If I do the delete, "yum update" changes behavior and only selects 64 bit packages. Something is wrong here. I also have the exactarch=1. If that doesn't mean x86_64, what does it mean? -Steve From skvidal at fedoraproject.org Sun Sep 23 02:35:03 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 22 Sep 2007 22:35:03 -0400 Subject: yum pulling in 386 packages In-Reply-To: <200709222155.50750.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <200709222155.50750.sgrubb@redhat.com> Message-ID: <1190514903.2166.26.camel@cutter> On Sat, 2007-09-22 at 21:55 -0400, Steve Grubb wrote: > On Saturday 22 September 2007 19:33:30 seth vidal wrote: > > If you want to avoid this behavior in the future add: exclude=*.?86 to > > your yum.conf. > > Doesn't "yum update" mean update the packages I have installed? I do not have > i386 packages installed. No packages selected REQUIRES 32 bit only packages. > Typing "yum update NetworkManager" selected only x64_64 packages even though > I didn't specify an architecture. Why can't "yum update" follow the same > behavior? Why does the obsolete cause it to decide to pull in 32 bit > packages? If I do the delete, "yum update" changes behavior and only selects > 64 bit packages. Something is wrong here. > > I also have the exactarch=1. If that doesn't mean x86_64, what does it mean? obsoletes are allowed to cross arch boundaries. In fact, there's no way to specify otherwise in an rpm -sv From michel.sylvan at gmail.com Sun Sep 23 04:12:27 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 23 Sep 2007 00:12:27 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190410702.5762.26.camel@valkyrie.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> Message-ID: On 21/09/2007, Matthew Saltzman wrote: > My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64 > live dvd and installed the x86_64 DVD. This message covers > platform-specific issues that I encountered. > > Live DVD: > > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > system-config-display, there are two problems. > > (1) The Monitor section of xorg.conf is missing. Is this the 14.1" or 15" screen? Which resolution? (I'm asking, because on my 14.1" WXGA (1280x800) the display is detected just fine) -- Michel From louisg00 at bellsouth.net Sun Sep 23 04:38:48 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sun, 23 Sep 2007 00:38:48 -0400 Subject: boot.iso with stage2 In-Reply-To: <1190496051.9745.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> Message-ID: <1190522328.8062.4.camel@sonlaptop> On Sat, 22 Sep 2007 20:48:49 -0400, Jesse Keating wrote: > On Sat, 2007-09-22 at 17:20 -0400, Louis E Garcia II wrote: > > If I placed stage2.img inside the boot.iso from rawhide and burned it > > would it act like a rescuecd? would the installer find stage2 in the cd > > instead of downloading it. > > > > -Thanks > > Why not just download the rescue cd? The boot.iso may need more bits > on it to act like a rescue image. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? Because rawhide doesn't provide a rescue cd. -Louis From jfrieben at gmx.de Sun Sep 23 06:23:48 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 23 Sep 2007 08:23:48 +0200 Subject: boot.iso with stage2 In-Reply-To: <1190522328.8062.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> <1190522328.8062.4.camel@sonlaptop> Message-ID: <20070923062348.302060@gmx.net> > Because rawhide doesn't provide a rescue cd. > > -Louis This shouldn't be a major problem as any recent rescue CD can be used to either rescue a system or do a net install of 'rawhide'. I even managed to install FC5 using some F7 test release rescue CD when the kernel of the FC5 install media didn't support the network card of the system [whereas a later update kernel would]. -JF -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From dwmw2 at infradead.org Sun Sep 23 08:48:32 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 23 Sep 2007 09:48:32 +0100 Subject: yum pulling in 386 packages In-Reply-To: <1190504659.2166.24.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> Message-ID: <1190537312.7150.300.camel@pmac.infradead.org> On Sat, 2007-09-22 at 19:44 -0400, seth vidal wrote: > On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote: > > On 9/22/07, seth vidal wrote: > > > If you want to avoid this behavior in the future add: exclude=*.?86 to > > > your yum.conf. That doesn't work when you want _some_ i386 packages which you specify explicitly. Or on ppc64/sparc64 where you do want the 64-bit kernel but all userspace can be 32-bit. It's just a fairly dodgy workaround. > > Is this something that anaconda should add to all x86_64 installations > > or is this just a workaround that might hide bugs and prevent Steve > > from being the canary in the coal mine? > > There isn't a bug here.Yum is doing exactly what it says to do. "it says to do"? I'm not quite sure of your meaning there -- I think you're really saying "yum is doing exactly what yum does". Which is true, but not really relevant. I consider yum's behaviour buggy, as do many others. Arguing over whether to call bug #235756 a bug or an RFE doesn't really buy us anything. It's just bug #235756. All bug reports are really requests for enhancement at some level, aren't they? If I say 'yum install foo', I just want _one_ version of foo installed -- the 32-bit PPC version that I actually intend to use. I don't want a pointless 64-bit version installed, and I don't want an i386 version installed for qemu to use under /usr/qemu-i386 either. If I want those, I'll ask for them. Neither do I want yum to search for ssh sessions where I am logged in as root to other boxes, and install 'foo' there too. Although 'install foo' is, when you think about it, a fairly vague command and can be wilfully misinterpreted to mean any of the above, it really _ought_ to be interpreted with a little bit of common sense. By doing _any_ but the first of the operations above, yum would be exceeding its mandate; doing something I didn't _really_ ask it to do. It's supposed to be a useful piece of software, for $DEITY's sake -- not a genie in a bottle trying to distort my wishes. It would be really nice if we had a proper fix for this misbehaviour before F8. -- dwmw2 From drago01 at gmail.com Sun Sep 23 08:58:57 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 23 Sep 2007 10:58:57 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190479249.22181.1.camel@shinybook.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> <200709221214.19184.sgrubb@redhat.com> <1190479249.22181.1.camel@shinybook.infradead.org> Message-ID: <46F62AD1.5030608@gmail.com> David Woodhouse wrote: > On Sat, 2007-09-22 at 12:14 -0400, Steve Grubb wrote: > >> On Saturday 22 September 2007 11:14:02 David Woodhouse wrote: >> >>>> So, those of you with pristine 64 bit machines, watch out for this or 32 >>>> bit packages will start creeping back into your system. Is this a known >>>> problem or should a bz be filed? >>>> >>> Hm, how did you get a pristine 64-bit machine? >>> >> One day a couple months ago, I noticed I was about to download > 100 Mb of >> packages that I would never use (I think it was all the 386 kde packages), so >> I did a yum remove of every 386 or 686 package I could find. Doing "yum >> update" has not pulled any 386 packages back in until today. >> > > Yeah, I think the bug only trips when you pull in something by name. If > you invoke 'yum install foo' that will pull in both versions yum install yum-basearchonly will do exactly that (only pull in foo if you want foo.i386 you have to ask for it). From ville.skytta at iki.fi Sun Sep 23 09:00:20 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 23 Sep 2007 12:00:20 +0300 Subject: yum pulling in 386 packages In-Reply-To: <1190504659.2166.24.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> Message-ID: <200709231200.21125.ville.skytta@iki.fi> On Sunday 23 September 2007, seth vidal wrote: > On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote: > > On 9/22/07, seth vidal wrote: > > > If you want to avoid this behavior in the future add: exclude=*.?86 to > > > your yum.conf. > > > > Is this something that anaconda should add to all x86_64 installations > > or is this just a workaround that might hide bugs and prevent Steve > > from being the canary in the coal mine? > > There isn't a bug here.Yum is doing exactly what it says to do. If steve > wants an x86_64-pure system then in order to avoid obsoletes coming in > like this he needs to add an exclude. I don't think it's an acceptable solution for the very common case where you want some ix86 packages on an x86_64 system. FWIW, smart seems to do the right thing out of the box (which is one of the few remaining reasons I personally still prefer it over yum). From denis at poolshark.org Sun Sep 23 09:11:27 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 23 Sep 2007 11:11:27 +0200 Subject: open-vm-tools (was Re: [Policy Change] Kernel Module...) In-Reply-To: <1190492961.3966.4.camel@localhost.localdomain> References: <1190492961.3966.4.camel@localhost.localdomain> Message-ID: <46F62DBF.2090405@poolshark.org> Tom "spot" Callaway wrote: > At one point (pre Fedora 8), packages containing "addon" kernel modules > were permitted. This is no longer the case. Fedora strongly encourages > kernel module packagers to submit their code into the upstream kernel > tree. > > Existing kernel module packages must be removed (or merged into the main > kernel package) before Fedora 9. > > The reference documentation on how to package kernel modules in the > "kmod" style has been preserved > http://fedoraproject.org/wiki/Obsolete/KernelModules > > This change was ratified by FESCo. In a somewhat ironic turn of event, the new policy coincides with the release of the much anticipated open-vm-tools (http://open-vm-tools.sourceforge.net/), the VMware guest OS tool suite. VMware is doing the right thing here by completely opening up their guest stuff and it's fair to say nobody will miss their Nvidia-style vmware-config-tools.pl script (and the any any updates) :-) It would be nice to have this in Fedora. The goal being having Fedora fully functional out of the box when installed in a VM. The review is here: https://bugzilla.redhat.com/show_bug.cgi?id=294341 Philip Langdale says they are aware of the need to push this upstream and will work on it. Eventually (see bugzilla ticket). How actively is unfortunately hard to know for sure. To their defense, they have successfully pushed some of their work upstream in the past, their X.org driver for example. So how can we make this happen ? Could this be discussed at the next FESCo meeting ? thx -denis From buildsys at redhat.com Sun Sep 23 10:14:58 2007 From: buildsys at redhat.com (Build System) Date: Sun, 23 Sep 2007 06:14:58 -0400 Subject: rawhide report: 20070923 changes Message-ID: <200709231014.l8NAEw0K015040@porkchop.devel.redhat.com> Updated Packages: BackupPC-3.0.0-3.fc8 -------------------- * Fri Sep 21 2007 Johan Cwiklinski 3.0.0-3 - Fixed SELinux policy module * Wed Sep 12 2007 Johan Cwiklinski 3.0.0-2 - Added SELinux policy module * Tue Jan 30 2007 Johan Cwiklinski 3.0.0-1 - Rebuild RPM for v 3.0.0 GConf2-2.20.0-2.fc8 ------------------- * Sat Sep 22 2007 Matthias Clasen - 2.20.0-2 - Require /usr/bin/killall, since gconftool uses it aspell-he-1.0-2.fc8 ------------------- * Sun Apr 01 2007 Dan Kenigsberg 1.0-3 - Clean spec file according to lessons from Bug #212974. bash-completion-20060301-6.fc8 ------------------------------ * Sat Sep 22 2007 Ville Skytt?? - 20060301-6 - Patch to improve perl completion (#299571, Jim Radford, http://use.perl.org/~Alias/journal/33508). * Mon Aug 13 2007 Ville Skytt?? - 20060301-5 - License: GPLv2+ compiz-fusion-0.5.2-7.09b700.fc8 -------------------------------- * Thu Sep 20 2007 Adel Gadllah 0.5.2-7.09b700 - Update to 0.6 branch (builds against current compiz) * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 - Add animation to plugin list compiz-fusion-extras-0.5.2-6.6871d0.fc8 --------------------------------------- * Thu Sep 20 2007 Adel Gadllah 0.5.2-6.6871d0 - Update to 0.6 branch (builds against current compiz) fedora-package-config-smart-8-10 -------------------------------- * Sun Sep 23 2007 Ville Skytt?? - 8-10 - Update for Fedora 8. - Add empty %build section. - Improve summary and description. - License: GPL+ - Update URL. filezilla-3.0.1-1.fc8 --------------------- * Sat Sep 22 2007 kwizart < kwizart at gmail.com > - 3.0.1-1 - Update to 3.0.1 gcc-4.1.2-26 ------------ * Sat Sep 22 2007 Jakub Jelinek 4.1.2-26 - don't ignore throw specification of function types in type hashing (PR c++/33506) - handle makeinfo version >= 4.10 in gcc configury gcompris-8.4-2.fc8 ------------------ * Sat Sep 22 2007 Hans de Goede 8.4-2 - Fix keyboard not working in fullscreen mode gdb-6.6-28.fc8 -------------- * Sat Sep 22 2007 Jan Kratochvil - 6.6-28 - Support also the `$allocate' and `$delete' ctor/dtor variants (BZ 301701). - Fix the build compatibility with texinfo >= 4.10. - Fix the testcase for pending signals (from BZ 233852). * Sun Sep 16 2007 Jan Kratochvil - 6.6-27 - Fix attaching to stopped processes and/or pending signals. * Tue Aug 28 2007 Jan Kratochvil - 6.6-26 - New fast verification whether the .debug file matches its peer (build-id). - New locating of the matching binaries from the pure core file (build-id). gnome-applets-1:2.20.0-4.fc8 ---------------------------- * Sat Sep 22 2007 David Woodhouse - 1.2.20.0-4 - Build modemlights applet again (#301601) * Sat Sep 22 2007 Matthias Clasen - 1:2.20.0-3 - Make the gweather.pc file less useless kernel-2.6.23-0.195.rc7.git3.fc8 -------------------------------- * Sat Sep 22 2007 Chuck Ebbert - 2.6.23-rc7-git3 * Fri Sep 21 2007 Chuck Ebbert - Build dcdbas and dell_rbu modules on i586 (#216304) mercurial-0.9.4-8.fc8 --------------------- * Sat Sep 22 2007 Neal Becker - 0.9.4-8 - Just cp contrib tree. - Revert install -O2 nautilus-open-terminal-0.8-2.fc8 -------------------------------- * Sat Sep 22 2007 Paul W. Frields - 0.8-2 - Fix download and source URIs php-pear-DB-1.7.13-1.fc8 ------------------------ * Fri Sep 21 2007 Remi Collet 1.7.13-1 - update to 1.7.13 - fix TEXTERS encoding php-pear-MDB2-Driver-mysql-1.4.1-2.fc8 -------------------------------------- * Sat Sep 22 2007 Christopher Stone 1.4.1-2 - Update Requires php-pecl-memcache-2.2.0-1.fc8 ----------------------------- python-nltk-0.9-0.2.b2.fc8 -------------------------- * Sat Sep 22 2007 Michel Salim - 0.9.0.2.b - BR on tkinter, it is now needed at build time python-nltk_lite-0.9-0.1.b2.fc8 ------------------------------- python-turbokid-1.0.3-1.fc8 --------------------------- * Sat Sep 22 2007 Luke Macken - 1.0.3-1 - 1.0.3 sepostgresql-8.2.5-1.23.fc8 --------------------------- * Sat Sep 22 2007 - 8.2.5-1.23 - update base PostgreSQL to 8.2.5 smart-0.51-49.fc8 ----------------- * Sat Sep 22 2007 Ville Skytt?? - 0.51-49 - 0.51; autofs, ccache, and autotools (partially) patches addressed upstream. source-highlight-2.7-1.fc8 -------------------------- * Sun Sep 16 2007 Adrian Reber - 2.7-1 - updated to 2.7 - updated files section - updated license thinkfinger-0.3-4.fc8 --------------------- * Wed Sep 05 2007 Julian Sikorski - 0.3-4 - Patched to allow non-root users, making screensavers work. Patches by William Jon McCann and Mike Bonnet (RH #256107) trac-bazaar-plugin-0.2-5.20070829bzr182.fc8 ------------------------------------------- * Sat Sep 22 2007 Toshio Kuratomi - 0.2-5.20070829bzr182 - Patches to fix RSS feed in timeline view. Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.i386 requires libgmpxx.so.3 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 ppl - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.ppc requires libgmpxx.so.3 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From jkeating at redhat.com Sun Sep 23 11:15:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Sep 2007 07:15:14 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190537312.7150.300.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> Message-ID: <20070923071514.5d7b9f44@redhat.com> On Sun, 23 Sep 2007 09:48:32 +0100 David Woodhouse wrote: > "it says to do"? I'm not quite sure of your meaning there -- I think > you're really saying "yum is doing exactly what yum does". Which is > true, but not really relevant. Yum is doing what Fedora has asked for a multilib strategy all the way up to Fedora 8. No matter how much you bitch whine moan complain call things bugs whatever doesn't change the fact that we have a current strategy for multilib and yum is following that strategy. When the strategy changes, yum will change to. If yum were acting out of spec with that strategy then that would be a bug. Please stop accusing software of doing what the project is asking of it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Sep 23 11:17:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Sep 2007 07:17:37 -0400 Subject: open-vm-tools (was Re: [Policy Change] Kernel Module...) In-Reply-To: <46F62DBF.2090405@poolshark.org> References: <1190492961.3966.4.camel@localhost.localdomain> <46F62DBF.2090405@poolshark.org> Message-ID: <20070923071737.7ad7d5bc@redhat.com> On Sun, 23 Sep 2007 11:11:27 +0200 Denis Leroy wrote: > So how can we make this happen ? Could this be discussed at the next > FESCo meeting ? You post to fedora-kernel-list I do believe and see if carrying the vmware plugins in the Fedora kernel package would be acceptable while the modules are headed upstream. This is the method to getting non-upstream modules into Fedora. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frank-buettner at gmx.net Sun Sep 23 12:11:31 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 23 Sep 2007 14:11:31 +0200 Subject: missing packages in the epel repo Message-ID: <46F657F3.4030101@gmx.net> Hello, why are so many packages at the epel repos gone?? for example: qt4-qsa, ctapi-cyberjack. qt4 .... All these was available last weak. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From mattdm at mattdm.org Sun Sep 23 12:48:47 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 23 Sep 2007 08:48:47 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190514903.2166.26.camel@cutter> References: <200709220944.33124.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <200709222155.50750.sgrubb@redhat.com> <1190514903.2166.26.camel@cutter> Message-ID: <20070923124847.GA32664@jadzia.bu.edu> On Sat, Sep 22, 2007 at 10:35:03PM -0400, seth vidal wrote: > obsoletes are allowed to cross arch boundaries. In fact, there's no way > to specify otherwise in an rpm Hmmm. In other cases where two packages obsolete one installed one, do they both get installed, or is there some "best fit" attempt? Conversely, if a package of one arch tries to obsolete a package which previously had two archs installed, are they both cleaned up? (In previous versions of yum, I believe only the one matching the new package was removed. Haven't tested recently.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Sep 23 12:49:26 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 23 Sep 2007 08:49:26 -0400 Subject: yum pulling in 386 packages In-Reply-To: <46F62AD1.5030608@gmail.com> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> <200709221214.19184.sgrubb@redhat.com> <1190479249.22181.1.camel@shinybook.infradead.org> <46F62AD1.5030608@gmail.com> Message-ID: <20070923124926.GB32664@jadzia.bu.edu> On Sun, Sep 23, 2007 at 10:58:57AM +0200, dragoran wrote: > yum install yum-basearchonly will do exactly that (only pull in foo if > you want foo.i386 you have to ask for it). I think that it likely doesn't cover this particular case. It's got some other bugs too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mschwendt.tmp0701.nospam at arcor.de Sun Sep 23 13:00:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 23 Sep 2007 15:00:01 +0200 Subject: missing packages in the epel repo In-Reply-To: <46F657F3.4030101@gmx.net> References: <46F657F3.4030101@gmx.net> Message-ID: <20070923150001.a1ff24c5.mschwendt.tmp0701.nospam@arcor.de> On Sun, 23 Sep 2007 14:11:31 +0200, Frank B?ttner wrote: > Hello, why are so many packages at the epel repos gone?? Many? You only list three. > for example: qt4-qsa, ctapi-cyberjack. qt4 .... > All these was available last weak. You've talked to the EPEL repo admins about ctapi-cyberjack: https://bugzilla.redhat.com/show_bug.cgi?id=279991 https://www.redhat.com/archives/epel-devel-list/2007-September/msg00034.html Your question regarding qt4 is not precise enough. Qt 4.x is part of RHEL5, so it cannot be offered in EPEL5. And in EPEL4 it cannot be a higher version than in RHEL5. That was a topic in March already when qt4 was added as a NEW pkg. See epel-devel-list archives. qt4-qsa? It has not been in any build report since March. From drago01 at gmail.com Sun Sep 23 13:02:48 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 23 Sep 2007 15:02:48 +0200 Subject: yum pulling in 386 packages In-Reply-To: <20070923124926.GB32664@jadzia.bu.edu> References: <200709220944.33124.sgrubb@redhat.com> <1190474042.27926.1.camel@shinybook.infradead.org> <200709221214.19184.sgrubb@redhat.com> <1190479249.22181.1.camel@shinybook.infradead.org> <46F62AD1.5030608@gmail.com> <20070923124926.GB32664@jadzia.bu.edu> Message-ID: <46F663F8.8050004@gmail.com> Matthew Miller wrote: > On Sun, Sep 23, 2007 at 10:58:57AM +0200, dragoran wrote: > >> yum install yum-basearchonly will do exactly that (only pull in foo if >> you want foo.i386 you have to ask for it). >> > > I think that it likely doesn't cover this particular case. It's got some > other bugs too. > > true in this case (obsolutes) it does exactly nothing... what are the other bugs you are refering too? From sundaram at fedoraproject.org Sun Sep 23 13:20:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 23 Sep 2007 18:50:02 +0530 Subject: Calling any text editor for any text file In-Reply-To: References: Message-ID: <46F66802.9050004@fedoraproject.org> Marcin Zaj?czkowski wrote: > Hi, > > > Some time ago I asked [1] about calling default text editor from an > application (here for isomaster). I can't use editor assigned to > specified mime type, because any (text) file (even html) should be > opened in a text editor (not e.g. web browser). > > I wrote a small script for that purpose and before its upload I would > like to ask for comments. > > > [1] - > https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00698.html After you are done with adding whatever optimizations has been suggested here, you might want to post to the portland list in freedesktop.org and include this as part of xdg-utils so everyone can benefit. Rahul From mjs at CLEMSON.EDU Sun Sep 23 13:30:22 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sun, 23 Sep 2007 09:30:22 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: References: <1190410702.5762.26.camel@valkyrie.localdomain> Message-ID: <1190554222.29485.21.camel@vincent52.localdomain> On Sun, 2007-09-23 at 00:12 -0400, Michel Salim wrote: > On 21/09/2007, Matthew Saltzman wrote: > > My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64 > > live dvd and installed the x86_64 DVD. This message covers > > platform-specific issues that I encountered. > > > > Live DVD: > > > > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > > system-config-display, there are two problems. > > > > (1) The Monitor section of xorg.conf is missing. > > Is this the 14.1" or 15" screen? Which resolution? (I'm asking, > because on my 14.1" WXGA (1280x800) the display is detected just fine) It's the 14.1" 1280x800, in fact. What might be different, then? -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From martin.sourada at seznam.cz Sun Sep 23 14:30:47 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 23 Sep 2007 16:30:47 +0200 Subject: Nodoka issues In-Reply-To: <1190500425.3259.27.camel@ignacio.lan> References: <1190446104.3259.12.camel@ignacio.lan> <1190450364.19809.122.camel@pc-notebook> <1190500425.3259.27.camel@ignacio.lan> Message-ID: <1190557847.19809.155.camel@pc-notebook> On Sun, 2007-09-23 at 00:33 +0200, Ignacio Vazquez-Abrams wrote: > Excellent. > https://bugzilla.redhat.com/show_bug.cgi?id=301851 > Thanks for that. > The iconize/maximize/close buttons. Compare: > http://ivazquez.fedorapeople.org/images/nodoka-tabs.png > http://ivazquez.fedorapeople.org/images/nodoka-tabs2.png > Hm... I see what you mean now. I like the first one better for some reason, but I can try to make a compromise - I'll play with various positions and decide what seems best. > > > 5) The packages are misnamed. They should be gtk2-engine-nodoka, > > > gnome-theme-nodoka, and metacity-theme-nodoka. > > > > > gtk-engine-nodoka as in gtk-engine-murrine. No point in changing already > > used naming schemes. > > It's disheartening to see "they already screwed up" as justification for > this. But at least it's the truth. > Yep, I dunno whether this naming scheme is screwed up, but I see no point in using two different schemes in one repo. > > nodoka-theme-gnome is used because the main name is nodoka theme > > (similar scheme to beryl-gnome, which is metapackage pulling all gnome > > related beryl bits in), so I put it in the front, noone mentioned it as > > an issue in the review request, also there are currently no naming > > guidelines for that AFAIK. > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e865dfbf5ffb4156a1bdf299ace96f48af903a7a > > "If a new package is considered an "addon" package that enhances or adds > a new functionality to an existing Fedora package without being useful > on its own, its name should reflect this fact. > > The new package ("child") should prepend the "parent" package in its > name, in the format: %{parent}-%{child}." > > I see the parent as being gnome, and the child as being nodoka. > Well, yet never complained about that till now (not a justification). Better move this part of discussion to -devel (CC-ing). But from my point of view I see nodoka as the parent and the children are theme for metacity, theme+engine for gtk2 and gnome metatheme (and more will hopefully come later), so IMHO it is rather questionable in this case. And as I used these names in upstream packages as well it would require a change there as well, because I AFAIK fedora package name should not differ from upstream name (save for the parent additions in addons packages). > > nodoka-metacity-theme as in {echo,tango}-icon-theme. > > Well, that's stretching just a bit. There's a difference between a set > of icons packaged to create a theme, and a theme for just a single app. > You're probably right there. Martin > > I looked at various theme packages that were in the repos and decided on > > these names after. If there are any guidelines concerning this, please > > forward me to them, if not it would be good to create ones, what do you > > think? > > I definitely think this would be a good idea. Plenty of package reviews > have come and gone with comments about naming, but still we have > contention, as observed here. > -------------- 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 nicolas.mailhot at laposte.net Sun Sep 23 16:24:22 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 23 Sep 2007 18:24:22 +0200 Subject: [Long] Do we need a font SIG ? In-Reply-To: <46F34327.5090506@redhat.com> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46EA78F1.4090203@nicubunu.ro> <37146.192.54.193.51.1189772518.squirrel@rousalka.dyndns.org> <46F34327.5090506@redhat.com> Message-ID: <1190564662.11233.5.camel@rousalka.dyndns.org> Le vendredi 21 septembre 2007 ? 14:05 +1000, Jens Petersen a ?crit : > I noticed there is already http://fedoraproject.org/wiki/Fonts. > > Should we create http://fedoraproject.org/wiki/SIGs/Fonts or use Fonts? Ok, I've created http://fedoraproject.org/wiki/SIGs/Fonts and started fleshing it out. It's not declared in http://fedoraproject.org/wiki/SIGs yet because there is still a lot of work to do, moving all the existing fonts-related wiki material in a single place, integrating it in something coherent, filling the holes, getting the policy pages reviewed, etc. I'd appreciate any help getting this done. If you want more info just PM me. -- 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 dwmw2 at infradead.org Sun Sep 23 16:30:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 23 Sep 2007 17:30:05 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070923071514.5d7b9f44@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> Message-ID: <1190565005.7150.308.camel@pmac.infradead.org> On Sun, 2007-09-23 at 07:15 -0400, Jesse Keating wrote: > Yum is doing what Fedora has asked for a multilib strategy all the way > up to Fedora 8. That strategy is, quite simply, wrong. In all other cases we call an implementation of such a misguided strategy a 'bug'. If you want me to call it a 'fish' in this case, then by all means I'll do so. If you can make this URL work, all the better: https://fishzilla.redhat.com/showdependencytree.cgi?id=multilib :) -- dwmw2 From dwmw2 at infradead.org Sun Sep 23 16:32:44 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 23 Sep 2007 17:32:44 +0100 Subject: open-vm-tools (was Re: [Policy Change] Kernel Module...) In-Reply-To: <46F62DBF.2090405@poolshark.org> References: <1190492961.3966.4.camel@localhost.localdomain> <46F62DBF.2090405@poolshark.org> Message-ID: <1190565164.7150.312.camel@pmac.infradead.org> On Sun, 2007-09-23 at 11:11 +0200, Denis Leroy wrote: > Philip Langdale says they are aware of the need to push this upstream > and will work on it. Eventually (see bugzilla ticket). How actively is > unfortunately hard to know for sure. To their defense, they have > successfully pushed some of their work upstream in the past, their X.org > driver for example. > > So how can we make this happen ? Could this be discussed at the next > FESCo meeting ? To quote the review bug: "some of the drivers will require a lot of changes or a complete rewrite to get accepted (and vmblock probably wouldn't get accepted at all and we'd need to rewrite it using fuse)." I think it's far from obvious that FESCo would have voted to allow this particular package anyway. -- dwmw2 From jonathan.underwood at gmail.com Sun Sep 23 16:33:56 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 23 Sep 2007 17:33:56 +0100 Subject: Calling any text editor for any text file In-Reply-To: <200709222359.54262.ville.skytta@iki.fi> References: <200709222318.15391.ville.skytta@iki.fi> <200709222359.54262.ville.skytta@iki.fi> Message-ID: <645d17210709230933i49cc4d4axe500ec9942ad4313@mail.gmail.com> On 22/09/2007, Ville Skytt? wrote: > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > > Ville Skytt? wrote: > > > Does emacs graphical interface (doesn't need a console)? > > Yes. It also starts faster than XEmacs and integrates better with the desktop > (at least look and feel wise) so I suggest trying it before XEmacs in the > script. Also - if you're starting Emacs, you should consider calling emacsclient -a emacs which uses an existing Emacs if one is running with emacsserver running, or starts emacs if not. See: http://www.emacswiki.org/cgi-bin/wiki/EmacsClient and the emacs documentation. From ville.skytta at iki.fi Sun Sep 23 19:22:06 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-2?q?Skytt=E4?=) Date: Sun, 23 Sep 2007 22:22:06 +0300 Subject: Calling any text editor for any text file In-Reply-To: <645d17210709230933i49cc4d4axe500ec9942ad4313@mail.gmail.com> References: <200709222359.54262.ville.skytta@iki.fi> <645d17210709230933i49cc4d4axe500ec9942ad4313@mail.gmail.com> Message-ID: <200709232222.06480.ville.skytta@iki.fi> On Sunday 23 September 2007, Jonathan Underwood wrote: > On 22/09/2007, Ville Skytt? wrote: > > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > > > Ville Skytt? wrote: > > > > > > Does emacs graphical interface (doesn't need a console)? > > > > Yes. It also starts faster than XEmacs and integrates better with the > > desktop (at least look and feel wise) so I suggest trying it before > > XEmacs in the script. > > Also - if you're starting Emacs, you should consider calling > emacsclient -a emacs which uses an existing Emacs if one is > running with emacsserver running, or starts emacs if not. The confusing thing about that is that it'll not only reuse a running emacs, it'll reuse an existing window too, pushing its current buffer out of view to the buffer list (Where did my existing open Emacs and its buffer go?). And if only one window was active, carelessly closing the window will kill all the buffers active in it, possibly resulting in data loss. Granted, maybe people who do activate the server (which needs to be explicitly done) are aware of this, but even then I'm not sure if it'd be a good thing to do by default. If emacsclient would open a new frame for each new file, the problem would be much less severe IMO. If the opening is done with a shell script, people can use shell aliases to get emacsclient stuff transparently done the way they prefer. From ville.skytta at iki.fi Sun Sep 23 19:28:34 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 23 Sep 2007 22:28:34 +0300 Subject: yum pulling in 386 packages In-Reply-To: <1190565005.7150.308.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> Message-ID: <200709232228.35037.ville.skytta@iki.fi> On Sunday 23 September 2007, David Woodhouse wrote: > On Sun, 2007-09-23 at 07:15 -0400, Jesse Keating wrote: > > Yum is doing what Fedora has asked for a multilib strategy all the way > > up to Fedora 8. > > That strategy is, quite simply, wrong. In all other cases we call an > implementation of such a misguided strategy a 'bug'. I tend to agree. Is the strategy documented somewhere so one can educate oneself and verify that this indeed is the desired behaviour that follows from it? I'm having hard time coming up with any arguments that would support the way things currently work, but would be interested in finding out if I've missed something. From jonathan.underwood at gmail.com Sun Sep 23 19:57:09 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 23 Sep 2007 20:57:09 +0100 Subject: Calling any text editor for any text file In-Reply-To: <200709232222.06480.ville.skytta@iki.fi> References: <200709222359.54262.ville.skytta@iki.fi> <645d17210709230933i49cc4d4axe500ec9942ad4313@mail.gmail.com> <200709232222.06480.ville.skytta@iki.fi> Message-ID: <645d17210709231257n19148a31o6ca269cbdc77d30a@mail.gmail.com> On 23/09/2007, Ville Skytt? wrote: > On Sunday 23 September 2007, Jonathan Underwood wrote: > > On 22/09/2007, Ville Skytt? wrote: > > > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > > > > Ville Skytt? wrote: > > > > > > > > Does emacs graphical interface (doesn't need a console)? > > > > > > Yes. It also starts faster than XEmacs and integrates better with the > > > desktop (at least look and feel wise) so I suggest trying it before > > > XEmacs in the script. > > > > Also - if you're starting Emacs, you should consider calling > > emacsclient -a emacs which uses an existing Emacs if one is > > running with emacsserver running, or starts emacs if not. > > The confusing thing about that is that it'll not only reuse a running emacs, > it'll reuse an existing window too, pushing its current buffer out of view to > the buffer list (Where did my existing open Emacs and its buffer go?). And > if only one window was active, carelessly closing the window will kill all > the buffers active in it, possibly resulting in data loss. > > Granted, maybe people who do activate the server (which needs to be explicitly > done) are aware of this, but even then I'm not sure if it'd be a good thing > to do by default. If emacsclient would open a new frame for each new file, > the problem would be much less severe IMO. If the opening is done with a > shell script, people can use shell aliases to get emacsclient stuff > transparently done the way they prefer. Yes, good points, and in light of the last point, i agree. From jos at xos.nl Sun Sep 23 20:28:35 2007 From: jos at xos.nl (Jos Vos) Date: Sun, 23 Sep 2007 22:28:35 +0200 Subject: yum pulling in 386 packages In-Reply-To: <200709232228.35037.ville.skytta@iki.fi> References: <200709220944.33124.sgrubb@redhat.com> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <200709232228.35037.ville.skytta@iki.fi> Message-ID: <20070923202835.GA12446@jasmine.xos.nl> On Sun, Sep 23, 2007 at 10:28:34PM +0300, Ville Skytt? wrote: > On Sunday 23 September 2007, David Woodhouse wrote: > > That strategy is, quite simply, wrong. In all other cases we call an > > implementation of such a misguided strategy a 'bug'. > > I tend to agree. Is the strategy documented somewhere so one can educate > oneself and verify that this indeed is the desired behaviour that follows > from it? I'm having hard time coming up with any arguments that would > support the way things currently work, but would be interested in finding out > if I've missed something. Also, thy explanation that yum exactly does what the intended strategy for Fedora is, is not very satisfying... Yum should ideally implement various strategies (maybe via plugins), and Fedora can then be configured by default for "the intended strategy". If Fedora changes strategies, there should be no need to adapt the software (only its configuration). People wanting to use other strategies (a few have already passed in this thread) should be able to do so. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From itendsnow at gmail.com Sun Sep 23 20:49:35 2007 From: itendsnow at gmail.com (Ryan McDonough) Date: Sun, 23 Sep 2007 21:49:35 +0100 Subject: Hardware check idea Message-ID: <7eded3840709231349q67df044erd5344040f927b9c3@mail.gmail.com> After proposing this in the Fedora irc room I decided to post it to everyone on the list for feedback: I would like to see an application that would run on windows/osx/linux that would check hardware and see if your mobo/cpu/fans etc will work with the newer kernels and if not what boot commands you may need and what problems these boot commands may cause, it would check against the current top 5 distrobutions kernels, plus the current standard kernel. It wouldn't be total hardware like gfx etc, just the core hardware like mobo, cpu, fans as its the hardware that you can't really change (easily) unlike a video card. I feel this would bring great benefits as it would allow people to see if the newer distrobutions will actually boot with no problems without having to download 700mb live cd images and take all the time and effort to burn the cd and then have to report that it wouldn't boot on a forum. I have experienced a problem with a kernel update after the 2.6.20 release that the newer distrobutions were using as I couldn't/can't boot without noacpi acpi=off, added to my boot command which causes power management to go bye bye along with my monitor after 15 minutes. I'm not a great programmer as I've just started, but I would like to see if people think this project is feasible and a good use of developers time and help/learn as much as I could. -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rms at 1407.org Sun Sep 23 21:57:08 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sun, 23 Sep 2007 22:57:08 +0100 Subject: lesswatts.org In-Reply-To: <1190437993.9010.5.camel@localhost6.localdomain6> References: <1190437993.9010.5.camel@localhost6.localdomain6> Message-ID: <20070923215708.GC8480@roque.1407.org> On Fri, Sep 21, 2007 at 11:13:13PM -0600, Richi Plana wrote: > Of the several projects hosted on http://www.lesswatts.org/ (PowerTOP, > Tickless Idle, Processor Power Management, Battery Life Toolkit, Power > Policy Manager, Power QoS, Display and Graphics Power Savings, Device > and Bus Power Management, ACPICA) how many are currently packages for > Fedora? What are they called? How are they identified? Do they belong in > any particular software group? Some are kernel patches so are they in > any existing Fedora kernel? It's an interesting initiative, but is it helping the AMD64 people? I expect some measures help, regardless of architecture, but definitely not all, and powertop seems overly dedicated to intel hardware! Is there any similar tools for AMD64 architectures? Hugs, Rui -- Or is it? Today is Sweetmorn, the 47th day of Bureaucracy in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From choeger at cs.tu-berlin.de Sun Sep 23 22:16:11 2007 From: choeger at cs.tu-berlin.de (=?ISO-8859-1?Q?Christoph_H=F6ger?=) Date: Mon, 24 Sep 2007 00:16:11 +0200 Subject: Hardware check idea In-Reply-To: <7eded3840709231349q67df044erd5344040f927b9c3@mail.gmail.com> References: <7eded3840709231349q67df044erd5344040f927b9c3@mail.gmail.com> Message-ID: <46F6E5AB.6060300@cs.tu-berlin.de> Hi, I think that such an application would simply require too much manpower (as you would have to keep tons of metadata up to date), although some kind of wiki could help out. The programming should be rather simple (you can readout hardware infos on windows, don't you?) but the information management would be hell. What I personally would prefer was a simple "Of course it runs with linux/Yes, we provide GPLed drivers" Sticker on Pcs and Notebooks. *dream* Ryan McDonough schrieb: > After proposing this in the Fedora irc room I decided to post it to > everyone on the list for feedback: > > I would like to see an application that would run on windows/osx/linux > that would check hardware and see if your mobo/cpu/fans etc will work > with the newer kernels and if not what boot commands you may need and > what problems these boot commands may cause, it would check against the > current top 5 distrobutions kernels, plus the current standard kernel. > > It wouldn't be total hardware like gfx etc, just the core hardware like > mobo, cpu, fans as its the hardware that you can't really change > (easily) unlike a video card. > > I feel this would bring great benefits as it would allow people to see > if the newer distrobutions will actually boot with no problems without > having to download 700mb live cd images and take all the time and effort > to burn the cd and then have to report that it wouldn't boot on a forum. > > I have experienced a problem with a kernel update after the 2.6.20 > release that the newer distrobutions were using as I couldn't/can't boot > without noacpi acpi=off, added to my boot command which causes power > management to go bye bye along with my monitor after 15 minutes. > > I'm not a great programmer as I've just started, but I would like to see > if people think this project is feasible and a good use of developers > time and help/learn as much as I could. > > -Ryan > From laurent.rineau__fedora at normalesup.org Sun Sep 23 23:19:05 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Mon, 24 Sep 2007 01:19:05 +0200 Subject: Yum from rawhide has forgot to pull a dependancy! Message-ID: <200709240119.06109@rineau.tsetse> Currently on my machine, I have CGAL-devel installed, and it requires boost-devel>=1.32. However, boost-devel is not installed! lrineau at schtroumpf ~ $ rpm -q --requires CGAL-devel | grep boost boost-devel >= 1.32 lrineau at schtroumpf ~ $ rpm -q --whatprovides boost-devel no package provides boost-devel zsh: exit 1 rpm -q --whatprovides boost-devel lrineau at schtroumpf ~ $ rpm -q yum CGAL-devel yum-3.2.5-3.fc8 CGAL-devel-3.3.1-2.fc8 What is wrong? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau schtroumpf is a freshly installed F8test2 (from the KDE), then updated (but NetworkManager, whose recent versions fail to connect to my wireless router). From itendsnow at gmail.com Sun Sep 23 23:43:35 2007 From: itendsnow at gmail.com (Ryan McDonough) Date: Mon, 24 Sep 2007 00:43:35 +0100 Subject: Hardware check idea In-Reply-To: <46F6E5AB.6060300@cs.tu-berlin.de> References: <7eded3840709231349q67df044erd5344040f927b9c3@mail.gmail.com> <46F6E5AB.6060300@cs.tu-berlin.de> Message-ID: <7eded3840709231643i606d77dci22e2569fe73b63fd@mail.gmail.com> My thought would be that it could boot the kernels in the background like vmware or qemu and then take live data and figure it out based on info it recieves. That way itd cut down on data it would need. On 23/09/2007, Christoph H?ger wrote: > Hi, > > I think that such an application would simply require too much manpower > (as you would have to keep tons of metadata up to date), although some > kind of wiki could help out. > The programming should be rather simple (you can readout hardware infos > on windows, don't you?) but the information management would be hell. > > What I personally would prefer was a simple "Of course it runs with > linux/Yes, we provide GPLed drivers" Sticker on Pcs and Notebooks. *dream* > > Ryan McDonough schrieb: > > After proposing this in the Fedora irc room I decided to post it to > > everyone on the list for feedback: > > > > I would like to see an application that would run on windows/osx/linux > > that would check hardware and see if your mobo/cpu/fans etc will work > > with the newer kernels and if not what boot commands you may need and > > what problems these boot commands may cause, it would check against the > > current top 5 distrobutions kernels, plus the current standard kernel. > > > > It wouldn't be total hardware like gfx etc, just the core hardware like > > mobo, cpu, fans as its the hardware that you can't really change > > (easily) unlike a video card. > > > > I feel this would bring great benefits as it would allow people to see > > if the newer distrobutions will actually boot with no problems without > > having to download 700mb live cd images and take all the time and effort > > to burn the cd and then have to report that it wouldn't boot on a forum. > > > > I have experienced a problem with a kernel update after the 2.6.20 > > release that the newer distrobutions were using as I couldn't/can't boot > > without noacpi acpi=off, added to my boot command which causes power > > management to go bye bye along with my monitor after 15 minutes. > > > > I'm not a great programmer as I've just started, but I would like to see > > if people think this project is feasible and a good use of developers > > time and help/learn as much as I could. > > > > -Ryan > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From katzj at redhat.com Mon Sep 24 00:03:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:03:34 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190410702.5762.26.camel@valkyrie.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> Message-ID: <1190592214.4603.10.camel@localhost.localdomain> On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > system-config-display, there are two problems. > > (1) The Monitor section of xorg.conf is missing. This is correct -- there shouldn't need to be a monitor section as it should be auto-detected > (2) The nv driver hangs with a black screen. The keyboard is still > functional and I can reboot with -- --. This sounds like a driver bug, please file against xorg-x11-drv-nv and include your X.log, lspci info and xorg.conf > - I used gparted to resize NTFS partitions and partition the drive. It > hung at the end of the resize operation without confirming it is > finished (although the operation appears to have completed). Also, > gparted quits after the rescan step after each operation set. Haven't seen/heard this one. Probably worth filing against gparted (or maybe ntfs-progs; hard to say) though > - Have to install with "vesa" kernel option. The nv driver boots to a > black screen. Same as above. > - On the Disk Druid screen, the screen is not repainted after opening > and closing popups. This is filed already -- see bug 289281 > - The display is only configured for 800x600. This is going to be related to lack of proper monitor probing. > - Screen brightness is erratic. The screen brightness applet appears, > but whatever controls I hit, brightness changes randomly up or down and > does not get fully bright or dim. If I switch to a VC, I can control > the brightness, but ^@ characters appear on the display. This has been reported a couple of times-- Warren was going to try to track this down and get some better reporting of it I believe > - X server doesn't terminate on logout--I have to -- to > kill it. Sounds like an X server bug > - Suspend doesn't work at all. Select Suspend from the power applet and > the machine starts to suspend, the light comes on, then the light goes > off and the machine is live, except that the display is black. I can > reboot as above. Using which X driver? > - Hibernate appears to work, but on resume I get a message that > hibernate failed. Sounds buggy > - Stopping the bluetooth service on reboot or shutdown fails, although > starting on bootup succeeds. Have not tested bluetooth functionality > otherwise. I believe I saw some discussion about this, but am not certain anymore Jeremy From katzj at redhat.com Mon Sep 24 00:15:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Sep 2007 20:15:53 -0400 Subject: boot.iso with stage2 In-Reply-To: <1190496051.9745.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> Message-ID: <1190592953.4603.19.camel@localhost.localdomain> On Sat, 2007-09-22 at 17:20 -0400, Louis E Garcia II wrote: > If I placed stage2.img inside the boot.iso from rawhide and burned it > would it act like a rescuecd? would the installer find stage2 in the cd > instead of downloading it. If you take a look at /usr/lib/anaconda-runtime/mk-rescueimage, you can do basically the exact manipulations. But yeah, the above is basically correct Jeremy From sundaram at fedoraproject.org Mon Sep 24 06:02:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Sep 2007 11:32:32 +0530 Subject: Why upstream? Message-ID: <46F752F8.9010406@fedoraproject.org> Hi With the recent changes on not allowing separate kernel module packages anymore in the Fedora repository, I thought now would be a good time to document why we insist on upstream code. I have used other references and made the guidelines generic. http://fedoraproject.org/wiki/RahulSundaram/WhyUpstream If you have any additional points or corrections, feel free to edit the wiki directly or let me know. I intend to send it to FESCo later. Rahul From louisg00 at bellsouth.net Mon Sep 24 07:12:28 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Mon, 24 Sep 2007 03:12:28 -0400 Subject: boot.iso with stage2 In-Reply-To: <1190496051.9745.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> Message-ID: <1190617948.5987.4.camel@sonlaptop> On Sun, 23 Sep 2007 20:15:53 -0400, Jeremy Katz wrote: > On Sat, 2007-09-22 at 17:20 -0400, Louis E Garcia II wrote: > > If I placed stage2.img inside the boot.iso from rawhide and burned it > > would it act like a rescuecd? would the installer find stage2 in the cd > > instead of downloading it. > > If you take a look at /usr/lib/anaconda-runtime/mk-rescueimage, you can > do basically the exact manipulations. But yeah, the above is basically > correct > > Jeremy I know this has been covered before but why is the installer in two stages? Both stages can fit on a CD easily. -Louis From buildsys at redhat.com Mon Sep 24 07:57:50 2007 From: buildsys at redhat.com (Build System) Date: Mon, 24 Sep 2007 03:57:50 -0400 Subject: rawhide report: 20070924 changes Message-ID: <200709240757.l8O7voBX006845@porkchop.devel.redhat.com> Updated Packages: alsa-plugins-1.0.14-3.fc8 ------------------------- * Mon Sep 24 2007 Lennart Poettering - 1.0.14-3 - Change PulseAudio buffering defaults to more sane values blender-2.45-2.fc8 ------------------ * Sun Sep 23 2007 Jochen Schmitt 2.45-2 - Change method how to determinate python version * Thu Sep 20 2007 Jochen Schmitt 2.45-1 - New upstream release chemtool-1.6.11-2.fc8 --------------------- * Sun Sep 23 2007 Dominik 'Rathann' Mierzejewski 1.6.11-2 - drop libEMF dependency (current transfig/fig2dev supports EMF output) compiz-fusion-0.5.2-8.09b700.fc8 -------------------------------- * Sun Sep 23 2007 Adel Gadllah 0.5.2-8.09b700 - Fix changelog date * Sat Sep 22 2007 Adel Gadllah 0.5.2-7.09b700 - Update to 0.6 branch (builds against current compiz) * Wed Sep 19 2007 Adel Gadllah 0.5.2-6 - Add animation to plugin list compiz-fusion-extras-0.5.2-7.6871d0.fc8 --------------------------------------- * Sun Sep 23 2007 Adel Gadllah 0.5.2-7.6871d0 - GConf schemas got renamed .. fix scripts to install them - Fix changelog date * Sat Sep 22 2007 Adel Gadllah 0.5.2-6.6871d0 - Update to 0.6 branch (builds against current compiz) * Sat Sep 15 2007 Adel Gadllah 0.5.2-5 - Fix gconf schemas install (RH #53692) - Some build fixes flim-1.14.8-3.fc8 ----------------- * Mon Sep 24 2007 Jens Petersen - 1.14.8-3 - update license to GPLv2+ freenx-0.7.0-2.fc8 ------------------ * Sun Sep 23 2007 Ville Skytt?? - 0.7.0-2 - Do not try to set up KDE_PRINTRC if ENABLE_KDE_CUPS is not 1, deal better with errors when it is (#290351). gdb-6.6-29.fc8 -------------- * Sun Sep 23 2007 Jan Kratochvil - 6.6-29 - Fixed the kernel VDSO loading (`warning: no loadable sections found in ...'). - Fix the testcase for pending signals (from BZ 233852). * Sat Sep 22 2007 Jan Kratochvil - 6.6-28 - Support also the `$allocate' and `$delete' ctor/dtor variants (BZ 301701). - Fix the build compatibility with texinfo >= 4.10. - Fix the testcase for pending signals (from BZ 233852). * Sun Sep 16 2007 Jan Kratochvil - 6.6-27 - Fix attaching to stopped processes and/or pending signals. gqview-2.0.4-5 -------------- * Sun Sep 23 2007 Michael Schwendt - 2.0.4-5 - update patch: gimp-remote doesn't know option -n anymore gstreamer-plugins-pulse-0.9.5-0.4.svn20070924.fc8 ------------------------------------------------- * Mon Sep 24 2007 Lennart Poettering - 0.9.5-0.4.svn20070924 - Update SVN snapshot gtk-nodoka-engine-0.6-3.fc8 --------------------------- * Sun Sep 23 2007 Martin Sourada - 0.6-3 - Require at least the version of gtk it was build against -- rhbz 301851 (patch from Ignacio Vazquez-Abrams) m2crypto-0.18-2 --------------- * Sun Sep 23 2007 Miloslav Trma?? - 0.18-2 - Add missing Host: header to CONNECT requests (patch by Karl Grindley) Resolves: #239034 - Fix License: nickle-2.58-1.fc8 ----------------- * Sun Sep 23 2007 Michel Salim 2.58-1 - Update to 2.58 scim-fcitx-3.1.1-7.fc8 ---------------------- * Mon Sep 24 2007 Jens Petersen - 3.1.1-7 - update license field to GPLv2+ - remove with_libstdc_preview macro sylpheed-2.4.6-1 ---------------- * Wed Sep 19 2007 Michael Schwendt - 2.4.6-1 - Update to 2.4.6 (bug-fixes, but also minor feature additions and rewrites). vinagre-0.3-1.fc8 ----------------- xscreensaver-1:5.03-8.fc8 ------------------------- * Mon Sep 24 2007 Mamoru Tasaka - 1:5.03-8 - Some cleanup. Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.i386 requires libgmpxx.so.3 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 ppl - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-gprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-swiprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-utils - 0.9-14.fc8.ppc requires libgmpxx.so.3 ppl-yap - 0.9-14.fc8.ppc requires libgmpxx.so.3 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-swiprolog - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-utils - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) ppl-yap - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics sending mail failed From dev at nigelj.com Mon Sep 24 09:30:13 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 24 Sep 2007 21:30:13 +1200 (NZST) Subject: Orphaning Packages/Retiring Packager Message-ID: <42203.202.154.149.198.1190626213.squirrel@webmail.nigelj.com> Hi everyone, just a quick message to say that I'll no longer be maintaining packages for the Fedora Project (hence a lot of Orphan messages going out on fedora-extras-commits at present). Main reasons include: * I'm not a big fan of the post merge Fedora * CentOS & RHEL suit my linux views at the moment (at least I'm not updating every half hour). * I have a contract that legally means I can't contribute (tbh I'm not worried about this one, because I spend so much time at work or on the bus, that at the end of the day I wouldn't have the time if the contract didn't exist) So long and thanks for all the fish! Nigel Jones (Please keep me in CC for any replies) As a reference I'm going through manually and orphaning the following packages: * calcurse -- Text-based personal organizer * redet -- Regular expression development and execution tool * redet-doc -- Documentation for redet * timidity++ -- A software wavetable MIDI synthesizer * windowlab -- Small and Simple Amiga-like Window Manager (Anything else is just EL branches of packages) From jochen.schlick at comsoft.de Mon Sep 24 09:45:10 2007 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Mon, 24 Sep 2007 11:45:10 +0200 Subject: yum update so slow Message-ID: <46F78726.4020808@comsoft.de> Hi, I have a laptop where rawhide is installed since the days of Fedora Core 1. It has only 256MB ram so updating using yum was always like a lame duck but nowadays it's really a crap. Last friday the yum update process crashed when yum wants to update the rpm library package. At least the line with the rpm package was the last one displayed before the laptop was dead. After reboot I had to overwrite some corrupted rpmlibs from an other rawhide system - ok shit happens sometimes - to get rpm work again - I verified this by installing some glibc/kde-rpms via rpm directly yesterday. After a clean reboot and stopping all services (to save ram) I tried a new update via yum yesterday evening ..... -- dependency resolving was successful - after 30 minutes -- then yum displays that it wants to pull 300 Meg (~70 packages) -- after pressing "y" nothing more or less visible happens for at least two hours. -- and now, this morning after eight hours: 2 packages updated (and a glibc error message about a double free...) -- with this update "speed" I will have an "up to date" system in 12 days... :-( best regards -- --------------------------------------------------------------------------- Jochen Schlick --------------------------------------------------------------------------- From nicolas.mailhot at laposte.net Mon Sep 24 09:53:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 24 Sep 2007 11:53:15 +0200 (CEST) Subject: desc and summary In-Reply-To: <1190483413.3234.23.camel@shuttle> References: <27834210.1539991189604591702.JavaMail.www@wwinf8403> <1190483413.3234.23.camel@shuttle> Message-ID: <35766.192.54.193.51.1190627595.squirrel@rousalka.dyndns.org> Le Sam 22 septembre 2007 19:50, Dimitris Glezos a ?crit : > ???? 12-09-2007, ????? ???, ??? ??? 15:43 +0200, ?/? > nicolas.mailhot at laposte.net ??????: >> > De : "Jeremy Katz" >> >> > Actually, nothing says that additional repos can't have their own >> > specspo-type package as well. >> >> This is considerably upping the bar to creation of a new repository, >> and making impossible the common "collect rpms, launch createrepo" >> workflow > > Is it that bad really? It's a step that could be done by a script and > have the POs hosted at the repo's own VCS, reached by transifex. Small local or third-party repositories have almost no infrastructure, they manage bunches of rpm and nothing else, so if translations are not embedded in the packages themselves (in the spec of in a detached file inside the srpm) they get lost. You'll note that Fedora is no different, we do not require a working yum repo for new package submissions, just a srpm somewhere on the net Regards -- Nicolas Mailhot From tomek at crocom.com.pl Mon Sep 24 10:53:47 2007 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Mon, 24 Sep 2007 12:53:47 +0200 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190592214.4603.10.camel@localhost.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> <1190592214.4603.10.camel@localhost.localdomain> Message-ID: <1190631227.30606.10.camel@s1.crocom.com.pl> Dnia 23-09-2007, N o godzinie 20:03 -0400, Jeremy Katz napisa?(a): > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > > - Screen brightness is erratic. The screen brightness applet appears, > > but whatever controls I hit, brightness changes randomly up or down and > > does not get fully bright or dim. If I switch to a VC, I can control > > the brightness, but ^@ characters appear on the display. > > This has been reported a couple of times-- Warren was going to try to > track this down and get some better reporting of it I believe This is because changing brightness generate brightness key event. User turn brightness one step down, event is generated, event is seen by gnome-power-manager which turns brightness down, event is generated... all the way down to 0 up up to max. This issue is fixable at HAL (hal-info) level. Please update /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi with you model number and also send patch to HAL upstream list. Nb. this file in F7 still has a typo for other model ("Z31t" instead of "Z61t") -- Tomasz Torcz Crocom Computer Systems From jkeating at redhat.com Mon Sep 24 11:17:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 07:17:36 -0400 Subject: yum pulling in 386 packages In-Reply-To: <20070923202835.GA12446@jasmine.xos.nl> References: <200709220944.33124.sgrubb@redhat.com> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <200709232228.35037.ville.skytta@iki.fi> <20070923202835.GA12446@jasmine.xos.nl> Message-ID: <20070924071736.2119dde0@redhat.com> On Sun, 23 Sep 2007 22:28:35 +0200 Jos Vos wrote: > Also, thy explanation that yum exactly does what the intended strategy > for Fedora is, is not very satisfying... Yum should ideally implement > various strategies (maybe via plugins), and Fedora can then be > configured by default for "the intended strategy". If Fedora changes > strategies, there should be no need to adapt the software (only its > configuration). > > People wanting to use other strategies (a few have already passed in > this thread) should be able to do so. This is the plan for Fedora 9. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Sep 24 11:23:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 07:23:16 -0400 Subject: yum pulling in 386 packages In-Reply-To: <200709232228.35037.ville.skytta@iki.fi> References: <200709220944.33124.sgrubb@redhat.com> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <200709232228.35037.ville.skytta@iki.fi> Message-ID: <20070924072316.35ceca9b@redhat.com> On Sun, 23 Sep 2007 22:28:34 +0300 "Ville Skytt?" wrote: > I tend to agree. Is the strategy documented somewhere so one can > educate oneself and verify that this indeed is the desired behaviour > that follows from it? I'm having hard time coming up with any > arguments that would support the way things currently work, but would > be interested in finding out if I've missed something. Jeremy was working on documenting it. It is a strategy that has been developed over a period of releases that offered multilib. Quite simply, we want both runtime library and development package availability of the secondary arch installed by default. To accomplish this we use the existence of a -devel subpackage to trigger selection as a multilib package. We then require the package that holds the symlink destination of any .so files in the -devel subpackage. We then depsolve that to make sure all the secondary arch deps are resolved. There are a few more things going on, a few whitelists, a bare minimum blacklist. http://git.fedoraproject.org/?p=hosted/mash;a=blob_plain;f=mash/multilib.py;hb=HEAD has the gory details. This is the method by which we select which packages are multilib (finally a programatic way instead of a hand generated list we had before). The second part of the strategy was that tools like yum will install the available packages by default if simply asked to 'install foo' and "foo" wasn't arch specified. Yes, some of us would like to change this around a bit in Fedora 9, by making it configurable client side which strategy to follow, and to determine at install time which compat arch packages to pull in based on configured strategy. This would eliminate the need to pre-populate the repos with secondary arch content at compose time. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Sep 24 11:24:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 07:24:07 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190565005.7150.308.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> Message-ID: <20070924072407.6fa861a2@redhat.com> On Sun, 23 Sep 2007 17:30:05 +0100 David Woodhouse wrote: > That strategy is, quite simply, wrong. Then work to fix the strategy, don't shoot the tools for following the requested script. Dropping snide comments about them doesn't make anybody any more eager to listen to you. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Sep 24 11:36:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 24 Sep 2007 07:36:30 -0400 Subject: boot.iso with stage2 In-Reply-To: <1190617948.5987.4.camel@sonlaptop> References: <1190496051.9745.4.camel@sonlaptop> <1190617948.5987.4.camel@sonlaptop> Message-ID: <1190633790.4603.65.camel@localhost.localdomain> On Mon, 2007-09-24 at 03:12 -0400, Louis E Garcia II wrote: > On Sun, 23 Sep 2007 20:15:53 -0400, Jeremy Katz wrote: > > On Sat, 2007-09-22 at 17:20 -0400, Louis E Garcia II wrote: > > > If I placed stage2.img inside the boot.iso from rawhide and burned it > > > would it act like a rescuecd? would the installer find stage2 in the cd > > > instead of downloading it. > > > > If you take a look at /usr/lib/anaconda-runtime/mk-rescueimage, you can > > do basically the exact manipulations. But yeah, the above is basically > > correct > > I know this has been covered before but why is the installer in two stages? > Both stages can fit on a CD easily. The first stage has to be in RAM as an initramfs while the second can just be mounted and used[1] without requiring much of a memory hit. Also, if you're booting the installer via PXE, it helps to minimize the amount you have to download via tftp Jeremy [1] At least, if you're doing an NFS, CD or hard drive install From dtimms at iinet.net.au Mon Sep 24 12:08:10 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 24 Sep 2007 22:08:10 +1000 Subject: yum update so slow In-Reply-To: <46F78726.4020808@comsoft.de> References: <46F78726.4020808@comsoft.de> Message-ID: <46F7A8AA.2060403@iinet.net.au> Jochen Schlick wrote: > Hi, I have a laptop where rawhide is installed since the days > of Fedora Core 1. It has only 256MB ram so updating using yum > was always like a lame duck but nowadays it's really a crap. Since that RAM is valuable: are you starting in runlevel 3 - ie no GUI ? You can also save some memory when yum performs transactions by updating a coupla packages at a time, perhaps like: yum check-update to see what is there. yum update rpm yum yum update kernel reboot in runlevel 3 again. yum update x* yum update g* and so on. Having another vt open with top running can give a good idea of how much RAM / processor the process is using. {one of mine is an old pentiumII with 384MB}. DaveT. From skvidal at fedoraproject.org Mon Sep 24 12:11:26 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 24 Sep 2007 08:11:26 -0400 Subject: yum update so slow In-Reply-To: <46F78726.4020808@comsoft.de> References: <46F78726.4020808@comsoft.de> Message-ID: <1190635886.6478.0.camel@cutter> On Mon, 2007-09-24 at 11:45 +0200, Jochen Schlick wrote: > Hi, I have a laptop where rawhide is installed since the days > of Fedora Core 1. It has only 256MB ram so updating using yum > was always like a lame duck but nowadays it's really a crap. > > Last friday the yum update process crashed when yum wants > to update the rpm library package. At least the line with the rpm > package was the last one displayed before the laptop was dead. > After reboot I had to overwrite some corrupted rpmlibs from an > other rawhide system - ok shit happens sometimes - to get rpm > work again - I verified this by installing some glibc/kde-rpms > via rpm directly yesterday. > After a clean reboot and stopping all services (to save ram) I > tried a new update via yum yesterday evening ..... > > -- dependency resolving was successful - after 30 minutes > -- then yum displays that it wants to pull 300 Meg (~70 packages) > -- after pressing "y" nothing more or less visible happens > for at least two hours. > -- and now, this morning after eight hours: 2 packages updated > (and a glibc error message about a double free...) > -- with this update "speed" I will have an "up to date" system > in 12 days... :-( You're almost definitely swapping. Take a look at your memory use and see if that is the case. -sv From dwmw2 at infradead.org Mon Sep 24 13:21:08 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 14:21:08 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924072407.6fa861a2@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> Message-ID: <1190640068.2905.13.camel@pmac.infradead.org> On Mon, 2007-09-24 at 07:24 -0400, Jesse Keating wrote: > Then work to fix the strategy, don't shoot the tools for following the > requested script. But there is no actual script -- the only place this is written down is in yum's implementation. Hence wanting it fixed in yum's implementation. > Dropping snide comments about them doesn't make anybody any more eager > to listen to you. You make it sound like I'm not actively working on a strategy for improving multilib, despite the existence of http://bugzilla.redhat.com/showdependencytree.cgi?id=multilib and the (minor) progress we've already made on it. -- dwmw2 From dwmw2 at infradead.org Mon Sep 24 13:26:01 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 14:26:01 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924072316.35ceca9b@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <200709232228.35037.ville.skytta@iki.fi> <20070924072316.35ceca9b@redhat.com> Message-ID: <1190640361.2905.19.camel@pmac.infradead.org> On Mon, 2007-09-24 at 07:23 -0400, Jesse Keating wrote: > Quite simply, we want both runtime library and development package > availability of the secondary arch installed by default. We missed a step here. Why on earth would we want this? Users _don't_ seem to want this. As far as I can tell, the only time this is useful is to work around the fact that RPM dependencies aren't arch-specific. That is: at the moment, if I want to build foo.i386 and it says 'BuildRequires: bar-devel', that requirement will be 'satisfied' by the existence of bar-devel.x86_64. And my 'foo' package won't actually build. That's also on the multilib tracker bug, btw -- bug #235755. With RPM fixed so that Requires and BuildRequires can actually pull in the package which is _needed_, I don't see any benefit of having all the secondary-arch stuff installed by default. When you install Skype.i386.rpm on an x86_64 box, the dependencies will work and you'll get the libraries you want. When you want to build evolution.i386 on an x86_64 box, you'll probably have to install a bunch of xxx-devel.i386 packages -- but that's fine. Unless we're going to have a policy of "install _every_ -devel package in every available flavour", you're often going to have to install a few packages to satisfy dependencies. There's no problem with that. With RPM bugs out of the way, there just isn't a viable reason for wanting all the secondary-arch stuff installed by default. I could see an argument for the "install everything" case -- you have infinite disk space and you don't ever want to have to manually install something for dependencies, and you want to use software which isn't RPM-packaged. But "install everything which for the secondary arch which happens to be installed for the primary" is just weird. -- dwmw2 From jkeating at redhat.com Mon Sep 24 13:35:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 09:35:54 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190640068.2905.13.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> Message-ID: <20070924093554.20d14c15@redhat.com> On Mon, 24 Sep 2007 14:21:08 +0100 David Woodhouse wrote: > But there is no actual script -- the only place this is written down > is in yum's implementation. Hence wanting it fixed in yum's > implementation. It's also in mash, and in pungi. It may not be "written down" anywhere, but it is a script that we're all playing by. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Sep 24 13:41:12 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 14:41:12 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924093554.20d14c15@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> <20070924093554.20d14c15@redhat.com> Message-ID: <1190641272.2905.24.camel@pmac.infradead.org> On Mon, 2007-09-24 at 09:35 -0400, Jesse Keating wrote: > On Mon, 24 Sep 2007 14:21:08 +0100 > David Woodhouse wrote: > > > But there is no actual script -- the only place this is written down > > is in yum's implementation. Hence wanting it fixed in yum's > > implementation. > > It's also in mash, and in pungi. The multilib tracker bug has RFEs for that too. > It may not be "written down" anywhere, but it is a script that we're > all playing by. OK, so how do we fix it? I _thought_ that the best option was what I'd already done -- file individual enhancement requests as part of a coherent plan to get us to a better place. But you don't like those. So what now? -- dwmw2 From sgrubb at redhat.com Mon Sep 24 13:48:08 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 24 Sep 2007 09:48:08 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190640361.2905.19.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> Message-ID: <200709240948.09223.sgrubb@redhat.com> On Monday 24 September 2007 09:26:01 David Woodhouse wrote: > > Quite simply, we want both runtime library and development package > > availability of the secondary arch installed by default. > > We missed a step here. Why on earth would we want this? Users _don't_ > seem to want this. +1 I can't see why anyone would want this. 2 years ago when open office was not 64 bit safe and several other high profile apps were still working out the 64 bit issues, I could see why we wanted this. Its different today. The fact is that we cause people to download way more updates for libraries that are completely unneeded. It affects people doing the mirroring, ISP's having bandwidth consumed, and users that have issues related to failed updates causing mismatching versions of 32 and 64 bit packages (with no good way to fix it) and less available diskspace. If you are a developer and *want* the ability to do cross compiling, then I could see those people wanting multilib. I think the common case is people want a pure 64 or 32 bit machine so they have more free diskspace and quicker updates and less hassle when it goes wrong. -Steve From dwmw2 at infradead.org Mon Sep 24 13:52:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 14:52:38 +0100 Subject: yum pulling in 386 packages In-Reply-To: <200709240948.09223.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> Message-ID: <1190641958.2905.28.camel@pmac.infradead.org> On Mon, 2007-09-24 at 09:48 -0400, Steve Grubb wrote: > If you are a developer and *want* the ability to do cross compiling, > then I could see those people wanting multilib. Note that we're not talking about "multilib or not". We're talking about whether to install a bunch of packages for the secondary architecture by _default_. If you want to build a package (other than in mock), then you have to install its dependencies -- a bunch of -devel packages. Would you expect those packages to be installed for you automatically, just in _case_ you need them? That's the kind of thinking that leads to wanting an 'Everything' install, isn't it? -- dwmw2 From jkeating at redhat.com Mon Sep 24 13:51:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 09:51:48 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190641272.2905.24.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> <20070924093554.20d14c15@redhat.com> <1190641272.2905.24.camel@pmac.infradead.org> Message-ID: <20070924095148.458da2de@redhat.com> On Mon, 24 Sep 2007 14:41:12 +0100 David Woodhouse wrote: > OK, so how do we fix it? I _thought_ that the best option was what I'd > already done -- file individual enhancement requests as part of a > coherent plan to get us to a better place. But you don't like those. > So what now? I've been planning for some time now a get together of sorts in person to hash this out. The basic idea I'm thinking of is a runtime configuration in yum that lets you adhere to whatever multilib strategy you want on that particular system. You point at both full repos and let yum figure out, based on requested strategy, what to do on install/update/obsolete/whatever actions. Composing exploaded repos is easy, no cross pollination. Composing DVDs is easy (but bloaty) you just put both repos in whole on the media (or opt out of the secondary arch all together on the media). My plan for the get together is to hash out what each of these strategies are, get out and understood why we're at where we are at today (I'm told time and time again that there are real good reasons...), determine the best default strategy going forward, and work out what happens when users do silly things like change strategies mid stream or whatever. I wanted to do this near the time that F9 development starts, unknown if it will happen or not. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Sep 24 13:57:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 24 Sep 2007 15:57:39 +0200 Subject: EPEL report week 38 2007 Message-ID: <46F7C253.6040804@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week38 = Weekly EPEL Summary = Week 38/2007 == Most important happenings == * [:ThorstenLeemhuis:knurd] redesigned the schedule page in the wiki and created special "task" pages for each epel-todo-list task -- he hopes to improve the workflow. See his [https://www.redhat.com/archives/epel-devel-list/2007-September/msg00076.html announcement] for more details == EPEL SIG Meeting == Meting was canceld this week. Next meeting: 20070926 at 17:00 UTC in #fedora-meeting == Stats == === General === Number of EPEL Contributors 1 We welcome 1 new contributors: tsmetana === EPEL 5 === Number of source packages: 660 Number of binary packages: 1278 There are 5 new Packages: * awstats | Advanced Web Statistics * haproxy | HA-Proxy is a TCP/HTTP reverse proxy for high availability environments * kaffeine | Xine-based media player * nut | Network UPS Tools * xine-lib | Xine library === EPEL 4 === Number of source packages: 420 Number of binary packages: 856 There are 2 new Packages: * haproxy | HA-Proxy is a TCP/HTTP reverse proxy for high availability environments * nut | Network UPS Tools ---- ["CategoryEPELReports"] From lkundrak at redhat.com Mon Sep 24 14:03:03 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 24 Sep 2007 16:03:03 +0200 Subject: yum update so slow In-Reply-To: <46F78726.4020808@comsoft.de> References: <46F78726.4020808@comsoft.de> Message-ID: <1190642583.5661.30.camel@localhost.localdomain> On Mon, 2007-09-24 at 11:45 +0200, Jochen Schlick wrote: > Hi, I have a laptop where rawhide is installed since the days > of Fedora Core 1. It has only 256MB ram so updating using yum > was always like a lame duck but nowadays it's really a crap. > Last friday the yum update process crashed when yum wants > to update the rpm library package. > -- and now, this morning after eight hours: 2 packages updated > (and a glibc error message about a double free...) Do you have a core dump (well, if you have enough storage, yum is sometimes too greedy :)? > -- with this update "speed" I will have an "up to date" system > in 12 days... :-( What I was doing when updating my 128M machine w/o swap was NFS-mounting its root and updating it on a machine with more memory, or used rpm by hand. Trying to use yum on that machine would not be smart (yum is unable to fork itself when trying to run scriptlets). -- Lubomir Kundrak (Red Hat Security Response Team) From limb at jcomserv.net Mon Sep 24 13:41:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 24 Sep 2007 08:41:16 -0500 (CDT) Subject: Orphaning Packages/Retiring Packager In-Reply-To: <42203.202.154.149.198.1190626213.squirrel@webmail.nigelj.com> References: <42203.202.154.149.198.1190626213.squirrel@webmail.nigelj.com> Message-ID: <36315.63.85.68.164.1190641276.squirrel@mail.jcomserv.net> > Hi everyone, just a quick message to say that I'll no longer be > maintaining packages for the Fedora Project (hence a lot of Orphan > messages going out on fedora-extras-commits at present). > > Main reasons include: > * I'm not a big fan of the post merge Fedora > * CentOS & RHEL suit my linux views at the moment (at least I'm not > updating every half hour). > * I have a contract that legally means I can't contribute (tbh I'm not > worried about this one, because I spend so much time at work or on the > bus, that at the end of the day I wouldn't have the time if the contract > didn't exist) > > So long and thanks for all the fish! > > Nigel Jones > > (Please keep me in CC for any replies) > > As a reference I'm going through manually and orphaning the following > packages: > > * calcurse -- Text-based personal organizer > * redet -- Regular expression development and execution tool > * redet-doc -- Documentation for redet > * timidity++ -- A software wavetable MIDI synthesizer > * windowlab -- Small and Simple Amiga-like Window Manager > > (Anything else is just EL branches of packages) Happy trails, and thanks for your work. I'll take calcurse, if no one else absolutely MUST have it. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From dwmw2 at infradead.org Mon Sep 24 14:25:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 15:25:34 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924095148.458da2de@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> <20070924093554.20d14c15@redhat.com> <1190641272.2905.24.camel@pmac.infradead.org> <20070924095148.458da2de@redhat.com> Message-ID: <1190643934.2905.37.camel@pmac.infradead.org> On Mon, 2007-09-24 at 09:51 -0400, Jesse Keating wrote: > On Mon, 24 Sep 2007 14:41:12 +0100 > David Woodhouse wrote: > > > OK, so how do we fix it? I _thought_ that the best option was what I'd > > already done -- file individual enhancement requests as part of a > > coherent plan to get us to a better place. But you don't like those. > > So what now? > > I've been planning for some time now a get together of sorts in person > to hash this out. The basic idea I'm thinking of is a runtime > configuration in yum that lets you adhere to whatever multilib strategy > you want on that particular system. You point at both full repos and > let yum figure out, based on requested strategy, what to do on > install/update/obsolete/whatever actions. Composing exploaded repos is > easy, no cross pollination. Composing DVDs is easy (but bloaty) you > just put both repos in whole on the media (or opt out of the secondary > arch all together on the media). > > My plan for the get together is to hash out what each of these > strategies are, get out and understood why we're at where we are at > today (I'm told time and time again that there are real good > reasons...), There are reasons, certainly. I'm not sure all of them are _good_ reasons :) One of the reasons I see for the 'install both' strategy is the lack of arch-specific dependencies in RPM. I tried building evolution.ppc64 recently, having purged my system of all ppc64 userspace. It was not fun, because the BuildRequires were all satisfied by the existence of the 32-bit packages, which weren't actually what was needed. But as I said, there's a bug on the tracker for that one too. "Just Install Everything" isn't really a good workaround, although it does work. > I wanted to do this near the time that F9 development starts, unknown > if it will happen or not. Who do we need that isn't based around Boston? I seem to spend half my life on planes at the moment, and come through Boston relatively frequently. Should I just try to give you a bit of warning each time I fly in, to see if we can all find some time? I should probably be out there next week or so, hopefully. -- dwmw2 From jkeating at redhat.com Mon Sep 24 14:30:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 24 Sep 2007 10:30:37 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190643934.2905.37.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> <20070924093554.20d14c15@redhat.com> <1190641272.2905.24.camel@pmac.infradead.org> <20070924095148.458da2de@redhat.com> <1190643934.2905.37.camel@pmac.infradead.org> Message-ID: <20070924103037.745fab66@redhat.com> On Mon, 24 Sep 2007 15:25:34 +0100 David Woodhouse wrote: > Who do we need that isn't based around Boston? I seem to spend half my > life on planes at the moment, and come through Boston relatively > frequently. Should I just try to give you a bit of warning each time I > fly in, to see if we can all find some time? Seth Vidal and Bill Nottingham at least. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From billcrawford1970 at gmail.com Mon Sep 24 14:43:34 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 24 Sep 2007 15:43:34 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <20070918100913.7f2c9e3a@localhost.localdomain> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> <20070918100913.7f2c9e3a@localhost.localdomain> Message-ID: <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> On 18/09/2007, Jesse Keating wrote: ... > No, it's just getting rid of the assumption that you have to log in as > root to administrate something. Even when one of the things you want to do is: umount /home system-config-lvm ... mount -a ? From dominik at greysector.net Mon Sep 24 14:47:41 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 24 Sep 2007 16:47:41 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190641958.2905.28.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> Message-ID: <20070924144741.GA6791@ryvius.pekin.waw.pl> On Monday, 24 September 2007 at 15:52, David Woodhouse wrote: > On Mon, 2007-09-24 at 09:48 -0400, Steve Grubb wrote: > > If you are a developer and *want* the ability to do cross compiling, > > then I could see those people wanting multilib. > > Note that we're not talking about "multilib or not". We're talking about > whether to install a bunch of packages for the secondary architecture by > _default_. > > If you want to build a package (other than in mock), then you have to > install its dependencies -- a bunch of -devel packages. > > Would you expect those packages to be installed for you automatically, > just in _case_ you need them? That's the kind of thinking that leads to > wanting an 'Everything' install, isn't it? Indeed. +1 to turning this off by default. In fact, +1 to installing only 64bit packages on x86_64 install (while keeping the i386 versions in the repository, of course). Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cmadams at hiwaay.net Mon Sep 24 14:54:52 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 24 Sep 2007 09:54:52 -0500 Subject: yum pulling in 386 packages In-Reply-To: <20070924144741.GA6791@ryvius.pekin.waw.pl> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> <20070924144741.GA6791@ryvius.pekin.waw.pl> Message-ID: <20070924145452.GC1063599@hiwaay.net> Once upon a time, Dominik 'Rathann' Mierzejewski said: > Indeed. +1 to turning this off by default. In fact, +1 to installing > only 64bit packages on x86_64 install (while keeping the i386 versions > in the repository, of course). Why keep the i386 versions in the repo? It would be better to write down the rules that are used to pull i386 packages into the x86_64 repo and then make a yum plugin that can point to the i386 repo and follow the rules (when enabled). -- 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 Mon Sep 24 15:20:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 16:20:07 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924145452.GC1063599@hiwaay.net> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> <20070924144741.GA6791@ryvius.pekin.waw.pl> <20070924145452.GC1063599@hiwaay.net> Message-ID: <1190647207.2905.68.camel@pmac.infradead.org> On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote: > Why keep the i386 versions in the repo? It would be better to write > down the rules that are used to pull i386 packages into the x86_64 > repo and then make a yum plugin that can point to the i386 repo and > follow the rules (when enabled). There's a lot of sense in this. One of the options being discussed is to ship _nothing_ of the secondary arch (or almost nothing) in the primary repository, and allow yum to be pointed at the basic i386 repo. Of course, that means we've suddenly got a whole load of i386 packages visible to x86_64 yum which weren't there before; with the current install-both behaviour that wouldn't work too well. But as part of a more coherent approach, I think it's the way forward. Note that for some 64-bit architectures like sparc64/ppc64 we run mostly 32-bit userspace, because 64-bit userspace just isn't worth the bloat (the only reason it's worth the bloat for x86 is because you actually get a sane number of _registers_ that way). So the 32-bit tree would probably still carry a _few_ 64-bit packages there (kernel, gdb, systemtap, etc.). -- dwmw2 From dcbw at redhat.com Mon Sep 24 15:18:06 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 24 Sep 2007 11:18:06 -0400 Subject: Wireless and D-Bus problems with latest rawhide? In-Reply-To: <46F51345.10708@warmcat.com> References: <62041.87.194.100.54.1190234783.squirrel@webmail.cream.org> <46F1AF30.8090308@redhat.com> <56619.87.194.100.54.1190463427.squirrel@webmail.cream.org> <46F50D63.2020201@warmcat.com> <20070922085029.62400f5f@redhat.com> <46F51345.10708@warmcat.com> Message-ID: <1190647086.3437.22.camel@xo-3E-67-34.localdomain> On Sat, 2007-09-22 at 14:06 +0100, Andy Green wrote: > Somebody in the thread at some point said: > > On Sat, 22 Sep 2007 13:41:07 +0100 > > Andy Green wrote: > > > >> Not sure one should blame iwl3945 for this. I updated a friend's > >> machine to development yesterday, on rt73usb. Development > >> wpa_supplicant crapped out during initscripts with a dbus error (dbus > >> doesn't seem to get started until ordinal 26 in the initscripts?). > >> NetworkManager was completely unable to authenticate to a WPA AP. I I've been able to do WPA[2]-PSK without problems so far; at the moment the applet will only accept the hex key for WEP and WPA-PSK. Also adding "-ddd" to the end of the Exec= line in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant and restarting should put a wealth of debugging information in /var/log/wpa_supplicant.log which is very useful in these situations. > >> downgraded NetworkManage and wpa_supplicant to the F7 versions and it > >> worked as usual. > > > > I think that uses the same underlying wifi stack as the iwl3945. > > Regardless we're fixing this bugs as fast as we can as they come up. > > Each new day's NetworkManager should improve upon the last. > > Just adding my experience wrt iwl3945 getting the blame. I don't think > mac80211 should get the blame either since I didn't change the kernel > during this. rt2500usb (which uses mac80211) has been working pretty well for me so far this week; but this is again hugely driver dependent. People with iwlwifi have not been so lucky for some reason. I still don't consider mac80211 "stable" given the quirks we've seen with it and the ongoing heavy development upstream. Dan > But don't get me wrong, it's fine if NetworkManager (which has gotten a > LOT better for me in the last months) is broken in Development at any > particular time. The fact the F7 one was "stable" enough to replace it > is fine too. > > -Andy > From ajackson at redhat.com Mon Sep 24 15:21:25 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 24 Sep 2007 11:21:25 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190410702.5762.26.camel@valkyrie.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> Message-ID: <1190647285.3418.2.camel@localhost.localdomain> On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64 > live dvd and installed the x86_64 DVD. This message covers > platform-specific issues that I encountered. > > Live DVD: > > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > system-config-display, there are two problems. > > (1) The Monitor section of xorg.conf is missing. > (2) The nv driver hangs with a black screen. The keyboard is still > functional and I can reboot with -- --. > > Hand-editing xorg.conf to create a Monitor section and using the vesa > driver restores X functionality. An X log from the failed nv startup would be helpful here. > - X server doesn't terminate on logout--I have to -- to > kill it. This was a bug I inflicted with a particular libICE/libSM combination. It should be fixed now, I hope. > - Suspend doesn't work at all. Select Suspend from the power applet and > the machine starts to suspend, the light comes on, then the light goes > off and the machine is live, except that the display is black. I can > reboot as above. As always, suspend on nv graphics chips is a disaster. - ajax From myfedora at richip.dhs.org Mon Sep 24 15:59:11 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 24 Sep 2007 09:59:11 -0600 Subject: yum pulling in 386 packages In-Reply-To: <1190647207.2905.68.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> <20070924144741.GA6791@ryvius.pekin.waw.pl> <20070924145452.GC1063599@hiwaay.net> <1190647207.2905.68.camel@pmac.infradead.org> Message-ID: <1190649551.23386.9.camel@localhost6.localdomain6> On Mon, 2007-09-24 at 16:20 +0100, David Woodhouse wrote: > On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote: > > Why keep the i386 versions in the repo? It would be better to write > > down the rules that are used to pull i386 packages into the x86_64 > > repo and then make a yum plugin that can point to the i386 repo and > > follow the rules (when enabled). > > There's a lot of sense in this. One of the options being discussed is to > ship _nothing_ of the secondary arch (or almost nothing) in the primary > repository, and allow yum to be pointed at the basic i386 repo. One problem with this is that many arch-specific packages contain 1) arch-neutral resources in them (like documentation, data files and arch-neutral scripts) and 2) some binaries in /usr/bin that collide with each other. Ideally, a solution like that would allow installing of packages from any arbitrary architecture (say, ppc and i386) without there every being any collisions. Unfortunately, neither the alternatives system nor FHS supports multi-arch installs. Even the current i386-x86_64 installs aren't perfect. The library separation and linking works alright, but the executable programs in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both soundtouch.x86_64 and soundtouch.i386 is x86_64 only). Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the future? :-) -- Richi Plana From myfedora at richip.dhs.org Mon Sep 24 16:06:34 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 24 Sep 2007 10:06:34 -0600 Subject: Root login in rawhide and display managers In-Reply-To: <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> <20070918100913.7f2c9e3a@localhost.localdomain> <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> Message-ID: <1190649994.23386.15.camel@localhost6.localdomain6> On Mon, 2007-09-24 at 15:43 +0100, Bill Crawford wrote: > On 18/09/2007, Jesse Keating wrote: > ... > > No, it's just getting rid of the assumption that you have to log in as > > root to administrate something. > > Even when one of the things you want to do is: > > umount /home > system-config-lvm > ... > mount -a Well ... in fairness, the original argument was between giving root an X Windows session to do administration vs. administering from a regular user X Window session. If administrative tasks like the one you mentioned happens often, then I suggest those systems create at least one user whose $HOME isn't in /home. :-p -- Richi Plana From drago01 at gmail.com Mon Sep 24 16:08:25 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 24 Sep 2007 18:08:25 +0200 Subject: yum pulling in 386 packages In-Reply-To: <200709240948.09223.sgrubb@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> Message-ID: <46F7E0F9.9040307@gmail.com> Steve Grubb wrote: > If you are a developer and *want* the ability to do cross compiling, then I > could see those people wanting multilib. I think the common case is people > want a pure 64 or 32 bit machine so they have more free diskspace and quicker > updates and less hassle when it goes wrong. > -1 no if someone wants a pure 64 bit system he should have a option to do that. multilib is not a bad thing but it just lets you install and run 32bit apps on your 64bit system. please don't go down to no multilib and start using chroot hacks... thats WRONG ... the only thing that needs to be fixed here is dont install both archs when somebody wants to install an app. yum install foo -> install the default arch only yum install foo.i386 install foo.i386 and its deps (may also be 32 bit or noarch). From dwmw2 at infradead.org Mon Sep 24 16:11:16 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 17:11:16 +0100 Subject: yum pulling in 386 packages In-Reply-To: <46F7E0F9.9040307@gmail.com> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <46F7E0F9.9040307@gmail.com> Message-ID: <1190650276.2905.109.camel@pmac.infradead.org> On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote: > no if someone wants a pure 64 bit system he should have a option to do > that. multilib is not a bad thing but it just lets you install and run > 32bit apps on your 64bit system. > please don't go down to no multilib and start using chroot hacks... I don't think anybody is suggesting that we ditch multilib altogether. We are suggesting only that the i386 packages should not be installed by _default_ -- they should be installed only when they're actually needed. -- dwmw2 From drago01 at gmail.com Mon Sep 24 16:32:52 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 24 Sep 2007 18:32:52 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190650276.2905.109.camel@pmac.infradead.org> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <46F7E0F9.9040307@gmail.com> <1190650276.2905.109.camel@pmac.infradead.org> Message-ID: <46F7E6B4.7060305@gmail.com> David Woodhouse wrote: > On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote: > >> no if someone wants a pure 64 bit system he should have a option to do >> that. multilib is not a bad thing but it just lets you install and run >> 32bit apps on your 64bit system. >> please don't go down to no multilib and start using chroot hacks... >> > > I don't think anybody is suggesting that we ditch multilib altogether. > We are suggesting only that the i386 packages should not be installed by > _default_ -- they should be installed only when they're actually needed. > > I don't disagree with you on that ;) but as I said I am against killing multilib. From myfedora at richip.dhs.org Mon Sep 24 16:34:14 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Mon, 24 Sep 2007 10:34:14 -0600 Subject: yum pulling in 386 packages In-Reply-To: <46F7E0F9.9040307@gmail.com> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <46F7E0F9.9040307@gmail.com> Message-ID: <1190651654.23386.28.camel@localhost6.localdomain6> On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote: > Steve Grubb wrote: > > If you are a developer and *want* the ability to do cross compiling, then I > > could see those people wanting multilib. I think the common case is people > > want a pure 64 or 32 bit machine so they have more free diskspace and quicker > > updates and less hassle when it goes wrong. > > > -1 > > no if someone wants a pure 64 bit system he should have a option to do > that. multilib is not a bad thing but it just lets you install and run > 32bit apps on your 64bit system. > please don't go down to no multilib and start using chroot hacks... > thats WRONG ... THAT'S the kind of thinking I like! Where people don't bash other people's preferences but instead leave them options. It's good for a distro like Fedora to choose one default since it simplifies things for the majority of people, but care should be taken to leave things open for other options and, at times, to even aid in the selection of other options. Sometimes it's just so easy to fall into the exclusive way-of-thinking, particularly when either a personal preference is perceived to be threatened or if there's pressure to get something out and the easy choice seems so attractive. > the only thing that needs to be fixed here is dont install both archs > when somebody wants to install an app. > yum install foo -> install the default arch only > yum install foo.i386 install foo.i386 and its deps (may also be 32 bit > or noarch). Agree with there being a "default" during install and when no arch is specified, but read my previous post on existing problems with multi-arch installs. Besides ... going back to i386-x86_64 installs specifically ... I think it has always been the idea to eventually drop the default install of i386 packages. Having them there would just ease transitions ... particularly with many i386, binary-only packages. At least that was my impression. After having used Fedora x86_64 for the last year or so, I can say that I can live with just an x86_64-install only and add packages when needed (nspluginwrapper and maybe SDL libstdc++ for some games for me). -- Richi Plana From tmz at pobox.com Mon Sep 24 17:28:15 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 24 Sep 2007 13:28:15 -0400 Subject: diff missing in plague buildroot In-Reply-To: <200709192253.05944.dennis@ausil.us> References: <20070919140103.bed29d24.mschwendt.tmp0701.nospam@arcor.de> <20070919204236.7448e51a@ghistelwchlohm.scrye.com> <200709192253.05944.dennis@ausil.us> Message-ID: <20070924172815.GA9800@psilocybe.teonanacatl.org> Dennis Gilmore wrote: > Once upon a time Wednesday 19 September 2007, Kevin Fenzi wrote: >> On Wed, 19 Sep 2007 14:01:03 +0200 >> >> mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: >>> http://buildsys.fedoraproject.org/logs/fedora-6-extras/36389-fslint-2.24- >>>1.fc6/noarch/build.log >>> >>> Checking for unpackaged >>> file(s): /usr/lib/rpm/check-files /var/tmp/fslint-2.24-1-root-mockbuild >>> /usr/lib/rpm/check-files: line 25: diff: command not found >>> >>> >>> Strange. Has anybody changed the FE6 buildroot defs? >>> Doesn't rpm-build require diffutils anymore? >> >> Yeah, it looks like the buildsys-build package was updated recently >> to match the new min buildroot requirements. ;( >> >> diffutils is no longer required by buildsys-build. >> >> I personally would say we should just revert back to the previous >> one, especially since fc6 isn't going to be around too much longer >> anyhow. I don't think it gains us much to change it at this >> point... >> >>> EPEL5+4 don't seem to be affected. >> >> Yeah, they were updated I think, then reverted due to a bug... > they had a different bug. i have reverted the fc6 version. i will > make sure diff is in the fc-6 buildroot. I think this affects F-7 mock builds as well. buildsys-build-0.8-1.fc7[1] doesn't require diffutils, nor does rpm-build-4.4.2.1-1.fc7. BTw, where is the current srpm or spec file for buildsys-build kept? I can find older versions in mock's git repo, but not the 0.8 spec or srpm. (I'm probably missing it somewhere obvious [though the most obvious place would be right beside the rpm]. :) [1] http://buildsys.fedoraproject.org/buildgroups/7/i386/buildsys-build-0.8-1.fc7.noarch.rpm -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Truth is like a well-known whore. Everybody knows her but it's embarrassing to meet her in the street. -- Wolfgang Borchert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From billcrawford1970 at gmail.com Mon Sep 24 17:31:49 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 24 Sep 2007 18:31:49 +0100 Subject: [RFC] /var versus /srv (Off-topic) In-Reply-To: <1190391766.23728.42.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> <1190391766.23728.42.camel@localhost6.localdomain6> Message-ID: <544eb990709241031t584f10cckb03ee542597ffd35@mail.gmail.com> On 21/09/2007, Richi Plana wrote: > As much as I like to see grammar and proper use of the language > maintained, I would value effective communication above it. +1/-1 gets > the message across while saving bytes. Same goes for smileys, ;). Actually, it's nice because it sidesteps language issues entirely ;) (yes, I realise that's pretty much irrelevant given that all the traffic on the list is "in English" ...) From j.w.r.degoede at hhs.nl Mon Sep 24 17:36:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 24 Sep 2007 19:36:14 +0200 Subject: Orphaning Packages/Retiring Packager In-Reply-To: <36315.63.85.68.164.1190641276.squirrel@mail.jcomserv.net> References: <42203.202.154.149.198.1190626213.squirrel@webmail.nigelj.com> <36315.63.85.68.164.1190641276.squirrel@mail.jcomserv.net> Message-ID: <46F7F58E.8050301@hhs.nl> Nigel Jones wrote: > Hi everyone, just a quick message to say that I'll no longer be > maintaining packages for the Fedora Project (hence a lot of Orphan > messages going out on fedora-extras-commits at present). > > Main reasons include: > * I'm not a big fan of the post merge Fedora > * CentOS & RHEL suit my linux views at the moment (at least I'm not > updating every half hour). > * I have a contract that legally means I can't contribute (tbh I'm not > worried about this one, because I spend so much time at work or on the > bus, that at the end of the day I wouldn't have the time if the contract > didn't exist) > > So long and thanks for all the fish! > > Nigel Jones > > (Please keep me in CC for any replies) > > As a reference I'm going through manually and orphaning the following > packages: > > * calcurse -- Text-based personal organizer > * redet -- Regular expression development and execution tool > * redet-doc -- Documentation for redet > * timidity++ -- A software wavetable MIDI synthesizer > * windowlab -- Small and Simple Amiga-like Window Manager > > (Anything else is just EL branches of packages) > I'll take timidity++, as several of my packages depend on it. I've filed a request for ownership in the PackageDB. Nigel, can you please ack the request? Regards, Hans From dgboles at gmail.com Mon Sep 24 17:53:06 2007 From: dgboles at gmail.com (David Boles) Date: Mon, 24 Sep 2007 13:53:06 -0400 Subject: Root login in rawhide and display managers In-Reply-To: <1190649994.23386.15.camel@localhost6.localdomain6> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> <20070918100913.7f2c9e3a@localhost.localdomain> <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> <1190649994.23386.15.camel@localhost6.localdomain6> Message-ID: <46F7F982.5020408@gmail.com> on 9/24/2007 12:06 PM, Richi Plana wrote: > On Mon, 2007-09-24 at 15:43 +0100, Bill Crawford wrote: >> On 18/09/2007, Jesse Keating wrote: >> ... >>> No, it's just getting rid of the assumption that you have to log in as >>> root to administrate something. >> Even when one of the things you want to do is: >> >> umount /home >> system-config-lvm >> ... >> mount -a > > Well ... in fairness, the original argument was between giving root an X > Windows session to do administration vs. administering from a regular > user X Window session. > > If administrative tasks like the one you mentioned happens often, then I > suggest those systems create at least one user whose $HOME isn't > in /home. :-p What I said the other, and I still feel this way, was that *if* you are the qualified admin of this system you should know how to change the 'no root GUI' default setting to allow root to login with a WM desktop. You should not but you should know how to do this. Or how to get to a root login without X when already logged as 'you' in a WM, login as root an start an X session for your WM. And later how to logout as root get back to logged in as 'you' in an X session DM. Or how to do admin duties from a terminal in a 'you' DM by logging and doing them from the CLI. Or, will in the terminal windows how to start, as root, the GUI frontends that you would like to use. Remember I said "qualified admin"? If you really are one of those you should know how to do some, actually you should know how to do all, of these. If you don't know how to do these. IMO you are not a "qualified admin". And you have no business even being root. Me? I am *not* qualified to admin a system but I know how to do all of these examples. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From dominik at greysector.net Mon Sep 24 18:08:18 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 24 Sep 2007 20:08:18 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190649551.23386.9.camel@localhost6.localdomain6> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> <20070924144741.GA6791@ryvius.pekin.waw.pl> <20070924145452.GC1063599@hiwaay.net> <1190647207.2905.68.camel@pmac.infradead.org> <1190649551.23386.9.camel@localhost6.localdomain6> Message-ID: <20070924180818.GA10011@ryvius.pekin.waw.pl> On Monday, 24 September 2007 at 17:59, Richi Plana wrote: [...] > Even the current i386-x86_64 installs aren't perfect. The library > separation and linking works alright, but the executable programs > in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both > soundtouch.x86_64 and soundtouch.i386 is x86_64 only). Then the libs need to be moved to a separate package, but the fact that 64bit binaries silently overwrite 32bit ones on x86_64 is a feature, not a bug. > Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the > future? :-) Let's just NOT go there again, please. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From davej at redhat.com Mon Sep 24 18:40:42 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 24 Sep 2007 14:40:42 -0400 Subject: open-vm-tools (was Re: [Policy Change] Kernel Module...) In-Reply-To: <20070923071737.7ad7d5bc@redhat.com> References: <1190492961.3966.4.camel@localhost.localdomain> <46F62DBF.2090405@poolshark.org> <20070923071737.7ad7d5bc@redhat.com> Message-ID: <20070924184042.GA12020@redhat.com> On Sun, Sep 23, 2007 at 07:17:37AM -0400, Jesse Keating wrote: > On Sun, 23 Sep 2007 11:11:27 +0200 > Denis Leroy wrote: > > > So how can we make this happen ? Could this be discussed at the next > > FESCo meeting ? > > You post to fedora-kernel-list I do believe Fairly pointless really, unless a rehashing of what was commented in the bug is desired. Dave -- http://www.codemonkey.org.uk From wtogami at redhat.com Mon Sep 24 18:48:31 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 24 Sep 2007 14:48:31 -0400 Subject: squirm package for Fedora Message-ID: <46F8067F.5060708@redhat.com> http://togami.com/~warren/fedora/squirm-1.26-1.fc7.src.rpm Fast and flexible Squid redirector using regexp patterns I packaged squirm because I thought I would use it with my squid reverse proxy, but I ended up deciding that I don't want to use it. If somebody else wants it in Fedora, then go ahead and take this package, perhaps add more fixes and submit it for review. Warren Togami wtogami at redhat.com From dwmw2 at infradead.org Mon Sep 24 19:03:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 20:03:59 +0100 Subject: yum pulling in 386 packages In-Reply-To: <46F7E6B4.7060305@gmail.com> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <46F7E0F9.9040307@gmail.com> <1190650276.2905.109.camel@pmac.infradead.org> <46F7E6B4.7060305@gmail.com> Message-ID: <1190660640.2905.112.camel@pmac.infradead.org> On Mon, 2007-09-24 at 18:32 +0200, dragoran wrote: > I don't disagree with you on that ;) > but as I said I am against killing multilib. That's fine, but in that case I refer you to mailing list etiquette -- if you want to start a thread on a completely separate topic, please don't do it by replying to this thread. -- dwmw2 From besfahbo at redhat.com Mon Sep 24 18:59:35 2007 From: besfahbo at redhat.com (Behdad Esfahbod) Date: Mon, 24 Sep 2007 14:59:35 -0400 Subject: [Long] Do we need a font SIG ? In-Reply-To: <46F337B2.9000104@redhat.com> References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> <46F337B2.9000104@redhat.com> Message-ID: <1190660375.5055.1.camel@behdad.behdad.org> On Thu, 2007-09-20 at 23:17 -0400, M?ir?n Duffy wrote: > Nicolas Mailhot wrote: > > I created a mockup wiki page to try to make all this clear > > http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix > > It's far from complete, but I hope it's complete enough to give > > everyone an idea of the potential SIG scope. > > > > So, who wants to play? Is Fedora ready for a font SIG or should I ask > > again next year? > > I'm in! Let's not let this thread die! Who else is in? /me too. > ~m -- behdad http://behdad.org/ -------------- 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 denis at poolshark.org Mon Sep 24 20:25:04 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 24 Sep 2007 22:25:04 +0200 Subject: open-vm-tools (was Re: [Policy Change] Kernel Module...) In-Reply-To: <20070924184042.GA12020@redhat.com> References: <1190492961.3966.4.camel@localhost.localdomain> <46F62DBF.2090405@poolshark.org> <20070923071737.7ad7d5bc@redhat.com> <20070924184042.GA12020@redhat.com> Message-ID: <46F81D20.7040400@poolshark.org> Dave Jones wrote: > On Sun, Sep 23, 2007 at 07:17:37AM -0400, Jesse Keating wrote: > > On Sun, 23 Sep 2007 11:11:27 +0200 > > Denis Leroy wrote: > > > > > So how can we make this happen ? Could this be discussed at the next > > > FESCo meeting ? > > > > You post to fedora-kernel-list I do believe > > Fairly pointless really, unless a rehashing of what was commented in > the bug is desired. Right, which is why I didn't. You and DavidW have already spoken against it, so that pretty much seals it. open-vm-tools would have made a lot more sense as a kmod or dkms package anyways. It's unfortunate really. From buildsys at fedoraproject.org Mon Sep 24 21:02:11 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 24 Sep 2007 21:02:11 -0000 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 Message-ID: <20070924210211.4594.97455@extras64.linux.duke.edu> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de koffice-karbon - 1.6.2-3.fc7.i386 (39 days) koffice-kivio - 1.6.2-3.fc7.i386 (39 days) koffice-kspread - 1.6.2-3.fc7.i386 (39 days) berrange AT redhat.com perl-Test-AutoBuild - 1.2.0-3.fc6.noarch perl-Test-AutoBuild - 1.2.0-3.fc6.noarch perl-Test-AutoBuild - 1.2.0-3.fc6.noarch bjohnson AT symetrix.com dbmail - 2.2.4-4.fc7.i386 (81 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (35 days) lxtnow AT gmail.com python-gammu - 0.20-1.fc7.i386 (52 days) python-gammu - 0.20-1.fc7.ppc (52 days) python-gammu - 0.20-1.fc7.x86_64 (52 days) tcallawa AT redhat.com compat-wxGTK-devel - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-devel - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-devel - 2.4.2-21.fc6.ppc (70 days) compat-wxGTK-devel - 2.4.2-21.fc6.x86_64 (70 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-gl - 2.4.2-21.fc6.ppc (70 days) compat-wxGTK-gl - 2.4.2-21.fc6.x86_64 (70 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-stc - 2.4.2-21.fc6.ppc (70 days) compat-wxGTK-stc - 2.4.2-21.fc6.x86_64 (70 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (70 days) compat-wxGTK-xrc - 2.4.2-21.fc6.ppc (70 days) compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64 (70 days) twoerner AT redhat.com postfix-pflogsumm - 2:2.4.3-2.fc7.i386 (101 days) postfix-pflogsumm - 2:2.4.3-2.fc7.ppc (101 days) postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64 (101 days) ====================================================================== Broken packages in fedora-7-i386: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 perl-Test-AutoBuild-1.2.0-3.fc6.noarch requires /usr/bin/mkisofs ====================================================================== Broken packages in fedora-7-ppc: compat-wxGTK-devel-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.ppc requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 perl-Test-AutoBuild-1.2.0-3.fc6.noarch requires /usr/bin/mkisofs ====================================================================== Broken packages in fedora-7-x86_64: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires libwx_gtk-2.4.so.0()(64bit) compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-gl-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 dbmail-2.2.4-4.fc7.i386 requires dbmail-database-driver = 0:2.2.4-4.fc7 koffice-karbon-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kivio-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 koffice-kspread-1.6.2-3.fc7.i386 requires koffice-core = 0:1.6.2-3.fc7 perl-Test-AutoBuild-1.2.0-3.fc6.noarch requires /usr/bin/mkisofs ====================================================================== Broken packages in fedora-updates-7-i386: postfix-pflogsumm-2:2.4.3-2.fc7.i386 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.i386 requires libGammu.so.1 ====================================================================== Broken packages in fedora-updates-7-ppc: postfix-pflogsumm-2:2.4.3-2.fc7.ppc requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.ppc requires libGammu.so.1 ====================================================================== Broken packages in fedora-updates-7-x86_64: postfix-pflogsumm-2:2.4.3-2.fc7.x86_64 requires postfix = 0:2.4.3-2.fc7 python-gammu-0.20-1.fc7.x86_64 requires libGammu.so.1()(64bit) From berrange at redhat.com Mon Sep 24 21:14:20 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 24 Sep 2007 22:14:20 +0100 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <20070924210129.4360.77452@extras64.linux.duke.edu> References: <20070924210129.4360.77452@extras64.linux.duke.edu> Message-ID: <20070924211420.GB13735@redhat.com> Whatever script is producing this report is broken, since /usr/bin/mkisofs definitely exists on F7, and I could install perl-Test-AutoBuild without any dependancy problems on F7 [root at celery ~]# cat /etc/fedora-release Fedora release 7 (Moonshine) [root at celery ~]# rpm -q --whatprovides /usr/bin/mkisofs genisoimage-1.1.6-1.fc7 On Mon, Sep 24, 2007 at 09:01:29PM -0000, Fedora Extras repoclosure wrote: > This is an automated mail created by an experimental script. s/experimental/broken/ > Your following packages in the repository contain broken dependencies: > > ====================================================================== > The results in this report consider Test Updates! > ====================================================================== > > package: perl-Test-AutoBuild - 1.2.0-3.fc6.noarch from fedora-7-ppc > unresolved deps: > /usr/bin/mkisofs > > package: perl-Test-AutoBuild - 1.2.0-3.fc6.noarch from fedora-7-x86_64 > unresolved deps: > /usr/bin/mkisofs > > package: perl-Test-AutoBuild - 1.2.0-3.fc6.noarch from fedora-7-i386 > unresolved deps: > /usr/bin/mkisofs Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From opensource at till.name Mon Sep 24 21:20:58 2007 From: opensource at till.name (Till Maas) Date: Mon, 24 Sep 2007 23:20:58 +0200 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <20070924211420.GB13735@redhat.com> References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: <200709242321.08104.opensource@till.name> On Monday 24 September 2007 23:14:20 Daniel P. Berrange wrote: > Whatever script is producing this report is broken, since /usr/bin/mkisofs > definitely exists on F7, and I could install perl-Test-AutoBuild without > any dependancy problems on F7 Nevertheless, imho it would be better to require /usr/bin/genisoimage instead of mkisofs, because mkisofs is only a compat symlink. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From berrange at redhat.com Mon Sep 24 21:24:08 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 24 Sep 2007 22:24:08 +0100 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <200709242321.08104.opensource@till.name> References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> <200709242321.08104.opensource@till.name> Message-ID: <20070924212408.GC13735@redhat.com> On Mon, Sep 24, 2007 at 11:20:58PM +0200, Till Maas wrote: > On Monday 24 September 2007 23:14:20 Daniel P. Berrange wrote: > > Whatever script is producing this report is broken, since /usr/bin/mkisofs > > definitely exists on F7, and I could install perl-Test-AutoBuild without > > any dependancy problems on F7 > > Nevertheless, imho it would be better to require /usr/bin/genisoimage instead > of mkisofs, because mkisofs is only a compat symlink. No, because the application explicitly invokves 'mkisofs' and not 'genisoimage'. If you put a dependancy on '/usr/bin/genisoimage' and the mkisofs symlink goes away, then the app stops working. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mschwendt.tmp0701.nospam at arcor.de Mon Sep 24 21:40:18 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 24 Sep 2007 23:40:18 +0200 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <20070924211420.GB13735@redhat.com> References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: <20070924234018.239f0b6c.mschwendt.tmp0701.nospam@arcor.de> On Mon, 24 Sep 2007 22:14:20 +0100, Daniel P. Berrange wrote: > > Whatever script is producing this report is broken, since /usr/bin/mkisofs > definitely exists on F7, and I could install perl-Test-AutoBuild without > any dependancy problems on F7 > > [root at celery ~]# cat /etc/fedora-release > Fedora release 7 (Moonshine) > [root at celery ~]# rpm -q --whatprovides /usr/bin/mkisofs > genisoimage-1.1.6-1.fc7 > > On Mon, Sep 24, 2007 at 09:01:29PM -0000, Fedora Extras repoclosure wrote: > > This is an automated mail created by an experimental script. > > s/experimental/broken/ No. Don't be so negative. The script is not stupid. There's an updated genisoimage package which does not include /usr/bin/mkisofs anymore: http://koji.fedoraproject.org/koji/buildinfo?buildID=19197 http://koji.fedoraproject.org/koji/rpminfo?rpmID=215296 It's a test update. Now the mission is to either prevent that update from being pushed to stable, or to look into it and prepare an updated perl-Test-AutoBuild. From mschwendt.tmp0701.nospam at arcor.de Mon Sep 24 21:47:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 24 Sep 2007 23:47:50 +0200 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <20070924234018.239f0b6c.mschwendt.tmp0701.nospam@arcor.de> References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> <20070924234018.239f0b6c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070924234750.89de7abc.mschwendt.tmp0701.nospam@arcor.de> On Mon, 24 Sep 2007 23:40:18 +0200, Michael Schwendt wrote: > On Mon, 24 Sep 2007 22:14:20 +0100, Daniel P. Berrange wrote: > > > > > Whatever script is producing this report is broken, since /usr/bin/mkisofs > > definitely exists on F7, and I could install perl-Test-AutoBuild without > > any dependancy problems on F7 > > > > [root at celery ~]# cat /etc/fedora-release > > Fedora release 7 (Moonshine) > > [root at celery ~]# rpm -q --whatprovides /usr/bin/mkisofs > > genisoimage-1.1.6-1.fc7 > > > > On Mon, Sep 24, 2007 at 09:01:29PM -0000, Fedora Extras repoclosure wrote: > > > This is an automated mail created by an experimental script. > > > > s/experimental/broken/ > > No. Don't be so negative. The script is not stupid. There's an updated > genisoimage package which does not include /usr/bin/mkisofs anymore: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=19197 > http://koji.fedoraproject.org/koji/rpminfo?rpmID=215296 > > It's a test update. > > Now the mission is to either prevent that update from being pushed to > stable, or to look into it and prepare an updated perl-Test-AutoBuild. 1.1.6-3.fc7 is it in updates-testing: http://koji.fedoraproject.org/koji/rpminfo?rpmID=213886 1.1.6-5.fc7 is pending in bodhi and includes mkisofs again From kevin.kofler at chello.at Mon Sep 24 21:39:51 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Sep 2007 21:39:51 +0000 (UTC) Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: Daniel P. Berrange redhat.com> writes: > Whatever script is producing this report is broken, since /usr/bin/mkisofs > definitely exists on F7, and I could install perl-Test-AutoBuild without > any dependancy problems on F7 But the testing update 1.1.6-3 no longer provides this file at RPM level, because it now sets it up using the alternatives system, thus upgrading leaves you with a broken dependency. There's a 1.1.6-5 pending which has this file marked as %ghost (as a hack to make the transition from hardcoded symlinks to alternatives working smoothly). Are %ghosted files considered "provided" by RPM? Kevin Kofler From berrange at redhat.com Mon Sep 24 22:07:29 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 24 Sep 2007 23:07:29 +0100 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: <20070924220729.GD13735@redhat.com> On Mon, Sep 24, 2007 at 09:39:51PM +0000, Kevin Kofler wrote: > Daniel P. Berrange redhat.com> writes: > > Whatever script is producing this report is broken, since /usr/bin/mkisofs > > definitely exists on F7, and I could install perl-Test-AutoBuild without > > any dependancy problems on F7 > > But the testing update 1.1.6-3 no longer provides this file at RPM level, > because it now sets it up using the alternatives system, thus upgrading leaves > you with a broken dependency. Ok this what was confusing - I checked what I had already installed, and also what was in CVS, not noticing the intermediate version in updates-testing > There's a 1.1.6-5 pending which has this file marked as %ghost (as a hack to > make the transition from hardcoded symlinks to alternatives working smoothly). > Are %ghosted files considered "provided" by RPM? Yes the -5 works correctly # rpm -q --whatprovides /usr/bin/mkisofs genisoimage-1.1.6-5.fc7 Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dwmw2 at infradead.org Mon Sep 24 22:09:22 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 24 Sep 2007 23:09:22 +0100 Subject: yum pulling in 386 packages In-Reply-To: <1190649551.23386.9.camel@localhost6.localdomain6> References: <200709220944.33124.sgrubb@redhat.com> <20070924072316.35ceca9b@redhat.com> <1190640361.2905.19.camel@pmac.infradead.org> <200709240948.09223.sgrubb@redhat.com> <1190641958.2905.28.camel@pmac.infradead.org> <20070924144741.GA6791@ryvius.pekin.waw.pl> <20070924145452.GC1063599@hiwaay.net> <1190647207.2905.68.camel@pmac.infradead.org> <1190649551.23386.9.camel@localhost6.localdomain6> Message-ID: <1190671762.2905.172.camel@pmac.infradead.org> On Mon, 2007-09-24 at 09:59 -0600, Richi Plana wrote: > On Mon, 2007-09-24 at 16:20 +0100, David Woodhouse wrote: > > On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote: > > > Why keep the i386 versions in the repo? It would be better to write > > > down the rules that are used to pull i386 packages into the x86_64 > > > repo and then make a yum plugin that can point to the i386 repo and > > > follow the rules (when enabled). > > > > There's a lot of sense in this. One of the options being discussed is to > > ship _nothing_ of the secondary arch (or almost nothing) in the primary > > repository, and allow yum to be pointed at the basic i386 repo. > > One problem with this is that many arch-specific packages contain 1) > arch-neutral resources in them (like documentation, data files and > arch-neutral scripts) and 2) some binaries in /usr/bin that collide with > each other. Ideally, a solution like that would allow installing of > packages from any arbitrary architecture (say, ppc and i386) without > there every being any collisions. Unfortunately, neither the > alternatives system nor FHS supports multi-arch installs. That's kind of an orthogonal point -- yes, it's an issue with our existing multilib setup, but it's not directly related to the question at hand, of which packages should be installed by default for the secondary arch and how they should get there. And it's made neither better nor worse by what Chris proposed. It's also something which is partially addressed by something on the multilib tracker bug. Have you looked at that? > Even the current i386-x86_64 installs aren't perfect. The library > separation and linking works alright, but the executable programs > in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both > soundtouch.x86_64 and soundtouch.i386 is x86_64 only). This is bug #235757 (ignore the temporary bit for F7 to prefer 32-bit). > Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the > future? :-) No. :) -- dwmw2 From notting at redhat.com Tue Sep 25 01:58:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 24 Sep 2007 21:58:16 -0400 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: <20070925015816.GC21760@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > There's a 1.1.6-5 pending which has this file marked as %ghost (as a hack to > make the transition from hardcoded symlinks to alternatives working smoothly). > Are %ghosted files considered "provided" by RPM? You can also do: Provides: /path/to/file for things provided by alternatives. Bill From mmcgrath at redhat.com Tue Sep 25 03:49:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 24 Sep 2007 22:49:11 -0500 Subject: db2 outage Message-ID: <46F88537.4060005@redhat.com> I need to work on db2 asap (space issues). I'd like this to be tomorrow night around midnight Eastern. Is there any reason we should not do this? -Mike From buildsys at redhat.com Tue Sep 25 09:19:19 2007 From: buildsys at redhat.com (Build System) Date: Tue, 25 Sep 2007 05:19:19 -0400 Subject: rawhide report: 20070925 changes Message-ID: <200709250919.l8P9JJjo022299@porkchop.devel.redhat.com> New package baekmuk-bdf-fonts Korean bitmap fonts New package baekmuk-ttf-fonts Free Korean TrueType fonts New package fmtools Simple Video for Linux radio card programs New package gsoap Generator Tools for Coding SOAP/XML Web Services in C and C++ New package ladspa-fil-plugins LADSPA Filter plugins New package ladspa-mcp-plugins A set of audio plugins for LADSPA New package ladspa-rev-plugins A reverberation plugin for LADSPA New package ladspa-vco-plugins Anti-aliased pulse and sawtooth oscillators New package libflashsupport Optional Library Interfaces for Adobe Flash Player New package lohit-fonts Free Indian truetype/opentype fonts New package moreutils Additional unix utilities New package odt2txt Converts an OpenDocument to plain text New package opengl-games-utils Utilities to check proper 3d support before launching 3d games New package perl-Time-Duration Time-Duration - rounded or exact English expression of durations New package phpTodo PHP todo list manager New package qfits A stand-alone general purpose FITS library and command line utilities New package qpxtool CD/DVD Quality check tool New package xorg-x11-drv-avivo Xorg X11 AVIVO video driver Updated Packages: Miro-0.9.8.1-6.fc8 ------------------ * Thu Sep 20 2007 Thorsten Scherf 0.9.8.1-3 - new Firefox dep TurboGears-1.0.3.2-2.fc8 ------------------------ * Mon Sep 24 2007 Luke Macken 1.0.3.2-2 - Update setuptools patch to "fix" CherryPy dependency error alsa-utils-1.0.15-0.3.rc1.fc8 ----------------------------- * Mon Sep 24 2007 Martin Stransky 1.0.15-0.3.rc1 - fixed #303151 - wrong salsa dir in /etc/udev/rules.d/90-alsa.rules anaconda-11.3.0.33-1 -------------------- * Mon Sep 24 2007 Jeremy Katz 11.3.0.33-1 - Blacklist some modules to try to avoid #299351 - Copy over media.repo if it exists - Fix for pulling firmware - Remove a useless progress window (#240459) - Fix Romanian traceback (#292091) - Catch an exception on repo setup (#295381) - Fix network device tool tips - Fix display of groups being installed vs no (#296581) - Fix Serbian language/keyboard (msivak, #235709) - Honor "boot from" dropdown more (msivak, #243556, #243799) - Make sure people are adequately warned about booting from a drive they're not installing to (msivak, #243799) - Don't label lvm on live installs either (#297391) antlr-0:2.7.7-1jpp.6.fc8 ------------------------ * Mon Sep 24 2007 Deepak Bhole 2.7.7-1jpp.6 - Resolve bz# 242305: Remove libantlr-pic.a, and compile libantlr.a with fPIC apr-util-1.2.10-2.fc8 --------------------- * Mon Sep 24 2007 Jesse Keating - 1.2.10-2 - Rebuild for upgrade path (add dist since that's now on F-7 branch) autofs-1:5.0.2-16 ----------------- * Mon Sep 24 2007 Ian Kent - 5.0.2-16 - add descriptive comments to config about LDAP schema discovery. - work around segfault at exit caused by libxml2. - fix foreground logging (also fixes shutdown needing extra signal bug). avahi-0.6.21-6.fc8 ------------------ * Tue Sep 25 2007 Lennart Poettering - 0.6.21-6 - resolves #279301: fix segfault when no domains are configured in resolv.conf (pulled from upstream SVN r1525) bind-32:9.5.0-14.a6.fc8 ----------------------- * Mon Sep 24 2007 Adam Tkac 32:9.5.0-14.a6 - added edns patch again (#275091) * Mon Sep 24 2007 Adam Tkac 32:9.5.0-13.a6 - removed bind-9.3.3-edns.patch patch (see #275091 for reasons) * Thu Sep 20 2007 Adam Tkac 32:9.5.0-12.4.a6 - build with O2 - removed "autotools" patch - bugfixing in bind-chroot-admin (#279901) blobAndConquer-0.91-4.fc8 ------------------------- * Mon Sep 24 2007 Hans de Goede 0.91-4 - Use opengl-games-utils wrapper to show error dialog when DRI is missing bugzilla-3.0.2-0.fc8 -------------------- * Mon Sep 24 2007 John Berninger - 3.0.2-0 - update to 3.0.2 - bz 299981 clamav-0.91.2-2.fc8 ------------------- * Mon Sep 24 2007 Jesse Keating - 0.91.2-2 - Bump release for upgrade path. clanbomber-1.05-7.fc8 --------------------- * Mon Sep 24 2007 Hans de Goede 1.05-7 - Revert last change, clanbomber does not use OpenGL (oops) * Mon Sep 24 2007 Hans de Goede 1.05-6 - Use opengl-games-utils wrapper to show error dialog when DRI is missing dbus-glib-0.73-4.fc8 -------------------- * Mon Sep 24 2007 Dan Williams - 0.73-4 - Dispatch NameOwnerChanged signals to proxies only once (fdo #12505) eclipse-egit-0.3.0-1.fc8 ------------------------ * Mon Sep 24 2007 Ben Konrath 0.3.0.fc8 - 0.3.0 eclipse-rpm-editor-0.1.0-8.fc8 ------------------------------ * Mon Sep 24 2007 fons 0.1.0-8 - Fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=204146 - Fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=204150 evince-2.20.0-2.fc8 ------------------- * Mon Sep 24 2007 Matthias Clasen - 2.20.0-2 - Add a missing schema file facter-1.3.8-1.fc8 ------------------ * Mon Sep 24 2007 David Lutterkort - 1.3.8-1 - Update license tag - Copy all of lib/ into ruby_sitelibdir fonts-indic-2.1.5-3.fc8 ----------------------- * Mon Sep 24 2007 Parag Nemade - 2.1.5-3.fc8 - this is now a meta-package since Lohit fonts were moved to lohit-fonts (#253158) - each subpackage requires the corresponding lohit-fonts subpackage fonts-korean-2.2-5.fc8 ---------------------- * Mon Sep 24 2007 Jens Petersen - 2.2-5.fc8 - this is now a meta-package after moving baekmuk-bdf and baekmuk-ttf to separate packages (#253155) gambas-1.0.19-3.fc8 ------------------- * Mon Sep 24 2007 Jesse Keating - 1.0.19-3 - BuildRequire sqlite-devel instead of sqlite2-devel. * Mon Sep 24 2007 Jesse Keating - 1.0.19-2 - Rebuild for new sqlite. gmp-4.2.2-3.fc8 --------------- * Mon Sep 24 2007 Ivana Varekova 4.2.2-3 - fix libgmpxx.so link * Thu Sep 20 2007 Ivana Varekova 4.2.2-2 - fix check tag * Wed Sep 19 2007 Ivana Varekova 4.2.2-1 - update to 4.2.2 gnome-screensaver-2.20.0-5.fc8 ------------------------------ * Mon Sep 24 2007 Matthias Clasen - 2.20.0-5 - Fix up GConf requires (#220547) * Fri Sep 21 2007 Matthias Clasen - 2.20.0-4 - Add %pre scriptlet gnuplot-4.2.0-6.fc8 ------------------- * Mon Sep 24 2007 Ivana Varekova - 4.2.0-6 - spec file cleanup grhino-0.16.0-2.fc8 ------------------- * Mon Sep 24 2007 Michel Salim - 0.16.0-2 - License field updated - Remove invalid Version key from upstream desktop file gtk-nodoka-engine-0.6-4.fc8 --------------------------- * Mon Sep 24 2007 Martin Sourada - 0.6-4 - update the treeview patch - rhbz #297271 and rhbz #302551 inotify-tools-3.11-1.fc8 ------------------------ * Mon Sep 24 2007 Dawid Gajownik - 3.11-1 - Update to 3.11 (CVE-2007-5037, #299771) - Fix License tag iptables-1.3.8-4.fc8 -------------------- * Mon Sep 24 2007 Thomas Woerner 1.3.8-4 - fixed IPv6 reject type (rhbz#295181) - fixed init script: start, stop and status - support netfilter compiled into kernel in init script (rhbz#295611) - dropped inversion for limit modules from man pages (rhbz#220780) - fixed typo in ip6tables man page (rhbz#236185) isomaster-1.1-2.fc8 ------------------- * Wed Aug 29 2007 Marcin Zajaczkowski - 1.1-2 - added text-editor.sh to find existing GUI text editor * Wed Aug 29 2007 Marcin Zajaczkowski - 1.1-1 - updated to 1.1 - a default viewer is called by xdg-open (from xdg-utils) jakarta-commons-daemon-1:1.0.1-6jpp.4.fc8 ----------------------------------------- * Mon Sep 24 2007 Permaine Cheung - 1:1.0.1-6jpp.4 - Add execve path warning patch from James Ralston kernel-2.6.23-0.202.rc8.fc8 --------------------------- * Mon Sep 24 2007 Dave Jones - 2.6.23-rc8 * Mon Sep 24 2007 Roland McGrath - Fix powerpc oops on ptrace after exec. (#301791) * Mon Sep 24 2007 Dave Jones - Disable generic RTC. kudzu-1.2.75-2 -------------- * Mon Sep 24 2007 Adam Jackson 1.2.75-2 - BuildRequires: popt-devel popt-static * Wed Sep 05 2007 Adam Jackson 1.2.75-1 - Add pcidom to the exported slot list of pciDevice. - Add clog target to Makefile. kvm-36-5.fc8 ------------ * Mon Sep 24 2007 Jeremy Katz - 36-5 - fix build on x86_64 * Mon Sep 24 2007 Jeremy Katz - 36-3 - add support for selecting boot device at runtime libICE-1.0.4-1.fc8 ------------------ * Mon Sep 24 2007 Adam Jackson 1.0.4-1 - libICE 1.0.4 libX11-1.1.3-1.fc8 ------------------ * Mon Sep 24 2007 Adam Jackson 1.1.3-1 - libX11 1.1.3 libXaw-1.0.4-1.fc8 ------------------ * Mon Sep 24 2007 Adam Jackson 1.0.4-1 - libXaw 1.0.4 libXcursor-1.1.9-1.fc8 ---------------------- * Mon Sep 24 2007 Adam Jackson 1.1.9-1 - libXcursor 1.1.9 libXfont-1.3.1-1.fc8 -------------------- * Mon Sep 24 2007 Adam Jackson 1.3.1-1 - libXfont 1.3.1 * Mon Sep 17 2007 Adam Jackson 1.2.9-4 - Rebuild for abstract socket support. * Wed Aug 22 2007 Adam Jackson - 1.2.9-3 - Rebuild for PPC toolchain bug libXi-1.1.3-1.fc8 ----------------- * Mon Sep 24 2007 Adam Jackson 1.1.3-1 - libXi 1.1.3 libXpm-3.5.7-1.fc8 ------------------ * Mon Sep 24 2007 Adam Jackson 3.5.7-1 - libXpm 3.5.7 libXrandr-1.2.2-1.fc8 --------------------- * Mon Sep 24 2007 Adam Jackson 1.2.2-1 - libXrandr 1.2.2 libXrender-0.9.4-1.fc8 ---------------------- * Mon Sep 24 2007 Adam Jackson 0.9.4-1 - libXrender 0.9.4 libXtst-1.0.3-1.fc8 ------------------- * Mon Sep 24 2007 Adam Jackson 1.0.3-1 - libXtst 1.0.3 libpciaccess-0.9.1-1.fc8 ------------------------ * Mon Sep 24 2007 Adam Jackson 0.9.1-1 - libpciaccess 0.9.1 libselinux-2.0.34-3.fc8 ----------------------- * Mon Sep 24 2007 Dan Walsh - 2.0.34-3 - Add sparc patch to from Dennis Gilmore to build on Sparc platform * Mon Sep 24 2007 Dan Walsh - 2.0.34-2 - Remove leaked file descriptor lostirc-0.4.6-3.fc8 ------------------- machineball-1.0-4.fc8 --------------------- * Mon Sep 24 2007 Hans de Goede 1.0-4 - Use opengl-games-utils wrapper to show error dialog when DRI is missing maniadrive-1.2-4.fc8 -------------------- * Mon Sep 24 2007 Hans de Goede 1.2-4 - Use opengl-games-utils wrapper to show error dialog when DRI is missing nginx-0.5.32-1.fc8 ------------------ * Mon Sep 24 2007 Jeremy Hinegardner - 0.5.32-1 - updated to 0.5.32 - fixed rpmlint UTF-8 complaints. nhpf-1.42-10 ------------ * Wed Sep 26 2007 Caius Chance - 1.42-10 - Resolves: rhbz#249975 (nhpf not built with $RPM_OPT_FLAGS.) <<< Fixed CFLAGS in Makefile for more meaningful debuginfo. nsd-3.0.6-4.fc8 --------------- * Mon Sep 24 2007 Jesse Keating - 3.0.6-4 - Bump release for upgrade path. * Fri Sep 14 2007 Paul Wouters 3.0.6-3 - Do not include examples from nsd.conf.sample that causes bogus network traffic. ntp-4.2.4p2-6.fc8 ----------------- * Mon Sep 24 2007 Miroslav Lichvar 4.2.4p2-6 - require perl (#274771) - don't fail when starting with no interfaces (#300371) ocaml-libvirt-0.3.2.8-1.fc8 --------------------------- * Mon Sep 24 2007 Richard W.M. Jones - 0.3.2.8-1 - New upstream release 0.3.2.8. padevchooser-0.9.4-0.3.svn20070925.fc8 -------------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.4-0.3.svn20070825 - Update SVN snapshot paprefs-0.9.6-0.2.svn20070925.fc8 --------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.6-0.2.svn20070925 - Update SVN snapshot pavucontrol-0.9.5-0.4.svn20070925.fc8 ------------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.5-0.4.svn20070925 - Update from SVN pavumeter-0.9.3-0.2.svn20070925.fc8 ----------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.3-0.2.svn20070925 - Update from SVN snapshot * Thu Aug 16 2007 Lennart Poettering 0.9.3-0.1.svn20070816 - Update from SVN snapshot * Sat Sep 09 2006 Pierre Ossman 0.9.2-2 - Fix installation of desktop file. perl-DBD-SQLite2-0.33-8.fc8 --------------------------- * Mon Sep 24 2007 Jesse Keating - 0.33-8 - Fall back to internal sqlite2, we don't ship sqlite2 in Fedora anymore. perl-Net-Libdnet-0.01-3.fc8 --------------------------- perl-Nmap-Parser-1.05-4.fc8 --------------------------- * Mon Sep 24 2007 Jesse Keating - 1.05-4 - Bump release for upgrade path pinball-0.3.1-9.fc8 ------------------- * Mon Sep 24 2007 Hans de Goede 0.3.1-9 - Use opengl-games-utils wrapper to show error dialog when DRI is missing policycoreutils-2.0.26-3.fc8 ---------------------------- * Mon Sep 24 2007 Dan Walsh 2.0.26-3 - Show local changes with semanage * Mon Sep 24 2007 Dan Walsh 2.0.26-2 - Fixed spelling mistakes in booleans defs - Update po * Tue Sep 18 2007 Dan Walsh 2.0.26-1 - Update to upstream * Fix setfiles selabel option flag setting for 64-bit from Stephen Smalley. ppl-0.9-15.fc8 -------------- * Mon Sep 24 2007 Jesse Keating - 0.9-15 - Rebuild for new libgmpxx pstoedit-3.45-1.fc8 ------------------- * Thu Sep 20 2007 Denis Leroy - 3.45-1 - Update to new upstream 3.45, bugfix release - Updated quiet patch for 3.45 pulseaudio-0.9.7-0.12.svn20070925.fc8 ------------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.7-0.12.svn20070925 - New SVN snapshot - Split off libflashsupport again - Rename "-lib" packages to "-libs", like all other packages do it. - Provide esound python-setuptools-0.6c7-2.fc8 ----------------------------- * Mon Sep 24 2007 Konstantin Ryabitsev - 0.6c7-2 - Move pretty much everything back into runtime in order to avoid more brokenness than we're trying to address with these fixes. * Fri Sep 14 2007 Konstantin Ryabitsev - 0.6c7-1 - Upstream 0.6c7 - Move some things from devel into runtime, in order to not break other projects. quarry-0.2.0-2.fc8 ------------------ * Mon Sep 24 2007 Michel Salim - 0.2.0-2 - License field update - Remove invalid version key from desktop file rsyslog-1.19.6-1.fc8 -------------------- * Tue Sep 25 2007 Tomas Heinrich 1.19.6 - upstream bugfix release scorched3d-40.1d-6.fc8 ---------------------- * Mon Sep 24 2007 Hans de Goede 40.1d-6 - Use opengl-games-utils wrapper to show error dialog when DRI is missing selinux-policy-3.0.8-11.fc8 --------------------------- * Mon Sep 24 2007 Dan Walsh 3.0.8-11 - Fix maxima * Mon Sep 24 2007 Dan Walsh 3.0.8-10 - Eliminate rpm_t:fifo_file avcs - Fix dbus path for helper app * Sat Sep 22 2007 Dan Walsh 3.0.8-9 - Fix service start stop terminal avc's setroubleshoot-1.10.5-1.fc8 --------------------------- * Mon Sep 24 2007 John Dennis - 1.10.5-1 - update code for command line log file scanning to work with new log file scanning code introduced for the browser. setroubleshoot-plugins-1.10.3-1.fc8 ----------------------------------- * Mon Sep 24 2007 John Dennis - 1.10.3-1 - Resolves bug #231762: Original PO strings bugs struts-0:1.2.9-4jpp.8.fc8 ------------------------- * Mon Sep 24 2007 Deepak Bhole 1.2.9-4jpp.8 - Exclude webapp classes from native compilation (issues with check-build-root) * Thu Sep 20 2007 Deepak Bhole 1.2.9-4jpp.7 - Rebuild for ppc32 execmem issue and new build-id - Add %{?dist} as per new policy supertuxkart-0.3-2.fc8 ---------------------- * Mon Sep 24 2007 Hans de Goede 0.3-2 - Use opengl-games-utils wrapper to show error dialog when DRI is missing system-config-network-1.4.1-2.fc8 --------------------------------- * Mon Sep 24 2007 Harald Hoyer - 1.4.1-2 - require newt-python instead of newt only * Mon Sep 24 2007 Harald Hoyer - 1.4.1 - version 1.4.1 * Thu Aug 16 2007 Harald Hoyer - 1.4.0 - version 1.4.0 taglib-1.5-0.3.20070924svn.fc8 ------------------------------ * Mon Sep 24 2007 Aurelien Bompard 1.5-0.3.20070924svn - rebuild * Mon Sep 24 2007 Aurelien Bompard 1.5-0.2.20070924svn - BR: automake * Mon Sep 24 2007 Aurelien Bompard 1.5-0.1.20070924svn - update to svn version tdom-0.8.2-2.fc8 ---------------- * Sun Sep 23 2007 Wart - 0.8.2-2 - Added missing linkage against -lexpat timidity++-2.13.2-2.fc8 ----------------------- * Mon Sep 24 2007 Jindrich Novy 2.13.2-2 - spec/license fixes tremulous-1.1.0-4.fc8 --------------------- * Mon Sep 24 2007 Hans de Goede 1.1.0-4 - Use opengl-games-utils wrapper to show error dialog when DRI is missing vegastrike-0.4.3-7.fc8 ---------------------- * Mon Sep 24 2007 Hans de Goede 0.4.3-7 - Use opengl-games-utils wrapper to show error dialog when DRI is missing * Tue Aug 28 2007 Hans de Goede 0.4.3-6 - Rebuild for new expat 2.0 * Wed Aug 22 2007 Hans de Goede 0.4.3-5 - Rebuild for buildId vixie-cron-4:4.2-3.fc8 ---------------------- * Mon Sep 24 2007 Marcela Maslanova - 4:4.2-3 - cron own cron.deny - correct license tag - with-pam (configure) is now optional vnc-4.1.2-22.fc8 ---------------- * Mon Sep 24 2007 Adam Tkac 4.1.2-22 - obsoleted vnc-s390.patch - build with --disable-xorg * Wed Aug 22 2007 Adam Tkac 4.1.2-21 - rebuild (BuildID feature) - GPLv2 license * Mon Aug 06 2007 Adam Tkac 4.1.2-20.2 - updated vnc-s390 patch to latest xorg wdfs-1.4.2-4.fc8 ---------------- * Mon Sep 24 2007 Adam Jackson 1.4.2-4 - Fix spelling error in URL. (#302731) xen-3.1.0-8.fc8 --------------- * Mon Sep 24 2007 Daniel P. Berrange - 3.1.0-8.fc8 - Make 32-bit FC-6 guest PVFB work on x86_64 host * Mon Sep 24 2007 Daniel P. Berrange - 3.1.0-7.fc8 - Re-add support for back-compat FC6 PVFB support - Fix handling of explicit port numbers (rhbz #279581) xmoto-0.3.3-2.fc8 ----------------- * Mon Sep 24 2007 Jon Ciesla 0.3.3-2 - Patches from upstream to correct BZ 295981. * Wed Aug 29 2007 Jon Ciesla 0.3.3-1 - Bumped to upstream. - Fixed URL. * Thu Aug 16 2007 Jon Ciesla 0.3.1-2 - License tag correction. xorg-x11-apps-7.3-1.fc8 ----------------------- * Mon Sep 24 2007 Adam Jackson 7.3-1 - xconsole 1.0.3 - xmessage 1.0.2 - Bump to 7.3-1 xorg-x11-drv-ati-6.7.194-1.fc8 ------------------------------ * Mon Sep 24 2007 Dave Airlie 6.7.194-1 - xf86-video-ati 6.7.194 xorg-x11-drv-mouse-1.2.2-1.fc8 ------------------------------ * Mon Sep 24 2007 Adam Jackson 1.2.2-1 - xf86-input-mouse 1.2.2 xorg-x11-drv-nv-2.1.5-1.fc8 --------------------------- * Mon Sep 24 2007 Adam Jackson 2.1.5-1 - xf86-video-nv 2.1.5. xorg-x11-drv-vmmouse-12.4.2-1.fc8 --------------------------------- * Mon Sep 24 2007 Adam Jackson 12.4.2-1 - xf86-input-vmmouse 12.4.2 xorg-x11-drv-vmware-10.15.1-1.fc8 --------------------------------- * Mon Sep 24 2007 Adam Jackson 10.15.1-1 - xf86-video-vmware 10.15.1 xorg-x11-drv-void-1.1.1-6.fc8 ----------------------------- * Mon Sep 24 2007 Adam Jackson 1.1.1-6 - xf86-input-void 1.1.1 xorg-x11-drv-voodoo-1.1.1-1.fc8 ------------------------------- * Mon Sep 24 2007 Adam Jackson 1.1.1-1 - xf86-video-voodoo 1.1.1 xorg-x11-proto-devel-7.3-1.fc8 ------------------------------ * Mon Sep 24 2007 Adam Jackson 7.3-1 - dgaproto 2.0.3 - Bump to 7.3 xorg-x11-server-utils-7.3-1.fc8 ------------------------------- * Mon Sep 24 2007 Adam Jackson 7.3-1 - sessreg 1.0.3 - xgamma 1.0.2 - xmodmap 1.0.3 - xrdb 1.0.4 - xset 1.0.3 - xsetroot 1.0.2 - Bump to 7.3 xorg-x11-utils-7.3-1.fc8 ------------------------ * Mon Sep 24 2007 Adam Jackson 7.3-1 - xdriinfo 1.0.2 - xwininfo 1.0.3 - Bump to 7.3 xorg-x11-xinit-1.0.7-1.fc8 -------------------------- * Mon Sep 24 2007 Adam Jackson 1.0.7-1 - xinit 1.0.7 yasm-0.6.2-1.fc8 ---------------- * Mon Sep 24 2007 Matthias Saou 0.6.2-1 - Update to 0.6.2. Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.i686 requires kernel-i686 = 0:2.6.23-0.187.rc6.git7.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 setroubleshoot - 1.10.5-1.fc8.noarch requires selinux-policy-base >= 0:3.0.7-10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) setroubleshoot - 1.10.5-1.fc8.noarch requires selinux-policy-base >= 0:3.0.7-10 Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc requires kernel-ppc = 0:2.6.23-0.187.rc6.git7.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone setroubleshoot - 1.10.5-1.fc8.noarch requires selinux-policy-base >= 0:3.0.7-10 Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300 - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.187.rc6.git7.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.187.rc6.git7.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display setroubleshoot - 1.10.5-1.fc8.noarch requires selinux-policy-base >= 0:3.0.7-10 xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From buildsys at fedoraproject.org Tue Sep 25 10:37:10 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 25 Sep 2007 06:37:10 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-25 Message-ID: <20070925103710.DB96A15212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 8 BackupPC-3.0.0-3.fc6 bugzilla-3.0.2-0.fc6 em8300-kmod-0.16.3-1.2.6.22.7_57.fc6 facter-1.3.8-1.fc6 NEW fmtools-1.0.2-2.fc6 : Simple Video for Linux radio card programs php-pear-MDB2-Driver-mysql-1.4.1-2.fc6 python-iniparse-0.2.2-1.fc6 trac-bazaar-plugin-0.2-5.20070829bzr182.fc6 Changes in Fedora Extras 6: BackupPC-3.0.0-3.fc6 -------------------- * Fri Sep 21 2007 Johan Cwiklinski 3.0.0-3 - Fixed SELinux policy module * Wed Sep 12 2007 Johan Cwiklinski 3.0.0-2 - Added SELinux policy module * Tue Jan 30 2007 Johan Cwiklinski 3.0.0-1 - Rebuild RPM for v 3.0.0 bugzilla-3.0.2-0.fc6 -------------------- * Mon Sep 24 2007 John Berninger - 3.0.2-0 - update to 3.0.2 - bz 299981 em8300-kmod-0.16.3-1.2.6.22.7_57.fc6 ------------------------------------ * Tue Sep 25 2007 Ville Skytt? - Rebuild for kernel 2.6.22.7-57.fc6. facter-1.3.8-1.fc6 ------------------ * Mon Sep 24 2007 David Lutterkort - 1.3.8-1 - Update license tag - Copy all of lib/ into ruby_sitelibdir fmtools-1.0.2-2.fc6 ------------------- * Fri Sep 21 2007 kwizart - 1.0.2-2 - Fix shebang - Fix perm on source - Fix mixed use of spaces and tabs - Remove internal header to use it from kernel-headers * Sun Aug 26 2007 kwizart - 1.0.2-1 - Update to 1.0.2 php-pear-MDB2-Driver-mysql-1.4.1-2.fc6 -------------------------------------- * Sat Sep 22 2007 Christopher Stone 1.4.1-2 - Update Requires python-iniparse-0.2.2-1.fc6 --------------------------- * Tue Sep 25 2007 Tim Lauridsen - 0.2.2-1 - Updated to release 0.2.2 - removed patch to to fix problems with out commented lines, included in upstream source * Wed Sep 12 2007 Tim Lauridsen - 0.2.1-4 - Added some logic to get the right python-setuptools buildrequeres - based on the fedora version, to make the same spec file useful in - all fedora releases. * Mon Sep 10 2007 Tim Lauridsen - 0.2.1-3 - Added patch from upstream svn to fix problems with out commented lines. * Tue Aug 28 2007 Tim Lauridsen - 0.2.1-2 - Changed BuildRequires python-setuptools to python-setuptools-devel trac-bazaar-plugin-0.2-5.20070829bzr182.fc6 ------------------------------------------- * Sat Sep 22 2007 Toshio Kuratomi - 0.2-5.20070829bzr182 - Patches to fix RSS feed in timeline view. * Wed Aug 29 2007 Toshio Kuratomi - 0.2-4.20070829bzr182 - Update license tag to reflect GPLv2+. - New update from upstream that clarifies license and makes setuptools build a correct tarball. * Sun Aug 12 2007 Toshio Kuratomi - 0.2-3.20070712bzr180 - Update license tag to reflect GPLv2 only. From j.w.r.degoede at hhs.nl Tue Sep 25 11:50:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 25 Sep 2007 13:50:00 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils Message-ID: <46F8F5E8.3000801@hhs.nl> Hi All, In preperation for the Games Live DVD, I've created a small bash script which resides in opengl-games-utils, which is meant to be used as a wrapper around OpenGL games. If DRI is available this wrapper does nothing, if it isn't it will show an error dialog, explaining about Free Software and 3D drivers and then exit. The idea here is that an error dialog is better then trying to click the quit menu option while the mouse is jumping from the right edge of the screen to the left edge (mouse navigation is anything but easy at 3 fps). This is esp. important for the Games Live DVD, as there people will not have those other drivers available. I've already added usage of this wrapper to all my games that are in the kickstart file for the Live DVD, and I will file bugs for this against a couple of the most highprofile games also in the kickstart, in the mean time everyone please check all your games for OpenGL usage and necessary add the wrapper. Adding the wrapper is _really_ easy: Add: "Requires: opengl-games-utils" Add to %install: "ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper" Add "%{_bindir}/%{name}-wrapper" to files Change the .desktop file Exec entry from "%{name}" to "%{name}-wrapper" Done! This all assumes your main binary name == %{name}, otherwise adapt as necessary. If you already have a wrapper script for one reason or the other, you can incorperate the checkDriOk function directly into your wrapper, no need todo a wrapper wrapper, see vegastrike's vegastrike-wrapper.sh CVS file as example. Regards, Hans From harald at redhat.com Tue Sep 25 12:07:12 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Sep 2007 14:07:12 +0200 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 In-Reply-To: <20070925015816.GC21760@nostromo.devel.redhat.com> References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> <20070925015816.GC21760@nostromo.devel.redhat.com> Message-ID: <46F8F9F0.40404@redhat.com> Bill Nottingham schrieb: > Kevin Kofler (kevin.kofler at chello.at) said: >> There's a 1.1.6-5 pending which has this file marked as %ghost (as a hack to >> make the transition from hardcoded symlinks to alternatives working smoothly). >> Are %ghosted files considered "provided" by RPM? > > You can also do: > > Provides: /path/to/file > > for things provided by alternatives. > > Bill > The problem was, that, if the previous symlink was not ghosted, rpm removed it after alternatives set up the symlinks in %post. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From overholt at redhat.com Tue Sep 25 12:06:59 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 25 Sep 2007 08:06:59 -0400 Subject: Review request: Eclipse Demonstration Screencasts Message-ID: <20070925120659.GA8115@redhat.com> Hi, As part of the Devel SIG initiative, we've been making some .ogg screencasts of various Eclipse operations. We hope to introduce people to Eclipse technology available in Fedora and -- over time -- hope to build up content to ease in new developers. I've put up a package for review with our initial set of .oggs. I'd like to include it in the test3 Developer Live image so if someone could get to it today, I'd really appreciate it :) https://bugzilla.redhat.com/show_bug.cgi?id=304861 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 gemi at bluewin.ch Tue Sep 25 12:15:16 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 25 Sep 2007 14:15:16 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F8F5E8.3000801@hhs.nl> References: <46F8F5E8.3000801@hhs.nl> Message-ID: <1190722516.8399.1.camel@localhost.localdomain> On Tue, 2007-09-25 at 13:50 +0200, Hans de Goede wrote: > This is esp. important for the Games Live DVD, as there people will > not have > those other drivers available. I wonder if it makes any sense to include OpenGL games in such a Games Live DVD, that does not provide drivers. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From lemenkov at gmail.com Tue Sep 25 12:18:24 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 25 Sep 2007 16:18:24 +0400 Subject: What prevents mldonkey from inclusion into Fedora? Message-ID: Hello All! We already have software which helps to create bittorrent, ftp and maybe some other servers for file sharing and huge number of clients for them. So why not to add mldonkey? -- With best regards! From debarshi.ray at gmail.com Tue Sep 25 12:20:07 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 25 Sep 2007 17:50:07 +0530 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <1190722516.8399.1.camel@localhost.localdomain> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> Message-ID: <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> > I wonder if it makes any sense to include OpenGL games in such a Games > Live DVD, that does not provide drivers. Why not? OpenGL games run on GPUs for which one has free software drivers. eg., Intel. Thus one can use such a LiveCD to check the availability and quality of graphics drivers and hardware before buying a new computer. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From j.w.r.degoede at hhs.nl Tue Sep 25 12:18:22 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 25 Sep 2007 14:18:22 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <1190722516.8399.1.camel@localhost.localdomain> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> Message-ID: <46F8FC8E.70906@hhs.nl> G?rard Milmeister wrote: > On Tue, 2007-09-25 at 13:50 +0200, Hans de Goede wrote: >> This is esp. important for the Games Live DVD, as there people will >> not have >> those other drivers available. > I wonder if it makes any sense to include OpenGL games in such a Games > Live DVD, that does not provide drivers. Yes it does, as OpenGL games will work fine on all integrated intel graphics (lots of systems) and on all pre r5xx radeons (quite a few systems). And who knows, with Fedora 9 we might have radeon 3d support over the whole line, and nouveau 3d support for nvidea cards, and yes then we still want to have this check, as there will always be some unsupported cards. Regards, Hans From bernie at codewiz.org Tue Sep 25 12:43:42 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 25 Sep 2007 08:43:42 -0400 Subject: What prevents mldonkey from inclusion into Fedora? In-Reply-To: References: Message-ID: <46F9027E.6060700@codewiz.org> Peter Lemenkov wrote: > Hello All! > We already have software which helps to create bittorrent, ftp and > maybe some other servers for file sharing and huge number of clients > for them. So why not to add mldonkey? I see no reason why mldonkey shouldn't be allowed in Fedora. It's licensed as GPL and the protocol it supports are not patented. This wiki page listing all the restrictions doesn't mention P2P servers: http://fedoraproject.org/wiki/ForbiddenItems An RPM is already in Livna. You could ask the maintainer if he wishes to open a review request for Fedora. Or you could do it yourself. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From rdieter at math.unl.edu Tue Sep 25 12:48:36 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Sep 2007 07:48:36 -0500 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> Message-ID: Kevin Kofler wrote: > Daniel P. Berrange redhat.com> writes: >> Whatever script is producing this report is broken, since >> /usr/bin/mkisofs definitely exists on F7, and I could install >> perl-Test-AutoBuild without any dependancy problems on F7 > > But the testing update 1.1.6-3 no longer provides this file at RPM level, > because it now sets it up using the alternatives system, thus upgrading > leaves you with a broken dependency. One reason why I've always tried to argue that alternatives-using packages should make an effort to own the alternatives target. -- Rex From rdieter at math.unl.edu Tue Sep 25 12:50:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Sep 2007 07:50:17 -0500 Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-09-24 References: <20070924210129.4360.77452@extras64.linux.duke.edu> <20070924211420.GB13735@redhat.com> <20070925015816.GC21760@nostromo.devel.redhat.com> <46F8F9F0.40404@redhat.com> Message-ID: Harald Hoyer wrote: > Bill Nottingham schrieb: >> Kevin Kofler (kevin.kofler at chello.at) said: >>> There's a 1.1.6-5 pending which has this file marked as %ghost (as a >>> hack to make the transition from hardcoded symlinks to alternatives >>> working smoothly). Are %ghosted files considered "provided" by RPM? >> >> You can also do: >> >> Provides: /path/to/file >> for things provided by alternatives. > The problem was, that, if the previous symlink was not ghosted, rpm > removed it after alternatives set up the symlinks in %post. right, another case where %ghost + alternatives would help. -- Rex From cra at WPI.EDU Tue Sep 25 13:09:14 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 25 Sep 2007 09:09:14 -0400 Subject: db2 outage In-Reply-To: <46F88537.4060005@redhat.com> References: <46F88537.4060005@redhat.com> Message-ID: <20070925130914.GE3789@angus.ind.WPI.EDU> On Mon, Sep 24, 2007 at 10:49:11PM -0500, Mike McGrath wrote: > I need to work on db2 asap (space issues). I'd like this to be tomorrow > night around midnight Eastern. Is there any reason we should not do this? Are we supposed to know what db2 does? What services will be affected? From mmcgrath at redhat.com Tue Sep 25 13:23:54 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 25 Sep 2007 08:23:54 -0500 Subject: db2 outage In-Reply-To: <20070925130914.GE3789@angus.ind.WPI.EDU> References: <46F88537.4060005@redhat.com> <20070925130914.GE3789@angus.ind.WPI.EDU> Message-ID: <46F90BEA.30800@redhat.com> Chuck Anderson wrote: > On Mon, Sep 24, 2007 at 10:49:11PM -0500, Mike McGrath wrote: > >> I need to work on db2 asap (space issues). I'd like this to be tomorrow >> night around midnight Eastern. Is there any reason we should not do this? >> > > Are we supposed to know what db2 does? What services will be > affected? > I'm mostly concerned with the releng team, I probably should have sent it to them directly. The biggest service affected will be the buildsystem and all of its requisites (bodhi, pkgdb, koji, etc) -Mike From james.antill at redhat.com Tue Sep 25 13:29:42 2007 From: james.antill at redhat.com (James Antill) Date: Tue, 25 Sep 2007 09:29:42 -0400 Subject: yum update so slow In-Reply-To: <46F78726.4020808@comsoft.de> References: <46F78726.4020808@comsoft.de> Message-ID: <1190726982.22109.31.camel@code.and.org> On Mon, 2007-09-24 at 11:45 +0200, Jochen Schlick wrote: > Hi, I have a laptop where rawhide is installed since the days > of Fedora Core 1. It has only 256MB ram so updating using yum > was always like a lame duck but nowadays it's really a crap. This might not help, but if you'd like to try something I've attached some python code which calls yum and "iterativlely updates". This might make it be small enough that it isn't living in swap, or at least not as badly. Let me know how it goes. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: yum-iter-update.py Type: text/x-python Size: 1588 bytes Desc: not available URL: -------------- 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 snecklifter at gmail.com Tue Sep 25 13:32:09 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 25 Sep 2007 14:32:09 +0100 Subject: db2 outage In-Reply-To: <46F90BEA.30800@redhat.com> References: <46F88537.4060005@redhat.com> <20070925130914.GE3789@angus.ind.WPI.EDU> <46F90BEA.30800@redhat.com> Message-ID: <364d303b0709250632r4368df73rbaa8559f50b9d2e0@mail.gmail.com> On 25/09/2007, Mike McGrath wrote: > > Chuck Anderson wrote: > > On Mon, Sep 24, 2007 at 10:49:11PM -0500, Mike McGrath wrote: > > > >> I need to work on db2 asap (space issues). I'd like this to be > tomorrow > >> night around midnight Eastern. Is there any reason we should not do > this? > >> > > > > Are we supposed to know what db2 does? What services will be > > affected? > > > > I'm mostly concerned with the releng team, I probably should have sent > it to them directly. The biggest service affected will be the > buildsystem and all of its requisites (bodhi, pkgdb, koji, etc) No I think you did right posting to -devel. If koji and bodhi are affected then surely it affects everyone using these systems, not just rel-eng (unless everyone building pkgs are part of rel-eng which would be news to me). I also had no clue what db2 was however I'm glad Chuck asked before me. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From billcrawford1970 at gmail.com Tue Sep 25 13:35:39 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 25 Sep 2007 14:35:39 +0100 Subject: Root login in rawhide and display managers In-Reply-To: <46F7F982.5020408@gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> <20070918100913.7f2c9e3a@localhost.localdomain> <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> <1190649994.23386.15.camel@localhost6.localdomain6> <46F7F982.5020408@gmail.com> Message-ID: <544eb990709250635j3ef07d83n9c85f328ddf43452@mail.gmail.com> On 24/09/2007, David Boles wrote: > What I said the other, and I still feel this way, was that *if* you are > the qualified admin of this system you should know how to change the 'no > root GUI' default setting to allow root to login with a WM desktop. You > should not but you should know how to do this. OK, how about making it an install-time option, checked by default? And if one can switch to a VT, login and run "startx" anyway, what's the benefit, really, of disallowing root login except to make it cosmetically more secure? From rjones at redhat.com Tue Sep 25 13:36:30 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 25 Sep 2007 14:36:30 +0100 Subject: What prevents mldonkey from inclusion into Fedora? In-Reply-To: References: Message-ID: <46F90EDE.1030605@redhat.com> Peter Lemenkov wrote: > Hello All! > We already have software which helps to create bittorrent, ftp and > maybe some other servers for file sharing and huge number of clients > for them. So why not to add mldonkey? If you need any help from the OCaml packaging side, let me know. Also see (although this being a program, not a library, most of the rules don't apply): https://fedoraproject.org/wiki/Packaging/OCaml Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mmcgrath at redhat.com Tue Sep 25 13:41:10 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 25 Sep 2007 08:41:10 -0500 Subject: db2 outage In-Reply-To: <364d303b0709250632r4368df73rbaa8559f50b9d2e0@mail.gmail.com> References: <46F88537.4060005@redhat.com> <20070925130914.GE3789@angus.ind.WPI.EDU> <46F90BEA.30800@redhat.com> <364d303b0709250632r4368df73rbaa8559f50b9d2e0@mail.gmail.com> Message-ID: <46F90FF6.4070309@redhat.com> Christopher Brown wrote: > On 25/09/2007, Mike McGrath wrote: > >> Chuck Anderson wrote: >> >>> On Mon, Sep 24, 2007 at 10:49:11PM -0500, Mike McGrath wrote: >>> >>> >>>> I need to work on db2 asap (space issues). I'd like this to be >>>> >> tomorrow >> >>>> night around midnight Eastern. Is there any reason we should not do >>>> >> this? >> >>> Are we supposed to know what db2 does? What services will be >>> affected? >>> >>> >> I'm mostly concerned with the releng team, I probably should have sent >> it to them directly. The biggest service affected will be the >> buildsystem and all of its requisites (bodhi, pkgdb, koji, etc) >> > > > No I think you did right posting to -devel. If koji and bodhi are affected > then surely it affects everyone using these systems, not just rel-eng > (unless everyone building pkgs are part of rel-eng which would be news to > me). I also had no clue what db2 was however I'm glad Chuck asked before me. > FWIW, this isn't the outage notification, just a request to see if any red flags go off. The actual notification will be sent out after a date has been set. -Mike From abo at kth.se Tue Sep 25 13:44:44 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 25 Sep 2007 15:44:44 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F8F5E8.3000801@hhs.nl> References: <46F8F5E8.3000801@hhs.nl> Message-ID: <1190727884.21155.32.camel@home.alexander.bostrom.net> On Tue, 2007-09-25 at 13:50 +0200, Hans de Goede wrote: > The idea here is that an error dialog is better then trying to click the quit > menu option while the mouse is jumping from the right edge of the screen to the > left edge (mouse navigation is anything but easy at 3 fps). Actually, I would consider that a bug in the application/game. If it's unable to render quickly enough to be usable it should either figure that out before putting the user in such a position or exit gracefully before the user gets frustrated and forces a hard reboot. A proper explanation of what happened is good, of course. /abo From jkeating at redhat.com Tue Sep 25 13:45:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 25 Sep 2007 09:45:05 -0400 Subject: db2 outage In-Reply-To: <46F88537.4060005@redhat.com> References: <46F88537.4060005@redhat.com> Message-ID: <20070925094505.030fe778@redhat.com> On Mon, 24 Sep 2007 22:49:11 -0500 Mike McGrath wrote: > I need to work on db2 asap (space issues). I'd like this to be > tomorrow night around midnight Eastern. Is there any reason we > should not do this? That would be tonight I suppose, and the only thing was that I'm in the middle of signing packages for Test3. However I hope to be done with that before midnight and then you'd be free to have an outage. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jochen.schlick at comsoft.de Tue Sep 25 13:59:19 2007 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Tue, 25 Sep 2007 15:59:19 +0200 Subject: yum update so slow In-Reply-To: <1190642583.5661.30.camel@localhost.localdomain> References: <46F78726.4020808@comsoft.de> <1190642583.5661.30.camel@localhost.localdomain> Message-ID: <46F91437.3000709@comsoft.de> Lubomir Kundrak wrote: > On Mon, 2007-09-24 at 11:45 +0200, Jochen Schlick wrote: >> Hi, I have a laptop where rawhide is installed since the days >> of Fedora Core 1. It has only 256MB ram so updating using yum >> was always like a lame duck but nowadays it's really a crap. > > >> Last friday the yum update process crashed when yum wants >> to update the rpm library package. > >> -- and now, this morning after eight hours: 2 packages updated >> (and a glibc error message about a double free...) > > Do you have a core dump (well, if you have enough storage, yum is > sometimes too greedy :)? > no, there were no core dumps. but I give it up using yum for updating. It had updated only 5 packages after 24 hours :-( >> -- with this update "speed" I will have an "up to date" system >> in 12 days... :-( > > What I was doing when updating my 128M machine w/o swap was NFS-mounting > its root and updating it on a machine with more memory, or used rpm by > hand. Trying to use yum on that machine would not be smart (yum is > unable to fork itself when trying to run scriptlets). > because yum had successfuly downloaded all necessary rpm I made a "rpm -Uhv *rpm" in yum's download directory and after an hour the system was up to date. best regards -- --------------------------------------------------------------------------- Jochen Schlick From sundaram at fedoraproject.org Tue Sep 25 14:24:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 25 Sep 2007 19:54:53 +0530 Subject: Root login in rawhide and display managers In-Reply-To: <544eb990709250635j3ef07d83n9c85f328ddf43452@mail.gmail.com> References: <46F038AC.9010503@fedoraproject.org> <46F11039.3020802@fedoraproject.org> <20070919124811.GA20979@imperial.ac.uk> <1190210934.2949.6.camel@localhost6.localdomain6> <20070918100913.7f2c9e3a@localhost.localdomain> <544eb990709240743h734d4024v159a15dfa7f0dac0@mail.gmail.com> <1190649994.23386.15.camel@localhost6.localdomain6> <46F7F982.5020408@gmail.com> <544eb990709250635j3ef07d83n9c85f328ddf43452@mail.gmail.com> Message-ID: <46F91A35.7080905@fedoraproject.org> Bill Crawford wrote: > On 24/09/2007, David Boles wrote: > >> What I said the other, and I still feel this way, was that *if* you are >> the qualified admin of this system you should know how to change the 'no >> root GUI' default setting to allow root to login with a WM desktop. You >> should not but you should know how to do this. > > OK, how about making it an install-time option, checked by default? Piling more options everywhere isn't really a good answer. > And if one can switch to a VT, login and run "startx" anyway, what's > the benefit, really, of disallowing root login except to make it > cosmetically more secure? The amount of code running as root is significantly less in a VT compared to running a entire desktop environment as root user. Rahul From mmcgrath at redhat.com Tue Sep 25 14:29:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 25 Sep 2007 09:29:14 -0500 Subject: Outage Notification - 2007-09-26 04:00 UTC (DB2) Message-ID: <46F91B3A.3050108@redhat.com> There will be an outage starting at 2007-09-26 04:00 UTC UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2007-09-26 04:00 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Ticket Link: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/163 Reason for Outage: DB2 is running out of disk space. This is a preventative maintenance to ensure that we don't completely run out. There are a couple of avenues I'm still examining but if they fail I'll be forced to rebuild db2 with more storage and that's the reason for the outage. Its possible the actual outage will only take an hour or two but just in case I've created a 5 hour block. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dwmw2 at infradead.org Tue Sep 25 14:45:53 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Sep 2007 15:45:53 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070924103037.745fab66@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <1190640068.2905.13.camel@pmac.infradead.org> <20070924093554.20d14c15@redhat.com> <1190641272.2905.24.camel@pmac.infradead.org> <20070924095148.458da2de@redhat.com> <1190643934.2905.37.camel@pmac.infradead.org> <20070924103037.745fab66@redhat.com> Message-ID: <1190731553.2905.256.camel@pmac.infradead.org> On Mon, 2007-09-24 at 10:30 -0400, Jesse Keating wrote: > On Mon, 24 Sep 2007 15:25:34 +0100 > David Woodhouse wrote: > > > Who do we need that isn't based around Boston? I seem to spend half my > > life on planes at the moment, and come through Boston relatively > > frequently. Should I just try to give you a bit of warning each time I > > fly in, to see if we can all find some time? > > Seth Vidal and Bill Nottingham at least. Ah, of course. Sorry -- I keep forgetting that not _everyone_ has been sucked into the Westford black hole yet :) -- dwmw2 From ffesti at redhat.com Tue Sep 25 15:19:35 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 25 Sep 2007 17:19:35 +0200 Subject: yum pulling in 386 packages In-Reply-To: <20070924072407.6fa861a2@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> Message-ID: <46F92707.1050205@redhat.com> Jesse Keating wrote: > On Sun, 23 Sep 2007 17:30:05 +0100 > David Woodhouse wrote: > >> That strategy is, quite simply, wrong. > > Then work to fix the strategy, don't shoot the tools for following the > requested script. Dropping snide comments about them doesn't make > anybody any more eager to listen to you. The point is that in fact yum is the problem (not the only one). Yum - as an updating tool - should honor the user's previously made decisions as much as possible. To be able to do that on a multilib system yum needs to take arch into account for more or less every decision (especially the arch of the already installed packages). As yum didn't do that in the past introducing multilib would have required to rewrite all package selection code within yum (and some other parts of the tool chain). Instead people came up with the "install everything" policy with the hope this would hide most problems of the non multilib aware tools. As we all known this only works for the simplest cases - not to mention all the other drawbacks that come up on this list every week (as in this thread). So it is not about changing the "default policy" but about having a sane behavior in our tools that do not depend on any policy but just work [1]. When it comes to that current case: This is an bug! Obsoletes have to be seen as updates which additionally involve a name change. Yes, obsoletes do not have an arch assosiated with them - as updates also do not. The updating tool (yum) has to decide what updates/obsoleting packages to install. And of course it has to take the archs of the already installed packages into account. No one would suggest to update foo-1-1.i368 to foo-2-1.i386 and foo-2-1.x86_64 although both have higher version numbers and the names also match. The same logic applies to obsoletes. Florian [1] tbh: some of the most hurting cases have been fixed in yum but large parts of the code are still arch agnostic. From mattdm at mattdm.org Tue Sep 25 15:23:15 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 25 Sep 2007 11:23:15 -0400 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <1190727884.21155.32.camel@home.alexander.bostrom.net> References: <46F8F5E8.3000801@hhs.nl> <1190727884.21155.32.camel@home.alexander.bostrom.net> Message-ID: <20070925152315.GA31821@jadzia.bu.edu> On Tue, Sep 25, 2007 at 03:44:44PM +0200, Alexander Bostr?m wrote: > Actually, I would consider that a bug in the application/game. If it's Yeah, but since there's thousands of programs with that "bug", the wrapper is a nicer solution. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at fedoraproject.org Tue Sep 25 15:23:15 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 25 Sep 2007 11:23:15 -0400 Subject: yum pulling in 386 packages In-Reply-To: <46F92707.1050205@redhat.com> References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> Message-ID: <1190733795.6478.46.camel@cutter> On Tue, 2007-09-25 at 17:19 +0200, Florian Festi wrote: > Jesse Keating wrote: > > On Sun, 23 Sep 2007 17:30:05 +0100 > > David Woodhouse wrote: > > > >> That strategy is, quite simply, wrong. > > > > Then work to fix the strategy, don't shoot the tools for following the > > requested script. Dropping snide comments about them doesn't make > > anybody any more eager to listen to you. > > The point is that in fact yum is the problem (not the only one). Yum - as an > updating tool - should honor the user's previously made decisions as much as > possible. To be able to do that on a multilib system yum needs to take arch > into account for more or less every decision (especially the arch of the > already installed packages). As yum didn't do that in the past introducing > multilib would have required to rewrite all package selection code within > yum (and some other parts of the tool chain). Instead people came up with > the "install everything" policy with the hope this would hide most problems > of the non multilib aware tools. As we all known this only works for the > simplest cases - not to mention all the other drawbacks that come up on this > list every week (as in this thread). Umm, you have it backward. When I was originally writing in the multilib support I asked how it should be done and was told, at the time, by Jeremy that it should install both of them b/c that's what users would want/expect. At least, that's what I vaguely recall. This has been about 3 years, now. > > So it is not about changing the "default policy" but about having a sane > behavior in our tools that do not depend on any policy but just work [1]. Wrong. It's about the policy. -sv From Jochen at herr-schmitt.de Tue Sep 25 15:37:30 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 25 Sep 2007 17:37:30 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <20070925152315.GA31821@jadzia.bu.edu> References: <46F8F5E8.3000801@hhs.nl> <1190727884.21155.32.camel@home.alexander.bostrom.net> <20070925152315.GA31821@jadzia.bu.edu> Message-ID: <46F92B3A.40102@herr-schmitt.de> Matthew Miller schrieb: > On Tue, Sep 25, 2007 at 03:44:44PM +0200, Alexander Bostr?m wrote: > >> Actually, I would consider that a bug in the application/game. If it's >> > > Yeah, but since there's thousands of programs with that "bug", the wrapper > is a nicer solution. > > For me, this wrapper is not a solution, because I have got a error message. I'm using the nvidia driver from rpm.livna.org and stellarium is running fine with this driver. So I was force to block BZ #304851 Best Regards: Jochen Schmitt From myfedora at richip.dhs.org Tue Sep 25 16:41:26 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 25 Sep 2007 10:41:26 -0600 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> Message-ID: <1190738486.31260.7.camel@localhost6.localdomain6> On Tue, 2007-09-25 at 17:50 +0530, Debarshi 'Rishi' Ray wrote: > > I wonder if it makes any sense to include OpenGL games in such a Games > > Live DVD, that does not provide drivers. > > Why not? OpenGL games run on GPUs for which one has free software > drivers. eg., Intel. Thus one can use such a LiveCD to check the > availability and quality of graphics drivers and hardware before > buying a new computer. One worry I have is that there are a lot of hardware out there with (currently) unsupported video cards and, in this case, first impressions matter. If someone new to Fedora or linux gives it a try and can't even get a single OpenGL-accelerated game running, that could do more harm than good. Of course, there's really nothing we can do about it at this point, but I was wondering if there was a better way to mitigate the problem (like add instructions on the error dialog for getting the needed drivers in as few steps as possible). Otherwise you may as well call the release 3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors Release. -- Richi Plana From sundaram at fedoraproject.org Tue Sep 25 16:45:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 25 Sep 2007 22:15:53 +0530 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <1190738486.31260.7.camel@localhost6.localdomain6> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> <1190738486.31260.7.camel@localhost6.localdomain6> Message-ID: <46F93B41.9070807@fedoraproject.org> Richi Plana wrote: > Of course, there's really nothing we can do about it at this point, but > I was wondering if there was a better way to mitigate the problem (like > add instructions on the error dialog for getting the needed drivers in > as few steps as possible). The wrapper will atleast inform you why the drivers aren't available and IMO we should be encouraging the use of Free software drivers especially at this point since both Intel and more recently ATI have come up with them leaving Nvidia as as the odd man out which hopefully Nouveau (which we already include) covers at a later stage. > Otherwise you may as well call the release > 3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors > Release. Well essentially Fedora is strongly Free software oriented anyway. Compared to the current experience this is a improvement. Rahul From jspaleta at gmail.com Tue Sep 25 16:55:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Sep 2007 08:55:19 -0800 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <1190738486.31260.7.camel@localhost6.localdomain6> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> <1190738486.31260.7.camel@localhost6.localdomain6> Message-ID: <604aa7910709250955w3a0b1ab2l4a1dea96a5a2ea56@mail.gmail.com> On 9/25/07, Richi Plana wrote: > Of course, there's really nothing we can do about it at this point, but > I was wondering if there was a better way to mitigate the problem (like > add instructions on the error dialog for getting the needed drivers in > as few steps as possible). 1) This tool is meant to help people running the Games LiveCD... no way to install more drivers while in live mode. 2) No.. as a project we will not be handing out explicit instructions on how to install 3rd party binary video drivers via a client dialog. > > Otherwise you may as well call the release > 3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors > Release. And that is the WHOLE point. This is what Fedora IS, as a project it is focused completely and utterly on the open source software stack. We aren't sugar coating it or hiding the fact that video driver coverage is a problem, by slipping users proprietary pills. Video driver coverage IS a problem, its a problem that needs to be stressed and not covered over in a very shallow and vain attempt to boost our distribution numbers by sneaking in addon drivers we don't support as a project. As the information being churned out of the AMD/ATI spec releases start to get churned into open driver development, something like opengl intensive livecd makes a lot of sense to me as a tool to help users who care about open source to make better hardware purchasing choices. -jef"please tell me the wrapper script dialog is disablable so users who want to play with 3 fps video can do so..even in a livecd install"spaleta From ndbecker2 at gmail.com Tue Sep 25 16:55:30 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 25 Sep 2007 12:55:30 -0400 Subject: truecrypt Message-ID: Has anyone looked at truecrypt? Looks interesting. I D/L the source, but it says: Note that Linux kernel headers, located in the 'include' directory, are not sufficient for compilation of the TrueCrypt kernel module. Fields of 'dm_dev' structure must be accessed by TrueCrypt but they are defined only in an internal kernel header 'drivers/md/dm.h'. No appropriate accessor function is available. The complete source code of the Linux kernel is required for compilation of the kernel module. From jima at beer.tclug.org Tue Sep 25 17:07:29 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 25 Sep 2007 12:07:29 -0500 (CDT) Subject: truecrypt In-Reply-To: References: Message-ID: On Tue, 25 Sep 2007, Neal Becker wrote: > Has anyone looked at truecrypt? Looks interesting. I D/L the source, but > it says: > > Note that Linux kernel headers, located in the 'include' directory, are > not sufficient for compilation of the TrueCrypt kernel module. Fields of > 'dm_dev' structure must be accessed by TrueCrypt but they are defined only > in > an internal kernel header 'drivers/md/dm.h'. No appropriate accessor > function > is available. The complete source code of the Linux kernel is required for > compilation of the kernel module. Don't we BR kernel-devel when building kmods anyway? I don't think this is a problem at all. (Aside from the possibility of kmod packaging going anyway, anyway.) Jima From sandeen at redhat.com Tue Sep 25 17:13:12 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 25 Sep 2007 12:13:12 -0500 Subject: truecrypt In-Reply-To: References: Message-ID: <46F941A8.2050702@redhat.com> Jima wrote: > On Tue, 25 Sep 2007, Neal Becker wrote: >> Has anyone looked at truecrypt? Looks interesting. I D/L the source, but >> it says: >> >> Note that Linux kernel headers, located in the 'include' directory, are >> not sufficient for compilation of the TrueCrypt kernel module. Fields of >> 'dm_dev' structure must be accessed by TrueCrypt but they are defined only >> in >> an internal kernel header 'drivers/md/dm.h'. No appropriate accessor >> function >> is available. The complete source code of the Linux kernel is required for >> compilation of the kernel module. > > Don't we BR kernel-devel when building kmods anyway? I don't think this > is a problem at all. (Aside from the possibility of kmod packaging going > anyway, anyway.) But, drivers/md/dm.h is not in kernel-devel. -Eric From jwboyer at jdub.homelinux.org Tue Sep 25 17:15:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 25 Sep 2007 12:15:37 -0500 Subject: truecrypt In-Reply-To: References: Message-ID: <20070925121537.5a57b89e@weaponx.rchland.ibm.com> On Tue, 25 Sep 2007 12:07:29 -0500 (CDT) Jima wrote: > On Tue, 25 Sep 2007, Neal Becker wrote: > > Has anyone looked at truecrypt? Looks interesting. I D/L the source, but > > it says: > > > > Note that Linux kernel headers, located in the 'include' directory, are > > not sufficient for compilation of the TrueCrypt kernel module. Fields of > > 'dm_dev' structure must be accessed by TrueCrypt but they are defined only > > in > > an internal kernel header 'drivers/md/dm.h'. No appropriate accessor > > function > > is available. The complete source code of the Linux kernel is required for > > compilation of the kernel module. > > Don't we BR kernel-devel when building kmods anyway? I don't think this > is a problem at all. (Aside from the possibility of kmod packaging going > anyway, anyway.) It's not a possibility. They are going away. josh From jima at beer.tclug.org Tue Sep 25 17:17:07 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 25 Sep 2007 12:17:07 -0500 (CDT) Subject: truecrypt In-Reply-To: <46F941A8.2050702@redhat.com> References: <46F941A8.2050702@redhat.com> Message-ID: On Tue, 25 Sep 2007, Eric Sandeen wrote: > But, drivers/md/dm.h is not in kernel-devel. ...as I was just noticing. Oops, spoke too soon. :-) Jima From j.w.r.degoede at hhs.nl Tue Sep 25 17:23:26 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 25 Sep 2007 19:23:26 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <604aa7910709250955w3a0b1ab2l4a1dea96a5a2ea56@mail.gmail.com> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> <1190738486.31260.7.camel@localhost6.localdomain6> <604aa7910709250955w3a0b1ab2l4a1dea96a5a2ea56@mail.gmail.com> Message-ID: <46F9440E.4070402@hhs.nl> Jeff Spaleta wrote: > -jef"please tell me the wrapper script dialog is disablable so users > who want to play with 3 fps video can do so..even in a livecd > install"spaleta > Well, the live cd has a modifiable filesystem and I'm sure it will contain a texteditor so yes the script can be disabled (by commenting out the check), or users can start the game from the commandline starting foo instead of foo-wrapper which the menu entry will start. Hans "wonders if jef got my mail about londonlaw" de Goede From j.w.r.degoede at hhs.nl Tue Sep 25 17:24:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 25 Sep 2007 19:24:52 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F92B3A.40102@herr-schmitt.de> References: <46F8F5E8.3000801@hhs.nl> <1190727884.21155.32.camel@home.alexander.bostrom.net> <20070925152315.GA31821@jadzia.bu.edu> <46F92B3A.40102@herr-schmitt.de> Message-ID: <46F94464.602@hhs.nl> Jochen Schmitt wrote: > Matthew Miller schrieb: >> On Tue, Sep 25, 2007 at 03:44:44PM +0200, Alexander Bostr?m wrote: >> >>> Actually, I would consider that a bug in the application/game. If it's >>> >> Yeah, but since there's thousands of programs with that "bug", the wrapper >> is a nicer solution. >> >> > For me, this wrapper is not a solution, because I have got a error > message. I'm using the > nvidia driver from rpm.livna.org and stellarium is running fine with > this driver. > > So I was force to block BZ #304851 > Ugh, I agree this is bad, but not using the wrapper is not the solution, the wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers where both using dri as well (I'm pretty sure the fglrx driver is, but I'll give it a try). Can you please attach the output of glxinfo for an nvidia card, then I'll try to come up with a fixed version of the script. Luckily I put the script in a seperate rpm and did not copy and paste it to a gazillion game packages, cases like this being exactly the reason to have the script in one central place. Regards, Hans From jspaleta at gmail.com Tue Sep 25 17:57:18 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Sep 2007 09:57:18 -0800 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F9440E.4070402@hhs.nl> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> <1190738486.31260.7.camel@localhost6.localdomain6> <604aa7910709250955w3a0b1ab2l4a1dea96a5a2ea56@mail.gmail.com> <46F9440E.4070402@hhs.nl> Message-ID: <604aa7910709251057l98fc04dse79715916c6812a0@mail.gmail.com> On 9/25/07, Hans de Goede wrote: > Hans "wonders if jef got my mail about londonlaw" de Goede Oh i probably got it... and missed it. -jef"goes digging into gmail cache and muses to himself that Google and its Advertising partners probably already know that I got the email and finds it disappointing that they didn't tell me by giving me text ads related to London street crime and bus tickets."spaleta From lmacken at redhat.com Tue Sep 25 18:39:07 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 25 Sep 2007 14:39:07 -0400 Subject: truecrypt In-Reply-To: References: Message-ID: <20070925183907.GC5516@crow.myhome.westell.com> On Tue, Sep 25, 2007 at 12:55:30PM -0400, Neal Becker wrote: > Has anyone looked at truecrypt? Looks interesting. I D/L the source, but > it says: > > Note that Linux kernel headers, located in the 'include' directory, are > not sufficient for compilation of the TrueCrypt kernel module. Fields of > 'dm_dev' structure must be accessed by TrueCrypt but they are defined only > in > an internal kernel header 'drivers/md/dm.h'. No appropriate accessor > function > is available. The complete source code of the Linux kernel is required for > compilation of the kernel module. Truecrypt is awesome, but their license[0] is a bit questionable. It's a hybrid of a bunch of different licenses and has some interesting distribution clauses. IANAL, so we definitely would want to run it by fedora-legal-list if we hope to get truecrypt into Fedora. There has also been some talk about this license in the Debian community: http://lists.debian.org/debian-legal/2006/06/msg00294.html http://lists.debian.org/debian-legal/2006/07/msg00008.html luke [0]: http://www.truecrypt.org/license.php From jspaleta at gmail.com Tue Sep 25 18:47:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Sep 2007 10:47:48 -0800 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F9440E.4070402@hhs.nl> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <3170f42f0709250520w5c44c68er461f616c9b0db5e3@mail.gmail.com> <1190738486.31260.7.camel@localhost6.localdomain6> <604aa7910709250955w3a0b1ab2l4a1dea96a5a2ea56@mail.gmail.com> <46F9440E.4070402@hhs.nl> Message-ID: <604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com> On 9/25/07, Hans de Goede wrote: > Well, the live cd has a modifiable filesystem and I'm sure it will contain a > texteditor so yes the script can be disabled (by commenting out the check), I was thinking more like a environment variable that the script can check for. So that on a per-user basis this can be disabled quickly for all games just by exporting the environment variable. Since you are asking for the games packages to use this by default, there needs to be a per-user way to disable the script action on multi-user configurations. -jef From tjb at unh.edu Tue Sep 25 19:30:49 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 25 Sep 2007 15:30:49 -0400 Subject: Fedora 7 Updates Busted Again? Message-ID: <1190748649.5242.10.camel@raptor.sr.unh.edu> Did the Fedora 7 updates get whacked again? It seems my mirror of kernel.org just deleted almost all the F7 updates. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tdiehl at rogueind.com Tue Sep 25 19:36:29 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 25 Sep 2007 15:36:29 -0400 (EDT) Subject: Fedora 7 Updates Busted Again? In-Reply-To: <1190748649.5242.10.camel@raptor.sr.unh.edu> References: <1190748649.5242.10.camel@raptor.sr.unh.edu> Message-ID: On Tue, 25 Sep 2007, Thomas J. Baker wrote: > > Did the Fedora 7 updates get whacked again? It seems my mirror of > kernel.org just deleted almost all the F7 updates. Yep!! Jesse and company are working on it. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From dominik at greysector.net Tue Sep 25 19:43:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 25 Sep 2007 21:43:36 +0200 Subject: truecrypt In-Reply-To: <20070925183907.GC5516@crow.myhome.westell.com> References: <20070925183907.GC5516@crow.myhome.westell.com> Message-ID: <20070925194336.GF8137@ryvius.pekin.waw.pl> On Tuesday, 25 September 2007 at 20:39, Luke Macken wrote: > On Tue, Sep 25, 2007 at 12:55:30PM -0400, Neal Becker wrote: > > Has anyone looked at truecrypt? Looks interesting. I D/L the source, but > > it says: > > > > Note that Linux kernel headers, located in the 'include' directory, are > > not sufficient for compilation of the TrueCrypt kernel module. Fields of > > 'dm_dev' structure must be accessed by TrueCrypt but they are defined only > > in > > an internal kernel header 'drivers/md/dm.h'. No appropriate accessor > > function > > is available. The complete source code of the Linux kernel is required for > > compilation of the kernel module. > > Truecrypt is awesome, but their license[0] is a bit questionable. It's a > hybrid of a bunch of different licenses and has some interesting > distribution clauses. IANAL, so we definitely would want to run it by > fedora-legal-list if we hope to get truecrypt into Fedora. There has also > been some talk about this license in the Debian community: > > http://lists.debian.org/debian-legal/2006/06/msg00294.html > http://lists.debian.org/debian-legal/2006/07/msg00008.html > > luke > > [0]: http://www.truecrypt.org/license.php Here are src.rpms with tools and kmod: http://rpm.greysector.net/livna/ Feel free to submit them to livna/rpmfusion. I don't have time to maintain them, but I made those when I was looking for a cryptofs solution for both Linux and Windows (and settled on LUKS instead). Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From halfline at gmail.com Tue Sep 25 20:17:44 2007 From: halfline at gmail.com (Ray Strode) Date: Tue, 25 Sep 2007 16:17:44 -0400 Subject: artwork split up Message-ID: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> Hi, redhat-artwork has way too many build requirements and unrelated content. I've split it up in a bunch of little packages and filed review requests for each one. You can see them all here: https://bugzilla.redhat.com/showdependencytree.cgi?id=305441 Once they get in, I don't plan on working on them much (basically just an initial push to fix whatever broke in the split). If anyone wants to be the upstream (and downstream) for one or more of the packages that's fine with me. Jeremy is currently working on getting them all hosted. Note, there will probably be a lot of issues initially. The split wasn't hard work, but it was very redundant and time consuming, so I'm sure I introduced more than a few regressions. Just thought I'd give everyone a heads up. --Ray From mattdm at mattdm.org Tue Sep 25 20:19:41 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 25 Sep 2007 16:19:41 -0400 Subject: artwork split up In-Reply-To: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> Message-ID: <20070925201940.GA27099@jadzia.bu.edu> On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote: > redhat-artwork has way too many build requirements and unrelated content. > I've split it up in a bunch of little packages and filed review > requests for each one. Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- this is very helpful. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Matt_Domsch at dell.com Tue Sep 25 21:06:51 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 25 Sep 2007 16:06:51 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-25 Message-ID: <20070925160651.A13071@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 Tue Sep 25 15:36:25 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 4738 Number failed to build: 462 Number expected to fail due to ExclusiveArch or ExcludeArch: 31 Leaving: 431 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 431 ---------------------------------- adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung redhat com airsnort-0.2.7e-11.fc7 (build/make) andreas.bierfert lowlatency de akode-2.0.1-8.fc8 (buildroot) rdieter math unl edu alacarte-0.11.3-4.fc8 (build/make) rstrode redhat com amsn-0.96-7.fc7 (build/make) sander hoentjen eu apt-0.5.15lorg3.93-2.fc8 (build/make) Axel.Thimm ATrpms net atitvout-0.4-7 (buildroot) andreas.bierfert lowlatency de avr-binutils-2.17-4.fc8 (buildroot) j.w.r.degoede hhs nl awesfx-0.5.0d-4.fc7 (build/make) stransky redhat com azureus-2.5.0.4-2.fc7 (build/make) green redhat com callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2 redhat com castor-0.9.5-1jpp.7 (buildroot) pcheung redhat com centericq-4.21.0-14.fc8 (build/make) andreas.bierfert lowlatency de checkstyle-4.1-4jpp.1.fc7 (buildroot) nsantos redhat com chkfontpath-1.10.1-2.fc8 (build/make) krh redhat com clips-6.24-22.fc7 (build/make) rvinyard cs nmsu edu clisp-2.41-3.fc7 (build/make) gemi bluewin ch compat-erlang-R10B-10.7.fc7 (build/make) gemi bluewin ch compat-gcc-32-3.2.3-61 (build/make) jakub redhat com compat-gcc-34-3.4.6-7 (buildroot) jakub redhat com compiz-fusion-0.5.2-6.fc8.src.rpm compiz-fusion-extras-0.5.2-5.fc8.src.rpm conexus-0.5.3-2.fc8 (build/make) rvinyard cs nmsu edu cpan2rpm-2.028-2.fc6 (build/make) ghenry suretecsystems com cryptix-3.2.0-9jpp.1 (build/make) mwringe redhat com cryptix-asn1-20011119-7jpp.2 (build/make) vivekl redhat com cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones redhat com,opensource till name d4x-2.5.7.1-3.fc7 (build/make) matthias rpmforge net digikamimageplugins-0.9.1-1.fc7 (build/make) rdieter math unl edu dirac-0.7.0-2.fc8 (buildroot) kwizart gmail com eclipse-emf-2.2.2-1.fc7 (build/make) overholt redhat com eclipse-mylar-2.0-0.1.M2a.1.fc7 (build/make) overholt redhat com eiciel-0.9.4-1.fc7 (build/make) cweyl alumni drew edu em8300-kmod-0.16.3-5.2.6.23_0.187.rc6.git7.fc8 (buildroot) ville.skytta iki fi emelfm2-0.3.5-2.fc8 (build/make) fedora christoph-wickert de evolution-remove-duplicates-0.0.2-6.fc7 (build/make) michel.salim gmail com fakechroot-2.5-12.fc7 (build/make) Axel.Thimm ATrpms net fluxstyle-1.0.1-2.fc7 (build/make) miker5slow grandecom net fontypython-0.2.0-6.fc7 (build/make) cr33dog gmail com freetennis-0.4.8-6.fc7 (build/make) dev nigelj com gai-0.5.10-10.fc7 (build/make) michel.salim gmail com gajim-0.11.1-1.fc7 (buildroot) gajownik gmail com gambas-1.0.19-1.fc8.2 (buildroot) tcallawa redhat com gdb-6.6-27.fc8.src.rpm gdb-6.6-29.fc8 (buildroot) jan.kratochvil redhat com gdmap-0.7.5-6.fc6 (build/make) splinux fedoraproject org gedit-plugins-2.18.0-2.fc7 (build/make) trond.danielsen gmail com genius-0.7.7-2.fc7 (build/make) gemi bluewin ch gfa-0.4.1-4.fc7 (build/make) splinux25 gmail com ghdl-0.25-0.89svn.5.fc8 (build/make) t.sailer alumni ethz ch giggle-0.3-4.fc8 (build/make) jbowes redhat com glipper-0.95.1-2.fc7 (build/make) splinux fedoraproject org gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak redhat com gnome-pilot-2.0.15-5.fc7 (build/make) mbarnes redhat com gnomescan-0.4.0.2-1.fc7 (build/make) dakingun gmail com gnome-specimen-0.3-1.fc8 (build/make) splinux fedoraproject org gnomesword-2.2.3-5.fc8 (build/make) dakingun gmail com gpp-0.6.6-3.fc6 (build/make) Matt_Domsch dell com gpsim-0.22.0-4.fc8 (build/make) aportal univ-montp2 fr,alain.portal free fr grhino-0.16.0-1.fc7 (build/make) michel.salim gmail com grub-0.97-19 (build/make) pjones redhat com gstm-1.2-6.fc7 (build/make) splinux fedoraproject org gtk-sharp-1.0.10-12.fc7 (build/make) paul all-the-johnsons co uk gtranslator-1.1.7-3.fc8 (build/make) foolish guezz net gwenhywfar-2.6.0-1.fc8 (open_missing_mode) notting redhat com gwget-0.99-2.fc8 (build/make) fedora christoph-wickert de htop-0.6.5-1.fc7 (build/make) gajownik gmail com httpunit-1.6.2-1jpp.1.fc7 (build/make) mwringe redhat com inn-2.4.3-6.fc6 (build/make) jkeating redhat com isdn4k-utils-3.2-54.fc7 (build/make) than redhat com jgroups-2.2.9.2-3jpp.2 (build/make) vivekl redhat com jogl-1.0.0-5.7.beta5.fc6 (build/make) green redhat com kadu-0.5.0-4.fc8 (build/make) mr.ecik gmail com kawa-1.9.0-2.fc7 (build/make) green redhat com kbibtex-0.1.5.52-10.fc7 (build/make) ch.nolte noltec org kdeutils-3.5.7-5.fc8 (open_missing_mode) than redhat com,rdieter math unl edu kdissert-1.0.7-1.fc7 (build/make) icon fedoraproject org kgtk-0.8-2.fc7 (open_missing_mode) faucamp csir co za knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) dennis ausil us kudzu-1.2.74-1 (build/make) notting redhat com ladspa-1.12-8.fc7 (build/make) thomas apestaart org ldapjdk-4.17-1jpp.7 (build/make) vivekl redhat com libapreq2-2.09-0.rc2.7.fc8 (build/make) bojan rexursive com libgdiplus-1.2.4-1.fc8 (build/make) alexl redhat com libprelude-0.9.13-1.fc7 (build/make) tscherf redhat com libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf redhat com liferea-1.2.23-1.fc8 (build/make) bdpepple ameritech net lilypond-doc-2.10.13-1.fc7 (build/make) qspencer ieee org lockdev-1.0.1-11.fc7 (build/make) kzak redhat com logrotate-3.7.6-1.1.fc8 (build/make) tsmetana redhat com maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe redhat com mbuffer-20070502-1.fc7 (open_missing_mode) alex dalloz de memtest86+-1.70-1.fc7 (buildroot) wtogami redhat com mikmod-3.2.2-2.fc7 (build/make) jnovy redhat com Miro-0.9.8.1-2.fc7 (buildroot) tscherf redhat com mod_perl-2.0.3-14 (build/make) jorton redhat com monotone-0.36-2.fc8 (build/make) roland redhat com moto4lin-0.3-6.fc7 (build/make) jafo-redhat tummy com muine-0.8.7-3.fc7 (build/make) foolish guezz net mx4j-3.0.1-6jpp.4 (build/make) fnasser redhat com mysql-5.0.45-4.fc8 (build/make) tgl redhat com nagios-2.9-3.fc8 (build/make) mmcgrath redhat com nant-0.85-12.fc7 (build/make) paul all-the-johnsons co uk nemiver-0.4.0-1.fc8 (build/make) peter thecodergeek com nessus-core-2.2.9-2.fc7 (open_missing_mode) andreas.bierfert lowlatency de nkf-2.07-3.fc8 (build/make) tagoh redhat com notification-daemon-0.3.7-4.fc8 (build/make) davidz redhat com ntfs-config-1.0-0.4.rc5.fc8 (build/make) lxtnow gmail com ocsinventory-client-1.01-5.fc7 (build/make) Fedora FamilleCollet com octave-forge-2006.07.09-9.fc7 (build/make) qspencer ieee org openais-0.80.1-6 (open_missing_mode) jkeating redhat com openalpp-20060714-3.fc7 (build/make) chris.stone gmail com OpenIPMI-2.0.11-2.fc8 (needs_popt-devel) pknirsch redhat com openmpi-1.2.3-4.fc8 (open_missing_mode) dledford redhat com,jvdias redhat com openvpn-2.1-0.19.rc4.fc7 (build/make) steve silug org oprofile-0.9.3-3.fc8 (build/make) wcohen redhat com orpie-1.4.3-5.fc6 (build/make) lists forevermore net osgal-20060903-3.fc7 (buildroot) chris.stone gmail com osgcal-0.1.44-4.fc7 (build/make) chris.stone gmail com pam_abl-0.2.3-3.fc7 (build/make) alex dalloz de pari-2.3.0-5.fc7 (build/make) gemi bluewin ch passwd-0.74-4.fc8 (build/make) tmraz redhat com pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) sdl.web gmail com perl-5.8.8-25.fc8 (build/make) rnorwood redhat com,rc040203 freenet de,tcallawa redhat com perl-AnyData-0.10-4.fc8 (build/make) tcallawa redhat com perl-Apache-DBI-1.06-1.fc7 (build/make) Fedora FamilleCollet com perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve silug org perl-Authen-SASL-2.10-1.fc6 (build/make) jpo di uminho pt perl-bioperl-1.5.2_102-8.fc8 (build/make) alexl users sourceforge net perl-Boulder-1.30-3.fc6 (build/make) orion cora nwra com perl-Cache-2.04-2.fc6 (build/make) pertusus free fr perl-Cache-Cache-1.05-1.fc6 (build/make) jpo di uminho pt perl-Cache-Mmap-0.09-2.fc7 (build/make) steve silug org perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl alumni drew edu perl-CGI-Session-4.20-2.fc7 (build/make) andreas bawue net perl-CGI-Simple-0.077-7.fc8 (build/make) tcallawa redhat com perl-Chatbot-Eliza-1.04-3.fc7 (build/make) cweyl alumni drew edu perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl alumni drew edu perl-Class-InsideOut-1.06-1.fc7 (build/make) cweyl alumni drew edu perl-Class-MakeMethods-1.01-2.fc6 (build/make) cweyl alumni drew edu perl-Class-MethodMaker-2.08-4.fc6 (build/make) dgregor redhat com perl-Class-Observable-1.04-2.fc7 (build/make) andreas bawue net perl-Class-Std-0.0.8-1.fc7 (build/make) andreas bawue net perl-Compress-Bzip2-2.09-4.fc6 (build/make) jpo di uminho pt perl-Config-IniFiles-2.39-5.fc6 (build/make) jpo di uminho pt perl-Config-Record-1.1.1-3.fc6 (build/make) dgregor redhat com perl-Convert-ASN1-0.21-2.fc8 (build/make) rnorwood redhat com perl-Crypt-Blowfish-2.10-2.fc6 (build/make) andreas bawue net perl-Crypt-CBC-2.22-1.fc7 (build/make) andreas bawue net perl-Crypt-PasswdMD5-1.3-2.fc7 (build/make) mmcgrath redhat com perl-Data-Compare-0.16-1.fc7 (build/make) jpo di uminho pt perl-Data-HexDump-0.02-3.fc6 (build/make) andreas bawue net perl-Data-Password-1.07-1.fc7 (build/make) andreas bawue net perl-Date-Calc-5.4-2 (build/make) rnorwood redhat com perl-Date-Pcalc-1.2-4.fc6 (build/make) mmcgrath redhat com perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve silug org perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve silug org perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve silug org perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl alumni drew edu perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve silug org perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve silug org perl-DateTime-Set-0.25-4.fc7 (build/make) steve silug org perl-DBD-CSV-0.22-5.fc6 (build/make) jpo di uminho pt perl-DBD-MySQL-4.005-2.fc8 (build/make) rnorwood redhat com perl-DBD-Pg-1.49-5.fc8 (build/make) rnorwood redhat com perl-DBD-SQLite-1.12-2.fc6 (build/make) jpo di uminho pt perl-DBD-SQLite2-0.33-7.fc8.1 (buildroot) tcallawa redhat com perl-DBD-XBase-0.241-5.fc6 (build/make) jpo di uminho pt perl-Devel-Caller-0.11-1.fc7 (build/make) steve silug org perl-Devel-Cover-0.61-1.fc7 (build/make) jpo di uminho pt perl-Devel-Cycle-1.07-1.fc6 (build/make) jpo di uminho pt perl-Digest-MD4-1.5-3.fc6 (build/make) jpo di uminho pt perl-Digest-Nilsimsa-0.06-8.fc8 (build/make) wtogami redhat com perl-Exception-Class-1.23-3.fc7 (build/make) steve silug org perl-Expect-1.20-1.fc6 (build/make) jpo di uminho pt perl-Expect-Simple-0.02-1.fc6 (build/make) jpo di uminho pt perl-ExtUtils-CBuilder-0.19-1.fc8 (build/make) jpo di uminho pt perl-ExtUtils-Depends-0.205-5.fc6 (build/make) jpo di uminho pt perl-ExtUtils-ParseXS-2.18-1.fc7 (build/make) jpo di uminho pt perl-ExtUtils-PkgConfig-1.07-5.fc6 (build/make) jpo di uminho pt perl-ExtUtils-XSBuilder-0.28-2.fc6 (build/make) tcallawa redhat com perl-Feed-Find-0.06-2.fc6 (build/make) pertusus free fr perl-File-BaseDir-0.02-1.fc6 (build/make) pertusus free fr perl-File-DesktopEntry-0.02-1.fc6 (build/make) pertusus free fr perl-File-Find-Rule-0.30-3.fc7 (build/make) rc040203 freenet de,lxtnow gmail com perl-File-NFSLock-1.20-2.fc6 (build/make) pertusus free fr perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve silug org perl-File-RsyncP-0.68-2.fc8 (build/make) mmcgrath redhat com perl-File-Tail-0.99.3-5.fc6 (build/make) jpo di uminho pt perl-File-Type-0.22-4.fc7 (build/make) steve silug org perl-File-Which-0.05-2.fc7 (build/make) jpo di uminho pt perl-Finance-Quote-1.13-1.fc7 (build/make) notting redhat com perl-Finance-YahooQuote-0.21-2.fc7 (build/make) wtogami redhat com perl-FreezeThaw-0.43-5.fc6 (build/make) jpo di uminho pt perl-GD-2.35-2.fc6 (build/make) jpo di uminho pt perl-GDGraph-1.44-2.fc8 (build/make) jpo di uminho pt perl-GDGraph3d-0.63-7.fc8 (build/make) jpo di uminho pt perl-GDTextUtil-0.86-8.fc6 (build/make) jpo di uminho pt perl-Geo-Constants-0.06-1.fc7 (build/make) jpo di uminho pt perl-Geo-Ellipsoids-0.14-1.fc7 (build/make) jpo di uminho pt perl-Geo-Forward-0.11-1.fc7 (build/make) jpo di uminho pt perl-Geo-Functions-0.06-1.fc7 (build/make) jpo di uminho pt perl-Geo-Inverse-0.05-1.fc7 (build/make) jpo di uminho pt perl-Glib-1.144-1.fc7 (build/make) jpo di uminho pt perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl alumni drew edu perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl alumni drew edu perl-GPS-0.15-1.fc7 (build/make) jpo di uminho pt perl-GPS-PRN-0.05-1.fc7 (build/make) jpo di uminho pt perl-Hook-LexWrap-0.20-4.fc6 (build/make) jpo di uminho pt perl-HTML-Scrubber-0.08-4.fc6 (build/make) jpo di uminho pt perl-HTML-Table-2.04a-1.fc7 (build/make) orion cora nwra com perl-HTML-Template-2.9-1.fc7 (build/make) jpo di uminho pt perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve silug org perl-HTTP-Proxy-0.20-1.fc6 (build/make) jpo di uminho pt perl-HTTP-Request-Params-1.01-1.fc6 (build/make) jpo di uminho pt perl-HTTP-Server-Simple-0.27-1.fc7 (build/make) jpo di uminho pt perl-HTTP-Server-Simple-Mason-0.09-6.fc8 (build/make) rc040203 freenet de,lxtnow gmail com perl-Image-Base-1.07-7.fc6 (build/make) jpo di uminho pt perl-Image-Xbm-1.08-6.fc6 (build/make) jpo di uminho pt perl-Image-Xpm-1.09-6.fc6 (build/make) jpo di uminho pt perl-Inline-0.44-15.2.1 (build/make) rnorwood redhat com perl-IO-All-0.38-1.fc7 (build/make) steve silug org perl-IO-Capture-0.05-2.fc7 (build/make) jpo di uminho pt perl-IO-Interface-1.03-1.fc7 (build/make) jpo di uminho pt perl-IO-Multiplex-1.08-5.fc6 (build/make) lmb biosci ki se perl-IO-Socket-INET6-2.51-2.fc6 (build/make) wtogami redhat com perl-IO-Socket-SSL-1.02-1.fc7 (build/make) wtogami redhat com,jpo di uminho pt perl-IO-String-1.08-1.1.1 (build/make) rnorwood redhat com,jpo di uminho pt perl-IO-Tty-1.07-2.fc6 (build/make) jpo di uminho pt perl-IO-Zlib-1.04-4.2.1 (build/make) rnorwood redhat com,jpo di uminho pt perl-IPC-Cmd-0.36-2.fc7 (build/make) steve silug org perl-IPC-SharedCache-1.3-7.fc6 (build/make) jpo di uminho pt perl-Kwiki-0.39-1.fc7 (build/make) steve silug org perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve silug org perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve silug org perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve silug org perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve silug org perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve silug org perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve silug org perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve silug org perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve silug org perl-Kwiki-Search-0.12-5.fc7 (build/make) steve silug org perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve silug org perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve silug org perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve silug org perl-libxml-perl-0.08-1.2.1 (build/make) rnorwood redhat com perl-List-Compare-0.33-2.fc6 (build/make) cweyl alumni drew edu perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (build/make) jpo di uminho pt perl-Log-Dispatch-Config-1.01-2.fc6 (build/make) cweyl alumni drew edu perl-Log-Dispatch-FileRotate-1.16-1.fc7 (build/make) jpo di uminho pt perl-Log-Log4perl-1.11-1.fc8 (build/make) jpo di uminho pt perl-Log-Message-0.01-3.fc7 (build/make) steve silug org perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve silug org perl-LWP-Authen-Wsse-0.05-2.fc6 (build/make) pertusus free fr perl-Mail-Sender-0.8.13-2.fc6 (build/make) jpo di uminho pt perl-Mail-Sendmail-0.79-9.fc6 (build/make) jpo di uminho pt perl-MasonX-Interp-WithCallbacks-1.17-1.fc8 (build/make) steve silug org perl-Math-Round-0.06-1.fc7 (build/make) cweyl alumni drew edu perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh farsiweb info perl-MD5-2.03-1.fc7 (build/make) andreas bawue net perl-MIME-Lite-3.01-5.fc6 (build/make) mmcgrath redhat com perl-MLDBM-2.01-5.fc6 (build/make) jpo di uminho pt perl-Module-Build-0.2808-1.fc8 (build/make) steve silug org perl-Module-Install-0.67-1.fc8 (build/make) steve silug org perl-Module-Load-0.10-3.fc7 (build/make) steve silug org perl-Module-Loaded-0.01-3.fc7 (build/make) steve silug org perl-Module-Locate-1.7-1.fc6 (build/make) jpo di uminho pt perl-Module-Pluggable-3.60-1.fc7 (build/make) steve silug org perl-Module-Versions-Report-1.03-1.fc8 (build/make) jpo di uminho pt perl-Mozilla-LDAP-1.5.2-2.fc8 (build/make) rmeggins redhat com perl-NetAddr-IP-4.004-4.fc8 (build/make) andreas bawue net perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl alumni drew edu perl-Net-GPSD-0.35-1.fc7 (build/make) jpo di uminho pt perl-Net-Jabber-2.0-7.fc6 (build/make) cweyl alumni drew edu perl-Net-Netmask-1.9012-3.fc6 (build/make) wtogami redhat com perl-Net-Patricia-1.014-4.fc8 (build/make) orion cora nwra com perl-Net-Server-0.97-1.fc8 (buildroot) nicolas.mailhot laposte net perl-Net-SNMP-5.2.0-1.fc6 (build/make) jpo di uminho pt perl-Net-SNPP-1.17-2.fc7 (build/make) jeff ocjtech us perl-Net-SSLeay-1.30-5.fc8 (build/make) wtogami redhat com,jpo di uminho pt perl-Net-Telnet-3.03-5 (build/make) jkeating redhat com perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl alumni drew edu perl-Object-Accessor-0.32-2.fc7 (build/make) steve silug org perl-OpenFrame-3.05-6.fc7 (build/make) steve silug org perl-Package-Constants-0.01-3.fc7 (build/make) steve silug org perl-PadWalker-1.5-1.fc7 (build/make) jpo di uminho pt perl-Params-Check-0.26-1.fc7 (build/make) steve silug org perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve silug org perl-Parse-RecDescent-1.94-6.fc8 (build/make) rnorwood redhat com perl-Parse-Yapp-1.05-36.fc6 (build/make) pertusus free fr perl-PatchReader-0.9.5-4.fc6 (build/make) stickster gmail com perl-PBS-0.31-3.fc6 (build/make) garrick usc edu perl-Perl6-Bible-0.30-3.fc7 (build/make) steve silug org perl-Pipeline-3.12-4.fc7 (build/make) steve silug org perl-pmtools-1.01-2.fc6 (build/make) jpo di uminho pt perl-Pod-Escapes-1.04-5.fc6 (build/make) jpo di uminho pt perl-Pod-Simple-3.05-1.fc8 (build/make) jpo di uminho pt perl-Pod-Spell-1.01-2.fc7 (build/make) jpo di uminho pt perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl alumni drew edu perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Server-SimpleHTTP-1.23-2.fc7 (build/make) cweyl alumni drew edu perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl alumni drew edu perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl alumni drew edu perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl alumni drew edu perl-PPI-Tester-0.06-2.fc6 (build/make) jpo di uminho pt perl-Proc-Daemon-0.03-1.fc7.1 (build/make) Fedora FamilleCollet com perl-Readonly-1.03-6.fc6 (build/make) cweyl alumni drew edu perl-Readonly-XS-1.04-7.fc6 (build/make) cweyl alumni drew edu perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl alumni drew edu perl-Scalar-Properties-0.12-1.fc6 (build/make) jpo di uminho pt perl-Set-Infinite-0.61-3.fc7 (build/make) steve silug org perl-Set-Scalar-1.20-1.fc7 (build/make) jpo di uminho pt perl-SNMP_Session-1.08-3.fc6 (build/make) jpo di uminho pt perl-SOAP-Lite-0.68-2.fc6 (build/make) mmcgrath redhat com perl-Socket6-0.19-4.fc8 (build/make) wtogami redhat com,jpo di uminho pt perl-Spiffy-0.30-7.fc7 (build/make) steve silug org perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve silug org perl-SQL-Library-0.0.3-2.fc6 (build/make) cweyl alumni drew edu perl-SQL-Statement-1.15-2.fc6 (build/make) jpo di uminho pt perl-Statistics-Descriptive-2.6-2.fc6 (build/make) pertusus free fr perl-String-Format-1.14-1.fc6 (build/make) jpo di uminho pt perl-Sub-Identify-0.02-2.fc7 (build/make) cweyl alumni drew edu perl-Sub-Name-0.02-3.fc8 (build/make) cweyl alumni drew edu perl-SUPER-1.16-1.fc7 (build/make) cweyl alumni drew edu perl-SVG-2.34-2.fc8 (build/make) alexl users sourceforge net perl-Sys-SigAction-0.10-1.fc7 (build/make) andreas bawue net perl-TermReadKey-2.30-1.2.2.1 (build/make) rnorwood redhat com perl-Term-UI-0.14-2.fc7 (build/make) steve silug org perl-Test-Cmd-1.05-1.fc6 (build/make) jpo di uminho pt perl-Test-Differences-0.47-2.fc6 (build/make) jpo di uminho pt perl-Test-Expect-0.30-1.fc6 (build/make) jpo di uminho pt perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve silug org perl-Test-WWW-Mechanize-1.14-1.fc8 (build/make) jpo di uminho pt perl-TeX-Hyphen-0.140-5.fc6 (build/make) jpo di uminho pt perl-Text-CharWidth-0.04-2.fc7 (build/make) Axel.Thimm ATrpms net perl-Text-CHM-0.01-2.fc6 (build/make) pertusus free fr perl-Text-Kakasi-2.04-5.fc8 (build/make) tagoh redhat com perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve silug org perl-Text-Shellwords-1.08-2.fc8 (build/make) alexl users sourceforge net perl-Text-Template-1.44-4.fc6 (build/make) jpo di uminho pt perl-Text-Tree-1.0-2.fc7 (build/make) cweyl alumni drew edu perl-Text-Unidecode-0.04-4.fc6 (build/make) pertusus free fr perl-Text-WrapI18N-0.06-2.fc7 (build/make) Axel.Thimm ATrpms net perl-Tie-IxHash-1.21-6.fc6 (build/make) jpo di uminho pt perl-Time-modules-2003.1126-4.fc6 (build/make) kaboom oobleck net perl-Time-Period-1.20-1.fc6 (build/make) robert marcanoonline com perl-Time-Piece-1.09-2.fc6 (build/make) chris chrisgrau com perl-Tk-804.027-12.fc8 (build/make) andreas.bierfert lowlatency de perl-Tree-DAG_Node-1.05-4.fc6 (build/make) jpo di uminho pt perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo di uminho pt perl-URI-1.35-3 (build/make) rnorwood redhat com perl-WWW-Babelfish-0.16-1.fc7 (build/make) cweyl alumni drew edu perl-WWW-Bugzilla-0.9-1.fc7 (build/make) jpo di uminho pt perl-XML-DOM-1.44-2.fc6 (build/make) orion cora nwra com perl-XML-Dumper-0.81-2.fc6 (build/make) rnorwood redhat com perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) andreas bawue net perl-XML-Grove-0.46alpha-29.1.1 (build/make) rnorwood redhat com perl-XML-LibXML-1.62001-2.fc7 (build/make) rnorwood redhat com perl-XML-LibXML-Common-0.13-8.2.2 (build/make) rnorwood redhat com perl-XML-NamespaceSupport-1.09-2.fc8 (build/make) rnorwood redhat com perl-XML-RegExp-0.03-2.fc6 (build/make) orion cora nwra com perl-XML-SAX-Writer-0.50-2.fc7 (build/make) andreas bawue net perl-XML-Stream-1.22-6.fc6 (build/make) cweyl alumni drew edu perl-XML-Validator-Schema-1.08-1.fc7 (build/make) andreas bawue net perl-XML-XPath-1.13-4.fc6 (build/make) rnorwood redhat com perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve silug org pexpect-2.1-5.fc8 (build/make) toshio tiki-lounge com plexus-xmlrpc-1.0-0.1.b4.3jpp.6.fc8 (build/make) dbhole redhat com polyxmass-bin-0.9.3-2.fc6 (build/make) andreas.bierfert lowlatency de postgresql-8.2.5-1.fc8 (build/make) tgl redhat com ppc64-utils-0.12-1.fc8 (buildroot) pnasrat redhat com ppl-0.9-14.fc8 (build/make) bagnara cs unipr it prelink-0.3.10-1 (build/make) jakub redhat com prewikka-0.9.8-1.fc7 (build/make) tscherf redhat com pulseaudio-0.9.7-0.11.svn20070907.fc8 (build/make) lpoetter redhat com,drzeus-bugzilla drzeus cx python-boto-0.9b-1.fc8 (build/make) python-cheetah-2.0-0.7.rc8.fc8 (build/make) mikeb redhat com python-docs-2.5.1-1.fc8 (build/make) james.antill redhat com python-psyco-1.5.1-5.fc7 (buildroot) shahms shahms com python-reportlab-2.1-1.fc8 (build/make) bdpepple ameritech net python-urljr-1.0.1-1.fc7 (build/make) jeff ocjtech us python-vobject-0.4.8-1.fc8 (build/make) jbowes redhat com,dgoodwin dangerouslyinc com qa-assistant-0.4.90.5-2.fc6 (build/make) toshio tiki-lounge com qpidc-0.2-5.fc7 (build/make) aconway redhat com,meyering redhat com,nsantos redhat com quarry-0.2.0-1.fc7 (build/make) michel.salim gmail com rekall-2.4.5-6.fc8.1 (build/make) tcallawa redhat com renrot-0.25-2.fc7 (build/make) andy smile org ua rhm-0.1-3.fc7 (build/make) aconway redhat com,nsantos redhat com ruby-activerecord-1.15.1-1.fc7 (build/make) dlutter redhat com ruby-bdb-0.6.0-1.fc7 (build/make) miker5slow grandecom net rxvt-unicode-8.3-1.fc8 (build/make) andreas.bierfert lowlatency de s3switch-0.0-9.20020912.fc6 (buildroot) paul xelerance com seahorse-1.0.1-9.fc8 (build/make) skvidal linux duke edu shapelib-1.2.10-12.20060304cvs (build/make) mccann0011 hotmail com slrn-0.9.8.1pl1-3.20070716cvs.fc8 (build/make) mlichvar redhat com struts-1.2.9-4jpp.6 (build/make) dbhole redhat com swatch-3.2.1-1.fc6 (build/make) jpo di uminho pt sword-1.5.9-6.fc8 (open_missing_mode) dakingun gmail com synce-software-manager-0.9.0-7.fc6 (build/make) andreas.bierfert lowlatency de synce-trayicon-0.9.0-8.fc6 (build/make) andreas.bierfert lowlatency de syslinux-3.36-5.fc8 (buildroot) pjones redhat com syslog-ng-2.0.5-1.fc8 (build/make) jpo di uminho pt,pvrabec redhat com sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu gmail com tclabc-1.0.9-1.fc7 (build/make) gemi bluewin ch tclparser-1.4-2.20061030cvs.fc8 (build/make) wart kobold org tetex-3.0-41.fc8 (build/make) jnovy redhat com tinyerp-4.0.3-1.fc7 (build/make) dan danny cz udunits-1.12.4-11.fc8.2 (build/make) tcallawa redhat com unison-2.13.16-3.fc6 (build/make) gemi bluewin ch util-vserver-0.30.214-2.fc8 (build/make) enrico.scholz informatik tu-chemnitz de valgrind-3.2.3-6 (buildroot) jakub redhat com velocity-1.4-6jpp.1 (build/make) vivekl redhat com vkeybd-0.1.17a-3.fc7 (build/make) green redhat com xaos-3.2.3-1.fc7 (build/make) gemi bluewin ch xdaliclock-2.23-3.fc6 (build/make) kaboom oobleck net xen-3.1.0-6.fc8 (buildroot) riel redhat com xferstats-2.16-14.1 (build/make) than redhat com xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser redhat com xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung redhat com xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint redhat com xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint redhat com xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint redhat com xsri-2.1.0-12.fc8 (build/make) sandmann redhat com zaptel-1.4.2.1-1.fc7 (open_missing_mode) jeff ocjtech us With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Tue Sep 25 21:07:13 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 25 Sep 2007 16:07:13 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 Message-ID: <20070925160713.A13101@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 Tue Sep 25 15:44:42 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 4740 Number failed to build: 443 Number expected to fail due to ExclusiveArch or ExcludeArch: 10 Leaving: 433 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 433 ---------------------------------- adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung redhat com airsnort-0.2.7e-11.fc7 (build/make) andreas.bierfert lowlatency de akode-2.0.1-8.fc8 (buildroot) rdieter math unl edu amsn-0.96-7.fc7 (build/make) sander hoentjen eu apt-0.5.15lorg3.93-2.fc8 (build/make) Axel.Thimm ATrpms net athcool-0.3.11-5.fc6 (build/make) gajownik gmail com avr-binutils-2.17-4.fc8 (build/make) j.w.r.degoede hhs nl awesfx-0.5.0d-4.fc7 (build/make) stransky redhat com azureus-2.5.0.4-2.fc7 (build/make) green redhat com bes-3.5.1-3.fc8 (build/make) pertusus free fr callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2 redhat com castor-0.9.5-1jpp.7 (build/make) pcheung redhat com centericq-4.21.0-14.fc8 (build/make) andreas.bierfert lowlatency de checkstyle-4.1-4jpp.1.fc7 (buildroot) nsantos redhat com chkfontpath-1.10.1-2.fc8 (build/make) krh redhat com clips-6.24-22.fc7 (build/make) rvinyard cs nmsu edu clisp-2.41-3.fc7 (build/make) gemi bluewin ch compat-erlang-R10B-10.7.fc7 (build/make) gemi bluewin ch compat-gcc-296-2.96-138 (build/make) jakub redhat com compat-gcc-32-3.2.3-61 (build/make) jakub redhat com compat-gcc-34-3.4.6-7 (build/make) jakub redhat com compiz-fusion-0.5.2-6.fc8.src.rpm compiz-fusion-extras-0.5.2-5.fc8.src.rpm conexus-0.5.3-2.fc8 (build/make) rvinyard cs nmsu edu cpan2rpm-2.028-2.fc6 (build/make) ghenry suretecsystems com cryptix-3.2.0-9jpp.1 (build/make) mwringe redhat com cryptix-asn1-20011119-7jpp.2 (build/make) vivekl redhat com cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones redhat com,opensource till name d4x-2.5.7.1-3.fc7 (build/make) matthias rpmforge net digikamimageplugins-0.9.1-1.fc7 (build/make) rdieter math unl edu eclipse-3.3.0-20.fc8 (build/make) bkonrath redhat com eclipse-emf-2.2.2-1.fc7 (build/make) overholt redhat com eclipse-mylar-2.0-0.1.M2a.1.fc7 (build/make) overholt redhat com eclipse-mylyn-2.0.0-9.fc8 (build/make) eiciel-0.9.4-1.fc7 (build/make) cweyl alumni drew edu em8300-kmod-0.16.3-5.2.6.23_0.187.rc6.git7.fc8 (buildroot) ville.skytta iki fi emelfm2-0.3.5-2.fc8 (build/make) fedora christoph-wickert de evolution-remove-duplicates-0.0.2-6.fc7 (build/make) michel.salim gmail com fakechroot-2.5-12.fc7 (build/make) Axel.Thimm ATrpms net fluxstyle-1.0.1-2.fc7 (build/make) miker5slow grandecom net fontypython-0.2.0-6.fc7 (build/make) cr33dog gmail com freetennis-0.4.8-6.fc7 (build/make) dev nigelj com gai-0.5.10-10.fc7 (build/make) michel.salim gmail com gajim-0.11.1-1.fc7 (buildroot) gajownik gmail com gambas-1.0.19-1.fc8.2 (buildroot) tcallawa redhat com gauche-0.8.11-2.fc8 (build/make) gemi bluewin ch gdb-6.6-27.fc8.src.rpm gdmap-0.7.5-6.fc6 (build/make) splinux fedoraproject org gedit-plugins-2.18.0-2.fc7 (build/make) trond.danielsen gmail com genius-0.7.7-2.fc7 (build/make) gemi bluewin ch gfa-0.4.1-4.fc7 (build/make) splinux25 gmail com ghdl-0.25-0.89svn.5.fc8 (build/make) t.sailer alumni ethz ch giggle-0.3-4.fc8 (build/make) jbowes redhat com glipper-0.95.1-2.fc7 (build/make) splinux fedoraproject org gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak redhat com gnome-pilot-2.0.15-5.fc7 (build/make) mbarnes redhat com gnomescan-0.4.0.2-1.fc7 (build/make) dakingun gmail com gnomesword-2.2.3-5.fc8 (build/make) dakingun gmail com gpp-0.6.6-3.fc6 (build/make) Matt_Domsch dell com gpsim-0.22.0-4.fc8 (build/make) aportal univ-montp2 fr,alain.portal free fr grhino-0.16.0-1.fc7 (build/make) michel.salim gmail com gstm-1.2-6.fc7 (build/make) splinux fedoraproject org gtk-sharp-1.0.10-12.fc7 (build/make) paul all-the-johnsons co uk gtranslator-1.1.7-3.fc8 (build/make) foolish guezz net gwenhywfar-2.6.0-1.fc8 (open_missing_mode) notting redhat com gwget-0.99-2.fc8 (build/make) fedora christoph-wickert de htop-0.6.5-1.fc7 (build/make) gajownik gmail com httpunit-1.6.2-1jpp.1.fc7 (build/make) mwringe redhat com inn-2.4.3-6.fc6 (build/make) jkeating redhat com isdn4k-utils-3.2-54.fc7 (build/make) than redhat com jgroups-2.2.9.2-3jpp.2 (build/make) vivekl redhat com jogl-1.0.0-5.7.beta5.fc6 (build/make) green redhat com kadu-0.5.0-4.fc8 (build/make) mr.ecik gmail com kawa-1.9.0-2.fc7 (build/make) green redhat com kbibtex-0.1.5.52-10.fc7 (build/make) ch.nolte noltec org kdeutils-3.5.7-5.fc8 (open_missing_mode) than redhat com,rdieter math unl edu kdissert-1.0.7-1.fc7 (build/make) icon fedoraproject org kernel-2.6.23-0.193.rc7.git1.fc8.src.rpm kgtk-0.8-2.fc7 (open_missing_mode) faucamp csir co za knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) dennis ausil us kudzu-1.2.74-1 (build/make) notting redhat com ladspa-1.12-8.fc7 (build/make) thomas apestaart org ldapjdk-4.17-1jpp.7 (build/make) vivekl redhat com libapreq2-2.09-0.rc2.7.fc8 (build/make) bojan rexursive com libgdiplus-1.2.4-1.fc8 (build/make) alexl redhat com libprelude-0.9.13-1.fc7 (build/make) tscherf redhat com libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf redhat com liferea-1.2.23-1.fc8 (build/make) bdpepple ameritech net lilypond-doc-2.10.13-1.fc7 (build/make) qspencer ieee org lockdev-1.0.1-11.fc7 (build/make) kzak redhat com logrotate-3.7.6-1.1.fc8 (build/make) tsmetana redhat com maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe redhat com mbuffer-20070502-1.fc7 (open_missing_mode) alex dalloz de mercurial-0.9.4-7.fc8.src.rpm mikmod-3.2.2-2.fc7 (build/make) jnovy redhat com Miro-0.9.8.1-2.fc7 (buildroot) tscherf redhat com mod_perl-2.0.3-14 (build/make) jorton redhat com monotone-0.36-2.fc8 (build/make) roland redhat com mosml-2.01-9.fc7 (build/make) gemi bluewin ch moto4lin-0.3-6.fc7 (build/make) jafo-redhat tummy com muine-0.8.7-3.fc7 (build/make) foolish guezz net mx4j-3.0.1-6jpp.4 (build/make) fnasser redhat com mysql-5.0.45-4.fc8 (build/make) tgl redhat com nagios-2.9-3.fc8 (build/make) mmcgrath redhat com nant-0.85-12.fc7 (build/make) paul all-the-johnsons co uk nco-3.9.1-1.fc8 (build/make) ed eh3 com nemiver-0.4.0-1.fc8 (build/make) peter thecodergeek com nessus-core-2.2.9-2.fc7 (open_missing_mode) andreas.bierfert lowlatency de nkf-2.07-3.fc8 (build/make) tagoh redhat com notification-daemon-0.3.7-4.fc8 (build/make) davidz redhat com ocsinventory-client-1.01-5.fc7 (build/make) Fedora FamilleCollet com octave-forge-2006.07.09-9.fc7 (build/make) qspencer ieee org openais-0.80.1-6 (open_missing_mode) jkeating redhat com openalpp-20060714-3.fc7 (build/make) chris.stone gmail com OpenIPMI-2.0.11-2.fc8 (needs_popt-devel) pknirsch redhat com openmpi-1.2.3-4.fc8 (open_missing_mode) dledford redhat com,jvdias redhat com openvpn-2.1-0.19.rc4.fc7 (build/make) steve silug org oprofile-0.9.3-3.fc8 (build/make) wcohen redhat com orpie-1.4.3-5.fc6 (build/make) lists forevermore net osgal-20060903-3.fc7 (buildroot) chris.stone gmail com osgcal-0.1.44-4.fc7 (build/make) chris.stone gmail com pam_abl-0.2.3-3.fc7 (build/make) alex dalloz de pari-2.3.0-5.fc7 (build/make) gemi bluewin ch passwd-0.74-4.fc8 (build/make) tmraz redhat com pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) sdl.web gmail com perl-5.8.8-25.fc8 (build/make) rnorwood redhat com,rc040203 freenet de,tcallawa redhat com perl-AnyData-0.10-4.fc8 (build/make) tcallawa redhat com perl-Apache-DBI-1.06-1.fc7 (build/make) Fedora FamilleCollet com perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve silug org perl-Authen-SASL-2.10-1.fc6 (build/make) jpo di uminho pt perl-bioperl-1.5.2_102-8.fc8 (build/make) alexl users sourceforge net perl-Boulder-1.30-3.fc6 (build/make) orion cora nwra com perl-Cache-2.04-2.fc6 (build/make) pertusus free fr perl-Cache-Cache-1.05-1.fc6 (build/make) jpo di uminho pt perl-Cache-Mmap-0.09-2.fc7 (build/make) steve silug org perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl alumni drew edu perl-CGI-Session-4.20-2.fc7 (build/make) andreas bawue net perl-CGI-Simple-0.077-7.fc8 (build/make) tcallawa redhat com perl-Chatbot-Eliza-1.04-3.fc7 (build/make) cweyl alumni drew edu perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl alumni drew edu perl-Class-InsideOut-1.06-1.fc7 (build/make) cweyl alumni drew edu perl-Class-MakeMethods-1.01-2.fc6 (build/make) cweyl alumni drew edu perl-Class-MethodMaker-2.08-4.fc6 (build/make) dgregor redhat com perl-Class-Observable-1.04-2.fc7 (build/make) andreas bawue net perl-Class-Std-0.0.8-1.fc7 (build/make) andreas bawue net perl-Compress-Bzip2-2.09-4.fc6 (build/make) jpo di uminho pt perl-Config-IniFiles-2.39-5.fc6 (build/make) jpo di uminho pt perl-Config-Record-1.1.1-3.fc6 (build/make) dgregor redhat com perl-Convert-ASN1-0.21-2.fc8 (build/make) rnorwood redhat com perl-Crypt-Blowfish-2.10-2.fc6 (build/make) andreas bawue net perl-Crypt-CBC-2.22-1.fc7 (build/make) andreas bawue net perl-Crypt-PasswdMD5-1.3-2.fc7 (build/make) mmcgrath redhat com perl-Data-Compare-0.16-1.fc7 (build/make) jpo di uminho pt perl-Data-HexDump-0.02-3.fc6 (build/make) andreas bawue net perl-Data-Password-1.07-1.fc7 (build/make) andreas bawue net perl-Date-Calc-5.4-2 (build/make) rnorwood redhat com perl-Date-Pcalc-1.2-4.fc6 (build/make) mmcgrath redhat com perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve silug org perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve silug org perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve silug org perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl alumni drew edu perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve silug org perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve silug org perl-DateTime-Set-0.25-4.fc7 (build/make) steve silug org perl-DBD-CSV-0.22-5.fc6 (build/make) jpo di uminho pt perl-DBD-MySQL-4.005-2.fc8 (build/make) rnorwood redhat com perl-DBD-Pg-1.49-5.fc8 (build/make) rnorwood redhat com perl-DBD-SQLite-1.12-2.fc6 (build/make) jpo di uminho pt perl-DBD-SQLite2-0.33-7.fc8.1 (buildroot) tcallawa redhat com perl-DBD-XBase-0.241-5.fc6 (build/make) jpo di uminho pt perl-Devel-Caller-0.11-1.fc7 (build/make) steve silug org perl-Devel-Cover-0.61-1.fc7 (build/make) jpo di uminho pt perl-Devel-Cycle-1.07-1.fc6 (build/make) jpo di uminho pt perl-Digest-MD4-1.5-3.fc6 (build/make) jpo di uminho pt perl-Digest-Nilsimsa-0.06-8.fc8 (build/make) wtogami redhat com perl-Exception-Class-1.23-3.fc7 (build/make) steve silug org perl-Expect-1.20-1.fc6 (build/make) jpo di uminho pt perl-Expect-Simple-0.02-1.fc6 (build/make) jpo di uminho pt perl-ExtUtils-CBuilder-0.19-1.fc8 (build/make) jpo di uminho pt perl-ExtUtils-Depends-0.205-5.fc6 (build/make) jpo di uminho pt perl-ExtUtils-ParseXS-2.18-1.fc7 (build/make) jpo di uminho pt perl-ExtUtils-PkgConfig-1.07-5.fc6 (build/make) jpo di uminho pt perl-ExtUtils-XSBuilder-0.28-2.fc6 (build/make) tcallawa redhat com perl-Feed-Find-0.06-2.fc6 (build/make) pertusus free fr perl-File-BaseDir-0.02-1.fc6 (build/make) pertusus free fr perl-File-DesktopEntry-0.02-1.fc6 (build/make) pertusus free fr perl-File-Find-Rule-0.30-3.fc7 (build/make) rc040203 freenet de,lxtnow gmail com perl-File-NFSLock-1.20-2.fc6 (build/make) pertusus free fr perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve silug org perl-File-RsyncP-0.68-2.fc8 (build/make) mmcgrath redhat com perl-File-Tail-0.99.3-5.fc6 (build/make) jpo di uminho pt perl-File-Type-0.22-4.fc7 (build/make) steve silug org perl-File-Which-0.05-2.fc7 (build/make) jpo di uminho pt perl-Finance-Quote-1.13-1.fc7 (build/make) notting redhat com perl-Finance-YahooQuote-0.21-2.fc7 (build/make) wtogami redhat com perl-FreezeThaw-0.43-5.fc6 (build/make) jpo di uminho pt perl-GD-2.35-2.fc6 (build/make) jpo di uminho pt perl-GDGraph-1.44-2.fc8 (build/make) jpo di uminho pt perl-GDGraph3d-0.63-7.fc8 (build/make) jpo di uminho pt perl-GDTextUtil-0.86-8.fc6 (build/make) jpo di uminho pt perl-Geo-Constants-0.06-1.fc7 (build/make) jpo di uminho pt perl-Geo-Ellipsoids-0.14-1.fc7 (build/make) jpo di uminho pt perl-Geo-Forward-0.11-1.fc7 (build/make) jpo di uminho pt perl-Geo-Functions-0.06-1.fc7 (build/make) jpo di uminho pt perl-Geo-Inverse-0.05-1.fc7 (build/make) jpo di uminho pt perl-Glib-1.144-1.fc7 (build/make) jpo di uminho pt perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl alumni drew edu perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl alumni drew edu perl-GPS-0.15-1.fc7 (build/make) jpo di uminho pt perl-GPS-PRN-0.05-1.fc7 (build/make) jpo di uminho pt perl-Hook-LexWrap-0.20-4.fc6 (build/make) jpo di uminho pt perl-HTML-Scrubber-0.08-4.fc6 (build/make) jpo di uminho pt perl-HTML-Table-2.04a-1.fc7 (build/make) orion cora nwra com perl-HTML-Template-2.9-1.fc7 (build/make) jpo di uminho pt perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve silug org perl-HTTP-Proxy-0.20-1.fc6 (build/make) jpo di uminho pt perl-HTTP-Request-Params-1.01-1.fc6 (build/make) jpo di uminho pt perl-HTTP-Server-Simple-0.27-1.fc7 (build/make) jpo di uminho pt perl-HTTP-Server-Simple-Mason-0.09-6.fc8 (build/make) rc040203 freenet de,lxtnow gmail com perl-Image-Base-1.07-7.fc6 (build/make) jpo di uminho pt perl-Image-Xbm-1.08-6.fc6 (build/make) jpo di uminho pt perl-Image-Xpm-1.09-6.fc6 (build/make) jpo di uminho pt perl-Inline-0.44-15.2.1 (build/make) rnorwood redhat com perl-IO-All-0.38-1.fc7 (build/make) steve silug org perl-IO-Capture-0.05-2.fc7 (build/make) jpo di uminho pt perl-IO-Interface-1.03-1.fc7 (build/make) jpo di uminho pt perl-IO-Multiplex-1.08-5.fc6 (build/make) lmb biosci ki se perl-IO-Socket-INET6-2.51-2.fc6 (build/make) wtogami redhat com perl-IO-Socket-SSL-1.02-1.fc7 (build/make) wtogami redhat com,jpo di uminho pt perl-IO-String-1.08-1.1.1 (build/make) rnorwood redhat com,jpo di uminho pt perl-IO-Tty-1.07-2.fc6 (build/make) jpo di uminho pt perl-IO-Zlib-1.04-4.2.1 (build/make) rnorwood redhat com,jpo di uminho pt perl-IPC-Cmd-0.36-2.fc7 (build/make) steve silug org perl-IPC-SharedCache-1.3-7.fc6 (build/make) jpo di uminho pt perl-Kwiki-0.39-1.fc7 (build/make) steve silug org perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve silug org perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve silug org perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve silug org perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve silug org perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve silug org perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve silug org perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve silug org perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve silug org perl-Kwiki-Search-0.12-5.fc7 (build/make) steve silug org perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve silug org perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve silug org perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve silug org perl-libxml-perl-0.08-1.2.1 (build/make) rnorwood redhat com perl-List-Compare-0.33-2.fc6 (build/make) cweyl alumni drew edu perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (build/make) jpo di uminho pt perl-Log-Dispatch-Config-1.01-2.fc6 (build/make) cweyl alumni drew edu perl-Log-Dispatch-FileRotate-1.16-1.fc7 (build/make) jpo di uminho pt perl-Log-Log4perl-1.11-1.fc8 (build/make) jpo di uminho pt perl-Log-Message-0.01-3.fc7 (build/make) steve silug org perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve silug org perl-LWP-Authen-Wsse-0.05-2.fc6 (build/make) pertusus free fr perl-Mail-Sender-0.8.13-2.fc6 (build/make) jpo di uminho pt perl-Mail-Sendmail-0.79-9.fc6 (build/make) jpo di uminho pt perl-MasonX-Interp-WithCallbacks-1.17-1.fc8 (build/make) steve silug org perl-Math-Round-0.06-1.fc7 (build/make) cweyl alumni drew edu perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh farsiweb info perl-MD5-2.03-1.fc7 (build/make) andreas bawue net perl-MIME-Lite-3.01-5.fc6 (build/make) mmcgrath redhat com perl-MLDBM-2.01-5.fc6 (build/make) jpo di uminho pt perl-Module-Build-0.2808-1.fc8 (build/make) steve silug org perl-Module-Install-0.67-1.fc8 (build/make) steve silug org perl-Module-Load-0.10-3.fc7 (build/make) steve silug org perl-Module-Loaded-0.01-3.fc7 (build/make) steve silug org perl-Module-Locate-1.7-1.fc6 (build/make) jpo di uminho pt perl-Module-Pluggable-3.60-1.fc7 (build/make) steve silug org perl-Module-Versions-Report-1.03-1.fc8 (build/make) jpo di uminho pt perl-Mozilla-LDAP-1.5.2-2.fc8 (build/make) rmeggins redhat com perl-NetAddr-IP-4.004-4.fc8 (build/make) andreas bawue net perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl alumni drew edu perl-Net-GPSD-0.35-1.fc7 (build/make) jpo di uminho pt perl-Net-Jabber-2.0-7.fc6 (build/make) cweyl alumni drew edu perl-Net-Netmask-1.9012-3.fc6 (build/make) wtogami redhat com perl-Net-Patricia-1.014-4.fc8 (build/make) orion cora nwra com perl-Net-Server-0.97-1.fc8 (buildroot) nicolas.mailhot laposte net perl-Net-SNMP-5.2.0-1.fc6 (build/make) jpo di uminho pt perl-Net-SNPP-1.17-2.fc7 (build/make) jeff ocjtech us perl-Net-SSLeay-1.30-5.fc8 (build/make) wtogami redhat com,jpo di uminho pt perl-Net-Telnet-3.03-5 (build/make) jkeating redhat com perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl alumni drew edu perl-Object-Accessor-0.32-2.fc7 (build/make) steve silug org perl-OpenFrame-3.05-6.fc7 (build/make) steve silug org perl-Package-Constants-0.01-3.fc7 (build/make) steve silug org perl-PadWalker-1.5-1.fc7 (build/make) jpo di uminho pt perl-Params-Check-0.26-1.fc7 (build/make) steve silug org perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve silug org perl-Parse-RecDescent-1.94-6.fc8 (build/make) rnorwood redhat com perl-Parse-Yapp-1.05-36.fc6 (build/make) pertusus free fr perl-PatchReader-0.9.5-4.fc6 (build/make) stickster gmail com perl-PBS-0.31-3.fc6 (build/make) garrick usc edu perl-Perl6-Bible-0.30-3.fc7 (build/make) steve silug org perl-Pipeline-3.12-4.fc7 (build/make) steve silug org perl-pmtools-1.01-2.fc6 (build/make) jpo di uminho pt perl-Pod-Escapes-1.04-5.fc6 (build/make) jpo di uminho pt perl-Pod-Simple-3.05-1.fc8 (build/make) jpo di uminho pt perl-Pod-Spell-1.01-2.fc7 (build/make) jpo di uminho pt perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl alumni drew edu perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-Server-SimpleHTTP-1.23-2.fc7 (build/make) cweyl alumni drew edu perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl alumni drew edu perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl alumni drew edu perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl alumni drew edu perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl alumni drew edu perl-PPI-Tester-0.06-2.fc6 (build/make) jpo di uminho pt perl-Proc-Daemon-0.03-1.fc7.1 (build/make) Fedora FamilleCollet com perl-Readonly-1.03-6.fc6 (build/make) cweyl alumni drew edu perl-Readonly-XS-1.04-7.fc6 (build/make) cweyl alumni drew edu perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl alumni drew edu perl-Scalar-Properties-0.12-1.fc6 (build/make) jpo di uminho pt perl-Set-Infinite-0.61-3.fc7 (build/make) steve silug org perl-Set-Scalar-1.20-1.fc7 (build/make) jpo di uminho pt perl-SNMP_Session-1.08-3.fc6 (build/make) jpo di uminho pt perl-SOAP-Lite-0.68-2.fc6 (build/make) mmcgrath redhat com perl-Socket6-0.19-4.fc8 (build/make) wtogami redhat com,jpo di uminho pt perl-Spiffy-0.30-7.fc7 (build/make) steve silug org perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve silug org perl-SQL-Library-0.0.3-2.fc6 (build/make) cweyl alumni drew edu perl-SQL-Statement-1.15-2.fc6 (build/make) jpo di uminho pt perl-Statistics-Descriptive-2.6-2.fc6 (build/make) pertusus free fr perl-String-Format-1.14-1.fc6 (build/make) jpo di uminho pt perl-Sub-Identify-0.02-2.fc7 (build/make) cweyl alumni drew edu perl-Sub-Name-0.02-3.fc8 (build/make) cweyl alumni drew edu perl-SUPER-1.16-1.fc7 (build/make) cweyl alumni drew edu perl-SVG-2.34-2.fc8 (build/make) alexl users sourceforge net perl-Sys-SigAction-0.10-1.fc7 (build/make) andreas bawue net perl-TermReadKey-2.30-1.2.2.1 (build/make) rnorwood redhat com perl-Term-UI-0.14-2.fc7 (build/make) steve silug org perl-Test-Cmd-1.05-1.fc6 (build/make) jpo di uminho pt perl-Test-Differences-0.47-2.fc6 (build/make) jpo di uminho pt perl-Test-Expect-0.30-1.fc6 (build/make) jpo di uminho pt perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve silug org perl-Test-WWW-Mechanize-1.14-1.fc8 (build/make) jpo di uminho pt perl-TeX-Hyphen-0.140-5.fc6 (build/make) jpo di uminho pt perl-Text-CharWidth-0.04-2.fc7 (build/make) Axel.Thimm ATrpms net perl-Text-CHM-0.01-2.fc6 (build/make) pertusus free fr perl-Text-Kakasi-2.04-5.fc8 (build/make) tagoh redhat com perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve silug org perl-Text-Shellwords-1.08-2.fc8 (build/make) alexl users sourceforge net perl-Text-Template-1.44-4.fc6 (build/make) jpo di uminho pt perl-Text-Tree-1.0-2.fc7 (build/make) cweyl alumni drew edu perl-Text-Unidecode-0.04-4.fc6 (build/make) pertusus free fr perl-Text-WrapI18N-0.06-2.fc7 (build/make) Axel.Thimm ATrpms net perl-Tie-IxHash-1.21-6.fc6 (build/make) jpo di uminho pt perl-Time-modules-2003.1126-4.fc6 (build/make) kaboom oobleck net perl-Time-Period-1.20-1.fc6 (build/make) robert marcanoonline com perl-Time-Piece-1.09-2.fc6 (build/make) chris chrisgrau com perl-Tk-804.027-12.fc8 (build/make) andreas.bierfert lowlatency de perl-Tree-DAG_Node-1.05-4.fc6 (build/make) jpo di uminho pt perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo di uminho pt perl-URI-1.35-3 (build/make) rnorwood redhat com perl-WWW-Babelfish-0.16-1.fc7 (build/make) cweyl alumni drew edu perl-WWW-Bugzilla-0.9-1.fc7 (build/make) jpo di uminho pt perl-XML-DOM-1.44-2.fc6 (build/make) orion cora nwra com perl-XML-Dumper-0.81-2.fc6 (build/make) rnorwood redhat com perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) andreas bawue net perl-XML-Grove-0.46alpha-29.1.1 (build/make) rnorwood redhat com perl-XML-LibXML-1.62001-2.fc7 (build/make) rnorwood redhat com perl-XML-LibXML-Common-0.13-8.2.2 (build/make) rnorwood redhat com perl-XML-NamespaceSupport-1.09-2.fc8 (build/make) rnorwood redhat com perl-XML-RegExp-0.03-2.fc6 (build/make) orion cora nwra com perl-XML-SAX-Writer-0.50-2.fc7 (build/make) andreas bawue net perl-XML-Stream-1.22-6.fc6 (build/make) cweyl alumni drew edu perl-XML-Validator-Schema-1.08-1.fc7 (build/make) andreas bawue net perl-XML-XPath-1.13-4.fc6 (build/make) rnorwood redhat com perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve silug org php-pear-DB-1.7.12-2.fc8.src.rpm php-pecl-memcache-2.1.2-1.fc8.src.rpm plexus-xmlrpc-1.0-0.1.b4.3jpp.6.fc8 (build/make) dbhole redhat com polyxmass-bin-0.9.3-2.fc6 (build/make) andreas.bierfert lowlatency de postgresql-8.2.5-1.fc8 (build/make) tgl redhat com ppc64-utils-0.12-1.fc8 (buildroot) pnasrat redhat com prelink-0.3.10-1 (build/make) jakub redhat com pulseaudio-0.9.7-0.11.svn20070907.fc8 (build/make) lpoetter redhat com,drzeus-bugzilla drzeus cx python-cheetah-2.0-0.7.rc8.fc8 (build/make) mikeb redhat com python-docs-2.5.1-1.fc8 (build/make) james.antill redhat com python-turbokid-1.0.2-2.fc8.src.rpm python-urljr-1.0.1-1.fc7 (build/make) jeff ocjtech us python-vobject-0.4.8-1.fc8 (build/make) jbowes redhat com,dgoodwin dangerouslyinc com qa-assistant-0.4.90.5-2.fc6 (build/make) toshio tiki-lounge com qpidc-0.2-5.fc7 (build/make) aconway redhat com,meyering redhat com,nsantos redhat com quarry-0.2.0-1.fc7 (build/make) michel.salim gmail com rekall-2.4.5-6.fc8.1 (build/make) tcallawa redhat com renrot-0.25-2.fc7 (build/make) andy smile org ua rhm-0.1-3.fc7 (build/make) aconway redhat com,nsantos redhat com ruby-activerecord-1.15.1-1.fc7 (build/make) dlutter redhat com ruby-bdb-0.6.0-1.fc7 (build/make) miker5slow grandecom net rxvt-unicode-8.3-1.fc8 (build/make) andreas.bierfert lowlatency de seahorse-1.0.1-9.fc8 (build/make) skvidal linux duke edu sepostgresql-8.2.4-1.0.fc8.src.rpm shapelib-1.2.10-12.20060304cvs (build/make) mccann0011 hotmail com slrn-0.9.8.1pl1-3.20070716cvs.fc8 (build/make) mlichvar redhat com source-highlight-2.4-2.fc8.src.rpm struts-1.2.9-4jpp.6 (build/make) dbhole redhat com swatch-3.2.1-1.fc6 (build/make) jpo di uminho pt sword-1.5.9-6.fc8 (open_missing_mode) dakingun gmail com sylpheed-2.4.5-1.src.rpm synce-software-manager-0.9.0-7.fc6 (build/make) andreas.bierfert lowlatency de synce-trayicon-0.9.0-8.fc6 (build/make) andreas.bierfert lowlatency de syslog-ng-2.0.5-1.fc8 (build/make) jpo di uminho pt,pvrabec redhat com sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu gmail com tclabc-1.0.9-1.fc7 (build/make) gemi bluewin ch tclparser-1.4-2.20061030cvs.fc8 (build/make) wart kobold org tetex-3.0-41.fc8 (build/make) jnovy redhat com thinkfinger-0.3-3.fc8.src.rpm tinyerp-4.0.3-1.fc7 (build/make) dan danny cz trac-bazaar-plugin-0.2-4.20070829bzr182.fc8.src.rpm udunits-1.12.4-11.fc8.2 (build/make) tcallawa redhat com unison-2.13.16-3.fc6 (build/make) gemi bluewin ch util-vserver-0.30.214-2.fc8 (build/make) enrico.scholz informatik tu-chemnitz de velocity-1.4-6jpp.1 (build/make) vivekl redhat com vinagre-0.2-1.fc8.src.rpm vkeybd-0.1.17a-3.fc7 (build/make) green redhat com xaos-3.2.3-1.fc7 (build/make) gemi bluewin ch xdaliclock-2.23-3.fc6 (build/make) kaboom oobleck net xferstats-2.16-14.1 (build/make) than redhat com xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser redhat com xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung redhat com xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint redhat com xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint redhat com xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint redhat com xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint redhat com xscreensaver-5.03-7.fc8.src.rpm xsri-2.1.0-12.fc8 (build/make) sandmann redhat com zaptel-1.4.2.1-1.fc7 (open_missing_mode) jeff ocjtech us With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From sundaram at fedoraproject.org Tue Sep 25 21:06:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 26 Sep 2007 02:36:40 +0530 Subject: artwork split up In-Reply-To: <20070925201940.GA27099@jadzia.bu.edu> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> Message-ID: <46F97860.6070705@fedoraproject.org> Matthew Miller wrote: > On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote: >> redhat-artwork has way too many build requirements and unrelated content. >> I've split it up in a bunch of little packages and filed review >> requests for each one. > > Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- > this is very helpful. Yep. Good work. This would potentially help the art team continue to ship older themes on newer releases since some end users prefer that. Rahul From orion at cora.nwra.com Tue Sep 25 21:20:37 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 25 Sep 2007 15:20:37 -0600 Subject: LSB SDK Message-ID: <46F97BA5.1000308@cora.nwra.com> Any particular reason Fedora doesn't ship the LSB development kit (with /usr/include/lsb# etc)? Or nobody has needed it yet? -- 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 khc at pm.waw.pl Tue Sep 25 21:24:09 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 25 Sep 2007 23:24:09 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190733795.6478.46.camel@cutter> (seth vidal's message of "Tue, 25 Sep 2007 11:23:15 -0400") References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> Message-ID: seth vidal writes: > Umm, you have it backward. When I was originally writing in the multilib > support I asked how it should be done and was told, at the time, by > Jeremy that it should install both of them b/c that's what users would > want/expect. At least, that's what I vaguely recall. This has been about > 3 years, now. Well, I think it was like that 3 years ago. Now it seems users want x86_64 only, they don't want i386-devel, they maybe want i386 Firefox (can the Flash be used with some 32->64 wrapper?) and a couple of other things (32-bit gcc code generation, if the respective optional 32-bit libs are installed). Yes, some users need all i386 they can have (such as devel). I fully agree it would be great if we had _no_ i386 packages in x86_64, and if the right way to get 32-bit packages was just pointing yum etc. to the 32-bit repository. > Wrong. It's about the policy. Ok, then the policy should be fixed. -- Krzysztof Halasa From dominik at greysector.net Tue Sep 25 21:29:26 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 25 Sep 2007 23:29:26 +0200 Subject: yum pulling in 386 packages In-Reply-To: References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> Message-ID: <20070925212926.GB31754@ryvius.pekin.waw.pl> On Tuesday, 25 September 2007 at 23:24, Krzysztof Halasa wrote: > seth vidal writes: > > > Umm, you have it backward. When I was originally writing in the multilib > > support I asked how it should be done and was told, at the time, by > > Jeremy that it should install both of them b/c that's what users would > > want/expect. At least, that's what I vaguely recall. This has been about > > 3 years, now. > > Well, I think it was like that 3 years ago. > > Now it seems users want x86_64 only, they don't want i386-devel, > they maybe want i386 Firefox (can the Flash be used with some 32->64 > wrapper?) nspluginwrapper works quite well. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From lfarkas at bppiac.hu Tue Sep 25 21:36:17 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 25 Sep 2007 23:36:17 +0200 Subject: truecrypt In-Reply-To: <20070925183907.GC5516@crow.myhome.westell.com> References: <20070925183907.GC5516@crow.myhome.westell.com> Message-ID: <46F97F51.2080204@bppiac.hu> Luke Macken wrote: > On Tue, Sep 25, 2007 at 12:55:30PM -0400, Neal Becker wrote: >> Has anyone looked at truecrypt? Looks interesting. I D/L the source, but >> it says: >> >> Note that Linux kernel headers, located in the 'include' directory, are >> not sufficient for compilation of the TrueCrypt kernel module. Fields of >> 'dm_dev' structure must be accessed by TrueCrypt but they are defined only >> in >> an internal kernel header 'drivers/md/dm.h'. No appropriate accessor >> function >> is available. The complete source code of the Linux kernel is required for >> compilation of the kernel module. > > Truecrypt is awesome, but their license[0] is a bit questionable. It's a you can always found the latest kmod in: http://www.lfarkas.org/linux/packages/fedora/7/ -- Levente "Si vis pacem para bellum!" From bojan at rexursive.com Tue Sep 25 21:47:21 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 26 Sep 2007 07:47:21 +1000 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070925160713.A13101@humbolt.us.dell.com> References: <20070925160713.A13101@humbolt.us.dell.com> Message-ID: <1190756841.2996.8.camel@shrek.rexursive.com> On Tue, 2007-09-25 at 16:07 -0500, Matt Domsch wrote: > libapreq2-2.09-0.rc2.7.fc8 (build/make) bojan rexursive com Still that mock thingy with /etc/hosts: ------------------------------------------ mod APR::Request::Hook mkdir xs/APR/Re[ info] generating script t/TEST [ error] Can't resolve host: 'localhost' (check /etc/hosts) [ error] Can't resolve host: 'localhost' (check /etc/hosts) quest/Hook writing...xs/APR/Request/Hook/Makefile.PL ------------------------------------------ -- Bojan From tgl at redhat.com Tue Sep 25 22:36:04 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 25 Sep 2007 18:36:04 -0400 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070925160651.A13071@humbolt.us.dell.com> References: <20070925160651.A13071@humbolt.us.dell.com> Message-ID: <7889.1190759764@sss.pgh.pa.us> Matt Domsch writes: > Fedora Rawhide-in-Mock Build Results for x86_64 Tue Sep 25 15:36:25 CDT 2007 > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ You seem to be using a rather broken compiler --- both of the mysql builds failed with "internal compiler error" ... Also, it looks like this machine still fails to resolve "localhost". regards, tom lane From lmacken at redhat.com Tue Sep 25 22:37:41 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 25 Sep 2007 18:37:41 -0400 Subject: Fedora 7 Updates Busted Again? In-Reply-To: References: <1190748649.5242.10.camel@raptor.sr.unh.edu> Message-ID: <20070925223741.GF5516@crow.myhome.westell.com> On Tue, Sep 25, 2007 at 03:36:29PM -0400, Tom Diehl wrote: > On Tue, 25 Sep 2007, Thomas J. Baker wrote: > >> >> Did the Fedora 7 updates get whacked again? It seems my mirror of >> kernel.org just deleted almost all the F7 updates. > > Yep!! > > Jesse and company are working on it. Most of the arches are probably restored by now. So, we've been having some mash memory issues lately, and have had some trouble composing the f7-updates repo. The mash/createrepo processes would either get killed or bodhi would not update generate the updateinfo or update the f7-updates symlink properly. This morning I saw that last night's mash had completed successfully, so I updated the f7-updates symlink -- just as bodhi was running its weekly repo-cleaner that removes all of the repos that aren't being pointed to. Which also seemed to occur right when our latest repo was syncing live. Very unfortunate timing. I'm going to write some extensive sanity checks into bodhi's masher to ensure that this does not occur again. We should also increase our data retention to a little bit longer than an hour :( luke From mjs at exchange.clemson.edu Tue Sep 25 22:47:27 2007 From: mjs at exchange.clemson.edu (Matthew Saltzman) Date: Tue, 25 Sep 2007 18:47:27 -0400 Subject: Dependencies in today's updates Message-ID: <1190760447.9711.8.camel@vincent52.localdomain> Today's update to setroubleshoot requires selinux-policy-base >= 3.0.7-10, but there is no selinux-policy-base and nothing provides it. firefox-2.0.0.6-8.fc8 still conflicts with xulrunner-1.9-0.alpha7.2.fc8. Are there workarounds? Fixes in the works? -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at CLEMSON.EDU Tue Sep 25 22:52:37 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Tue, 25 Sep 2007 18:52:37 -0400 Subject: Dependency problems in today's updates Message-ID: <1190760757.9711.9.camel@vincent52.localdomain> Today's update to setroubleshoot requires selinux-policy-base >= 3.0.7-10, but there is no selinux-policy-base and nothing provides it. firefox-2.0.0.6-8.fc8 still conflicts with xulrunner-1.9-0.alpha7.2.fc8. Are there workarounds? Fixes in the works? -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From roland at redhat.com Wed Sep 26 00:29:02 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 25 Sep 2007 17:29:02 -0700 (PDT) Subject: buildreq for "localhost works" Message-ID: <20070926002902.C407B4D04B7@magilla.localdomain> With recent changes to the implicit buildreq set, my package broke in the mass-rebuild-in-mock tests. It needs an environment in which "localhost" resolves properly. i.e., the canonical dummy /etc/hosts or whatever. This used to be implicitly supplied, and apparently no longer is. I can't figure out off hand what buildrequire would supply this. Thanks, Roland From Matt_Domsch at dell.com Wed Sep 26 01:08:16 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 25 Sep 2007 20:08:16 -0500 Subject: buildreq for "localhost works" In-Reply-To: <20070926002902.C407B4D04B7@magilla.localdomain> References: <20070926002902.C407B4D04B7@magilla.localdomain> Message-ID: <20070926010816.GA11232@auslistsprd01.us.dell.com> On Tue, Sep 25, 2007 at 05:29:02PM -0700, Roland McGrath wrote: > With recent changes to the implicit buildreq set, my package broke in the > mass-rebuild-in-mock tests. It needs an environment in which "localhost" > resolves properly. i.e., the canonical dummy /etc/hosts or whatever. > This used to be implicitly supplied, and apparently no longer is. > I can't figure out off hand what buildrequire would supply this. It was a bug in mock for a while, not creating /etc/hosts. I've upgraded mock to the latest from rawhide on all my buildhosts and am rerunning the whole run. Will post new results when they're available. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From skvidal at fedoraproject.org Wed Sep 26 01:15:33 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 25 Sep 2007 21:15:33 -0400 Subject: yum pulling in 386 packages In-Reply-To: References: <200709220944.33124.sgrubb@redhat.com> <1190471424.2166.18.camel@cutter> <200709221104.35264.sgrubb@redhat.com> <20070922171422.77bf3eac@redhat.com> <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> Message-ID: <1190769333.6478.62.camel@cutter> On Tue, 2007-09-25 at 23:24 +0200, Krzysztof Halasa wrote: > seth vidal writes: > > > Umm, you have it backward. When I was originally writing in the multilib > > support I asked how it should be done and was told, at the time, by > > Jeremy that it should install both of them b/c that's what users would > > want/expect. At least, that's what I vaguely recall. This has been about > > 3 years, now. > > Well, I think it was like that 3 years ago. > > Now it seems users want x86_64 only, they don't want i386-devel, > they maybe want i386 Firefox (can the Flash be used with some 32->64 > wrapper?) and a couple of other things (32-bit gcc code generation, > if the respective optional 32-bit libs are installed). > > Yes, some users need all i386 they can have (such as devel). > > I fully agree it would be great if we had _no_ i386 packages in > x86_64, and if the right way to get 32-bit packages was just pointing > yum etc. to the 32-bit repository. > > > Wrong. It's about the policy. > > Ok, then the policy should be fixed. Right - which is what Jesse is trying to get organized. A meeting, a whiteboard, a plan. -sv From wart at kobold.org Wed Sep 26 01:29:01 2007 From: wart at kobold.org (Wart) Date: Tue, 25 Sep 2007 18:29:01 -0700 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070925160651.A13071@humbolt.us.dell.com> References: <20070925160651.A13071@humbolt.us.dell.com> Message-ID: <46F9B5DD.8030406@kobold.org> Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 Tue Sep 25 15:36:25 CDT 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 4738 > Number failed to build: 462 > Number expected to fail due to ExclusiveArch or ExcludeArch: 31 > Leaving: 431 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 431 > ---------------------------------- [...] > tclparser-1.4-2.20061030cvs.fc8 (build/make) wart kobold org Ugh. This is due to a new bug in Tcl that seems to have been introduced in -test2: https://bugzilla.redhat.com/show_bug.cgi?id=306321 --Wart From dominik at greysector.net Wed Sep 26 06:33:33 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 26 Sep 2007 08:33:33 +0200 Subject: truecrypt In-Reply-To: <46F97F51.2080204@bppiac.hu> References: <20070925183907.GC5516@crow.myhome.westell.com> <46F97F51.2080204@bppiac.hu> Message-ID: <20070926063333.GC4067@ryvius.pekin.waw.pl> On Tuesday, 25 September 2007 at 23:36, Farkas Levente wrote: > Luke Macken wrote: > > On Tue, Sep 25, 2007 at 12:55:30PM -0400, Neal Becker wrote: > >> Has anyone looked at truecrypt? Looks interesting. I D/L the source, but > >> it says: > >> > >> Note that Linux kernel headers, located in the 'include' directory, are > >> not sufficient for compilation of the TrueCrypt kernel module. Fields of > >> 'dm_dev' structure must be accessed by TrueCrypt but they are defined only > >> in > >> an internal kernel header 'drivers/md/dm.h'. No appropriate accessor > >> function > >> is available. The complete source code of the Linux kernel is required for > >> compilation of the kernel module. > > > > Truecrypt is awesome, but their license[0] is a bit questionable. It's a > > you can always found the latest kmod in: > http://www.lfarkas.org/linux/packages/fedora/7/ Talk about duplicated effort. ;) Why don't you submit your package (perhaps after merging with mine) to rpmfusion? Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bojan at rexursive.com Wed Sep 26 07:16:05 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 26 Sep 2007 07:16:05 +0000 (UTC) Subject: Fedora 7 Updates Busted Again? References: <1190748649.5242.10.camel@raptor.sr.unh.edu> Message-ID: Tom Diehl rogueind.com> writes: > Yep!! On the bright side, it may be a good opportunity to build/push 2.6.22.8 kernel and save users a reboot :-) -- Bojan From spng.yang at gmail.com Wed Sep 26 07:36:25 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 26 Sep 2007 15:36:25 +0800 Subject: Why my rhythmbox can not import some mp3? Message-ID: <46FA0BF9.1050203@gmail.com> hi all, i in F8 Rawhide with rhythmbox: rhythmbox-0.11.2-6.fc8.i386 i can import most of my music, but there are some songs(mp3), which can not be imported, and have errors: Import Errors: Internal data flow error but other mp3 can be imported smoothly and hear well. Those mp3, which can not imported in rhythmbox, can be played by mplayer so i don't where is wrong, can anyone give me some hints? From david at lovesunix.net Wed Sep 26 09:03:14 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 26 Sep 2007 11:03:14 +0200 Subject: yum pulling in 386 packages In-Reply-To: <20070925212926.GB31754@ryvius.pekin.waw.pl> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> Message-ID: <1190797396.27642.1.camel@dawkins> tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann' Mierzejewski: > On Tuesday, 25 September 2007 at 23:24, Krzysztof Halasa wrote: > > seth vidal writes: > > > > > Umm, you have it backward. When I was originally writing in the multilib > > > support I asked how it should be done and was told, at the time, by > > > Jeremy that it should install both of them b/c that's what users would > > > want/expect. At least, that's what I vaguely recall. This has been about > > > 3 years, now. > > > > Well, I think it was like that 3 years ago. > > > > Now it seems users want x86_64 only, they don't want i386-devel, > > they maybe want i386 Firefox (can the Flash be used with some 32->64 > > wrapper?) > > nspluginwrapper works quite well. I've never personally had any kind of success with it - David From lfarkas at bppiac.hu Wed Sep 26 09:21:16 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Wed, 26 Sep 2007 11:21:16 +0200 Subject: truecrypt In-Reply-To: <20070926063333.GC4067@ryvius.pekin.waw.pl> References: <20070925183907.GC5516@crow.myhome.westell.com> <46F97F51.2080204@bppiac.hu> <20070926063333.GC4067@ryvius.pekin.waw.pl> Message-ID: <46FA248C.6010701@bppiac.hu> Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 25 September 2007 at 23:36, Farkas Levente wrote: >> Luke Macken wrote: >>> On Tue, Sep 25, 2007 at 12:55:30PM -0400, Neal Becker wrote: >>>> Has anyone looked at truecrypt? Looks interesting. I D/L the source, but >>>> it says: >>>> >>>> Note that Linux kernel headers, located in the 'include' directory, are >>>> not sufficient for compilation of the TrueCrypt kernel module. Fields of >>>> 'dm_dev' structure must be accessed by TrueCrypt but they are defined only >>>> in >>>> an internal kernel header 'drivers/md/dm.h'. No appropriate accessor >>>> function >>>> is available. The complete source code of the Linux kernel is required for >>>> compilation of the kernel module. >>> Truecrypt is awesome, but their license[0] is a bit questionable. It's a >> you can always found the latest kmod in: >> http://www.lfarkas.org/linux/packages/fedora/7/ > > Talk about duplicated effort. ;) Why don't you submit your package (perhaps > after merging with mine) to rpmfusion? i'd be happy if any repo will contain it and i don't have to recompile. everybody can use my spec in any repo. the main reason that i use it (ie. i've truecrypt volumes) and i always need the latest kmod for the latest fedora kernel while most repo is in a few days delay. -- Levente "Si vis pacem para bellum!" From jochen.schlick at comsoft.de Wed Sep 26 09:39:38 2007 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Wed, 26 Sep 2007 11:39:38 +0200 Subject: yum update so slow In-Reply-To: <1190726982.22109.31.camel@code.and.org> References: <46F78726.4020808@comsoft.de> <1190726982.22109.31.camel@code.and.org> Message-ID: <46FA28DA.5080304@comsoft.de> James Antill wrote: > On Mon, 2007-09-24 at 11:45 +0200, Jochen Schlick wrote: >> Hi, I have a laptop where rawhide is installed since the days >> of Fedora Core 1. It has only 256MB ram so updating using yum >> was always like a lame duck but nowadays it's really a crap. > > This might not help, but if you'd like to try something I've attached > some python code which calls yum and "iterativlely updates". This might > make it be small enough that it isn't living in swap, or at least not as > badly. > Let me know how it goes. > I tried yesterday evening it on my laptop and on a ram-shrinked(256MB) rawhide qemu/kvm-guest at home. At first it looked fine, but when the script started to update with X11-stuff (perhaps due to their dependencies or so) it failed to update with "Error: Failed to update:..." the script tried the next one and so on. After an hour I realized that both systems were no longer reachable and continuously swapping. This morning I have the following results: - The laptop was dead and after a reboot it hangs (so it needs further forensic analysis ;-) - The rawhide quemu/kvm guest is alive, but most of the 70 updates are failed when I believe the update script. /var/log/messages shows a lot of oom-killer activity. On first sight I think every failed update corresponds with at least one oom-killer entry... best regards -- --------------------------------------------------------------------------- Jochen Schlick --------------------------------------------------------------------------- From lkundrak at redhat.com Wed Sep 26 10:04:27 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 26 Sep 2007 12:04:27 +0200 Subject: buildreq for "localhost works" In-Reply-To: <20070926002902.C407B4D04B7@magilla.localdomain> References: <20070926002902.C407B4D04B7@magilla.localdomain> Message-ID: <1190801067.2314.1.camel@localhost.localdomain> On Tue, 2007-09-25 at 17:29 -0700, Roland McGrath wrote: > With recent changes to the implicit buildreq set, my package broke in > the > mass-rebuild-in-mock tests. It needs an environment in which > "localhost" > resolves properly. i.e., the canonical dummy /etc/hosts or whatever. > This used to be implicitly supplied, and apparently no longer is. > I can't figure out off hand what buildrequire would supply this. Apart from the other reply to this post; I can't imagine why would a build system need to be this much tied to the build host. I would call it a bug in the build system and patch around it. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Wed Sep 26 10:07:12 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 26 Sep 2007 12:07:12 +0200 Subject: Why my rhythmbox can not import some mp3? In-Reply-To: <46FA0BF9.1050203@gmail.com> References: <46FA0BF9.1050203@gmail.com> Message-ID: <1190801232.2314.5.camel@localhost.localdomain> On Wed, 2007-09-26 at 15:36 +0800, Ken YANG wrote: > hi all, > > > i in F8 Rawhide with rhythmbox: > > rhythmbox-0.11.2-6.fc8.i386 > > i can import most of my music, but there are some > songs(mp3), which can not be imported, and have errors: > > Import Errors: Internal data flow error > > but other mp3 can be imported smoothly and hear well. > > Those mp3, which can not imported in rhythmbox, can be > played by mplayer > > so i don't where is wrong, can anyone give me some hints? Ken; first of all MPEG is patent encumbered and thus not supported on fedora -- you probably have problem with a 3rd party package, gstreamer-plugins-ugly. Does it work with other versions of gstreamer, gstreamer-plugins-ugly and rhythmbox? Do you have a sample file that can reproduce the problem? -- Lubomir Kundrak (Red Hat Security Response Team) From dwmw2 at infradead.org Wed Sep 26 10:14:47 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 26 Sep 2007 11:14:47 +0100 Subject: yum pulling in 386 packages In-Reply-To: <1190797396.27642.1.camel@dawkins> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> <1190797396.27642.1.camel@dawkins> Message-ID: <1190801687.2905.308.camel@pmac.infradead.org> On Wed, 2007-09-26 at 11:03 +0200, David Nielsen wrote: > tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann' Mierzejewski: > > nspluginwrapper works quite well. > > I've never personally had any kind of success with it Really? At one point (with a bit of qemu hacking) I even had the i386 flash plugin running with nspluginwrapper+qemu-i386 in my PowerPC firefox. I wouldn't _recommend_ it, and there was a bit more thread-related qemu hacking to be done before it worked _well_, but it was definitely working. -- dwmw2 From lkundrak at redhat.com Wed Sep 26 10:15:05 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 26 Sep 2007 12:15:05 +0200 Subject: artwork split up In-Reply-To: <46F97860.6070705@fedoraproject.org> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> Message-ID: <1190801705.2314.10.camel@localhost.localdomain> On Wed, 2007-09-26 at 02:36 +0530, Rahul Sundaram wrote: > Matthew Miller wrote: > > On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote: > >> redhat-artwork has way too many build requirements and unrelated content. > >> I've split it up in a bunch of little packages and filed review > >> requests for each one. > > > > Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- > > this is very helpful. > > Yep. Good work. This would potentially help the art team continue to > ship older themes on newer releases since some end users prefer that. This is really cool -- I really like the DNA theme, unfortunatelly, unlike the gdm theme, its desktop backgrounds are no longer present in subsequent redhat-artwork packages. At the first glance none of this packages contain it either. It would be really nice if we had packages with pictures from older themes. Anyone would package those, or mind if I did that? -- Lubomir Kundrak (Red Hat Security Response Team) From david at lovesunix.net Wed Sep 26 10:17:27 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 26 Sep 2007 12:17:27 +0200 Subject: Why my rhythmbox can not import some mp3? In-Reply-To: <46FA0BF9.1050203@gmail.com> References: <46FA0BF9.1050203@gmail.com> Message-ID: <1190801848.27642.3.camel@dawkins> ons, 26 09 2007 kl. 15:36 +0800, skrev Ken YANG: > hi all, > > > i in F8 Rawhide with rhythmbox: > > rhythmbox-0.11.2-6.fc8.i386 > > i can import most of my music, but there are some > songs(mp3), which can not be imported, and have errors: > > Import Errors: Internal data flow error > > but other mp3 can be imported smoothly and hear well. > > Those mp3, which can not imported in rhythmbox, can be > played by mplayer > > so i don't where is wrong, can anyone give me some hints? I to have noticed a few mp3s which used to work display that error. I haven't had much time to figure out what is going on though. - David From nicu_fedora at nicubunu.ro Wed Sep 26 10:25:27 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 26 Sep 2007 13:25:27 +0300 Subject: artwork split up In-Reply-To: <1190801705.2314.10.camel@localhost.localdomain> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> Message-ID: <46FA3397.9090208@nicubunu.ro> Lubomir Kundrak wrote: > > This is really cool -- I really like the DNA theme, unfortunatelly, > unlike the gdm theme, its desktop backgrounds are no longer present in > subsequent redhat-artwork packages. At the first glance none of this > packages contain it either. It would be really nice if we had packages > with pictures from older themes. Anyone would package those, or mind if > I did that? It was said many times we want to have available background from old releases, maybe even 1 or 2 releases back included in the default install, for those who like those better than the current. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From roland at redhat.com Wed Sep 26 10:32:35 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 26 Sep 2007 03:32:35 -0700 (PDT) Subject: buildreq for "localhost works" In-Reply-To: Lubomir Kundrak's message of Wednesday, 26 September 2007 12:04:27 +0200 <1190801067.2314.1.camel@localhost.localdomain> References: <20070926002902.C407B4D04B7@magilla.localdomain> <1190801067.2314.1.camel@localhost.localdomain> Message-ID: <20070926103235.5EDCA4D04B7@magilla.localdomain> > Apart from the other reply to this post; I can't imagine why would a > build system need to be this much tied to the build host. I would call > it a bug in the build system and patch around it. Oh, please. Using free TCP ports on loopback is "tied to the build host"? It's a universal presumption that "localhost" means 127.0.0.1 and/or ::1, depending what protocols you are speaking at the instant in question. There's anal, there's draconian, and then there's butthead pointless. From mlichvar at redhat.com Wed Sep 26 10:43:24 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 26 Sep 2007 12:43:24 +0200 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070925160651.A13071@humbolt.us.dell.com> References: <20070925160651.A13071@humbolt.us.dell.com> Message-ID: <20070926104324.GD6851@localhost> On Tue, Sep 25, 2007 at 04:06:51PM -0500, Matt Domsch wrote: > slrn-0.9.8.1pl1-3.20070716cvs.fc8 (build/make) mlichvar redhat com It's a symbol name mismatch in nss_compat_ossl, filed bug #306711. -- Miroslav Lichvar From spng.yang at gmail.com Wed Sep 26 10:48:55 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 26 Sep 2007 18:48:55 +0800 Subject: Why my rhythmbox can not import some mp3? In-Reply-To: <1190801232.2314.5.camel@localhost.localdomain> References: <46FA0BF9.1050203@gmail.com> <1190801232.2314.5.camel@localhost.localdomain> Message-ID: <46FA3917.6030509@gmail.com> Lubomir Kundrak wrote: > On Wed, 2007-09-26 at 15:36 +0800, Ken YANG wrote: >> hi all, >> >> >> i in F8 Rawhide with rhythmbox: >> >> rhythmbox-0.11.2-6.fc8.i386 >> >> i can import most of my music, but there are some >> songs(mp3), which can not be imported, and have errors: >> >> Import Errors: Internal data flow error >> >> but other mp3 can be imported smoothly and hear well. >> >> Those mp3, which can not imported in rhythmbox, can be >> played by mplayer >> >> so i don't where is wrong, can anyone give me some hints? > > Ken; first of all MPEG is patent encumbered and thus not supported on > fedora -- you probably have problem with a 3rd party package, > gstreamer-plugins-ugly. yes, i got ugly plugins from livna: gstreamer-plugins-ugly-0.10.6-1.lvn8.i386 > > Does it work with other versions of gstreamer, gstreamer-plugins-ugly > and rhythmbox? Do you have a sample file that can reproduce the problem? yes, i just test the F7 version: gstreamer-plugins-ugly-0.10.5-2.lvn7.i386.rpm thanks for your answer > From naheemzaffar at gmail.com Wed Sep 26 10:56:16 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 26 Sep 2007 11:56:16 +0100 Subject: artwork split up In-Reply-To: <46FA3397.9090208@nicubunu.ro> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> <46FA3397.9090208@nicubunu.ro> Message-ID: <3adc77210709260356u77340f80y61aa6cdcf564afed@mail.gmail.com> Probably the wrong place to ask this, but I am not subscribed to the art list. Will the old artwork be touched up where necessary to go for the more "unbranded" style (I think) fedora has been moving towards? (first thoughts - Bubbles and FedoraDNA have the logo build in as part of the background artwork, so can't/shouldn't change. But flying high just has the name written on top,but not as part of the image. It probably can be removed if Fedora goes down this road.) From jkeating at redhat.com Wed Sep 26 11:13:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 07:13:27 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190797396.27642.1.camel@dawkins> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> <1190797396.27642.1.camel@dawkins> Message-ID: <20070926071327.55bf451b@redhat.com> On Wed, 26 Sep 2007 11:03:14 +0200 David Nielsen wrote: > I've never personally had any kind of success with it I'm happily using nspluginwrapper.i386 + adobe flash to be able to view flash things in my x86_64 browser. Of course this will be made moot when gnash starts working better (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Sep 26 11:28:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 07:28:00 -0400 Subject: We are Frozen for Test3 Message-ID: <20070926072800.2e91ac04@redhat.com> We froze for test3 early this morning. This also marks the Devel freeze for the remainder of the Fedora 8 development cycle. Builds from rawhide will continue to get the 'dist-f8' tag, and will be available in the buildroots to build against. However rawhide will compose from the 'dist-rawhide' tag, which inherits from 'f8-test3'. If you need to get a build into Fedora 8 Test3, please follow http://fedoraproject.org/wiki/ReleaseEngineering/TestFreezePolicy For schedule information, see http://fedoraproject.org/wiki/Releases/8/Schedule To see if your build made the freeze cut off, see http://koji.fedoraproject.org/koji/builds?tagID=27 or simply call 'koji latest-pkg f8-test3 ' -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin.kofler at chello.at Wed Sep 26 11:26:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 26 Sep 2007 11:26:41 +0000 (UTC) Subject: artwork split up References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> Message-ID: Lubomir Kundrak redhat.com> writes: > This is really cool -- I really like the DNA theme, unfortunatelly, > unlike the gdm theme, its desktop backgrounds are no longer present in > subsequent redhat-artwork packages. I'd really like a working FedoraDNA KDM theme (the same reasoning applies to GDM too), for a simple reason: some users want to turn off the user list (or "face browser" as the GNOME folks call the same feature), and the newer themes have a blank placeholder where the user list should be if you disable it, which looks ugly. So we should keep at least one Fedora* theme without the user list working. Kevin Kofler From dwmw2 at infradead.org Wed Sep 26 11:47:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 26 Sep 2007 12:47:11 +0100 Subject: yum pulling in 386 packages In-Reply-To: <20070926071327.55bf451b@redhat.com> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> <1190797396.27642.1.camel@dawkins> <20070926071327.55bf451b@redhat.com> Message-ID: <1190807231.2905.348.camel@pmac.infradead.org> On Wed, 2007-09-26 at 07:13 -0400, Jesse Keating wrote: > I'm happily using nspluginwrapper.i386 + adobe flash to be able to > view flash things in my x86_64 browser. Of course this will be made > moot when gnash starts working better (: To be fair, hnash in rawhide _is_ a lot better... although perhaps still not 'good'. At least I'm kind of getting out of the habit of just typing 'killall -9 gnash' whenever X or the system starts crawling. -- dwmw2 From jkeating at redhat.com Wed Sep 26 12:12:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 08:12:38 -0400 Subject: yum pulling in 386 packages In-Reply-To: <1190807231.2905.348.camel@pmac.infradead.org> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> <1190797396.27642.1.camel@dawkins> <20070926071327.55bf451b@redhat.com> <1190807231.2905.348.camel@pmac.infradead.org> Message-ID: <20070926081238.3f785d25@redhat.com> On Wed, 26 Sep 2007 12:47:11 +0100 David Woodhouse wrote: > To be fair, hnash in rawhide _is_ a lot better... although perhaps > still not 'good'. At least I'm kind of getting out of the habit of > just typing 'killall -9 gnash' whenever X or the system starts > crawling. Last time I tried it in rawhide it kept booting me right out of X :/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Wed Sep 26 12:15:56 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 26 Sep 2007 08:15:56 -0400 Subject: artwork split up In-Reply-To: <1190801705.2314.10.camel@localhost.localdomain> References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> Message-ID: <1190808957.4421.2.camel@localhost.localdomain> On Wed, 2007-09-26 at 12:15 +0200, Lubomir Kundrak wrote: > On Wed, 2007-09-26 at 02:36 +0530, Rahul Sundaram wrote: > > Matthew Miller wrote: > > > On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote: > > >> redhat-artwork has way too many build requirements and unrelated content. > > >> I've split it up in a bunch of little packages and filed review > > >> requests for each one. > > > > > > Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- > > > this is very helpful. > > > > Yep. Good work. This would potentially help the art team continue to > > ship older themes on newer releases since some end users prefer that. > > This is really cool -- I really like the DNA theme, unfortunatelly, > unlike the gdm theme, its desktop backgrounds are no longer present in > subsequent redhat-artwork packages. At the first glance none of this > packages contain it either. It would be really nice if we had packages > with pictures from older themes. Anyone would package those, or mind if > I did that? The old packages should be available in cvs, so anybody with sufficient interest can take the source, and package up the part he is interested in. Using Rays packages as guideline for package naming and spec file should make this very easy. From martin.sourada at seznam.cz Wed Sep 26 12:33:03 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 26 Sep 2007 14:33:03 +0200 Subject: Dependency problems in today's updates In-Reply-To: <1190760757.9711.9.camel@vincent52.localdomain> References: <1190760757.9711.9.camel@vincent52.localdomain> Message-ID: <1190809983.1124.4.camel@pc-notebook> On Wed, 2007-09-26 at 00:52 +0200, Matthew Saltzman wrote: > Today's update to setroubleshoot requires selinux-policy-base >= > 3.0.7-10, but there is no selinux-policy-base and nothing provides it. > > firefox-2.0.0.6-8.fc8 still conflicts with xulrunner-1.9-0.alpha7.2.fc8. > > Are there workarounds? Fixes in the works? > -- > Matthew Saltzman > > Clemson University Math Sciences > mjs AT clemson DOT edu > http://www.math.clemson.edu/~mjs > Dunno about fixes, but certainly there is a workaround - just download (and install) newer xulrunner from koji [1] (don't know why it wasn't pushed to rawhide though) and yum should stop complaining about it (as the one in repos, the wrong one, is older and the new one does not conflict with firefox). Martin References: [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=19320 -------------- 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 nicu_fedora at nicubunu.ro Wed Sep 26 13:27:00 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 26 Sep 2007 16:27:00 +0300 Subject: artwork split up In-Reply-To: References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> Message-ID: <46FA5E24.70702@nicubunu.ro> Kevin Kofler wrote: > I'd really like a working FedoraDNA KDM theme (the same reasoning applies to > GDM too), for a simple reason: some users want to turn off the user list > (or "face browser" as the GNOME folks call the same feature), and the newer > themes have a blank placeholder where the user list should be if you disable > it, which looks ugly. So we should keep at least one Fedora* theme without the > user list working. People on the Art Team have experience mostly with GNOME theming, but if you come to the art list with the request and provide some handy KDM guides, there may be someone wanting to work on it. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jkeating at redhat.com Wed Sep 26 13:52:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 09:52:52 -0400 Subject: Dependency problems in today's updates In-Reply-To: <1190809983.1124.4.camel@pc-notebook> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> Message-ID: <20070926095252.13173b24@redhat.com> On Wed, 26 Sep 2007 14:33:03 +0200 Martin Sourada wrote: > Dunno about fixes, but certainly there is a workaround - just download > (and install) newer xulrunner from koji [1] (don't know why it wasn't > pushed to rawhide though) and yum should stop complaining about it (as > the one in repos, the wrong one, is older and the new one does not > conflict with firefox). It's not in rawhide as we're not actually sure we want to introduce Xul into F8 at this point. It's not suitable to build other packages against due to upstream changes. There should be no xulrunner in rawhide at this point. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Wed Sep 26 14:21:28 2007 From: jorton at redhat.com (Joe Orton) Date: Wed, 26 Sep 2007 15:21:28 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070925160713.A13101@humbolt.us.dell.com> References: <20070925160713.A13101@humbolt.us.dell.com> Message-ID: <20070926142128.GA13094@redhat.com> On Tue, Sep 25, 2007 at 04:07:13PM -0500, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 Tue Sep 25 15:44:42 CDT 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ mod_perl is listed as failing to build on both i386 and x86_64, yet the logs provided show a successful build with binary RPMs produced. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/mod_perl-2.0.3-14.src.rpm/result/ Regards, joe From Matt_Domsch at dell.com Wed Sep 26 14:37:43 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 26 Sep 2007 09:37:43 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070926142128.GA13094@redhat.com> References: <20070925160713.A13101@humbolt.us.dell.com> <20070926142128.GA13094@redhat.com> Message-ID: <20070926143743.GB28612@auslistsprd01.us.dell.com> On Wed, Sep 26, 2007 at 03:21:28PM +0100, Joe Orton wrote: > On Tue, Sep 25, 2007 at 04:07:13PM -0500, Matt Domsch wrote: > > Fedora Rawhide-in-Mock Build Results for i386 Tue Sep 25 15:44:42 CDT 2007 > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > mod_perl is listed as failing to build on both i386 and x86_64, yet the > logs provided show a successful build with binary RPMs produced. > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/mod_perl-2.0.3-14.src.rpm/result/ i re-ran the failures overnight, so some previously false failures are now good. I'll have the stats email out shortly. Down to 395 failures on i386, 408 on x86_64. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jkeating at redhat.com Wed Sep 26 14:46:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 10:46:56 -0400 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070926143743.GB28612@auslistsprd01.us.dell.com> References: <20070925160713.A13101@humbolt.us.dell.com> <20070926142128.GA13094@redhat.com> <20070926143743.GB28612@auslistsprd01.us.dell.com> Message-ID: <20070926104656.028a4502@redhat.com> On Wed, 26 Sep 2007 09:37:43 -0500 Matt Domsch wrote: > i re-ran the failures overnight, so some previously false failures are > now good. I'll have the stats email out shortly. Down to 395 > failures on i386, 408 on x86_64. Did your build set include glibc-2.6.90-14? That introduces -D_FORTIFY_SOURCE{,=2} support for C++ and there may be some warnings in the build output about potential buffer overflows (which would result in runtime aborts and glibc logging). I'm curious if we can check the C++ builds for any warnings like this. Warnings such as "warning: call to __builtin___memcpy_chk will always overflow destination buffer" -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mjs at CLEMSON.EDU Wed Sep 26 15:06:41 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 11:06:41 -0400 Subject: Dependency problems in today's updates In-Reply-To: <20070926095252.13173b24@redhat.com> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> Message-ID: <1190819201.10711.50.camel@vincent52.localdomain> On Wed, 2007-09-26 at 09:52 -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 14:33:03 +0200 > Martin Sourada wrote: > > > Dunno about fixes, but certainly there is a workaround - just download > > (and install) newer xulrunner from koji [1] (don't know why it wasn't > > pushed to rawhide though) and yum should stop complaining about it (as > > the one in repos, the wrong one, is older and the new one does not > > conflict with firefox). > > > It's not in rawhide as we're not actually sure we want to introduce Xul > into F8 at this point. It's not suitable to build other packages > against due to upstream changes. There should be no xulrunner in > rawhide at this point. Does that mean the workaround is to rpm -e xulrunner? > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From Matt_Domsch at dell.com Wed Sep 26 15:41:25 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 26 Sep 2007 10:41:25 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-26 Message-ID: <20070926104125.A31491@humbolt.us.dell.com> Once more, with a few more verbose messages about missing BRs: (popt-devel and perl(ExtUtils::MakeMaker). And note how what's listed is your FAS account name, not an email address. And yes, the localhost fix is in here too. -Matt Fedora Rawhide-in-Mock Build Results for x86_64 Wed Sep 26 09:49:44 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 4816 Number failed to build: 440 Number expected to fail due to ExclusiveArch or ExcludeArch: 32 Leaving: 408 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 408 ---------------------------------- adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung airsnort-0.2.7e-11.fc7 (build/make) awjb akode-2.0.1-8.fc8 (buildroot) rdieter alacarte-0.11.3-4.fc8 (build/make) rstrode amsn-0.96-7.fc7 (build/make) tjikkun apt-0.5.15lorg3.93-2.fc8 (build/make) athimm atitvout-0.4-7 (buildroot) awjb avr-binutils-2.17-4.fc8 (build/make) jwrdegoede awesfx-0.5.0d-4.fc7 (build/make) stransky azureus-2.5.0.4-2.fc7 (build/make) green callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2 castor-0.9.5-1jpp.7 (build/make) pcheung centericq-4.21.0-14.fc8 (build/make) awjb checkstyle-4.1-4jpp.1.fc7 (buildroot) rmyers chkfontpath-1.10.1-2.fc8 (build/make) krh clips-6.24-22.fc7 (build/make) rvinyard compat-erlang-R10B-10.7.fc7 (build/make) gemi compat-gcc-32-3.2.3-61 (buildroot) jakub compat-gcc-34-3.4.6-7 (build/make) jakub conexus-0.5.3-2.fc8 (build/make) rvinyard cpan2rpm-2.028-2.fc6 (needs_perl_ExtUtils_MakeMaker) ghenry cryptix-3.2.0-9jpp.1 (build/make) mwringe cryptix-asn1-20011119-7jpp.2 (build/make) vivekl cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones d4x-2.5.7.1-3.fc7 (build/make) thias digikamimageplugins-0.9.1-1.fc7 (build/make) rdieter eclipse-emf-2.2.2-1.fc7 (build/make) overholt eclipse-mylar-2.0-0.1.M2a.1.fc7 (build/make) overholt eiciel-0.9.4-1.fc7 (build/make) cweyl em8300-kmod-0.16.3-5.2.6.23_0.187.rc6.git7.fc8 (buildroot) scop emelfm2-0.3.5-2.fc8 (build/make) cwickert evolution-remove-duplicates-0.0.2-6.fc7 (build/make) salimma fakechroot-2.5-12.fc7 (build/make) athimm fluxstyle-1.0.1-2.fc7 (build/make) errr fontypython-0.2.0-6.fc7 (build/make) cr33dog freetennis-0.4.8-6.fc7 (build/make) orphan gai-0.5.10-10.fc7 (build/make) salimma gajim-0.11.1-1.fc7 (buildroot) gajownik gambas-1.0.19-1.fc8.2.src.rpm gdb-6.6-29.fc8 (buildroot) jkratoch gdmap-0.7.5-6.fc6 (build/make) splinux gedit-plugins-2.18.0-2.fc7 (build/make) trondd genius-0.7.7-2.fc7 (build/make) gemi gfa-0.4.1-4.fc7 (build/make) splinux ghdl-0.25-0.89svn.5.fc8 (build/make) sailer giggle-0.3-4.fc8 (build/make) jbowes glipper-0.95.1-2.fc7 (build/make) splinux gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak gnome-pilot-2.0.15-5.fc7 (build/make) mbarnes gnomescan-0.4.0.2-1.fc7 (build/make) deji gnome-specimen-0.3-1.fc8 (build/make) splinux gnomesword-2.2.3-5.fc8 (build/make) deji gpp-0.6.6-3.fc6 (build/make) mdomsch gpsim-0.22.0-4.fc8 (build/make) dionysos grhino-0.16.0-1.fc7.src.rpm grub-0.97-19 (build/make) pjones gstm-1.2-6.fc7 (build/make) splinux gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtranslator-1.1.7-3.fc8 (build/make) sindrepb gwenhywfar-2.6.0-1.fc8 (open_missing_mode) notting gwget-0.99-2.fc8 (build/make) cwickert htop-0.6.5-1.fc7 (build/make) gajownik inn-2.4.3-6.fc6 (build/make) odvorace isdn4k-utils-3.2-54.fc7 (build/make) than jgroups-2.2.9.2-3jpp.2 (build/make) vivekl jogl-1.0.0-5.7.beta5.fc6 (build/make) green kadu-0.5.0-4.fc8 (build/make) ecik kawa-1.9.0-2.fc7 (build/make) green kbibtex-0.1.5.52-10.fc7 (build/make) noltec kdeutils-3.5.7-5.fc8 (open_missing_mode) than kdissert-1.0.7-1.fc7 (build/make) icon kgtk-0.8-2.fc7 (open_missing_mode) faucamp knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil kudzu-1.2.74-1.src.rpm kvm-36-5.fc8 (buildroot) katzj ladspa-1.12-8.fc7 (build/make) thomasvs ldapjdk-4.17-1jpp.7 (build/make) vivekl libgdiplus-1.2.4-1.fc8 (build/make) alexl libprelude-0.9.13-1.fc7 (build/make) tscherf libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf liferea-1.2.23-1.fc8 (build/make) bpepple lilypond-doc-2.10.13-1.fc7 (build/make) qspencer lockdev-1.0.1-11.fc7 (needs_perl_ExtUtils_MakeMaker) kzak logrotate-3.7.6-1.1.fc8 (build/make) tsmetana maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe mbuffer-20070502-1.fc7 (open_missing_mode) adalloz memtest86+-1.70-1.fc7 (buildroot) wtogami mikmod-3.2.2-2.fc7 (build/make) jnovy Miro-0.9.8.1-2.fc7.src.rpm moto4lin-0.3-6.fc7 (build/make) jafo muine-0.8.7-3.fc7 (build/make) sindrepb mx4j-3.0.1-6jpp.4 (build/make) fnasser mysql-5.0.45-4.fc8 (build/make) tgl nagios-2.9-3.fc8 (build/make) mmcgrath nant-0.85-12.fc7 (build/make) pfj nemiver-0.4.0-1.fc8 (build/make) pgordon nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb nkf-2.07-3.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh notification-daemon-0.3.7-4.fc8 (build/make) davidz ntfs-config-1.0-0.4.rc5.fc8 (build/make) laxathom ocsinventory-client-1.01-5.fc7 (needs_perl_ExtUtils_MakeMaker) remi octave-forge-2006.07.09-9.fc7 (build/make) qspencer openais-0.80.1-6 (open_missing_mode) sdake openalpp-20060714-3.fc7 (build/make) xulchris OpenIPMI-2.0.11-2.fc8 (needs_popt-devel) pknirsch openmpi-1.2.3-4.fc8 (open_missing_mode) dledford oprofile-0.9.3-3.fc8 (build/make) wcohen orpie-1.4.3-5.fc6 (build/make) xris osgal-20060903-3.fc7 (buildroot) xulchris osgcal-0.1.44-4.fc7 (build/make) xulchris pam_abl-0.2.3-3.fc7 (build/make) adalloz pari-2.3.0-5.fc7 (build/make) gemi passwd-0.74-4.fc8 (build/make) tmraz pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo perl-AnyData-0.10-4.fc8 (needs_perl_ExtUtils_MakeMaker) spot perl-Apache-DBI-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) remi perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve perl-Authen-SASL-2.10-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-bioperl-1.5.2_102-8.fc8 (build/make) alexlan perl-Boulder-1.30-3.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-Cache-2.04-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Cache-Cache-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Cache-Mmap-0.09-2.fc7 (build/make) steve perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl perl-CGI-Session-4.20-2.fc7 (build/make) ixs perl-CGI-Simple-0.077-7.fc8 (needs_perl_ExtUtils_MakeMaker) spot perl-Chatbot-Eliza-1.04-3.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl perl-Class-InsideOut-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-MakeMethods-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-MethodMaker-2.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor perl-Class-Observable-1.04-2.fc7 (build/make) ixs perl-Class-Std-0.0.8-1.fc7 (build/make) ixs perl-Compress-Bzip2-2.09-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Config-IniFiles-2.39-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Config-Record-1.1.1-3.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor perl-Convert-ASN1-0.21-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Crypt-Blowfish-2.10-2.fc6 (needs_perl_ExtUtils_MakeMaker) ixs perl-Crypt-CBC-2.22-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs perl-Crypt-PasswdMD5-1.3-2.fc7 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-Data-Compare-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Data-HexDump-0.02-3.fc6 (needs_perl_ExtUtils_MakeMaker) ixs perl-Data-Password-1.07-1.fc7 (build/make) ixs perl-Date-Calc-5.4-2 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Date-Pcalc-1.2-4.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve perl-DateTime-Set-0.25-4.fc7 (build/make) steve perl-DBD-CSV-0.22-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-DBD-MySQL-4.005-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-DBD-Pg-1.49-5.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-DBD-SQLite-1.12-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-DBD-SQLite2-0.33-7.fc8.1.src.rpm perl-DBD-XBase-0.241-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Devel-Caller-0.11-1.fc7 (build/make) steve perl-Devel-Cover-0.61-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Devel-Cycle-1.07-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Digest-MD4-1.5-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Digest-Nilsimsa-0.06-8.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Exception-Class-1.23-3.fc7 (build/make) steve perl-Expect-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Expect-Simple-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-CBuilder-0.19-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-Depends-0.205-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-ParseXS-2.18-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-PkgConfig-1.07-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-XSBuilder-0.28-2.fc6 (needs_perl_ExtUtils_MakeMaker) spot perl-Feed-Find-0.06-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-BaseDir-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-DesktopEntry-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu perl-File-NFSLock-1.20-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve perl-File-RsyncP-0.68-2.fc8 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-File-Tail-0.99.3-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-File-Type-0.22-4.fc7 (build/make) steve perl-File-Which-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Finance-Quote-1.13-1.fc7 (needs_perl_ExtUtils_MakeMaker) notting perl-Finance-YahooQuote-0.21-2.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami perl-FreezeThaw-0.43-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-GD-2.35-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDGraph-1.44-2.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDGraph3d-0.63-7.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDTextUtil-0.86-8.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Constants-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Ellipsoids-0.14-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Forward-0.11-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Functions-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Inverse-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Glib-1.144-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl perl-GPS-0.15-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-GPS-PRN-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Hook-LexWrap-0.20-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Scrubber-0.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Table-2.04a-1.fc7 (needs_perl_ExtUtils_MakeMaker) orion perl-HTML-Template-2.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve perl-HTTP-Request-Params-1.01-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Base-1.07-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Xbm-1.08-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Xpm-1.09-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Inline-0.44-15.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IO-All-0.38-1.fc7 (build/make) steve perl-IO-Capture-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Interface-1.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Multiplex-1.08-5.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-Socket-INET6-2.51-2.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-Socket-SSL-1.02-1.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-String-1.08-1.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IO-Tty-1.07-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Zlib-1.04-4.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IPC-Cmd-0.36-2.fc7 (build/make) steve perl-IPC-SharedCache-1.3-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Kwiki-0.39-1.fc7 (build/make) steve perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve perl-Kwiki-Search-0.12-5.fc7 (build/make) steve perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve perl-libxml-perl-0.08-1.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-List-Compare-0.33-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Dispatch-Config-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Log-Dispatch-FileRotate-1.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Log4perl-1.11-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Message-0.01-3.fc7 (build/make) steve perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve perl-LWP-Authen-Wsse-0.05-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Mail-Sender-0.8.13-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Mail-Sendmail-0.79-9.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Math-Round-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh perl-MD5-2.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs perl-MIME-Lite-3.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-MLDBM-2.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Module-Build-0.2808-1.fc8 (build/make) steve perl-Module-Install-0.67-1.fc8 (build/make) steve perl-Module-Load-0.10-3.fc7 (build/make) steve perl-Module-Loaded-0.01-3.fc7 (build/make) steve perl-Module-Locate-1.7-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Module-Pluggable-3.60-1.fc7 (build/make) steve perl-Module-Versions-Report-1.03-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Mozilla-LDAP-1.5.2-2.fc8 (needs_perl_ExtUtils_MakeMaker) rmeggins perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl perl-Net-GPSD-0.35-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Net-Jabber-2.0-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Net-Netmask-1.9012-3.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Net-Patricia-1.014-4.fc8 (needs_perl_ExtUtils_MakeMaker) orion perl-Net-SNMP-5.2.0-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Net-SNPP-1.17-2.fc7 (needs_perl_ExtUtils_MakeMaker) jcollie perl-Net-SSLeay-1.30-5.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Net-Telnet-3.03-5 (needs_perl_ExtUtils_MakeMaker) jkeating perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl perl-Object-Accessor-0.32-2.fc7 (build/make) steve perl-OpenFrame-3.05-6.fc7 (build/make) steve perl-Package-Constants-0.01-3.fc7 (build/make) steve perl-PadWalker-1.5-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Params-Check-0.26-1.fc7 (build/make) steve perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve perl-Parse-RecDescent-1.94-6.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Parse-Yapp-1.05-36.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-PatchReader-0.9.5-4.fc6 (needs_perl_ExtUtils_MakeMaker) pfrields perl-PBS-0.31-3.fc6 (needs_perl_ExtUtils_MakeMaker) garrick perl-Perl6-Bible-0.30-3.fc7 (build/make) steve perl-Pipeline-3.12-4.fc7 (build/make) steve perl-pmtools-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Escapes-1.04-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Simple-3.05-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Spell-1.01-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl perl-PPI-Tester-0.06-2.fc6 (build/make) jpo perl-Proc-Daemon-0.03-1.fc7.1 (needs_perl_ExtUtils_MakeMaker) remi perl-Readonly-1.03-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Readonly-XS-1.04-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl perl-Scalar-Properties-0.12-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Set-Infinite-0.61-3.fc7 (build/make) steve perl-Set-Scalar-1.20-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-SNMP_Session-1.08-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-SOAP-Lite-0.68-2.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-Socket6-0.19-4.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Spiffy-0.30-7.fc7 (build/make) steve perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve perl-SQL-Library-0.0.3-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-SQL-Statement-1.15-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Statistics-Descriptive-2.6-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-String-Format-1.14-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Sub-Identify-0.02-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Sub-Name-0.02-3.fc8 (needs_perl_ExtUtils_MakeMaker) cweyl perl-SUPER-1.16-1.fc7 (build/make) cweyl perl-SVG-2.34-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs perl-TermReadKey-2.30-1.2.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Term-UI-0.14-2.fc7 (build/make) steve perl-Test-Cmd-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Test-Differences-0.47-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Test-Expect-0.30-1.fc6 (build/make) jpo perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve perl-TeX-Hyphen-0.140-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Text-CharWidth-0.04-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm perl-Text-CHM-0.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Text-Kakasi-2.04-5.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve perl-Text-Shellwords-1.08-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan perl-Text-Template-1.44-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Text-Tree-1.0-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Text-Unidecode-0.04-4.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Text-WrapI18N-0.06-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm perl-Tie-IxHash-1.21-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Time-modules-2003.1126-4.fc6 (needs_perl_ExtUtils_MakeMaker) kaboom perl-Time-Period-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) robmv perl-Time-Piece-1.09-2.fc6 (needs_perl_ExtUtils_MakeMaker) cgrau perl-Tk-804.027-12.fc8 (build/make) awjb perl-Tree-DAG_Node-1.05-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo perl-URI-1.35-3 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-WWW-Babelfish-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-WWW-Bugzilla-0.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-XML-DOM-1.44-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-XML-Dumper-0.81-2.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs perl-XML-Grove-0.46alpha-29.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-LibXML-1.62001-2.fc7 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-LibXML-Common-0.13-8.2.2 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-NamespaceSupport-1.09-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-RegExp-0.03-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs perl-XML-Stream-1.22-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs perl-XML-XPath-1.13-4.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve pexpect-2.1-5.fc8 (build/make) toshio polyxmass-bin-0.9.3-2.fc6 (build/make) awjb ppc64-utils-0.12-1.fc8 (buildroot) dcantrel prelink-0.3.10-1 (build/make) jakub prewikka-0.9.8-1.fc7 (build/make) tscherf pulseaudio-0.9.7-0.11.svn20070907.fc8.src.rpm python-boto-0.9b-1.fc8 (build/make) robert python-docs-2.5.1-1.fc8 (build/make) james python-psyco-1.5.1-5.fc7 (buildroot) shahms python-reportlab-2.1-1.fc8 (build/make) bpepple python-urljr-1.0.1-1.fc7 (build/make) jcollie qa-assistant-0.4.90.5-2.fc6 (build/make) toshio qpidc-0.2-5.fc7 (build/make) aconway quarry-0.2.0-1.fc7.src.rpm rekall-2.4.5-6.fc8.1 (build/make) spot renrot-0.25-2.fc7 (needs_perl_ExtUtils_MakeMaker) andriy rhm-0.1-3.fc7 (build/make) aconway ruby-activerecord-1.15.1-1.fc7 (build/make) lutter ruby-bdb-0.6.0-1.fc7 (build/make) errr rxvt-unicode-8.3-1.fc8 (build/make) awjb s3switch-0.0-9.20020912.fc6 (buildroot) pwouters seahorse-1.0.1-9.fc8 (build/make) skvidal shapelib-1.2.10-12.20060304cvs (build/make) smccann slrn-0.9.8.1pl1-3.20070716cvs.fc8 (build/make) mlichvar struts-1.2.9-4jpp.6.src.rpm swatch-3.2.1-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo sword-1.5.9-6.fc8 (open_missing_mode) deji synce-software-manager-0.9.0-7.fc6 (build/make) awjb synce-trayicon-0.9.0-8.fc6 (build/make) awjb syslinux-3.36-5.fc8 (buildroot) pjones syslog-ng-2.0.5-1.fc8 (build/make) jpo sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu tclabc-1.0.9-1.fc7 (build/make) gemi tclparser-1.4-2.20061030cvs.fc8 (build/make) wart tetex-3.0-41.fc8 (build/make) jnovy tinyerp-4.0.3-1.fc7 (build/make) sharkcz udunits-1.12.4-11.fc8.2 (needs_perl_ExtUtils_MakeMaker) spot unison-2.13.16-3.fc6 (build/make) gemi valgrind-3.2.3-6 (buildroot) jakub velocity-1.4-6jpp.1 (build/make) vivekl vkeybd-0.1.17a-3.fc7 (build/make) green xaos-3.2.3-1.fc7 (build/make) gemi xdaliclock-2.23-3.fc6 (build/make) kaboom xen-3.1.0-6.fc8.src.rpm xen-3.1.0-8.fc8 (buildroot) xen-maint xferstats-2.16-14.1 (build/make) than xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint xsri-2.1.0-12.fc8 (build/make) ssp zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Wed Sep 26 15:41:29 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 26 Sep 2007 10:41:29 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-26 Message-ID: <20070926104129.A3810@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 Wed Sep 26 09:57:41 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 4817 Number failed to build: 405 Number expected to fail due to ExclusiveArch or ExcludeArch: 10 Leaving: 395 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 395 ---------------------------------- adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung airsnort-0.2.7e-11.fc7 (build/make) awjb akode-2.0.1-8.fc8 (buildroot) rdieter amsn-0.96-7.fc7 (build/make) tjikkun apt-0.5.15lorg3.93-2.fc8 (build/make) athimm athcool-0.3.11-5.fc6 (build/make) gajownik avr-binutils-2.17-4.fc8 (build/make) jwrdegoede awesfx-0.5.0d-4.fc7 (build/make) stransky azureus-2.5.0.4-2.fc7 (build/make) green bes-3.5.1-3.fc8 (build/make) pertusus callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2 castor-0.9.5-1jpp.7 (build/make) pcheung centericq-4.21.0-14.fc8 (build/make) awjb checkstyle-4.1-4jpp.1.fc7 (buildroot) rmyers chkfontpath-1.10.1-2.fc8 (build/make) krh clips-6.24-22.fc7 (build/make) rvinyard compat-erlang-R10B-10.7.fc7 (build/make) gemi compat-gcc-296-2.96-138 (build/make) jakub compat-gcc-32-3.2.3-61 (build/make) jakub compat-gcc-34-3.4.6-7 (build/make) jakub conexus-0.5.3-2.fc8 (build/make) rvinyard cpan2rpm-2.028-2.fc6 (needs_perl_ExtUtils_MakeMaker) ghenry cryptix-3.2.0-9jpp.1 (build/make) mwringe cryptix-asn1-20011119-7jpp.2 (build/make) vivekl cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones d4x-2.5.7.1-3.fc7 (build/make) thias digikamimageplugins-0.9.1-1.fc7 (build/make) rdieter eclipse-emf-2.2.2-1.fc7 (build/make) overholt eclipse-mylar-2.0-0.1.M2a.1.fc7 (build/make) overholt eiciel-0.9.4-1.fc7 (build/make) cweyl em8300-kmod-0.16.3-5.2.6.23_0.187.rc6.git7.fc8 (buildroot) scop emelfm2-0.3.5-2.fc8 (build/make) cwickert evolution-remove-duplicates-0.0.2-6.fc7 (build/make) salimma fakechroot-2.5-12.fc7 (build/make) athimm fluxstyle-1.0.1-2.fc7 (build/make) errr fontypython-0.2.0-6.fc7 (build/make) cr33dog freetennis-0.4.8-6.fc7 (build/make) orphan gai-0.5.10-10.fc7 (build/make) salimma gajim-0.11.1-1.fc7 (buildroot) gajownik gambas-1.0.19-1.fc8.2.src.rpm gdmap-0.7.5-6.fc6 (build/make) splinux gedit-plugins-2.18.0-2.fc7 (build/make) trondd genius-0.7.7-2.fc7 (build/make) gemi gfa-0.4.1-4.fc7 (build/make) splinux ghdl-0.25-0.89svn.5.fc8 (build/make) sailer giggle-0.3-4.fc8 (build/make) jbowes glipper-0.95.1-2.fc7 (build/make) splinux gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak gnome-pilot-2.0.15-5.fc7 (build/make) mbarnes gnomescan-0.4.0.2-1.fc7 (build/make) deji gnomesword-2.2.3-5.fc8 (build/make) deji gpp-0.6.6-3.fc6 (build/make) mdomsch gpsim-0.22.0-4.fc8 (build/make) dionysos grhino-0.16.0-1.fc7.src.rpm gstm-1.2-6.fc7 (build/make) splinux gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtranslator-1.1.7-3.fc8 (build/make) sindrepb gwenhywfar-2.6.0-1.fc8 (open_missing_mode) notting gwget-0.99-2.fc8 (build/make) cwickert htop-0.6.5-1.fc7 (build/make) gajownik inn-2.4.3-6.fc6 (build/make) odvorace isdn4k-utils-3.2-54.fc7 (build/make) than jgroups-2.2.9.2-3jpp.2 (build/make) vivekl jogl-1.0.0-5.7.beta5.fc6 (build/make) green kadu-0.5.0-4.fc8 (build/make) ecik kawa-1.9.0-2.fc7 (build/make) green kbibtex-0.1.5.52-10.fc7 (build/make) noltec kdeutils-3.5.7-5.fc8 (open_missing_mode) than kdissert-1.0.7-1.fc7 (build/make) icon kgtk-0.8-2.fc7 (open_missing_mode) faucamp knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil kudzu-1.2.74-1.src.rpm ladspa-1.12-8.fc7 (build/make) thomasvs ldapjdk-4.17-1jpp.7 (build/make) vivekl libgdiplus-1.2.4-1.fc8 (build/make) alexl libprelude-0.9.13-1.fc7 (build/make) tscherf libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf liferea-1.2.23-1.fc8 (build/make) bpepple lilypond-doc-2.10.13-1.fc7 (build/make) qspencer lockdev-1.0.1-11.fc7 (needs_perl_ExtUtils_MakeMaker) kzak logrotate-3.7.6-1.1.fc8 (build/make) tsmetana maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe mbuffer-20070502-1.fc7 (open_missing_mode) adalloz mikmod-3.2.2-2.fc7 (build/make) jnovy Miro-0.9.8.1-2.fc7.src.rpm mosml-2.01-9.fc7 (build/make) gemi moto4lin-0.3-6.fc7 (build/make) jafo muine-0.8.7-3.fc7 (build/make) sindrepb mx4j-3.0.1-6jpp.4 (build/make) fnasser mysql-5.0.45-4.fc8 (build/make) tgl nagios-2.9-3.fc8 (build/make) mmcgrath nant-0.85-12.fc7 (build/make) pfj nco-3.9.1-1.fc8 (build/make) edhill nemiver-0.4.0-1.fc8 (build/make) pgordon nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb nkf-2.07-3.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh notification-daemon-0.3.7-4.fc8 (build/make) davidz ocsinventory-client-1.01-5.fc7 (needs_perl_ExtUtils_MakeMaker) remi octave-forge-2006.07.09-9.fc7 (build/make) qspencer openais-0.80.1-6 (open_missing_mode) sdake openalpp-20060714-3.fc7 (build/make) xulchris OpenIPMI-2.0.11-2.fc8 (needs_popt-devel) pknirsch openmpi-1.2.3-4.fc8 (open_missing_mode) dledford oprofile-0.9.3-3.fc8 (build/make) wcohen orpie-1.4.3-5.fc6 (build/make) xris osgal-20060903-3.fc7 (buildroot) xulchris osgcal-0.1.44-4.fc7 (build/make) xulchris pam_abl-0.2.3-3.fc7 (build/make) adalloz pari-2.3.0-5.fc7 (build/make) gemi passwd-0.74-4.fc8 (build/make) tmraz pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo perl-AnyData-0.10-4.fc8 (needs_perl_ExtUtils_MakeMaker) spot perl-Apache-DBI-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) remi perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve perl-Authen-SASL-2.10-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-bioperl-1.5.2_102-8.fc8 (build/make) alexlan perl-Boulder-1.30-3.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-Cache-2.04-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Cache-Cache-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Cache-Mmap-0.09-2.fc7 (build/make) steve perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl perl-CGI-Session-4.20-2.fc7 (build/make) ixs perl-CGI-Simple-0.077-7.fc8 (needs_perl_ExtUtils_MakeMaker) spot perl-Chatbot-Eliza-1.04-3.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl perl-Class-InsideOut-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-MakeMethods-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Class-MethodMaker-2.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor perl-Class-Observable-1.04-2.fc7 (build/make) ixs perl-Class-Std-0.0.8-1.fc7 (build/make) ixs perl-Compress-Bzip2-2.09-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Config-IniFiles-2.39-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Config-Record-1.1.1-3.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor perl-Convert-ASN1-0.21-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Crypt-Blowfish-2.10-2.fc6 (needs_perl_ExtUtils_MakeMaker) ixs perl-Crypt-CBC-2.22-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs perl-Crypt-PasswdMD5-1.3-2.fc7 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-Data-Compare-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Data-HexDump-0.02-3.fc6 (needs_perl_ExtUtils_MakeMaker) ixs perl-Data-Password-1.07-1.fc7 (build/make) ixs perl-Date-Calc-5.4-2 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Date-Pcalc-1.2-4.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve perl-DateTime-Set-0.25-4.fc7 (build/make) steve perl-DBD-CSV-0.22-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-DBD-MySQL-4.005-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-DBD-Pg-1.49-5.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-DBD-SQLite-1.12-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-DBD-SQLite2-0.33-7.fc8.1.src.rpm perl-DBD-XBase-0.241-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Devel-Caller-0.11-1.fc7 (build/make) steve perl-Devel-Cover-0.61-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Devel-Cycle-1.07-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Digest-MD4-1.5-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Digest-Nilsimsa-0.06-8.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Exception-Class-1.23-3.fc7 (build/make) steve perl-Expect-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Expect-Simple-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-CBuilder-0.19-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-Depends-0.205-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-ParseXS-2.18-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-PkgConfig-1.07-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-ExtUtils-XSBuilder-0.28-2.fc6 (needs_perl_ExtUtils_MakeMaker) spot perl-Feed-Find-0.06-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-BaseDir-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-DesktopEntry-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu perl-File-NFSLock-1.20-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve perl-File-RsyncP-0.68-2.fc8 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-File-Tail-0.99.3-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-File-Type-0.22-4.fc7 (build/make) steve perl-File-Which-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Finance-Quote-1.13-1.fc7 (needs_perl_ExtUtils_MakeMaker) notting perl-Finance-YahooQuote-0.21-2.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami perl-FreezeThaw-0.43-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-GD-2.35-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDGraph-1.44-2.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDGraph3d-0.63-7.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-GDTextUtil-0.86-8.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Constants-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Ellipsoids-0.14-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Forward-0.11-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Functions-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Geo-Inverse-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Glib-1.144-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl perl-GPS-0.15-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-GPS-PRN-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Hook-LexWrap-0.20-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Scrubber-0.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Table-2.04a-1.fc7 (needs_perl_ExtUtils_MakeMaker) orion perl-HTML-Template-2.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve perl-HTTP-Request-Params-1.01-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Base-1.07-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Xbm-1.08-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Image-Xpm-1.09-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Inline-0.44-15.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IO-All-0.38-1.fc7 (build/make) steve perl-IO-Capture-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Interface-1.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Multiplex-1.08-5.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-Socket-INET6-2.51-2.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-Socket-SSL-1.02-1.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami perl-IO-String-1.08-1.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IO-Tty-1.07-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-IO-Zlib-1.04-4.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-IPC-Cmd-0.36-2.fc7 (build/make) steve perl-IPC-SharedCache-1.3-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Kwiki-0.39-1.fc7 (build/make) steve perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve perl-Kwiki-Search-0.12-5.fc7 (build/make) steve perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve perl-libxml-perl-0.08-1.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-List-Compare-0.33-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Dispatch-Config-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Log-Dispatch-FileRotate-1.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Log4perl-1.11-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Log-Message-0.01-3.fc7 (build/make) steve perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve perl-LWP-Authen-Wsse-0.05-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Mail-Sender-0.8.13-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Mail-Sendmail-0.79-9.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Math-Round-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh perl-MD5-2.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs perl-MIME-Lite-3.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-MLDBM-2.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Module-Build-0.2808-1.fc8 (build/make) steve perl-Module-Install-0.67-1.fc8 (build/make) steve perl-Module-Load-0.10-3.fc7 (build/make) steve perl-Module-Loaded-0.01-3.fc7 (build/make) steve perl-Module-Locate-1.7-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Module-Pluggable-3.60-1.fc7 (build/make) steve perl-Module-Versions-Report-1.03-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Mozilla-LDAP-1.5.2-2.fc8 (needs_perl_ExtUtils_MakeMaker) rmeggins perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl perl-Net-GPSD-0.35-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Net-Jabber-2.0-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Net-Netmask-1.9012-3.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Net-Patricia-1.014-4.fc8 (needs_perl_ExtUtils_MakeMaker) orion perl-Net-SNMP-5.2.0-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Net-SNPP-1.17-2.fc7 (needs_perl_ExtUtils_MakeMaker) jcollie perl-Net-SSLeay-1.30-5.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Net-Telnet-3.03-5 (needs_perl_ExtUtils_MakeMaker) jkeating perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl perl-Object-Accessor-0.32-2.fc7 (build/make) steve perl-OpenFrame-3.05-6.fc7 (build/make) steve perl-Package-Constants-0.01-3.fc7 (build/make) steve perl-PadWalker-1.5-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-Params-Check-0.26-1.fc7 (build/make) steve perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve perl-Parse-RecDescent-1.94-6.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Parse-Yapp-1.05-36.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-PatchReader-0.9.5-4.fc6 (needs_perl_ExtUtils_MakeMaker) pfrields perl-PBS-0.31-3.fc6 (needs_perl_ExtUtils_MakeMaker) garrick perl-Perl6-Bible-0.30-3.fc7 (build/make) steve perl-Pipeline-3.12-4.fc7 (build/make) steve perl-pmtools-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Escapes-1.04-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Simple-3.05-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo perl-Pod-Spell-1.01-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl perl-PPI-Tester-0.06-2.fc6 (build/make) jpo perl-Proc-Daemon-0.03-1.fc7.1 (needs_perl_ExtUtils_MakeMaker) remi perl-Readonly-1.03-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Readonly-XS-1.04-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl perl-Scalar-Properties-0.12-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Set-Infinite-0.61-3.fc7 (build/make) steve perl-Set-Scalar-1.20-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-SNMP_Session-1.08-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-SOAP-Lite-0.68-2.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath perl-Socket6-0.19-4.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami perl-Spiffy-0.30-7.fc7 (build/make) steve perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve perl-SQL-Library-0.0.3-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-SQL-Statement-1.15-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Statistics-Descriptive-2.6-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-String-Format-1.14-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Sub-Identify-0.02-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Sub-Name-0.02-3.fc8 (needs_perl_ExtUtils_MakeMaker) cweyl perl-SUPER-1.16-1.fc7 (build/make) cweyl perl-SVG-2.34-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs perl-TermReadKey-2.30-1.2.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-Term-UI-0.14-2.fc7 (build/make) steve perl-Test-Cmd-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Test-Differences-0.47-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Test-Expect-0.30-1.fc6 (build/make) jpo perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve perl-TeX-Hyphen-0.140-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Text-CharWidth-0.04-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm perl-Text-CHM-0.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Text-Kakasi-2.04-5.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve perl-Text-Shellwords-1.08-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan perl-Text-Template-1.44-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Text-Tree-1.0-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-Text-Unidecode-0.04-4.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus perl-Text-WrapI18N-0.06-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm perl-Tie-IxHash-1.21-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-Time-modules-2003.1126-4.fc6 (needs_perl_ExtUtils_MakeMaker) kaboom perl-Time-Period-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) robmv perl-Time-Piece-1.09-2.fc6 (needs_perl_ExtUtils_MakeMaker) cgrau perl-Tk-804.027-12.fc8 (build/make) awjb perl-Tree-DAG_Node-1.05-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo perl-URI-1.35-3 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-WWW-Babelfish-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl perl-WWW-Bugzilla-0.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo perl-XML-DOM-1.44-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-XML-Dumper-0.81-2.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs perl-XML-Grove-0.46alpha-29.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-LibXML-1.62001-2.fc7 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-LibXML-Common-0.13-8.2.2 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-NamespaceSupport-1.09-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-XML-RegExp-0.03-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs perl-XML-Stream-1.22-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs perl-XML-XPath-1.13-4.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve polyxmass-bin-0.9.3-2.fc6 (build/make) awjb ppc64-utils-0.12-1.fc8 (buildroot) dcantrel prelink-0.3.10-1 (build/make) jakub pulseaudio-0.9.7-0.11.svn20070907.fc8.src.rpm python-docs-2.5.1-1.fc8 (build/make) james python-urljr-1.0.1-1.fc7 (build/make) jcollie qa-assistant-0.4.90.5-2.fc6 (build/make) toshio qpidc-0.2-5.fc7 (build/make) aconway quarry-0.2.0-1.fc7.src.rpm rekall-2.4.5-6.fc8.1 (build/make) spot renrot-0.25-2.fc7 (needs_perl_ExtUtils_MakeMaker) andriy rhm-0.1-3.fc7 (build/make) aconway ruby-activerecord-1.15.1-1.fc7 (build/make) lutter ruby-bdb-0.6.0-1.fc7 (build/make) errr rxvt-unicode-8.3-1.fc8 (build/make) awjb seahorse-1.0.1-9.fc8 (build/make) skvidal shapelib-1.2.10-12.20060304cvs (build/make) smccann slrn-0.9.8.1pl1-3.20070716cvs.fc8 (build/make) mlichvar struts-1.2.9-4jpp.6.src.rpm swatch-3.2.1-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo sword-1.5.9-6.fc8 (open_missing_mode) deji synce-software-manager-0.9.0-7.fc6 (build/make) awjb synce-trayicon-0.9.0-8.fc6 (build/make) awjb syslog-ng-2.0.5-1.fc8 (build/make) jpo sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu tclabc-1.0.9-1.fc7 (build/make) gemi tclparser-1.4-2.20061030cvs.fc8 (build/make) wart tetex-3.0-41.fc8 (build/make) jnovy tinyerp-4.0.3-1.fc7 (build/make) sharkcz udunits-1.12.4-11.fc8.2 (needs_perl_ExtUtils_MakeMaker) spot unison-2.13.16-3.fc6 (build/make) gemi velocity-1.4-6jpp.1 (build/make) vivekl vkeybd-0.1.17a-3.fc7 (build/make) green xaos-3.2.3-1.fc7 (build/make) gemi xdaliclock-2.23-3.fc6 (build/make) kaboom xferstats-2.16-14.1 (build/make) than xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint xsri-2.1.0-12.fc8 (build/make) ssp zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From opensource at till.name Wed Sep 26 15:48:00 2007 From: opensource at till.name (Till Maas) Date: Wed, 26 Sep 2007 17:48:00 +0200 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-26 In-Reply-To: <20070926104129.A3810@humbolt.us.dell.com> References: <20070926104129.A3810@humbolt.us.dell.com> Message-ID: <200709261748.06549.opensource@till.name> On Mi September 26 2007, Matt Domsch wrote: > cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones ^^^^^^ It seems you changed from showing e-mail addresses to usernames here, the problem is, that in the previous report, I was listed there, too. (I comaintain cryptsetup-luks), but now I am not listed there anymore. The issue is fixed btw, it was already comitted to cvs but now it is also build into an srpm. I do not know how often it is the case that BRs are fixed in cvs but not in the srpm, but maybe it is worth checking for this, too. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Wed Sep 26 15:54:35 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Sep 2007 10:54:35 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-26 References: <20070926104125.A31491@humbolt.us.dell.com> Message-ID: Matt Domsch wrote: > Once more, with a few more verbose messages about missing BRs: ... > akode-2.0.1-8.fc8 (buildroot) rdieter fails due to awol pulseaudio-devel. Looks like the latest/rawhide pulseaudio includes (only) unversioned: Obsoletes: pulseaudio-devel suggestions? -- Rex From jkeating at redhat.com Wed Sep 26 15:57:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 11:57:43 -0400 Subject: Dependency problems in today's updates In-Reply-To: <1190819201.10711.50.camel@vincent52.localdomain> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> Message-ID: <20070926115743.6303baad@redhat.com> On Wed, 26 Sep 2007 11:06:41 -0400 Matthew Saltzman wrote: > Does that mean the workaround is to rpm -e xulrunner? Yes, if you happened to force the installation of xulrunner on the one day it showed up (with it's broken deps), you need to remove it manually. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Sep 26 16:00:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 12:00:37 -0400 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-26 In-Reply-To: References: <20070926104125.A31491@humbolt.us.dell.com> Message-ID: <20070926120037.625245da@redhat.com> On Wed, 26 Sep 2007 10:54:35 -0500 Rex Dieter wrote: > fails due to awol pulseaudio-devel. Looks like the latest/rawhide > pulseaudio includes (only) unversioned: > Obsoletes: pulseaudio-devel pulseaudio-libs-devel is the package you want to build against. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Sep 26 16:06:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Sep 2007 11:06:01 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-26 References: <20070926104125.A31491@humbolt.us.dell.com> <20070926120037.625245da@redhat.com> Message-ID: Jesse Keating wrote: > On Wed, 26 Sep 2007 10:54:35 -0500 > Rex Dieter wrote: > >> fails due to awol pulseaudio-devel. Looks like the latest/rawhide >> pulseaudio includes (only) unversioned: >> Obsoletes: pulseaudio-devel > > pulseaudio-libs-devel is the package you want to build against. thanks. I'd argue the pkg should still use (something like): Obsoletes: pulseaudio-devel < %{version}-%{release} -- Rex From mjs at CLEMSON.EDU Wed Sep 26 16:12:06 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 12:12:06 -0400 Subject: Dependency problems in today's updates In-Reply-To: <20070926115743.6303baad@redhat.com> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> <20070926115743.6303baad@redhat.com> Message-ID: <1190823126.15397.7.camel@vincent52.localdomain> On Wed, 2007-09-26 at 11:57 -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 11:06:41 -0400 > Matthew Saltzman wrote: > > > Does that mean the workaround is to rpm -e xulrunner? > > Yes, if you happened to force the installation of xulrunner on the one > day it showed up (with it's broken deps), you need to remove it > manually. I don't recall forcing anything--it just showed up. That does fix the Firefox dep, but I still have the other problem: the setroubleshoot update wants selinux-policy-base, which doesn't exist AFAIK. Thanks. > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at CLEMSON.EDU Wed Sep 26 16:25:05 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 12:25:05 -0400 Subject: NetworkManager-0.7 can't make new wireless connection Message-ID: <1190823905.15397.16.camel@vincent52.localdomain> I have NetworkManager-0.7.0-0.3.svn2852.fc8. When I pop down the menu in nm-applet and select "connect to new wireless network", nothing happens. I would expect a popup menu allowing me to specify a SSID and connection protocols, but I get nothing. This is a Thinkpad T61 with iwl3945, in case that matters. Kernel is 2.6.23-0.202.rc8.f8, but the issue has occurred ever since the first NM-0.7 was pushed, with whatever kernels have been pushed since then. I have set selinux to permissive, so there shouldn't be anything preventing access to anything. One thing is, the SSID I want is hidden, and it's the only one in the area. Bug? Or user error? Anyone have it working? Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From tibbs at math.uh.edu Wed Sep 26 16:28:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Sep 2007 11:28:26 -0500 Subject: Summary of the 2007-09-25 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the abbreviated packaging committee meeting which occurred on 2007-09-25 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes200709-25 Executive summary: No new guidelines this week. The Python Eggs guidelines don't seem to have been discussed by FESCo last week, so they're carried over. There are no new issues pending FESCo ratification. Miscellaneous business: There was some on-list discussion regarding virtual provides for the TeX distribution packages which carried over slightly into the IRC meeting. * http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming - J< From darrellpf at gmail.com Wed Sep 26 16:37:39 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Wed, 26 Sep 2007 09:37:39 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190823905.15397.16.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: On 9/26/07, Matthew Saltzman wrote: > I have NetworkManager-0.7.0-0.3.svn2852.fc8. When I pop down the menu > in nm-applet and select "connect to new wireless network", nothing > happens. I would expect a popup menu allowing me to specify a SSID and > connection protocols, but I get nothing. > > This is a Thinkpad T61 with iwl3945, in case that matters. Kernel is > 2.6.23-0.202.rc8.f8, but the issue has occurred ever since the first > NM-0.7 was pushed, with whatever kernels have been pushed since then. I > have set selinux to permissive, so there shouldn't be anything > preventing access to anything. One thing is, the SSID I want is hidden, > and it's the only one in the area. > > Bug? Or user error? Anyone have it working? > The latest release of Network Manager are really... cranky. I have a Compaq 6710B with iwl3945. It worked with FC7 and rawhide up until about two weeks ago. I managed to get it to work with kernel 181. I make sure a wired cable is plugged in (strange, but it seems to work), do a restart of haldaemon, then NetworkManger and I have wireless. There are some updates pending but they are on hold with the freeze. I also have rawhide on a Dell Inspiron 9300 laptop with an ipw2200 card. Again, since about two weeks ago it doesn't initially default connect to my AP, and won't automatically reconnect (eg, when the microwave in my kitchen shields the signal.). On that machine the latest kernel works. What you're seeing is probably a combination of problems with both NetworkManager and recent iwl3945 code. darrell From bruno at wolff.to Wed Sep 26 16:37:12 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 26 Sep 2007 11:37:12 -0500 Subject: Fedora 7 Updates Busted Again? In-Reply-To: References: <1190748649.5242.10.camel@raptor.sr.unh.edu> Message-ID: <20070926163712.GA2018@wolff.to> On Tue, Sep 25, 2007 at 15:36:29 -0400, Tom Diehl wrote: > On Tue, 25 Sep 2007, Thomas J. Baker wrote: > > > > >Did the Fedora 7 updates get whacked again? It seems my mirror of > >kernel.org just deleted almost all the F7 updates. > > Yep!! > > Jesse and company are working on it. I don't think it was fixed correctly. The files came back, but the updates from yesterday aren't available. From Matt_Domsch at dell.com Wed Sep 26 16:39:03 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 26 Sep 2007 11:39:03 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-26 In-Reply-To: <200709261748.06549.opensource@till.name> References: <20070926104129.A3810@humbolt.us.dell.com> <200709261748.06549.opensource@till.name> Message-ID: <20070926163903.GC28612@auslistsprd01.us.dell.com> On Wed, Sep 26, 2007 at 05:48:00PM +0200, Till Maas wrote: > On Mi September 26 2007, Matt Domsch wrote: > > > cryptsetup-luks-1.0.5-5.fc8 (build/make) pjones > ^^^^^^ > It seems you changed from showing e-mail addresses to usernames here, the > problem is, that in the previous report, I was listed there, too. (I > comaintain cryptsetup-luks), but now I am not listed there anymore. The packagedb shows me: Fedora|cryptsetup-luks|A utility for setting up encrypted filesystems|pjones||agk,mornfall,till,mbroz,dwysocha I only sent email to the person in field [3] (in this case, pjones). I'll add fields [4] (QA contact) and [5] (cc: list) to future emails. > The issue is fixed btw, it was already comitted to cvs but now it is > also build into an srpm. I do not know how often it is the case that > BRs are fixed in cvs but not in the srpm, but maybe it is worth > checking for this, too. I can't look in CVS for each package from where I'm at. I go on built SRPMS, as that's what our users will get. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jkeating at redhat.com Wed Sep 26 16:40:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 12:40:30 -0400 Subject: Fedora x86_64 rawhide rebuild in mock status 2007-09-26 In-Reply-To: References: <20070926104125.A31491@humbolt.us.dell.com> <20070926120037.625245da@redhat.com> Message-ID: <20070926124030.543f4562@redhat.com> On Wed, 26 Sep 2007 11:06:01 -0500 Rex Dieter wrote: > thanks. I'd argue the pkg should still use (something like): > Obsoletes: pulseaudio-devel < %{version}-%{release} Bugzilla is -> thataway... (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Wed Sep 26 16:51:28 2007 From: buildsys at redhat.com (Build System) Date: Wed, 26 Sep 2007 12:51:28 -0400 Subject: rawhide report: 20070926 changes Message-ID: <200709261651.l8QGpSe5001139@porkchop.devel.redhat.com> New package cgi-util A C library for creating Common Gateway Interface ("CGI") programs New package generic-logos Icons and pictures New package php-pear-MDB2-Driver-mysqli MySQL Improved MDB2 driver New package python-fedora Python modules for talking to Fedora Infrastructure Services Updated Packages: NetworkManager-1:0.7.0-0.3.svn2886.fc8 -------------------------------------- * Tue Sep 25 2007 Dan Williams - 1:0.7.0-0.3.svn2886 - New snapshot - Make wired device carrier state work in the applet - Fix handling of errors with unencrypted APs - Fix "frozen" applet icon by reporting NM state better - Fix output of AP frequency in nm-tool * Tue Sep 25 2007 Dan Williams - 1:0.7.0-0.3.svn2880 - New snapshot - Fix applet icon sizing on start (mclasen) - Fix nm-tool installation (mclasen) - Fix 'state' method call return (#303271) - Fix 40-bit WEP keys (again) - Fix loop when secrets were wrong/invalid - Fix applet crash when clicking Cancel in the password dialog - Ensure NM doesn't get stuck waiting for the supplicant to re-appear if it crashes or goes away - Make VPN properties applet work again - Increase timeout for network password entry * Fri Sep 21 2007 Dan Williams - 1:0.7.0-0.3.svn2852 - New snapshot (fix unencrypted & 40 bit WEP) PolicyKit-0.6-0.git20070925.fc8 ------------------------------- * Tue Sep 25 2007 David Zeuthen - 0.6-0.git20070925.fc8 - Update to git snapshot PolicyKit-gnome-0.6-0.git20070925.fc8 ------------------------------------- * Tue Sep 25 2007 David Zeuthen - 0.6-0.git20070925.fc8 - Update to git snapshot a2ps-4.13b-68.fc8 ----------------- * Tue Sep 25 2007 Tim Waugh 4.13b-68 - Make minus sign work in ISO-8859-5 (bug #252314). alex-2.1.0-5.fc8 ---------------- * Tue Sep 25 2007 Bryan O'Sullivan - 2.1.0-5 - don't try to build on ppc64 * Tue Sep 25 2007 Bryan O'Sullivan - 2.1.0-4 - build requires autoconf * Sun Jul 22 2007 Bryan O'Sullivan - 2.1.0-3 - apply a few cleanups from Jens Petersen anaconda-11.3.0.34-1 -------------------- * Tue Sep 25 2007 Jeremy Katz 11.3.0.34-1 - A few upgrade fixes; look for packages in /var/cache/yum/anaconda-upgrade/packages so that you can predownload them - Point to the mirror list for the "Additional Fedora Software" - Font movement (#304271) - Fix where firmware is looked for anacron-2.3-56.fc8 ------------------ * Tue Sep 25 2007 Marcela Maslanova 2.3-56 - cron.{hourly,daily} work correct -> remove checking whether cron.daily has been run - persist: run pc between midnight and 4:02 -> cron.daily run twice. - rhbz#296741 aspell-fo-51:0.2.16-7.fc8 ------------------------- * Tue Sep 25 2007 Ivana Varekova - 51:0.2.16-7 - increase epoch * Mon Sep 17 2007 Ivana Varekova - 50:0.2.16-6 - update to 0.2.16 * Thu Mar 29 2007 Ivana Varekova - 50:0.51-6 - add documentation audit-1.6.2-1.fc8 ----------------- * Tue Sep 25 2007 Steve Grubb 1.6.2-1 - Add support for searching by posix regular expressions in auparse - Route DEAMON events into rt interface - If event pipe is full, try again after doing local logging - Optionally add node/machine name to records in audit daemon - Update ausearch/aureport to specify nodes to search on - Fix segfault interpretting saddr fields in avcs authconfig-5.3.18-1.fc8 ----------------------- * Tue Sep 25 2007 Tomas Mraz - 5.3.18-1 - improve krb5.conf handling (#238766) ballbuster-1.0-3.fc8 -------------------- cdrkit-1.1.6-6.fc8 ------------------ * Tue Sep 25 2007 Harald Hoyer - 1.1.6-6 - fixed readcd man page symlink chkconfig-1.3.36-1 ------------------ * Tue Sep 25 2007 Bill Nottingham 1.3.36-1 - buildreq popt-devel, link it dynamically (#279531) - translation updates: kn, ko, mr, ro crontabs-1.10-18.fc8 -------------------- * Tue Sep 25 2007 Marcela Maslanova 1.10-18 - cron.{hourly, daily,...} run ok - rhbz#296741 cryptsetup-luks-1.0.5-7.fc8 --------------------------- * Thu Aug 30 2007 Till Maas - 1.0.5-7 - update URL - update license tag - recode ChangeLog from latin1 to uf8 - add smp_mflags to make * Fri Aug 24 2007 Till Maas - 1.0.5-6 - cleanup BuildRequires: - removed versions, packages in Fedora are new enough - changed popt to popt-devel cups-1:1.3.2-3.fc8 ------------------ * Tue Sep 25 2007 Tim Waugh 1:1.3.2-3 - Don't strip foomatic recommended strings from make/model names. * Fri Sep 21 2007 Tim Waugh 1:1.3.2-2 - Write printcap when remote printers have timed out (bug #290831). * Wed Sep 19 2007 Tim Waugh 1:1.3.2-1 - Include Till Kamppeter's dnssd backend. - 1.3.2. - No longer need str2512 patches. cyrus-imapd-2.3.9-7.fc8 ----------------------- * Sun Sep 23 2007 Tomas Janousek - 2.3.9-7 - updated the getgrouplist patch - fixed a few undeclared functions (and int to pointer conversions) dovecot-1:1.0.5-1.fc8 --------------------- * Tue Sep 25 2007 Tomas Janousek - 1:1.0.5-1 - downgraded to lastest upstream stable (1.0.5) duel3-0.1-0.4.20060225.fc8 -------------------------- * Tue Sep 25 2007 Hans de Goede 0.1-0.4.20060225 - Use opengl-games-utils wrapper to show error dialog when DRI is missing eclipse-cdt-1:4.0.1-0.2.v200709241202cvs.fc8 -------------------------------------------- * Tue Sep 25 2007 Andrew Overholt 4.0.1-0.2.v200709241202cvs - Fix moving of arch-specific plugins that haven't been updated to new version. * Mon Sep 24 2007 Andrew Overholt 4.0.1-0.1.v200709241202cvs - 4.0.1 RC. - Update autotools for Binaries fix. em8300-kmod-0.16.3-5.2.6.23_0.202.rc8.fc8 ----------------------------------------- * Tue Sep 25 2007 Ville Skytt?? - Rebuild for kernel 2.6.23-0.202.rc8.fc8. fedora-release-notes-7.92-1 --------------------------- * Sun Sep 16 2007 Paul W. Frields - 7.92-1 - Include new start page - Push new content for F8 test3 * Wed Sep 12 2007 Paul W. Frields - 7.91-1 - Link stylesheet resources to save space * Mon Aug 27 2007 Paul W. Frields - 7.90-2 - Remove superfluous PNG files - Bump release for rebranding change in homepage firefox-2.0.0.6-10.fc8 ---------------------- * Tue Sep 25 2007 Martin Stransky 2.0.0.6-10 - Removed hardcoded MAX_PATH, PATH_MAX and MAXPATHLEN macros * Mon Sep 24 2007 Christopher Aillon 2.0.0.6-9 - Startup notification support frysk-0.0.1.2007.09.24-1.fc8 ---------------------------- * Mon Sep 24 2007 Andrew Cagney - 0.0.1.2007.09.24-1 - Update files list. - Fix path to dogtail_scripts. - Fix touch paths to allow for build sub-directory. - Import frysk-0.0.1.2007.09.24.tar.bz2. - Remove frysk-20060922-a-cast.patch - Remove frysk-xfail-2130.patch. - Run bootstrap.sh over source tree. - Add autoconf, automake, and libtool to BuildRequires. - Remove binutils-devel from BuildRequires. - Build in separate sub-directory. - Do not force JV_SCAN into the build environment. - Update Licence. - Change BuildRoot to prefered fedora format. - Expand Summary to mention debugging. gcc-4.1.2-28 ------------ * Tue Sep 25 2007 Jakub Jelinek 4.1.2-28 - update from gcc-4_1-branch (-r127672:128736) - PRs bootstrap/33418, c++/31941, c++/32113, java/31842, target/33256, tree-optimization/33142 - add support for artificial, error and warning attributes - restore Java CNI ABI compatibility broken by JDWP changes (Keith Seitz) - fix ICE with set_rhs allowing non-gimple (Roger Sayle, #247407, PR tree-optimization/32694) - fix ICE on Fortran interface-body declaring current subroutine name (Paul Thomas, #300851, PR fortran/20880) gdb-6.6-30.fc8 -------------- * Tue Sep 25 2007 Jan Kratochvil - 6.6-30 - Fix re-setting of the ctors/dtors breakpoints with multiple PCs (BZ 301701). - Avoid one useless user question in the core files locator (build-id). * Sun Sep 23 2007 Jan Kratochvil - 6.6-29 - Fixed the kernel VDSO loading (`warning: no loadable sections found in ...'). - Fix the testcase for pending signals (from BZ 233852). * Sat Sep 22 2007 Jan Kratochvil - 6.6-28 - Support also the `$allocate' and `$delete' ctor/dtor variants (BZ 301701). - Fix the build compatibility with texinfo >= 4.10. - Fix the testcase for pending signals (from BZ 233852). gnome-applets-1:2.20.0-5.fc8 ---------------------------- * Tue Sep 25 2007 - Bastien Nocera - 1.2.20.0-5 - Fix possible crasher in the mixer messages when we receive an unhandled message (#302881) grig-0.7.2-3.fc8 ---------------- gtk2-2.12.0-4.fc8 ----------------- * Tue Sep 25 2007 Matthias Clasen - 2.12.0-4 - Fix a crash in simple search - Drop obsolete Obsoletes and Conflicts * Thu Sep 20 2007 Matthias Clasen - 2.12.0-3 - Fix a problem with swt and tooltips * Tue Sep 18 2007 Matthias Clasen - 2.12.0-2 - Adapt to tracker ABI changes gwget-0.99-3.fc8 ---------------- * Wed Sep 26 2007 Christoph Wickert - 0.99-3 - Build against epiphany 2.20 * Sat Aug 25 2007 Christoph Wickert - 0.99-2 - Run intltoolize to get locales installed properly with intltool 0.36.1 - Update license tag * Sat Jun 09 2007 Christoph Wickert - 0.99-1 - Update to 0.99 - Add support for epiphany 2.19 - Update desktop file hal-0.5.10-0.git20070925.fc8 ---------------------------- * Tue Sep 25 2007 - David Zeuthen - 0.5.10-0.git20070925.fc8 - Update to git snapshot hal-info-20070925-1.fc8 ----------------------- * Tue Sep 25 2007 David Zeuthen - 20070925-1.fc8 - Update to latest release. * Fri Aug 31 2007 David Zeuthen - 20070831-1.fc8 - Update to latest release. hamlib-1.2.6.2-1.fc8 -------------------- * Tue Sep 25 2007 Denis Leroy - 1.2.6.2-1 - Update to new upstream 1.2.6.2 - Added rigsmtr binary hplip-2.7.7-5.fc8 ----------------- * Tue Sep 25 2007 Tim Waugh 2.7.7-5 - Prevent hpfax trying to load configuration files as user lp. kcc-2.3-27 ---------- * Fri Sep 21 2007 Akira TAGOH - 2.3-27 - clean up the spec file. kdelibs-6:3.5.7-23.fc8 ---------------------- * Tue Sep 25 2007 Than Ngo - 6:3.5.7-23 - fix rh#243611, autostart from XDG_CONFIG_DIRS * Sun Sep 09 2007 Kevin Kofler 6:3.5.7-22 - Remove Conflicts: kdelibs4-devel, let kdelibs4 decide whether we conflict (allows using the old /opt/kde4 versions for now) * Wed Aug 22 2007 Rex Dieter 6:3.5.7-21 - vcard30 patch (kde#115219,rh#253496) - -devel: restore awol Requires (< f8 only) (#253801) - License: LGPLv2 kudzu-1.2.76-1 -------------- * Tue Sep 25 2007 Bill Nottingham 1.2.76-1 - scsi: minor fix to pull *a* tape device name - translation updates: kn - buildrequire popt-devel, link it statically (#279451) * Wed Sep 05 2007 Adam Jackson 1.2.75-1 - Add pcidom to the exported slot list of pciDevice. - Add clog target to Makefile. * Thu Aug 23 2007 Jeremy Katz - 1.2.74-1 - fix module names for new firewire stack changing (#231708) libsvm-2.84-5.fc8 ----------------- * Thu Aug 30 2007 Ding-Yi Chen - 2.84-5 - Split out libsvm-java - Add libsvm.so livecd-tools-012-1.fc8 ---------------------- * Tue Sep 25 2007 Jeremy Katz - 012-1 - Allow %post --nochroot to work for putting files in the root of the iso - Set environment variables for when %post is run - Add progress for downloads (Colin Walters) - Add cachedir option (Colin Walters) - Fixes for ppc/ppc64 to work again - Clean up bootloader config a little - Enable swaps in the default desktop config - Ensure all configs are installed (#281911) - Convert method line to a repo for easier config reuse (jkeating) - Kill the modprobe FATAL warnings (#240585) - Verify isos with iso-to-disk script - Allow passing xdriver for setting the xdriver (#291281) - Add turboliveinst patch (Douglas McClendon) - Make iso-to-disk support --resetmbr (#294041) - Clean up filesystem layout (Douglas McClendon) - Manifest tweaks for most configs mash-0.2.8-1.fc8 ---------------- * Tue Sep 25 2007 Bill Nottingham 0.2.8-1 - libflashsupport (#305541) methane-1.4.7-3.fc8 ------------------- minicom-2.2-5.fc8 ----------------- * Sun Sep 23 2007 Lubomir Kundrak 2.2-5 - Fix capture file handling (#302081) mkinitrd-6.0.18-1.fc8 --------------------- * Tue Sep 25 2007 Peter Jones - 6.0.18-1 - Fix segfault on x86_64 paravirt (#304731, patch from Harald Hoyer) mod_auth_kerb-5.3-6 ------------------- * Tue Sep 25 2007 Joe Orton 5.3-6 - fix configure invocation (#301181) neon-0.27.2-2 ------------- * Tue Sep 25 2007 Joe Orton 0.27.2-2 - update to 0.27.2 nkf-1:2.0.8b-1.fc8 ------------------ * Fri Sep 21 2007 Akira TAGOH - 1:2.0.8b-1 - New upstream release. - clean up the spec file. octave-6:2.9.14-2.fc8 --------------------- * Tue Sep 25 2007 Orion Poplawski 2.9.14-2 - Add /usr/share/octave/packages for add on packages and %ghost /usr/share/octave/octave_packages - Add patch for octave package manager that will be going upstream pam-0.99.8.1-10.fc8 ------------------- * Tue Sep 25 2007 Tomas Mraz 0.99.8.1-10 - update db4 to 4.6.19 (#274661) * Fri Sep 21 2007 Tomas Mraz 0.99.8.1-9 - do not preserve contexts when copying skel and other namespace.init fixes (#298941) - do not free memory sent to putenv (#231698) * Wed Sep 19 2007 Tomas Mraz 0.99.8.1-8 - add pam_selinux_permit module - pam_succeed_if: fix in operator (#295151) passwd-0.74-5.fc8 ----------------- * Tue Sep 25 2007 Tomas Mraz 0.74-5 - buildrequires popt-devel pulseaudio-0.9.7-0.13.svn20070925.fc8 ------------------------------------- * Tue Sep 25 2007 Lennart Poettering 0.9.7-0.13.svn20070925 - Remove libpulsecore.so symlink from pulseaudio-libs-devel to avoid multilib issues pungi-1.1.2-1.fc8 ----------------- * Tue Sep 25 2007 Jesse Keating - 1.1.2-1 - Fix location of media.repo file. python-iniparse-0.2.2-1.fc8 --------------------------- * Tue Sep 25 2007 Tim Lauridsen - 0.2.2-1 - Updated to release 0.2.2 - removed patch to to fix problems with out commented lines, included in upstream source * Wed Sep 12 2007 Tim Lauridsen - 0.2.1-4 - Added some logic to get the right python-setuptools buildrequeres - based on the fedora version, to make the same spec file useful in - all fedora releases. python-virtinst-0.300.1-1.fc8 ----------------------------- * Tue Sep 25 2007 Daniel P. Berrange - 0.300.1-1.fc8 - Update to 0.300.1 release - Added PXE support rpmdevtools-6.2-1.fc8 --------------------- * Sat Sep 08 2007 Ville Skytt?? - 6.2-1 - Sync deps with Fedora's new "assumed present in buildroots" packages list. * Thu Sep 06 2007 Ville Skytt?? - Init script template cleanups. * Tue Aug 28 2007 Ville Skytt?? - Update rpminfo to version 2004-07-07-02. rsyslog-1.19.6-2.fc8 -------------------- * Tue Sep 25 2007 Tomas Heinrich 1.19.6-2 - fix message suppression (303341) * Tue Sep 25 2007 Tomas Heinrich 1.19.6-1 - upstream bugfix release * Tue Aug 28 2007 Peter Vrabec 1.19.2-1 - upstream bugfix release - support for negative app selector, patch from theinric at redhat.com selinux-policy-3.0.8-13.fc8 --------------------------- * Mon Sep 24 2007 Dan Walsh 3.0.8-13 - Allow login programs to set ioctl on /proc * Mon Sep 24 2007 Dan Walsh 3.0.8-12 - Allow nsswitch apps to read samba_var_t slang-2.1.2-2.fc8 ----------------- * Tue Sep 25 2007 Miroslav Lichvar - 2.1.2-2 - fix integer underflow in compute_hash (#302181) - fix SLang_set_error when called from signal handler (#297661) squid-7:2.6.STABLE16-2.fc8 -------------------------- * Tue Sep 25 2007 Martin Bacovsky - 7:2.6.STABLE16-2 - our fd_config patch was replaced by upstream's version - Source1 (FAQ.sgml) points to local source (upstream's moved to wiki) stormbaancoureur-1.5.1-2.fc8 ---------------------------- * Tue Sep 25 2007 Hans de Goede 1.5.1-2 - Use opengl-games-utils wrapper to show error dialog when DRI is missing sword-1.5.9-7.fc8 ----------------- * Tue Sep 25 2007 Deji Akingunola - 1.5.9-7 - Fix the build failure due to glibc open() check system-config-firewall-1.0.7-1.fc8 ---------------------------------- * Tue Sep 25 2007 Thomas Woerner 1.0.7-1 - new translations - added openvpn to services (rhbz#) - fixed typo in description text for ipsec - using port numbers instead of port names for services - renamed some variables to be consistent - make tolltip better: bigger text, helper modules - dropped unused code: inconsistent handling - make port check button inactive in add_port_cb - new function _addDevice: code cleanup - allow to set variables in ipXtablesConfig, which were not set before - fixed os.system calls in ipXtablesClass to return proper return values - fixed status funciton in ipXtablesClass - new _append_unique function in fw_parser to prevent duplicates - added warning dialog for missing or unusable /etc/sysconfig/ip*tables files - fixed expand of the warning label in the startup dialog system-config-printer-0.7.74.2-3.fc8 ------------------------------------ * Tue Sep 25 2007 Tim Waugh 0.7.74.2-3 - Pull in SVN patch from stable branch for foomatic recommended drivers (bug #292021). system-config-soundcard-2.0.6-9.fc8 ----------------------------------- * Tue Sep 25 2007 Martin Stransky - 2.0.6-9 - fixed #291691 - Sound card not working gives a window with invalid instructions on first boot - rewritting configuration file option splitted to config restore and config reset - used plughw device in the hardware configuration instead of the hw telnet-1:0.17-41.fc8 -------------------- * Tue Sep 25 2007 Adam Tkac 1:0.17-41 - rebased "nodns" patch with patch from Bryn M. Reeves thunderbird-2.0.0.6-5.fc8 ------------------------- * Tue Sep 25 2007 Christopher Aillon 2.0.0.6-5 - Removed hardcoded MAX_PATH, PATH_MAX and MAXPATHLEN macros trackballs-1.1.4-3.fc8 ---------------------- * Tue Sep 25 2007 Hans de Goede 1.1.4-3 - Use opengl-games-utils wrapper to show error dialog when DRI is missing tracker-0.6.3-1.fc8 ------------------- * Tue Sep 25 2007 Deji Akingunola - 0.6.3-1 - Version 0.6.3 vim-2:7.1.119-1.fc8 ------------------- * Tue Sep 25 2007 Karsten Hopp 7.1.119-1 - patchlevel 119 * Mon Sep 24 2007 Karsten Hopp 7.1.116-1 - patchlevel 116 * Fri Sep 07 2007 Karsten Hopp 7.1.100-1 - patchlevel 100 virt-manager-0.5.1-1.fc8 ------------------------ * Tue Sep 25 2007 Daniel P. Berrange - 0.5.1-1.fc8 - Updated to 0.5.1 release - Open connections in background - Make VNC connection retries more robust - Allow changing of CDROM media on the fly - Add PXE boot installation of HVM guests - Allow tunnelling VNC over SSH wpa_supplicant-1:0.5.7-9.fc8 ---------------------------- * Tue Sep 25 2007 Dan Williams - 0.5.7-9 - Always allow explicit wireless scans triggered from a control interface Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed From kevin.kofler at chello.at Wed Sep 26 16:48:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 26 Sep 2007 16:48:37 +0000 (UTC) Subject: artwork split up References: <45abe7d80709251317p6e0b8223q372921c6edef396a@mail.gmail.com> <20070925201940.GA27099@jadzia.bu.edu> <46F97860.6070705@fedoraproject.org> <1190801705.2314.10.camel@localhost.localdomain> <46FA5E24.70702@nicubunu.ro> Message-ID: Nicu Buculei nicubunu.ro> writes: > People on the Art Team have experience mostly with GNOME theming, but if > you come to the art list with the request and provide some handy KDM > guides, there may be someone wanting to work on it. For the old themes like FedoraDNA, all that should be needed is the backgrounds being still there. What does need work for KDM is the new Infinity theme though. Kevin Kofler From mjs at CLEMSON.EDU Wed Sep 26 17:04:21 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 13:04:21 -0400 Subject: No hardware clock in kernel-2.6.23-0.202.rc8.fc8.x86_64 Message-ID: <1190826261.15397.29.camel@vincent52.localdomain> I get the following messages immediately after the Welcome...press 'I' messages on startup: Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Setting clock (utc): [OK] Starting udev: udevd-event[1316]: node_symlink: device node '/dev/rtc/' already exists, link to '/dev/rtc0' will not overwrite it. After logging in I run ls -l /dev/rtc*, and I get: crw------- 1 root root 10, 135 2007-09-26 12:44 /dev/rtc crw-r--r-- 1 root root 254, 0 2007-09-26 12:44 /dev/rtc0 Running hwclock --debug produces: hwclock from util-linux-ng 2.13 hwclock: Open of /dev/rtc failed, errno=19: No such device. No usable clock interface found. Cannot access the Hardware Clock by any known method. On shutdown, the attempt to write the time to the hardware clock also fails (of course). This is a Thinkpad T61. I don't think this occurred with earlier F8T2 kernels. The device properties are the same as on my F7 machine, a Thinkpad T41. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mike.cohler at gmail.com Wed Sep 26 17:04:16 2007 From: mike.cohler at gmail.com (Mike C) Date: Wed, 26 Sep 2007 17:04:16 +0000 (UTC) Subject: Fedora 7 Updates Busted Again? References: <1190748649.5242.10.camel@raptor.sr.unh.edu> <20070926163712.GA2018@wolff.to> Message-ID: Bruno Wolff III wolff.to> writes: > I don't think it was fixed correctly. The files came back, but the updates from > yesterday aren't available. > I did not see any update rpms on the main f7 updates repo - maybe something else has got broken? From bruno at wolff.to Wed Sep 26 17:46:34 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 26 Sep 2007 12:46:34 -0500 Subject: Fedora 7 Updates Busted Again? In-Reply-To: References: <1190748649.5242.10.camel@raptor.sr.unh.edu> <20070926163712.GA2018@wolff.to> Message-ID: <20070926174634.GA5569@wolff.to> On Wed, Sep 26, 2007 at 17:04:16 +0000, Mike C wrote: > Bruno Wolff III wolff.to> writes: > > > I don't think it was fixed correctly. The files came back, but the updates from > > yesterday aren't available. > > > I did not see any update rpms on the main f7 updates repo - maybe something else > has got broken? These packages were announced on the 25th: * Fedora 7 Update: mencal-2.3-1.fc7 updates * Fedora 7 Update: QuantLib-0.8.1-3.fc7 updates * Fedora 7 Update: smartmontools-5.37-3.2.fc7 updates * Fedora 7 Update: pv-1.1.0-1.fc7 updates * Fedora 7 Update: libieee1284-0.2.11-1.fc7 updates * Fedora 7 Update: solarwolf-1.5-2.fc7 updates * Fedora 7 Update: kernel-xen-2.6-2.6.20-2934.fc7 updates * Fedora 7 Update: ladspa-cmt-plugins-1.15-6.fc7 updates * Fedora 7 Update: ladspa-blop-plugins-0.2.8-5.fc7 updates * Fedora 7 Update: libzzub-0.2.3-8.fc7 updates * [SECURITY] Fedora 7 Update: fuse-2.7.0-5.fc7 updates * [SECURITY] Fedora 7 Update: ntfs-3g-1.913-2.fc7 updates * Fedora 7 Update: mach-0.9.2-2.fc7 updates * Fedora 7 Update: sdljava-0.9.1-4.fc7 updates * Fedora 7 Update: blam-1.8.3-6.fc7 updates * Fedora 7 Update: php-pear-MDB2-Driver-mysql-1.4.1-2.fc7 updates * Fedora 7 Update: mod_fcgid-2.2-1.fc7 updates * Fedora 7 Update: libselinux-2.0.14-7.fc7 updates * [SECURITY] Fedora 7 Update: kernel-2.6.22.7-85.fc7 updates * Fedora 7 Update: gnome-compiz-manager-0.10.4-1.fc7 updates * Fedora 7 Update: gtk-vnc-0.2.0-1.fc7 updates * Fedora 7 Update: suck-4.3.2-18.fc7 updates * Fedora 7 Update: highlight-2.6.4-1.fc7 updates * Fedora 7 Update: crossvc-1.5.2-1.fc7 updates * Fedora 7 Update: bwidget-1.8.0-2.fc7 updates * Fedora 7 Update: tklib-0.4.1-6.fc7 updates * Fedora 7 Update: spr-07.00.00-1.fc7 updates * Fedora 7 Update: tclpro-1.5.0-7.20061030cvs.fc7 updates * Fedora 7 Update: tcldebugger-1.4-2.20061030cvs.fc7 updates * Fedora 7 Update: python-vorbis-1.5-0.1.a updates * [SECURITY] Fedora 7 Update: bugzilla-3.0.2-0.fc7 updates * Fedora 7 Update: bouml-2.31.2-1.fc7 updates * Fedora 7 Update: ladspa-rev-plugins-0.3.1-3.fc7 updates * Fedora 7 Update: ladspa-vco-plugins-0.3.0-5.fc7 updates * Fedora 7 Update: ladspa-fil-plugins-0.1.0-2.fc7 updates * Fedora 7 Update: ladspa-mcp-plugins-0.3.0-4.fc7 updates * Fedora 7 Update: glob2-0.9.1-2.fc7 updates * Fedora 7 Update: vbetool-0.7-2.fc7 updates * Fedora 7 Update: opengl-games-utils-0.1-2.fc7 updates * Fedora 7 Update: wcstools-3.7.0-1.fc7 updates * [SECURITY] Fedora 7 Update: php-5.2.4-1.fc7 updates * Fedora 7 Update: gnomebaker-0.6.2-1.fc7 updates * Fedora 7 Update: libtiff-3.8.2-8.fc7 updates * Fedora 7 Update: mysql-5.0.45-1.fc7 updates From bpepple at fedoraproject.org Wed Sep 26 17:58:36 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 26 Sep 2007 13:58:36 -0400 Subject: Plan for tomorrows (20070926) FESCO meeting Message-ID: <1190829516.6496.1.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- transition plan for switching devel to rawhide - warren /topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy /topic Status Update: FESCo Proposal Template - f13 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nando at ccrma.Stanford.EDU Wed Sep 26 18:04:02 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 26 Sep 2007 11:04:02 -0700 Subject: Announcing the Audio Creation SIG / CCRMA merger effort In-Reply-To: <1190251611.29210.54.camel@cmn3.stanford.edu> References: <46EED66E.8040009@hhs.nl> <1190058386.16960.67.camel@localhost6.localdomain6> <46EEDA72.9040706@hhs.nl> <1190059606.16960.79.camel@localhost6.localdomain6> <1190068375.12423.11.camel@cmn3.stanford.edu> <1190073567.16960.90.camel@localhost6.localdomain6> <1190229615.29210.28.camel@cmn3.stanford.edu> <1190232247.6854.22.camel@localhost6.localdomain6> <1190251611.29210.54.camel@cmn3.stanford.edu> Message-ID: <1190829842.8346.15.camel@cmn3.stanford.edu> On Wed, 2007-09-19 at 18:26 -0700, Fernando Lopez-Lezcano wrote: > On Wed, 2007-09-19 at 14:04 -0600, Richi Plana wrote: > > Since you (Fernando) know the packages better than most, could you list > > the apps you think should be given higher priority for transitioning? > > I can make a list, of course. I suggested already all the ladspa plugin > collections I host and that's what Hans already submitted, those have > immediate impact in all apps that use ladpsa plugins. The reviewer response for the ladspa plugins has been fantastic! > I'll post more suggestions tomorrow (time to go home)... Sorry for the delay, some suggestions follow, in no particular order: qarecord: simple recorder application for alsa and jack ecasound: command line multitrack player / recorder, very good. meterbridge: software meterbridge for jack jaaa/japa: spectrum analysers for jack tapiir: multi delay line realtime processor jamin: audio mastering tool (good companion to ardour) bitmeter: "bit level" diagnostic tool for jack timemachine: "always on" jack recorder ams: alsa/jack modular synth amsynth: software synth aeolus: synthesized pipe organ qmidiarp/qmidicontrol/qmidiroute: small midi processing utils kmidimon: midi monitoring app and many more, of course.... -- Fernando From sundaram at fedoraproject.org Wed Sep 26 18:22:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 26 Sep 2007 23:52:06 +0530 Subject: Plan for tomorrows (20070926) FESCO meeting In-Reply-To: <1190829516.6496.1.camel@kennedy> References: <1190829516.6496.1.camel@kennedy> Message-ID: <46FAA34E.7050408@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- transition plan for switching devel to > rawhide - warren > > /topic Status Update: Compat Policy > http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy > > /topic Status Update: FESCo Proposal Template - f13 > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule Can FESCo look into http://fedoraproject.org/wiki/RahulSundaram/WhyUpstream for making it a guideline? Rahul From tjb at unh.edu Wed Sep 26 18:27:09 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 26 Sep 2007 14:27:09 -0400 Subject: Dependency problems in today's updates In-Reply-To: <1190823126.15397.7.camel@vincent52.localdomain> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> <20070926115743.6303baad@redhat.com> <1190823126.15397.7.camel@vincent52.localdomain> Message-ID: <1190831229.7965.6.camel@raptor.sr.unh.edu> On Wed, 2007-09-26 at 12:12 -0400, Matthew Saltzman wrote: > On Wed, 2007-09-26 at 11:57 -0400, Jesse Keating wrote: > > On Wed, 26 Sep 2007 11:06:41 -0400 > > Matthew Saltzman wrote: > > > > > Does that mean the workaround is to rpm -e xulrunner? > > > > Yes, if you happened to force the installation of xulrunner on the one > > day it showed up (with it's broken deps), you need to remove it > > manually. > > I don't recall forcing anything--it just showed up. > > That does fix the Firefox dep, but I still have the other problem: the > setroubleshoot update wants selinux-policy-base, which doesn't exist > AFAIK. > > Thanks. > I saw the same thing when updating with pup a few days back. It complained about not having the correct version of selinux (along with another dependency problem). I hit OK, unselected the other problematic rpm, then hit update again and it went through the update fine. It happened on all three of my F8T2 systems (two x86_64, one i386). This could be a pup bug but generating the conditions to make it occur again could be difficult. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tjb at unh.edu Wed Sep 26 18:29:53 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 26 Sep 2007 14:29:53 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190823905.15397.16.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: <1190831393.7965.9.camel@raptor.sr.unh.edu> On Wed, 2007-09-26 at 12:25 -0400, Matthew Saltzman wrote: > I have NetworkManager-0.7.0-0.3.svn2852.fc8. When I pop down the menu > in nm-applet and select "connect to new wireless network", nothing > happens. I would expect a popup menu allowing me to specify a SSID and > connection protocols, but I get nothing. > > This is a Thinkpad T61 with iwl3945, in case that matters. Kernel is > 2.6.23-0.202.rc8.f8, but the issue has occurred ever since the first > NM-0.7 was pushed, with whatever kernels have been pushed since then. I > have set selinux to permissive, so there shouldn't be anything > preventing access to anything. One thing is, the SSID I want is hidden, > and it's the only one in the area. > > Bug? Or user error? Anyone have it working? > > Thanks. > -- > Matthew Saltzman > > Clemson University Math Sciences > mjs AT clemson DOT edu > http://www.math.clemson.edu/~mjs > Not working very well for me since NM 0.7 either. I've got a Dell XPS M1210 with iwl3945 too. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tmus at tmus.dk Wed Sep 26 18:33:01 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 26 Sep 2007 16:33:01 -0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190389233.23728.16.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> Message-ID: Richi Plana wrote: > > Whenever I move services from one machine to another (say for a server > upgrade), I never backup /var. The only thing I backup out of it > is /var/www. > Hope you don't use databases such as mysql along with your www stuff, because you'd be sorely missing the databases in that case... Mysql puts databases in /var/lib/mysql per default on Fedora. /Thomas From mattdm at mattdm.org Wed Sep 26 19:06:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Sep 2007 15:06:03 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190823905.15397.16.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: <20070926190603.GA2999@jadzia.bu.edu> On Wed, Sep 26, 2007 at 12:25:05PM -0400, Matthew Saltzman wrote: > I have NetworkManager-0.7.0-0.3.svn2852.fc8. When I pop down the menu [...] > Bug? Or user error? Anyone have it working? It seems pretty broken for me, and apparently others: Like, test3 showstopper level of broken. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Sep 26 19:19:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 15:19:41 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926190603.GA2999@jadzia.bu.edu> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> Message-ID: <20070926151941.6fb844df@redhat.com> On Wed, 26 Sep 2007 15:06:03 -0400 Matthew Miller wrote: > It seems pretty broken for me, and apparently others: > > > > Like, test3 showstopper level of broken. Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the wpa_supplicant that just missed rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From selinux at gmail.com Wed Sep 26 19:31:07 2007 From: selinux at gmail.com (Tom London) Date: Wed, 26 Sep 2007 12:31:07 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926151941.6fb844df@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> Message-ID: <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> On 9/26/07, Jesse Keating wrote: > On Wed, 26 Sep 2007 15:06:03 -0400 > Matthew Miller wrote: > > > It seems pretty broken for me, and apparently others: > > > > > > > > Like, test3 showstopper level of broken. > > Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the > wpa_supplicant that just missed rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 > I have these installed; NM seems to be scanning properly, but seems only to accept HEX keys in the 'prompt for key popups' for both WEP and WPA. That to be expected? tom -- Tom London From myfedora at richip.dhs.org Wed Sep 26 19:57:48 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 26 Sep 2007 13:57:48 -0600 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> Message-ID: <1190836668.13811.4.camel@localhost6.localdomain6> On Wed, 2007-09-26 at 16:33 -0200, Thomas M Steenholdt wrote: > Richi Plana wrote: > > > > Whenever I move services from one machine to another (say for a server > > upgrade), I never backup /var. The only thing I backup out of it > > is /var/www. > Hope you don't use databases such as mysql along with your www stuff, > because you'd be sorely missing the databases in that case... Mysql puts > databases in /var/lib/mysql per default on Fedora. I don't leave them in the Fedora default. I usually use subdirectories like /home/pgsql (though if Fedora decides to standardize on /srv, I'd probably leave it there). Come to think of it, I don't even use the default httpd web pages subdirectory. Most of the sites served by httpd are virtual servers and located in their own /home/ subdirectory. -- Richi Plana From jdennis at redhat.com Wed Sep 26 20:03:22 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 26 Sep 2007 16:03:22 -0400 Subject: Dependency problems in today's updates In-Reply-To: <1190823126.15397.7.camel@vincent52.localdomain> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> <20070926115743.6303baad@redhat.com> <1190823126.15397.7.camel@vincent52.localdomain> Message-ID: <46FABB0A.3060401@redhat.com> Matthew Saltzman wrote: > That does fix the Firefox dep, but I still have the other problem: the > setroubleshoot update wants selinux-policy-base, which doesn't exist > AFAIK. The selinux-policy RPM was missing a provides for selinux-policy-base, that was corrected yesterday morning by Dan and should be in the new selinux-policy-3.0.8-13.fc8 John From denis at poolshark.org Wed Sep 26 20:07:19 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 26 Sep 2007 22:07:19 +0200 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926151941.6fb844df@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> Message-ID: <46FABBF7.50205@poolshark.org> Jesse Keating wrote: > On Wed, 26 Sep 2007 15:06:03 -0400 > Matthew Miller wrote: > >> It seems pretty broken for me, and apparently others: >> >> >> >> Like, test3 showstopper level of broken. > > Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the > wpa_supplicant that just missed rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 Much better. That fixed the missing nm-applet on login. It's pretty odd to have the NM inotify window show up early when logging in, before the gnome panel is even drawn. Did anyone else notice that ? From tjb at unh.edu Wed Sep 26 20:13:51 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 26 Sep 2007 16:13:51 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926151941.6fb844df@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> Message-ID: <1190837631.7965.20.camel@raptor.sr.unh.edu> On Wed, 2007-09-26 at 15:19 -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 15:06:03 -0400 > Matthew Miller wrote: > > > It seems pretty broken for me, and apparently others: > > > > > > > > Like, test3 showstopper level of broken. > > Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the > wpa_supplicant that just missed rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 > With just these two updates on top of yesterdays (no sync of rawhide yet) I cannot connect to a WPA ap but can to an non-encrypted one. I could do this for a bit yesterday too so I'm not sure if it's an improvement. Currently NM/wpa doesn't go through the gnome-keyring. It just prompts me for a password for the WPA ap but the connect/OK button is never enabled. I just tried again (to confirm what the 'engage' button really says) and the dialog that comes up is essentially 0x0 in size so I can't do anything with it. I'll keep watching for NM and wpa_supplicant updates in koji. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jkeating at redhat.com Wed Sep 26 20:16:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 16:16:16 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <46FABBF7.50205@poolshark.org> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <46FABBF7.50205@poolshark.org> Message-ID: <20070926161616.34bcc78a@redhat.com> On Wed, 26 Sep 2007 22:07:19 +0200 Denis Leroy wrote: > It's pretty odd to have the NM inotify window show up early when > logging in, before the gnome panel is even drawn. Did anyone else > notice that ? Yes, that's being worked on, but wasn't a high priority for Test3. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zcerza at redhat.com Wed Sep 26 20:20:31 2007 From: zcerza at redhat.com (Zack Cerza) Date: Wed, 26 Sep 2007 16:20:31 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> Message-ID: <46FABF0F.2010404@redhat.com> Tom London wrote: > On 9/26/07, Jesse Keating wrote: >> On Wed, 26 Sep 2007 15:06:03 -0400 >> Matthew Miller wrote: >> >>> It seems pretty broken for me, and apparently others: >>> >>> >>> >>> Like, test3 showstopper level of broken. >> Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the >> wpa_supplicant that just missed rawhide: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 >> > I have these installed; NM seems to be scanning properly, but seems > only to accept HEX keys in the 'prompt for key popups' for both WEP > and WPA. > > That to be expected? > > tom That NM only accepts hex keys is going to be a big problem for me, too, as my WPA2 AP only even lets me set a passphrase. Of course, I've got bigger problems with my iwl3945 than NM: https://bugzilla.redhat.com/show_bug.cgi?id=303871 Zack From mjs at CLEMSON.EDU Wed Sep 26 20:38:09 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 20:38:09 +0000 Subject: Dependency problems in today's updates In-Reply-To: <1190831229.7965.6.camel@raptor.sr.unh.edu> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> <20070926115743.6303baad@redhat.com> <1190823126.15397.7.camel@vincent52.localdomain> <1190831229.7965.6.camel@raptor.sr.unh.edu> Message-ID: <1190839089.16820.50.camel@vincent52.localdomain> On Wed, 2007-09-26 at 14:27 -0400, Thomas J. Baker wrote: > On Wed, 2007-09-26 at 12:12 -0400, Matthew Saltzman wrote: > > On Wed, 2007-09-26 at 11:57 -0400, Jesse Keating wrote: > > > On Wed, 26 Sep 2007 11:06:41 -0400 > > > Matthew Saltzman wrote: > > > > > > > Does that mean the workaround is to rpm -e xulrunner? > > > > > > Yes, if you happened to force the installation of xulrunner on the one > > > day it showed up (with it's broken deps), you need to remove it > > > manually. > > > > I don't recall forcing anything--it just showed up. > > > > That does fix the Firefox dep, but I still have the other problem: the > > setroubleshoot update wants selinux-policy-base, which doesn't exist > > AFAIK. > > > > Thanks. > > > > I saw the same thing when updating with pup a few days back. It > complained about not having the correct version of selinux (along with > another dependency problem). I hit OK, unselected the other problematic > rpm, then hit update again and it went through the update fine. It > happened on all three of my F8T2 systems (two x86_64, one i386). This > could be a pup bug but generating the conditions to make it occur again > could be difficult. I have the latest selinux, AFAIK (selinux-policy-3.0.8-11.fc8 and the targeted one, and libselinux-2.0.34-3.fc8 and relatives). Still won't update setroubleshoot to 0:1.10.5-1.fc8. Same problem with command-line yum: Missing dependency: selinux-policy-base >= 3.0.7-10 is needed by package setroubleshoot. > > Thanks, > > tjb -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at CLEMSON.EDU Wed Sep 26 20:39:24 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 20:39:24 +0000 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> Message-ID: <1190839164.16820.53.camel@vincent52.localdomain> On Wed, 2007-09-26 at 16:33 -0200, Thomas M Steenholdt wrote: > Richi Plana wrote: > > > > Whenever I move services from one machine to another (say for a server > > upgrade), I never backup /var. The only thing I backup out of it > > is /var/www. > > > > Hope you don't use databases such as mysql along with your www stuff, > because you'd be sorely missing the databases in that case... Mysql puts > databases in /var/lib/mysql per default on Fedora. Not to mention Mailman list configs and archives in /var/lib/mailman. > > /Thomas > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From loganjerry at gmail.com Wed Sep 26 20:44:45 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 26 Sep 2007 14:44:45 -0600 Subject: mediawiki dependencies Message-ID: <870180fe0709261344y6286e1b6l9bffeefa67c4dab7@mail.gmail.com> Even after doing a "yum clean all", I am getting this: [root at localhost ~]# yum install mediawiki Loading "skip-broken" plugin fedora 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 3.8 MB 00:07 updates 100% |=========================| 2.1 kB 00:00 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package mediawiki.i386 0:1.9.4-35.fc7 set to be updated --> Processing Dependency: php-gd for package: mediawiki --> Processing Dependency: php-xml for package: mediawiki --> Processing Dependency: php-pgsql for package: mediawiki --> Running transaction check ---> Package php-gd.i386 0:5.2.2-3 set to be updated --> Processing Dependency: php-common = 5.2.2-3 for package: php-gd ---> Package php-pgsql.i386 0:5.2.2-3 set to be updated --> Processing Dependency: php-common = 5.2.2-3 for package: php-pgsql ---> Package php-xml.i386 0:5.2.2-3 set to be updated --> Processing Dependency: php-common = 5.2.2-3 for package: php-xml --> Finished Dependency Resolution Error: Missing Dependency: php-common = 5.2.2-3 is needed by package php-gd Error: Missing Dependency: php-common = 5.2.2-3 is needed by package php-xml Error: Missing Dependency: php-common = 5.2.2-3 is needed by package php-pgsql [root at localhost ~]# rpm -q php-common php-common-5.2.4-1.fc7 Any idea what's going on? Thanks, -- Jerry James http://loganjerry.googlepages.com/ From mike at miketc.com Wed Sep 26 20:57:34 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 26 Sep 2007 15:57:34 -0500 Subject: Duplicate rpms Message-ID: <1190840254.3485.2.camel@scrappy.miketc.com> Ok, due to my stupidity and interrupting yum doing some upgrades, I have a few dup rpms that I need to get rid of the older ones. Is there a way to do this without tediously going through my whole list rpm by rpm and removing them one by one? Like a search script or command to use and have the older ones removed? Thanks, Mike Chambers From martin.sourada at seznam.cz Wed Sep 26 21:00:26 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 26 Sep 2007 23:00:26 +0200 Subject: Duplicate rpms In-Reply-To: <1190840254.3485.2.camel@scrappy.miketc.com> References: <1190840254.3485.2.camel@scrappy.miketc.com> Message-ID: <1190840426.1124.34.camel@pc-notebook> On Wed, 2007-09-26 at 22:57 +0200, Mike Chambers wrote: > Ok, due to my stupidity and interrupting yum doing some upgrades, I have > a few dup rpms that I need to get rid of the older ones. > > Is there a way to do this without tediously going through my whole list > rpm by rpm and removing them one by one? Like a search script or > command to use and have the older ones removed? > > Thanks, > > Mike Chambers > I believe package-cleanup --dupes (in yum-utils) is what you need. Martin -------------- 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 adam at spicenitz.org Wed Sep 26 21:00:40 2007 From: adam at spicenitz.org (Adam Goode) Date: Wed, 26 Sep 2007 17:00:40 -0400 Subject: Duplicate rpms In-Reply-To: <1190840254.3485.2.camel@scrappy.miketc.com> References: <1190840254.3485.2.camel@scrappy.miketc.com> Message-ID: <46FAC878.2050902@spicenitz.org> Mike Chambers wrote: > Ok, due to my stupidity and interrupting yum doing some upgrades, I have > a few dup rpms that I need to get rid of the older ones. > > Is there a way to do this without tediously going through my whole list > rpm by rpm and removing them one by one? Like a search script or > command to use and have the older ones removed? > > Thanks, > > Mike Chambers > Hi, You might have good luck with the Smart package manager. It has a command "Fix All Problems" that will often fix this. :-) yum install smart-gui Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Wed Sep 26 20:58:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 27 Sep 2007 02:28:56 +0530 Subject: Duplicate rpms In-Reply-To: <1190840254.3485.2.camel@scrappy.miketc.com> References: <1190840254.3485.2.camel@scrappy.miketc.com> Message-ID: <46FAC810.9000204@fedoraproject.org> Mike Chambers wrote: > Ok, due to my stupidity and interrupting yum doing some upgrades, I have > a few dup rpms that I need to get rid of the older ones. > > Is there a way to do this without tediously going through my whole list > rpm by rpm and removing them one by one? Like a search script or > command to use and have the older ones removed? # yum install yum-utils # package-cleanup --cleandupes Rahul From mike at miketc.com Wed Sep 26 21:06:02 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 26 Sep 2007 16:06:02 -0500 Subject: Duplicate rpms In-Reply-To: <46FAC810.9000204@fedoraproject.org> References: <1190840254.3485.2.camel@scrappy.miketc.com> <46FAC810.9000204@fedoraproject.org> Message-ID: <1190840762.3956.1.camel@scrappy.miketc.com> On Thu, 2007-09-27 at 02:28 +0530, Rahul Sundaram wrote: > Mike Chambers wrote: > > Ok, due to my stupidity and interrupting yum doing some upgrades, I have > > a few dup rpms that I need to get rid of the older ones. > > > > Is there a way to do this without tediously going through my whole list > > rpm by rpm and removing them one by one? Like a search script or > > command to use and have the older ones removed? > > # yum install yum-utils > # package-cleanup --cleandupes Thanks Rahul and Martin, that did the trick. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From mjs at CLEMSON.EDU Wed Sep 26 21:16:28 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 21:16:28 +0000 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926151941.6fb844df@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> Message-ID: <1190841388.16820.66.camel@vincent52.localdomain> On Wed, 2007-09-26 at 15:19 -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 15:06:03 -0400 > Matthew Miller wrote: > > > It seems pretty broken for me, and apparently others: > > > > > > > > Like, test3 showstopper level of broken. > > Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the > wpa_supplicant that just missed rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 OK did that. Now left-click pulls up the usual menu, but all selections are greyed out, except VPN Connections. > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From pemboa at gmail.com Wed Sep 26 21:17:56 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 26 Sep 2007 16:17:56 -0500 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> Message-ID: <16de708d0709261417p455a12a4u10246d2b76324e27@mail.gmail.com> On 9/26/07, Thomas M Steenholdt wrote: > Richi Plana wrote: > > > > Whenever I move services from one machine to another (say for a server > > upgrade), I never backup /var. The only thing I backup out of it > > is /var/www. > > > > Hope you don't use databases such as mysql along with your www stuff, > because you'd be sorely missing the databases in that case... Mysql puts > databases in /var/lib/mysql per default on Fedora. > > /Thomas Always thought that /var/lib was a weird place to put database files, as opposed to /var/db or /srv/database -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jdennis at redhat.com Wed Sep 26 21:27:02 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 26 Sep 2007 17:27:02 -0400 Subject: Dependency problems in today's updates In-Reply-To: <1190839089.16820.50.camel@vincent52.localdomain> References: <1190760757.9711.9.camel@vincent52.localdomain> <1190809983.1124.4.camel@pc-notebook> <20070926095252.13173b24@redhat.com> <1190819201.10711.50.camel@vincent52.localdomain> <20070926115743.6303baad@redhat.com> <1190823126.15397.7.camel@vincent52.localdomain> <1190831229.7965.6.camel@raptor.sr.unh.edu> <1190839089.16820.50.camel@vincent52.localdomain> Message-ID: <46FACEA6.2050607@redhat.com> Matthew Saltzman wrote: > I have the latest selinux, AFAIK (selinux-policy-3.0.8-11.fc8 and the > targeted one, and libselinux-2.0.34-3.fc8 and relatives). Still won't > update setroubleshoot to 0:1.10.5-1.fc8. Same problem with command-line > yum: > > Missing dependency: selinux-policy-base >= 3.0.7-10 is needed by > package setroubleshoot. The fix is in selinux-policy-targeted-3.0.8-13.fc8 built 2007-09-25 08:12:41, maybe it just hasn't hit the mirrors yet. From smooge at gmail.com Wed Sep 26 21:28:11 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 26 Sep 2007 15:28:11 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <20070921102620.5bb9ff5a.dcantrell@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> Message-ID: <80d7e4090709261428r7b1a11b2y6fa788113f72915d@mail.gmail.com> On 9/21/07, David Cantrell wrote: > On another note, could we please stop the +1 and -1 garbage replies to people? Just say you agree or disagree. Where did the +1 and -1 trend come from because it's really freaking annoying. > Amateur historian hat on This usage of +1/-1 has been in various places, but seems to have become mainstream sometime in the late 1990's when Slashdot implemented its first karma system. People would ask other people who had karma to +1/-1 an article/comment/etc because they felt it was important etc. It then started being used on other lists as a common meme as anyone who was anyone was reading Slashdot (even if not admitting it). Getting it to stop will be at this point like getting the press not to call criminal software users 'hackers'. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pemboa at gmail.com Wed Sep 26 21:32:24 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 26 Sep 2007 16:32:24 -0500 Subject: [RFC] /var versus /srv In-Reply-To: <80d7e4090709261428r7b1a11b2y6fa788113f72915d@mail.gmail.com> References: <46F33D05.4020701@ncsu.edu> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> <80d7e4090709261428r7b1a11b2y6fa788113f72915d@mail.gmail.com> Message-ID: <16de708d0709261432h71e6d1f2t2767f78b5f6975c7@mail.gmail.com> On 9/26/07, Stephen John Smoogen wrote: > On 9/21/07, David Cantrell wrote: > > > On another note, could we please stop the +1 and -1 garbage replies to people? Just say you agree or disagree. Where did the +1 and -1 trend come from because it's really freaking annoying. > > > > Amateur historian hat on > > This usage of +1/-1 has been in various places, but seems to have > become mainstream sometime in the late 1990's when Slashdot > implemented its first karma system. People would ask other people who > had karma to +1/-1 an article/comment/etc because they felt it was > important etc. It then started being used on other lists as a common > meme as anyone who was anyone was reading Slashdot (even if not > admitting it). > > Getting it to stop will be at this point like getting the press not to > call criminal software users 'hackers'. +1 -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jkeating at redhat.com Wed Sep 26 21:32:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 17:32:31 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190841388.16820.66.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <1190841388.16820.66.camel@vincent52.localdomain> Message-ID: <20070926173231.5e8734ac@redhat.com> On Wed, 26 Sep 2007 21:16:28 +0000 Matthew Saltzman wrote: > OK did that. Now left-click pulls up the usual menu, but all > selections are greyed out, except VPN Connections. Did you logout/reboot after installing those updates? The NetworkManager service would need to be restarted, and the new nm-applet has to be running. (oh and the new wpa_supplicant has to be running too) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Wed Sep 26 21:59:34 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 26 Sep 2007 15:59:34 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <1190839164.16820.53.camel@vincent52.localdomain> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> <1190839164.16820.53.camel@vincent52.localdomain> Message-ID: <1190843974.17132.10.camel@localhost6.localdomain6> On Wed, 2007-09-26 at 20:39 +0000, Matthew Saltzman wrote: > On Wed, 2007-09-26 at 16:33 -0200, Thomas M Steenholdt wrote: > > Richi Plana wrote: > > > > > > Whenever I move services from one machine to another (say for a server > > > upgrade), I never backup /var. The only thing I backup out of it > > > is /var/www. > > > > > > > Hope you don't use databases such as mysql along with your www stuff, > > because you'd be sorely missing the databases in that case... Mysql puts > > databases in /var/lib/mysql per default on Fedora. > > Not to mention Mailman list configs and archives in /var/lib/mailman. If there's any interest, I could make spec files (based off of the latest SRPM) for one of these packages to move the data directory from /var to /srv. Just let me know which packages you find interesting and I'll submit the spec file to the package maintainer (or here if Fedora doesn't want to move it). -- Richi Plana From jdennis at redhat.com Wed Sep 26 22:19:20 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 26 Sep 2007 18:19:20 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190843974.17132.10.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> Message-ID: <46FADAE8.5020404@redhat.com> Richi Plana wrote: > If there's any interest, I could make spec files (based off of the > latest SRPM) for one of these packages to move the data directory > from /var to /srv. Just let me know which packages you find interesting > and I'll submit the spec file to the package maintainer (or here if > Fedora doesn't want to move it). Hold on there partner :-) In the case of mailman (and many other packages) you can't just move things around without updating the selinux policy in lock step. Then there's the issue of breaking all the scripts out in the field which think they know where files are located, you're going to ruffle a lot of feathers if you move things without a big prior announcement and plenty of warning and plenty of justification. So far in this discussion I have yet to hear anything compelling enough to warrant the massive disruption this would cause. John From mjs at CLEMSON.EDU Wed Sep 26 22:35:02 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 26 Sep 2007 18:35:02 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070926173231.5e8734ac@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <1190841388.16820.66.camel@vincent52.localdomain> <20070926173231.5e8734ac@redhat.com> Message-ID: <1190846102.18321.6.camel@vincent52.localdomain> On Wed, 2007-09-26 at 17:32 -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 21:16:28 +0000 > Matthew Saltzman wrote: > > > OK did that. Now left-click pulls up the usual menu, but all > > selections are greyed out, except VPN Connections. > > Did you logout/reboot after installing those updates? The > NetworkManager service would need to be restarted, and the new > nm-applet has to be running. (oh and the new wpa_supplicant has to be > running too) Yes. If I plug in a wire, the wired entry turns un-greyed and NM connects. But the wireless options are never un-greyed. I even rmmodded and modprobed iwl3945. The wireless options disappear completely, but eventually come back greyed out. There is no indication that a network has been seen, but that's not surprising as the netowrk's SSID is hidden and NM isn't aware of it yet. Also noticed that if I stop NM and try to connect with ifup, I have to rmmod and modprobe iwl3945 before I can get it to work. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From kevin.kofler at chello.at Wed Sep 26 22:50:00 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 26 Sep 2007 22:50:00 +0000 (UTC) Subject: NetworkManager-0.7 can't make new wireless connection References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: What I don't understand is what the sense is behind: * importing 2 days after the feature freeze * an experimental SVN snapshot of NetworkManager * which is a huge rewrite * with still many missing features (i.e. regressions from the stable release) * and tons of bugs * (and both the above now persisting for ~1 month) * which is also API-incompatible and known to completely break KNetworkManager * with an empty contingency plan. Kevin Kofler From a.badger at gmail.com Thu Sep 27 00:12:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 26 Sep 2007 17:12:50 -0700 Subject: Update of bzr in F-7 Message-ID: <46FAF582.7010704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm going to be building some packages for the Bazaar Revision Control System (bzr, bzrtools, and bzr-gtk) for F-7 today. bzr-0.91 will fix some bugs that make bzr-0.18 fail when working with remote repositories that used tags. However, this upgrade will change the bzr package from noarch to arch specific. bzr plugins on x86_64 that are placed in the bzr directories will need to be updated to use the new location under %{_libdir} instead of under /usr/lib. This will affect bzrtools and bzr-gtk within Fedora, both of which I have prepared parallel updates for. Packages outside of Fedora or user managed bzr plugins installed into the system locations will need to be updated to install to the new location. This will not affect i386, plugins installed into user's home directories, or programs which use bzr but are not plugins (like meld, trac-bazaar-plugin, and loggerhead). I will be requesting these go into update-testing for F-7 immediately and sit there for at least a week before I push them out. Please let me know if this update will cause a problem for you and you need more time to work out the issues. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG+vWCX6yAic2E7kgRAkyHAJ40tAdMmlYY552FH2u3nXh9ZaWPTQCfYLar p+hyacsJ5Pn/ompNYlJZKcw= =lH0G -----END PGP SIGNATURE----- From bojan at rexursive.com Thu Sep 27 00:33:46 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 27 Sep 2007 00:33:46 +0000 (UTC) Subject: Fedora 7 Updates Busted Again? References: <1190748649.5242.10.camel@raptor.sr.unh.edu> Message-ID: Did I say .8? I meant .9 :-) PS. You can't beat these kernel boys for speed! ;-) -- Bojan From sgrubb at redhat.com Thu Sep 27 01:17:39 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 26 Sep 2007 21:17:39 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190843974.17132.10.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> Message-ID: <200709262117.40104.sgrubb@redhat.com> On Wednesday 26 September 2007 17:59:34 Richi Plana wrote: > If there's any interest, I could make spec files (based off of the > latest SRPM) for one of these packages to move the data directory > from /var to /srv. Just let me know which packages you find interesting > and I'll submit the spec file to the package maintainer (or here if > Fedora doesn't want to move it). AFAIK, selinux only knows about a couple servers, like apache, having data in /srv. If SE Linux is going to protect the data, a standard mapping between /srv and /var for everything should be worked out so that policy can be adapted. -Steve From jkeating at redhat.com Thu Sep 27 01:28:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 21:28:58 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <200709262117.40104.sgrubb@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> Message-ID: <20070926212858.2c158581@redhat.com> On Wed, 26 Sep 2007 21:17:39 -0400 Steve Grubb wrote: > AFAIK, selinux only knows about a couple servers, like apache, having > data in /srv. If SE Linux is going to protect the data, a standard > mapping between /srv and /var for everything should be worked out so > that policy can be adapted. Therein lies the problem. /srv/ is open ground for sysadmins to use, we can't prepopulate it with anything, and we can't assume what the local admin will use for a scheme. /srv//{web,ftp,backup} or /srv/{web,ftp,backup}/ or some other combo. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From myfedora at richip.dhs.org Thu Sep 27 02:52:45 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 26 Sep 2007 20:52:45 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <200709262117.40104.sgrubb@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> Message-ID: <1190861566.21836.0.camel@localhost6.localdomain6> On Wed, 2007-09-26 at 21:17 -0400, Steve Grubb wrote: > On Wednesday 26 September 2007 17:59:34 Richi Plana wrote: > > If there's any interest, I could make spec files (based off of the > > latest SRPM) for one of these packages to move the data directory > > from /var to /srv. Just let me know which packages you find interesting > > and I'll submit the spec file to the package maintainer (or here if > > Fedora doesn't want to move it). > > AFAIK, selinux only knows about a couple servers, like apache, having data > in /srv. If SE Linux is going to protect the data, a standard mapping > between /srv and /var for everything should be worked out so that policy can > be adapted. Technically, those SELinux policies should come or be set by the installation package. Would you happen to know what Fedora's stand on that is? -- Richi Plana From mattdm at mattdm.org Thu Sep 27 02:55:16 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Sep 2007 22:55:16 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070926212858.2c158581@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> Message-ID: <20070927025516.GA6919@jadzia.bu.edu> On Wed, Sep 26, 2007 at 09:28:58PM -0400, Jesse Keating wrote: > > AFAIK, selinux only knows about a couple servers, like apache, having > > data in /srv. If SE Linux is going to protect the data, a standard > > mapping between /srv and /var for everything should be worked out so > > that policy can be adapted. > Therein lies the problem. /srv/ is open ground for sysadmins to use, > we can't prepopulate it with anything, and we can't assume what the > local admin will use for a scheme. /srv//{web,ftp,backup} > or /srv/{web,ftp,backup}/ or some other combo. Can we make it easy for the SE Linux tools to let the admin choose their local /srv policy? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From lamont at gurulabs.com Thu Sep 27 02:57:43 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 26 Sep 2007 20:57:43 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <200709262117.40104.sgrubb@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> Message-ID: <20070926205743.66a83454@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 26 Sep 2007 21:17:39 -0400 Steve Grubb wrote: > On Wednesday 26 September 2007 17:59:34 Richi Plana wrote: > > If there's any interest, I could make spec files (based off of the > > latest SRPM) for one of these packages to move the data directory > > from /var to /srv. Just let me know which packages you find > > interesting and I'll submit the spec file to the package maintainer > > (or here if Fedora doesn't want to move it). > > AFAIK, selinux only knows about a couple servers, like apache, having > data in /srv. If SE Linux is going to protect the data, a standard > mapping between /srv and /var for everything should be worked out so > that policy can be adapted. SELinux doesn't care about file paths. If the directories have the right context labels, it doesn't matter where they are. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+xwn+YBsl9wN1AkRAsDIAJsG7A6/Rbyml4EMK+9cnG+KxTOz1gCfehWl HAFb5/W/WgBGG+WSOXk1yVA= =cRF8 -----END PGP SIGNATURE----- From lamont at gurulabs.com Thu Sep 27 03:28:11 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 26 Sep 2007 21:28:11 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <20070926212858.2c158581@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> Message-ID: <20070926212811.2f2eb03e@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 26 Sep 2007 21:28:58 -0400 Jesse Keating wrote: > On Wed, 26 Sep 2007 21:17:39 -0400 > Steve Grubb wrote: > > > AFAIK, selinux only knows about a couple servers, like apache, > > having data in /srv. If SE Linux is going to protect the data, a > > standard mapping between /srv and /var for everything should be > > worked out so that policy can be adapted. > > Therein lies the problem. /srv/ is open ground for sysadmins to use, And /var/ isn't "open ground"? Perhaps it shouldn't be, but the reality of things today is that it's a jumbled, cluttered mess. Sure, we've been using it this way for decades and are familiar with it. The /srv/ directory is quite new by comparison. As others have pointed out in this thread, a good number of real world sysadmins move things like web and ftp out of /var/ and/or create separate partitions/volumes to hold such content. The /var/ directory has been the catch-all location whenever people didn't know where a more appropriate location could be found for something. It's ugly and just because that's the way things have been forever doesn't mean it has to stay that way. The /srv/ directory is a good solution for two primary reasons: 1. Backups; just deal with /etc/ and /srv/ (and perhaps /home/ depending on the role of the box) if there's nothing left in /var/ that is non transitory. Things like the RPM DB should be in /var/ and shouldn't be backed up. 2. Organization. The data your services are serving up is under /srv/, their configs are in /etc/ and you don't have to think about where to find stuff. > we can't prepopulate it with anything, Why not? I have yet to see a single, viable argument on this list to explain why having /srv/web/ or /srv/ftp/ can't work as a starting point for a distribution nor for Fedora. Don't get me wrong, there have been a few ideas put forth, but so far, none of them have held water. > and we can't assume what the > local admin will use for a scheme. /srv//{web,ftp,backup} > or /srv/{web,ftp,backup}/ or some other combo. What does it matter? If someone is going to change /var/www/ and /var/ftp/ and others to a per-site organization, they're already doing something different from what is default on any UNIX or UNIX-like OS that I know of. Besides, SELinux won't care. You simply assign the right types to the per-site www/, ftp/, etc. directories and it will just work. Yes, I know, the parent directory structure will still have to allow those services to get there, too; again, if someone is reorganizing "against-the-grain," then they'll have to deal with that either way. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+yNL+YBsl9wN1AkRAtGqAKChSeBO6PsOEX+slAxdaQPJINKn/gCgoVlm 8mmvYiUMbk8+AQ6pj0xnvt4= =Ph3L -----END PGP SIGNATURE----- From ivazqueznet at gmail.com Thu Sep 27 03:38:36 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 26 Sep 2007 23:38:36 -0400 Subject: +1/-1 voting (was: Re: [RFC] /var versus /srv) In-Reply-To: <20070921102620.5bb9ff5a.dcantrell@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> Message-ID: <1190864316.3259.47.camel@ignacio.lan> On Fri, 2007-09-21 at 10:26 -0400, David Cantrell wrote: > Where did the +1 and -1 trend come from because it's really freaking annoying. The earliest I've heard of it happening is on various Apache mailing lists, to indicate acceptance or rejection of a change. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 ivazqueznet at gmail.com Thu Sep 27 04:04:19 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 27 Sep 2007 00:04:19 -0400 Subject: mediawiki dependencies In-Reply-To: <870180fe0709261344y6286e1b6l9bffeefa67c4dab7@mail.gmail.com> References: <870180fe0709261344y6286e1b6l9bffeefa67c4dab7@mail.gmail.com> Message-ID: <1190865859.3259.50.camel@ignacio.lan> On Wed, 2007-09-26 at 14:44 -0600, Jerry James wrote: > [root at localhost ~]# rpm -q php-common > php-common-5.2.4-1.fc7 > > Any idea what's going on? Thanks, You've updated php against a testing version that has been withdrawn. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Thu Sep 27 09:29:09 2007 From: buildsys at redhat.com (Build System) Date: Thu, 27 Sep 2007 05:29:09 -0400 Subject: rawhide report: 20070927 changes Message-ID: <200709270929.l8R9T9fQ018153@porkchop.devel.redhat.com> New package jisksp16-1990-fonts 16x16 JIS X 0212:1990 Bitmap font New package knm_new-fonts 12x12 JIS X 0208 Bitmap font New package makehuman Modeling of three-dimensional humanoid characters Updated Packages: a2ps-4.13b-69.fc8 ----------------- * Wed Sep 26 2007 Tim Waugh 4.13b-69 - Try out a perl stylesheet speed improvement (bug #252183). cacti-0.8.6j-10.fc8 ------------------- * Wed Sep 26 2007 Mike McGrath - 0.8.6j-10 - Rebuild for koji test desktop-backgrounds-7.92-6 -------------------------- * Wed Sep 26 2007 M??ir??n Duffy - 7.92-6 - wallpapers redone so there is no more banding - wallpapers renamed - infinity animated file bugs fixed (hopefully) * Thu Sep 20 2007 Ray Strode - 7.92-5 - fix symlinks again fedora-release-notes-7.92-2 --------------------------- * Wed Sep 26 2007 Bill Nottingham - 7.92-2 - fix symlinking (#306781) - set license tag -> Open Publication gtk-vnc-0.2.0-2.fc8 ------------------- * Wed Sep 26 2007 Daniel P. Berrange - 0.2.0-2.fc8 - Remove use of PROT_EXEC for coroutine stack (rhbz #307531 ) kde-settings-3.5-31.fc8 ----------------------- * Wed Sep 26 2007 Rex Dieter - 3.5-31 - kdesktoprc: [Desktop0] Wallpaper=/usr/share/backgrounds/images/default.png (#290571) - kopeterc: [ContactList] SmoothScrolling=false kdepim-6:3.5.7-9.svn20070926.ent.fc8 ------------------------------------ * Wed Sep 26 2007 Rex Dieter - 6:3.5.7-9.20070926.ent - kdepim-enterprise branch 20070926 snapshot (r717374) * Thu Sep 20 2007 Rex Dieter - 6:3.5.7-8.20070920.714749.ent - kdepim-enterprise branch 20070920 snapshot (r714749) kernel-2.6.23-0.204.rc8.fc8 --------------------------- * Tue Sep 25 2007 Dave Jones - Disable RTC_HCTOSYS. The initscripts already do this for us. * Tue Sep 25 2007 Dave Jones - x86-64: Disable local APIC timer use on AMD systems with C1E. libsemanage-2.0.9-1.fc8 ----------------------- * Wed Sep 26 2007 Dan Walsh - 2.0.9-1 - Upgrade to latest from NSA * Pass CFLAGS to CC even on link command, per Dennis Gilmore. * Clear errno on non-fatal errors to avoid reporting them upon a later error that does not set errno. * Improve reporting of system errors, e.g. full filesystem or read-only filesystem from Stephen Smalley. - Fix segfault in genhomedircon when using bad user names * Wed Sep 26 2007 Dan Walsh - 2.0.6-2 - Fix genhomedircon code to only generate valid context - Fixes autorelabel problem libsilc-0:1.0.2-4.fc8 --------------------- * Mon Sep 24 2007 Michael Schwendt 1.0.2-4 - filter out libsilc module SONAME Provides (#245323) - add a check section with a test that fails when the modules move libsvm-2.84-6.fc8 ----------------- * Wed Sep 26 2007 Ding-Yi Chen - 2.84-6 - Add defattr to each subpackage - Move libsvm.so to libsvm * Mon Sep 24 2007 Ding-Yi Chen - 2.84-5 - Split out libsvm-java - Add libsvm.so * Thu Aug 30 2007 Ding-Yi Chen - 2.84-4 - Refined description. - Fix the /tmp/python.ver problem pirut-1.3.20-1.fc8 ------------------ * Wed Sep 26 2007 Jeremy Katz - 1.3.20-1 - Fix hang with multiple searches (#296521) - Catch a couple more error cases (#302161) - Update translations selinux-policy-3.0.8-14.fc8 --------------------------- * Mon Sep 24 2007 Dan Walsh 3.0.8-14 - Allow xdm to talk to input device (fingerprint reader) - Allow octave to run as java system-config-soundcard-2.0.6-10.fc8 ------------------------------------ * Wed Sep 26 2007 Martin Stransky - 2.0.6-10 - fixed hardware device configuration tcl-1:8.4.15-5.fc8 ------------------ * Wed Sep 26 2007 Marcela Maslanova - 1:8.4.15-5 - fix of patch - set auto_path was broken - Resolves: rhbz#306321 * Fri Aug 24 2007 Marcela Maslanova - 1:8.4.15-4 - rebuild for mass rebuild - check license & path for 32b/64b fix * Thu Aug 09 2007 Marcela Maslanova - 1:8.4.15-3 - Resolves: rhbz#251410 tinyerp-4.0.3-2.fc8 ------------------- * Wed Sep 26 2007 Dan Horak 4.0.3-2 - update the desktop file to the current standards - update the license tag xchat-1:2.8.4-5.fc8 ------------------- * Wed Sep 26 2007 Kevin Kofler - 1:2.8.4-5 - apply xc284-improvescrollback.diff from upstream xen-3.1.0-10.fc8 ---------------- * Wed Sep 26 2007 Chris Lalancette - 3.1.0-10.fc8 - QEmu NE2000 overflow check - CVE-2007-1321 - Pygrub guest escape - CVE-2007-4993 * Mon Sep 24 2007 Daniel P. Berrange - 3.1.0-9.fc8 - Fix generation of manual pages (rhbz #250791) - Really fix FC-6 32-on-64 guests xkeyboard-config-1.1-1.fc8 -------------------------- * Wed Sep 26 2007 Matthias Clasen - 1.1-1 - Update to 1.1 - Drop upstreamed patches yum-3.2.5-4.fc8 --------------- * Tue Sep 25 2007 Jeremy Katz - 3.2.5-4 - pull in fixes from upstream for media handling, pkgid (#291471), and a potential depsolving bug Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From sgrubb at redhat.com Thu Sep 27 10:36:14 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 27 Sep 2007 06:36:14 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070926205743.66a83454@reaver.lamontpeterson.net> References: <46F33D05.4020701@ncsu.edu> <200709262117.40104.sgrubb@redhat.com> <20070926205743.66a83454@reaver.lamontpeterson.net> Message-ID: <200709270636.14666.sgrubb@redhat.com> On Wednesday 26 September 2007 22:57:43 Lamont Peterson wrote: > > AFAIK, selinux only knows about a couple servers, like apache, having > > data in /srv. If SE Linux is going to protect the data, a standard > > mapping between /srv and /var for everything should be worked out so > > that policy can be adapted. > > SELinux doesn't care about file paths. ?If the directories have the right > context labels, it doesn't matter where they are. You need more than the directories to be right. Sometimes the files inside the same directory have different labels. For each type being used, selinux needs the path. Here's a typical example from sendmail's policy: /var/log/mail(/.*)? gen_context(system_u:object_r:sendmail_log_t,s0) /var is hardcoded. -Steve From andy at warmcat.com Thu Sep 27 11:03:08 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 27 Sep 2007 12:03:08 +0100 Subject: [RFC] /var versus /srv In-Reply-To: <200709270636.14666.sgrubb@redhat.com> References: <46F33D05.4020701@ncsu.edu> <200709262117.40104.sgrubb@redhat.com> <20070926205743.66a83454@reaver.lamontpeterson.net> <200709270636.14666.sgrubb@redhat.com> Message-ID: <46FB8DEC.1010201@warmcat.com> Somebody in the thread at some point said: >> SELinux doesn't care about file paths. If the directories have the right >> context labels, it doesn't matter where they are. > > You need more than the directories to be right. Sometimes the files inside the > /var is hardcoded. It doesn't consider file paths when examining what it was you wanted to touch to see if you can. But when you create a file, by cp or whatever, it must use private knowledge about the specific path's "natural" context or it can't automagically label new files correctly based on where they were created. Maybe it will be possible to adjust the policies to accept both /var/blah and /srv/blah, or via a bool. -Andy From johannbg at hi.is Thu Sep 27 11:18:40 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 27 Sep 2007 11:18:40 +0000 Subject: [RFC] /var versus /srv In-Reply-To: <80d7e4090709261428r7b1a11b2y6fa788113f72915d@mail.gmail.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> <80d7e4090709261428r7b1a11b2y6fa788113f72915d@mail.gmail.com> Message-ID: <46FB9190.6040107@hi.is> Stephen John Smoogen wrote: > On 9/21/07, David Cantrell wrote: > > >> On another note, could we please stop the +1 and -1 garbage replies to people? Just say you agree or disagree. Where did the +1 and -1 trend come from because it's really freaking annoying. >> >> > > Amateur historian hat on > > This usage of +1/-1 has been in various places, but seems to have > become mainstream sometime in the late 1990's when Slashdot > implemented its first karma system. People would ask other people who > had karma to +1/-1 an article/comment/etc because they felt it was > important etc. It then started being used on other lists as a common > meme as anyone who was anyone was reading Slashdot (even if not > admitting it). > > Getting it to stop will be at this point like getting the press not to > call criminal software users 'hackers'. > > +10 Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From nicolas.mailhot at laposte.net Thu Sep 27 11:19:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Sep 2007 13:19:43 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <46FADAE8.5020404@redhat.com> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> Message-ID: <21973.192.54.193.51.1190891983.squirrel@rousalka.dyndns.org> Le Jeu 27 septembre 2007 00:19, John Dennis a ?crit : > Hold on there partner :-) In the case of mailman (and many other > packages) you can't just move things around without updating the > selinux policy in lock step. You mean, we can put stuff in /var/lib/, because it's "easy" for the local sysadmin to use /srv instead, but when we have to do it ourselves it's non-trivial? Regards, -- Nicolas Mailhot From jkeating at redhat.com Thu Sep 27 11:41:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 27 Sep 2007 07:41:00 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190861566.21836.0.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> Message-ID: <20070927074100.6a37fc03@redhat.com> On Wed, 26 Sep 2007 20:52:45 -0600 Richi Plana wrote: > Technically, those SELinux policies should come or be set by the > installation package. Would you happen to know what Fedora's stand on > that is? Not possible until SELinux upstream allows files to be written out with an unknown context or unabled context and switch to the new policy when it gets applied. Or something like that. Long long history and anger around this issue. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From abo at kth.se Thu Sep 27 11:43:12 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 27 Sep 2007 13:43:12 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <21973.192.54.193.51.1190891983.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921141722.GA32111@jadzia.bu.edu> <16de708d0709210727g2c8a937dk7664cf532da718ab@mail.gmail.com> <1190389233.23728.16.camel@localhost6.localdomain6> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <21973.192.54.193.51.1190891983.squirrel@rousalka.dyndns.org> Message-ID: <1190893392.5022.35.camel@home.alexander.bostrom.net> tor 2007-09-27 klockan 13:19 +0200 skrev Nicolas Mailhot: > You mean, we can put stuff in /var/lib/, because it's "easy" for the > local sysadmin to use /srv instead, but when we have to do it > ourselves it's non-trivial? Exactly. Changing system default without any justification is going to make admins cry. I'm one of them. Admins changing their settings because they think /var/lib is weird is not going to confuse the same admin. I'm a sysadmin. I say: Please don't do this. I'm fine with /var/lib and I don't want unnecessary changes that I have to deal with when upgrading. /abo From jkeating at redhat.com Thu Sep 27 11:43:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 27 Sep 2007 07:43:41 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070926212811.2f2eb03e@reaver.lamontpeterson.net> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> Message-ID: <20070927074341.19b40fa0@redhat.com> On Wed, 26 Sep 2007 21:28:11 -0600 Lamont Peterson wrote: > > we can't prepopulate it with anything, > > Why not? I have yet to see a single, viable argument on this list to > explain why having /srv/web/ or /srv/ftp/ can't work as a starting > point for a distribution nor for Fedora. Don't get me wrong, there > have been a few ideas put forth, but so far, none of them have held > water. Because the FHS is broken on this issue. They claim that it's for site admins to use and distributions can't layout any files that may disrupt or overwrite what a site admin may already have in place. > > > and we can't assume what the > > local admin will use for a scheme. /srv//{web,ftp,backup} > > or /srv/{web,ftp,backup}/ or some other combo. > > What does it matter? If someone is going to change /var/www/ > and /var/ftp/ and others to a per-site organization, they're already > doing something different from what is default on any UNIX or > UNIX-like OS that I know of. > > Besides, SELinux won't care. You simply assign the right types to > the per-site www/, ftp/, etc. directories and it will just work. > Yes, I know, the parent directory structure will still have to allow > those services to get there, too; again, if someone is reorganizing > "against-the-grain," then they'll have to deal with that either way. Wrong, see Steve's mail. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From abo at kth.se Thu Sep 27 11:50:08 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 27 Sep 2007 13:50:08 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <20070926212811.2f2eb03e@reaver.lamontpeterson.net> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> Message-ID: <1190893808.5022.46.camel@home.alexander.bostrom.net> ons 2007-09-26 klockan 21:28 -0600 skrev Lamont Peterson: > And /var/ isn't "open ground"? Perhaps it shouldn't be, but the > reality of things today is that it's a jumbled, cluttered mess. I'm a sysadmin. I expect the RPM:s to put things in /var, especially /var/lib/. I don't think /var/lib is that cluttered. Sure, one could use a scheme like //// but categories are hard an /var/lib is not big enough for something like that to be warranted. When _I_ configure something to use a local directory for storing data, I either put it in /var/local// or I use /srv/. I expect /srv to be like /var/local and /usr/local in that it's not touched by the operating system. (Which means anything installed by RPM:s, in the Fedora case.) That is how I've interpreted the FHS. /abo From brent at brentnorris.net Thu Sep 27 12:18:16 2007 From: brent at brentnorris.net (Brent Norris) Date: Thu, 27 Sep 2007 07:18:16 -0500 Subject: +1/-1 voting In-Reply-To: <1190864316.3259.47.camel@ignacio.lan> References: <46F33D05.4020701@ncsu.edu> <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> <1190864316.3259.47.camel@ignacio.lan> Message-ID: <46FB9F88.7060001@brentnorris.net> Ignacio Vazquez-Abrams wrote: > On Fri, 2007-09-21 at 10:26 -0400, David Cantrell wrote: >> Where did the +1 and -1 trend come from because it's really freaking annoying. > > The earliest I've heard of it happening is on various Apache mailing > lists, to indicate acceptance or rejection of a change. > > I always thought it was a take off of the Slashdot mod system, but I guess that could have come from anywhere. Brent From benny+usenet at amorsen.dk Thu Sep 27 12:11:52 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 27 Sep 2007 14:11:52 +0200 Subject: [RFC] /var versus /srv References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> <20070927074341.19b40fa0@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Because the FHS is broken on this issue. They claim that it's for JK> site admins to use and distributions can't layout any files that JK> may disrupt or overwrite what a site admin may already have in JK> place. Why don't we ignore the part of FHS that is broken, instead of ignoring the part of FHS that arguably isn't? That is, put stuff in /srv complete with layout, and stop polluting /var? /Benny From Matt_Domsch at dell.com Thu Sep 27 12:38:31 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 27 Sep 2007 07:38:31 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070926104656.028a4502@redhat.com> References: <20070925160713.A13101@humbolt.us.dell.com> <20070926142128.GA13094@redhat.com> <20070926143743.GB28612@auslistsprd01.us.dell.com> <20070926104656.028a4502@redhat.com> Message-ID: <20070927123831.GA24717@auslistsprd01.us.dell.com> On Wed, Sep 26, 2007 at 10:46:56AM -0400, Jesse Keating wrote: > On Wed, 26 Sep 2007 09:37:43 -0500 > Matt Domsch wrote: > > > i re-ran the failures overnight, so some previously false failures are > > now good. I'll have the stats email out shortly. Down to 395 > > failures on i386, 408 on x86_64. > > Did your build set include glibc-2.6.90-14? That introduces > -D_FORTIFY_SOURCE{,=2} support for C++ and there may be some warnings in the build output about potential buffer overflows (which would result in runtime aborts and glibc logging). I'm curious if we can check the C++ builds for any warnings like this. > > Warnings such as "warning: call to __builtin___memcpy_chk will always > overflow destination buffer" I re-ran all the failed builds and all the C++ applications overnight - there were no additional warnings reported, so the list stands at: dnsmasq-2.40-1.fc8.src.rpm freedroidrpg-0.10.3-1.fc8.src.rpm hping3-0.0.20051105-7.fc7.src.rpm Io-language-20070710-2.fc8.src.rpm libtirpc-0.1.7-10.fc8.src.rpm mcrypt-2.6.6-2.fc8.src.rpm openslp-1.2.1-7.fc8.src.rpm perl-Imager-0.60-1.fc8.src.rpm none of which are actually C++. dnsmasq upstream is already patched to fix this (thanks jima). Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From sgrubb at redhat.com Thu Sep 27 12:40:38 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 27 Sep 2007 08:40:38 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070926212811.2f2eb03e@reaver.lamontpeterson.net> References: <46F33D05.4020701@ncsu.edu> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> Message-ID: <200709270840.38988.sgrubb@redhat.com> On Wednesday 26 September 2007 23:28:11 Lamont Peterson wrote: > Besides, SELinux won't care. ?You simply assign the right types to the > per-site www/, ftp/, etc. directories and it will just work. Assigning the right types to the directory will probably stop avc denials that wanted to do file search - IOW a directory search. The files contained in those directories will still likely have the wrong type. If you are counting on the semantics of "cp" to preserve attributes, that is a fragile assumption. The first time a relabel occurs, the file and directory contexts will be reset to the defaults. You will either need to adjust policy or create a lot of entries in /etc/selinux/restorecond.conf. -Steve From sgrubb at redhat.com Thu Sep 27 12:55:17 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 27 Sep 2007 08:55:17 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46FB8DEC.1010201@warmcat.com> References: <46F33D05.4020701@ncsu.edu> <200709270636.14666.sgrubb@redhat.com> <46FB8DEC.1010201@warmcat.com> Message-ID: <200709270855.17552.sgrubb@redhat.com> On Thursday 27 September 2007 07:03:08 Andy Green wrote: > But when you create a file, by cp or whatever, it must use private > knowledge about the specific path's "natural" context or it can't > automagically label new files correctly based on where they were created. Correct. Cp has been coded to look at the originating context and apply that to the destination context when the --preserve option is supplied. It does not change the policy and the first time a relabel occurs, the context may be reset. > Maybe it will be possible to adjust the policies to accept both > /var/blah and /srv/blah, or via a bool. It looks like a couple daemons were done like this. However, its not all daemons and you have to move the files exactly where selinux policy says or you are fighting selinux. Looking at policy, I see /srv/* set to var_t, /srv/gallery2 set to httpd_sys_content_t, /srv/*/rsync/* set to public_content_t, and /srv/*/www/ set to httpd_sys_content_t. The easiest way to see this is to click on system | administration | SELinux Management menu item. Then select the File Labeling button and sort by File name by clicking on the left-most column. You can scroll down and see it. -Steve From abo at kth.se Thu Sep 27 12:55:30 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 27 Sep 2007 14:55:30 +0200 Subject: buildreq for "localhost works" In-Reply-To: <20070926103235.5EDCA4D04B7@magilla.localdomain> References: <20070926002902.C407B4D04B7@magilla.localdomain> <1190801067.2314.1.camel@localhost.localdomain> <20070926103235.5EDCA4D04B7@magilla.localdomain> Message-ID: <1190897730.5022.51.camel@home.alexander.bostrom.net> ons 2007-09-26 klockan 03:32 -0700 skrev Roland McGrath: > "localhost" means 127.0.0.1 and/or ::1 Actually, I remember some breakage a while back when "::1 localhost" was put in /etc/hosts. Nowadays it's localhost6(.localdomain6) instead. /abo From jorton at redhat.com Thu Sep 27 12:58:56 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 27 Sep 2007 13:58:56 +0100 Subject: +1/-1 voting (was: Re: [RFC] /var versus /srv) In-Reply-To: <1190864316.3259.47.camel@ignacio.lan> References: <16de708d0709202358p2af8aff5mda5fa286f21ea920@mail.gmail.com> <1190360363.31022.114.camel@mccallum.corsepiu.local> <31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org> <20070921100859.GA6032@devserv.devel.redhat.com> <1190380783.2142.52.camel@cutter> <20070921093924.123e483b@localhost.localdomain> <1190382715.2142.56.camel@cutter> <20070921095601.035cc74d@localhost.localdomain> <20070921102620.5bb9ff5a.dcantrell@redhat.com> <1190864316.3259.47.camel@ignacio.lan> Message-ID: <20070927125855.GA3945@redhat.com> On Wed, Sep 26, 2007 at 11:38:36PM -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2007-09-21 at 10:26 -0400, David Cantrell wrote: > > Where did the +1 and -1 trend come from because it's really freaking annoying. > > The earliest I've heard of it happening is on various Apache mailing > lists, to indicate acceptance or rejection of a change. Yeah, it originates from Apache AFAIK. http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/%3C9503152021.AA27714 at ooo.lanl.gov%3E joe From dwalsh at redhat.com Thu Sep 27 13:27:33 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Sep 2007 09:27:33 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070927025516.GA6919@jadzia.bu.edu> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070927025516.GA6919@jadzia.bu.edu> Message-ID: <46FBAFC5.3000005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Miller wrote: > On Wed, Sep 26, 2007 at 09:28:58PM -0400, Jesse Keating wrote: >>> AFAIK, selinux only knows about a couple servers, like apache, having >>> data in /srv. If SE Linux is going to protect the data, a standard >>> mapping between /srv and /var for everything should be worked out so >>> that policy can be adapted. >> Therein lies the problem. /srv/ is open ground for sysadmins to use, >> we can't prepopulate it with anything, and we can't assume what the >> local admin will use for a scheme. /srv//{web,ftp,backup} >> or /srv/{web,ftp,backup}/ or some other combo. > > Can we make it easy for the SE Linux tools to let the admin choose their > local /srv policy? > We can do it, using semanage commands, but not necessarily easy. Currently regex match the default location of files stored on disk. /srv/([^/]*/)?www(/.*)? system_u:object_r:httpd_sys_content_t:s0 /var/www(/.*)? system_u:object_r:httpd_sys_content_t:s0 /var/www/[^/]*/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/perl(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/icons(/.*)? system_u:object_r:httpd_sys_content_t:s0 /var/www/html/[^/]*/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/calamaris(/.*)? system_u:object_r:calamaris_www_t:s0 /var/www/apcupsd/multimon.cgi -- system_u:object_r:httpd_apcupsd_cgi_script_exec_t:s0 /var/www/apcupsd/upsimage.cgi -- system_u:object_r:httpd_apcupsd_cgi_script_exec_t:s0 /var/www/apcupsd/upsstats.cgi -- system_u:object_r:httpd_apcupsd_cgi_script_exec_t:s0 /var/www/apcupsd/upsfstats.cgi -- system_u:object_r:httpd_apcupsd_cgi_script_exec_t:s0 /var/www/cgi-bin/cgi -- system_u:object_r:httpd_mycgi_script_exec_t:s0 We could start to build tools that would allow you to change this location. semanage fcontext -a -t httpd_sys_script_exec_t /srv/web/cgi-bin(/.*)? Would add a context to this path. system-config-selinux has graphical tools to do this, but it still involves users choosing contexts and file paths. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG+6/FrlYvE4MpobMRAh/QAKC4Tm7B/kuxe/AFcncavaIe6vZnXQCbBpKI jcIYqF8EgcrXGHL89a18Uxs= =g8xn -----END PGP SIGNATURE----- From hhoffman at ip-solutions.net Thu Sep 27 13:59:16 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 27 Sep 2007 09:59:16 -0400 Subject: /etc/hosts and system entries Message-ID: <46FBB734.90403@ip-solutions.net> Hi, So, /etc/hosts comes setup by default (i.e. after kickstart install) # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname of the system was also added to the localhost entry: 127.0.0.1 my.host.com my localhost.localdomain localhost This had the distinct advantage that when apps (i.e. yum-updatesd) sent mail from the system via a mail host then address would appear as: root at my.host.com instead of root at localhost.com Am I remembering correctly, in terms of how I believe it used to be? If so, anyone know why it changed? Cheers, Harry From dwalsh at redhat.com Thu Sep 27 14:03:08 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Sep 2007 10:03:08 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46FB8DEC.1010201@warmcat.com> References: <46F33D05.4020701@ncsu.edu> <200709262117.40104.sgrubb@redhat.com> <20070926205743.66a83454@reaver.lamontpeterson.net> <200709270636.14666.sgrubb@redhat.com> <46FB8DEC.1010201@warmcat.com> Message-ID: <46FBB81C.3020405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy Green wrote: > Somebody in the thread at some point said: > >>> SELinux doesn't care about file paths. If the directories have the right >>> context labels, it doesn't matter where they are. >> You need more than the directories to be right. Sometimes the files inside the > >> /var is hardcoded. > > It doesn't consider file paths when examining what it was you wanted to > touch to see if you can. > > But when you create a file, by cp or whatever, it must use private > knowledge about the specific path's "natural" context or it can't > automagically label new files correctly based on where they were created. > > Maybe it will be possible to adjust the policies to accept both > /var/blah and /srv/blah, or via a bool. > > -Andy > sed 's/var/srv/g' is easy. But I have a feeling sysadmins are going to be much more complex than this. I don't think rpm does a good job of choosing alternate locations for the installed rpms. This seems to be a bigger problem then worrying about whether SELinux can put the proper file context in place. If you set the directory context correctly the files created in the directory will work. So labeling /src/www and /var/www the same means that apps creating files/directories in either will work exactly the same. You need to use semanage fcontext ... To make sure file labeling remains after a relabel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG+7gcrlYvE4MpobMRAjP9AJ9qsV/CELf/+OmD+S/SpfRHhDhPRgCgsOQT 7je6K5MrcpC3/rmd814kuno= =cwvB -----END PGP SIGNATURE----- From jkeating at redhat.com Thu Sep 27 10:04:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 27 Sep 2007 06:04:56 -0400 Subject: Fedora i386 rawhide rebuild in mock status 2007-09-25 In-Reply-To: <20070927123831.GA24717@auslistsprd01.us.dell.com> References: <20070925160713.A13101@humbolt.us.dell.com> <20070926142128.GA13094@redhat.com> <20070926143743.GB28612@auslistsprd01.us.dell.com> <20070926104656.028a4502@redhat.com> <20070927123831.GA24717@auslistsprd01.us.dell.com> Message-ID: <20070927060456.462c2d05@redhat.com> On Thu, 27 Sep 2007 07:38:31 -0500 Matt Domsch wrote: > I re-ran all the failed builds and all the C++ applications > overnight - there were no additional warnings reported, so the list > stands at: Thanks Matt, that makes me feel a lot better about this C++ change. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcantrell at redhat.com Thu Sep 27 14:02:29 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 27 Sep 2007 10:02:29 -0400 Subject: /etc/hosts and system entries In-Reply-To: <46FBB734.90403@ip-solutions.net> References: <46FBB734.90403@ip-solutions.net> Message-ID: <20070927100229.36836163.dcantrell@redhat.com> On Thu, 27 Sep 2007 09:59:16 -0400 Harry Hoffman wrote: > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > # Do not remove the following line, or various programs > # that require network functionality will fail. > 127.0.0.1 localhost.localdomain localhost > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > of the system was also added to the localhost entry: > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > mail from the system via a mail host then address would appear as: > root at my.host.com instead of root at localhost.com > > Am I remembering correctly, in terms of how I believe it used to be? If > so, anyone know why it changed? https://bugzilla.redhat.com/show_bug.cgi?id=253979 Fixed in rawhide. Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Thu Sep 27 14:07:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Sep 2007 10:07:22 -0400 Subject: /etc/hosts and system entries In-Reply-To: <46FBB734.90403@ip-solutions.net> References: <46FBB734.90403@ip-solutions.net> Message-ID: <1190902042.3476.4.camel@hopeson> On Thu, 2007-09-27 at 09:59 -0400, Harry Hoffman wrote: > Hi, > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > # Do not remove the following line, or various programs > # that require network functionality will fail. > 127.0.0.1 localhost.localdomain localhost > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > of the system was also added to the localhost entry: > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > mail from the system via a mail host then address would appear as: > root at my.host.com instead of root at localhost.com But breaks miserably in other situations when you wanto to resolve the ip address of your machine. A typical example is kerberos and winbindd (also using kerberos). > Am I remembering correctly, in terms of how I believe it used to be? If > so, anyone know why it changed? Breaks stuff. Simo. From ssorce at redhat.com Thu Sep 27 14:10:42 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Sep 2007 10:10:42 -0400 Subject: /etc/hosts and system entries In-Reply-To: <20070927100229.36836163.dcantrell@redhat.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> Message-ID: <1190902242.3476.8.camel@hopeson> On Thu, 2007-09-27 at 10:02 -0400, David Cantrell wrote: > On Thu, 27 Sep 2007 09:59:16 -0400 > Harry Hoffman wrote: > > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > > > # Do not remove the following line, or various programs > > # that require network functionality will fail. > > 127.0.0.1 localhost.localdomain localhost > > > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > > of the system was also added to the localhost entry: > > > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > > mail from the system via a mail host then address would appear as: > > root at my.host.com instead of root at localhost.com > > > > Am I remembering correctly, in terms of how I believe it used to be? If > > so, anyone know why it changed? > > https://bugzilla.redhat.com/show_bug.cgi?id=253979 > > Fixed in rawhide. > > Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. Please, PLEASE, reconsider. I've long hated this thing of assigning the hostname to 127.0.0.1, it always breaks when using kerberos/winbindd as the hostname needs to reflect the public facing ip. I personally think that Gnome is at fault here, is there any smarter way to at least change the hostname mappingi hosts when the main network interface gets an IP? Simo. From dcantrell at redhat.com Thu Sep 27 14:12:00 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 27 Sep 2007 10:12:00 -0400 Subject: /etc/hosts and system entries In-Reply-To: <1190902242.3476.8.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> Message-ID: <20070927101200.86ef2349.dcantrell@redhat.com> On Thu, 27 Sep 2007 10:10:42 -0400 Simo Sorce wrote: > On Thu, 2007-09-27 at 10:02 -0400, David Cantrell wrote: > > On Thu, 27 Sep 2007 09:59:16 -0400 > > Harry Hoffman wrote: > > > > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > > > > > # Do not remove the following line, or various programs > > > # that require network functionality will fail. > > > 127.0.0.1 localhost.localdomain localhost > > > > > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > > > of the system was also added to the localhost entry: > > > > > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > > > > > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > > > mail from the system via a mail host then address would appear as: > > > root at my.host.com instead of root at localhost.com > > > > > > Am I remembering correctly, in terms of how I believe it used to be? If > > > so, anyone know why it changed? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=253979 > > > > Fixed in rawhide. > > > > Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. > > > Please, PLEASE, reconsider. > I've long hated this thing of assigning the hostname to 127.0.0.1, it > always breaks when using kerberos/winbindd as the hostname needs to > reflect the public facing ip. > > I personally think that Gnome is at fault here, is there any smarter way > to at least change the hostname mappingi hosts when the main network > interface gets an IP? OK, now this is making sense as to why it changed before. It's incorrect. So here we are where a certain group of people want the hostname added to the 127.0.0.1 line and another group that doesn't. I tend to agree with the latter, but I would rather explore this post F-8 than now. Removing it, yet again, in rawhide after F-8 is released and any bugs that get opened we determine the program that's at fault and reassign the bug to that package. It'll be annoying to users, but I think it's best to not have the hostname on the 127.0.0.1 line. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hhoffman at ip-solutions.net Thu Sep 27 14:26:20 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 27 Sep 2007 10:26:20 -0400 Subject: /etc/hosts and system entries In-Reply-To: <20070927101200.86ef2349.dcantrell@redhat.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <20070927101200.86ef2349.dcantrell@redhat.com> Message-ID: <46FBBD8C.3040301@ip-solutions.net> Perhaps the best course of action is then to modify the local mail server (sendmail/postfix) to send out mail as the fully qualified domain name? Then again, what to do in the situation of DHCP. I guess that if mail is expected to be delivered locally then it's not a big deal. but if you're running a bunch of servers you are going to want to send the emails to a central location. I guess it sounds like a problem to solve outside of the hosts file (sorry for the thinking out loud/rambling) David Cantrell wrote: > On Thu, 27 Sep 2007 10:10:42 -0400 > Simo Sorce wrote: > >> On Thu, 2007-09-27 at 10:02 -0400, David Cantrell wrote: >>> On Thu, 27 Sep 2007 09:59:16 -0400 >>> Harry Hoffman wrote: >>> >>>> So, /etc/hosts comes setup by default (i.e. after kickstart install) >>>> >>>> # Do not remove the following line, or various programs >>>> # that require network functionality will fail. >>>> 127.0.0.1 localhost.localdomain localhost >>>> >>>> I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname >>>> of the system was also added to the localhost entry: >>>> >>>> 127.0.0.1 my.host.com my localhost.localdomain localhost >>>> >>>> >>>> This had the distinct advantage that when apps (i.e. yum-updatesd) sent >>>> mail from the system via a mail host then address would appear as: >>>> root at my.host.com instead of root at localhost.com >>>> >>>> Am I remembering correctly, in terms of how I believe it used to be? If >>>> so, anyone know why it changed? >>> https://bugzilla.redhat.com/show_bug.cgi?id=253979 >>> >>> Fixed in rawhide. >>> >>> Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. >> >> Please, PLEASE, reconsider. >> I've long hated this thing of assigning the hostname to 127.0.0.1, it >> always breaks when using kerberos/winbindd as the hostname needs to >> reflect the public facing ip. >> >> I personally think that Gnome is at fault here, is there any smarter way >> to at least change the hostname mappingi hosts when the main network >> interface gets an IP? > > OK, now this is making sense as to why it changed before. It's incorrect. > > So here we are where a certain group of people want the hostname added to the 127.0.0.1 line and another group that doesn't. I tend to agree with the latter, but I would rather explore this post F-8 than now. Removing it, yet again, in rawhide after F-8 is released and any bugs that get opened we determine the program that's at fault and reassign the bug to that package. It'll be annoying to users, but I think it's best to not have the hostname on the 127.0.0.1 line. > > From rdieter at math.unl.edu Thu Sep 27 13:57:40 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 27 Sep 2007 08:57:40 -0500 Subject: ggz Message-ID: I'm about to start working on packaging up ggz-related stuff, http://www.ggzgamingzone.org/ (needed for kdegames4, at least) Anybody happen to have started work on this, yet? Similarly, anyone interested in helping, comaintaining, reviewing? :) Otherwise, I'll probably end up borrowing a lot from existing rpmforge, Suse, mandriva packages. -- Rex From roopesh.majeti at gmail.com Thu Sep 27 14:34:20 2007 From: roopesh.majeti at gmail.com (roopesh majeti) Date: Thu, 27 Sep 2007 20:04:20 +0530 Subject: ggz In-Reply-To: References: Message-ID: <599059470709270734k64719221n106cfb2681f970ee@mail.gmail.com> I would like to drop by penny of help :) Rex, let me know the course of work !!!! On 9/27/07, Rex Dieter wrote: > I'm about to start working on packaging up ggz-related stuff, > http://www.ggzgamingzone.org/ > (needed for kdegames4, at least) > > Anybody happen to have started work on this, yet? Similarly, anyone > interested in helping, comaintaining, reviewing? :) > > Otherwise, I'll probably end up borrowing a lot from existing rpmforge, > Suse, mandriva packages. > > -- Rex > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From orion at cora.nwra.com Thu Sep 27 15:01:38 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 27 Sep 2007 09:01:38 -0600 Subject: rpmdb and /var filesystem corruption in F7+ Message-ID: <46FBC5D2.60902@cora.nwra.com> I have a lot of problems with rpmdb corruption occurring during (network) installs since around February 2007, and with yum updates afterwards. I've reported the problem here . The problem seems to have gotten worse with the latest rawhide releases - I think about one of every five attempts to perform an install succeeds. I'm still somewhat baffled that I appear to be the only person to be reporting these problems considering how reproducible they are for me with all kinds of hardware. I keep a separate /var partition, and recently one of our F7 systems' /var filesystem got corrupted . Perhaps the problems are related. Anyways, I'm concerned because this is causing me a lot of grief. I'm just amazed that this doesn't seem to be happening to anyone else. Is that true? -- 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 sandeen at redhat.com Thu Sep 27 15:05:19 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 27 Sep 2007 10:05:19 -0500 Subject: rpmdb and /var filesystem corruption in F7+ In-Reply-To: <46FBC5D2.60902@cora.nwra.com> References: <46FBC5D2.60902@cora.nwra.com> Message-ID: <46FBC6AF.2000509@redhat.com> Orion Poplawski wrote: > I have a lot of problems with rpmdb corruption occurring during > (network) installs since around February 2007, and with yum updates > afterwards. I've reported the problem here > . > > The problem seems to have gotten worse with the latest rawhide releases > - I think about one of every five attempts to perform an install > succeeds. I'm still somewhat baffled that I appear to be the only > person to be reporting these problems considering how reproducible they > are for me with all kinds of hardware. > > I keep a separate /var partition, and recently one of our F7 systems' > /var filesystem got corrupted > . Perhaps the > problems are related. > > Anyways, I'm concerned because this is causing me a lot of grief. I'm > just amazed that this doesn't seem to be happening to anyone else. Is > that true? > I added a note to the bug; can you provide me with an image of the corrupted filesystem, please? Thanks, -Eric From myfedora at richip.dhs.org Thu Sep 27 15:22:29 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 27 Sep 2007 09:22:29 -0600 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> <20070927074341.19b40fa0@redhat.com> Message-ID: <1190906550.1296.3.camel@localhost6.localdomain6> On Thu, 2007-09-27 at 14:11 +0200, Benny Amorsen wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> Because the FHS is broken on this issue. They claim that it's for > JK> site admins to use and distributions can't layout any files that > JK> may disrupt or overwrite what a site admin may already have in > JK> place. > > Why don't we ignore the part of FHS that is broken, instead of > ignoring the part of FHS that arguably isn't? That is, put stuff in > /srv complete with layout, and stop polluting /var? Well, don't stop there. Treat FHS as an upstream and send a patch request to have it changed. It only makes sense to patch our packages if a change really makes sense and upstream takes a while to move (they probably have to go through a longish process to make changes). -- Richi Plana From rdieter at math.unl.edu Thu Sep 27 14:57:54 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 27 Sep 2007 09:57:54 -0500 Subject: ggz References: <599059470709270734k64719221n106cfb2681f970ee@mail.gmail.com> Message-ID: roopesh majeti wrote: > I would like to drop by penny of help :) > Rex, let me know the course of work !!!! Well, here's I've got so far: http://kde-redhat.unl.edu/apt/kde-redhat/SOURCES/ggz/ (testing now to see if this is enough for kdegames4 to build). -- Rex From aportal at univ-montp2.fr Thu Sep 27 15:18:43 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 27 Sep 2007 17:18:43 +0200 Subject: koji error Message-ID: <200709271718.43185.aportal@univ-montp2.fr> Hi, I tried to rebuild gpsim according the popt package split, but I got this error: make build OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [koji] Erreur 1 Any idea? Regards, Alain -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From abo at kth.se Thu Sep 27 15:37:48 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 27 Sep 2007 17:37:48 +0200 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <20070926212858.2c158581@redhat.com> <20070926212811.2f2eb03e@reaver.lamontpeterson.net> <20070927074341.19b40fa0@redhat.com> Message-ID: <1190907468.5022.70.camel@home.alexander.bostrom.net> tor 2007-09-27 klockan 14:11 +0200 skrev Benny Amorsen: > Why don't we ignore the part of FHS that is broken, instead of > ignoring the part of FHS that arguably isn't? That is, put stuff in > /srv complete with layout, and stop polluting /var? Yeah, but as the FHS says, there's no consensus, so it's not really going to work to just start creating stuff and setting defaults. If you _really_ want to have a structure in /srv, I suggest using /srv/pkg/ or /srv/lib/. Especially the last one is not very likely to be in use already, and it has a nice symmetry with /usr/lib (applications) and /var/lib (app-internal data). But I'm going to recite the Fedora mantra here: Upstream it! /abo From oliver at linux-kernel.at Thu Sep 27 15:40:31 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 27 Sep 2007 17:40:31 +0200 Subject: koji error In-Reply-To: <200709271718.43185.aportal@univ-montp2.fr> References: <200709271718.43185.aportal@univ-montp2.fr> Message-ID: <46FBCEEF.50608@linux-kernel.at> On 09/27/2007 05:18 PM, Alain PORTAL wrote: > Hi, > > I tried to rebuild gpsim according the popt package split, but I got this > error: > > > make build > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake > failure')] > make: *** [koji] Erreur 1 > > Any idea? I can do a scratch build of gpsim in dist-f8 without problems... Maybe something's wrong with your cert? There was some Wiki on how to check if the cert is still valid... You better check yourself new certs I think... -of From mikeb at redhat.com Thu Sep 27 15:41:17 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 27 Sep 2007 11:41:17 -0400 Subject: koji error In-Reply-To: <200709271718.43185.aportal@univ-montp2.fr> References: <200709271718.43185.aportal@univ-montp2.fr> Message-ID: <1190907677.5755.0.camel@localhost.localdomain> On Thu, 2007-09-27 at 17:18 +0200, Alain PORTAL wrote: > Hi, > > I tried to rebuild gpsim according the popt package split, but I got this > error: > > > make build > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake > failure')] > make: *** [koji] Erreur 1 It looks like your certificate is expired. Get a new one from the Fedora Account System. From oliver at linux-kernel.at Thu Sep 27 15:43:00 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 27 Sep 2007 17:43:00 +0200 Subject: koji error In-Reply-To: <46FBCEEF.50608@linux-kernel.at> References: <200709271718.43185.aportal@univ-montp2.fr> <46FBCEEF.50608@linux-kernel.at> Message-ID: <46FBCF84.8050004@linux-kernel.at> On 09/27/2007 05:40 PM, Oliver Falk wrote: > On 09/27/2007 05:18 PM, Alain PORTAL wrote: >> Hi, >> >> I tried to rebuild gpsim according the popt package split, but I got this >> error: >> >> >> make build >> OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake >> failure')] >> make: *** [koji] Erreur 1 >> >> Any idea? > > I can do a scratch build of gpsim in dist-f8 without problems... Maybe > something's wrong with your cert? > > There was some Wiki on how to check if the cert is still valid... You > better check yourself new certs I think... I haven't found the wiki, but this way you can check: [oliver at malz ~]$ grep "Not After" .fedora.cert Not After : May 20 13:15:31 2008 GMT -of From oliver at linux-kernel.at Thu Sep 27 15:43:00 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 27 Sep 2007 17:43:00 +0200 Subject: koji error In-Reply-To: <46FBCEEF.50608@linux-kernel.at> References: <200709271718.43185.aportal@univ-montp2.fr> <46FBCEEF.50608@linux-kernel.at> Message-ID: <46FBCF84.8050004@linux-kernel.at> <<< No Message Collected >>> From tmz at pobox.com Thu Sep 27 15:47:05 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 27 Sep 2007 11:47:05 -0400 Subject: koji error In-Reply-To: <200709271718.43185.aportal@univ-montp2.fr> References: <200709271718.43185.aportal@univ-montp2.fr> Message-ID: <20070927154705.GB363@psilocybe.teonanacatl.org> Alain PORTAL wrote: > I tried to rebuild gpsim according the popt package split, but I got > this error: > > > make build > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired') Your ssl cert has expired. I believe you just need to visit https://admin.fedoraproject.org/accounts/gen-cert.cgi to generate a new one. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Everything the government touches turns to crap. -- Ringo Starr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From aportal at univ-montp2.fr Thu Sep 27 15:52:17 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 27 Sep 2007 17:52:17 +0200 Subject: koji error In-Reply-To: <46FBCF84.8050004@linux-kernel.at> References: <200709271718.43185.aportal@univ-montp2.fr> <46FBCEEF.50608@linux-kernel.at> <46FBCF84.8050004@linux-kernel.at> Message-ID: <200709271752.17548.aportal@univ-montp2.fr> Le Thursday 27 September 2007 17:43:00 Oliver Falk, vous avez ?crit?: > I haven't found the wiki, but this way you can check: > [oliver at malz ~]$ grep "Not After" .fedora.cert > Not After : May 20 13:15:31 2008 GMT Right Not After : Sep 21 15:26:09 2007 GMT -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From aportal at univ-montp2.fr Thu Sep 27 15:54:00 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 27 Sep 2007 17:54:00 +0200 Subject: koji error In-Reply-To: <20070927154705.GB363@psilocybe.teonanacatl.org> References: <200709271718.43185.aportal@univ-montp2.fr> <20070927154705.GB363@psilocybe.teonanacatl.org> Message-ID: <200709271754.00643.aportal@univ-montp2.fr> Le Thursday 27 September 2007 17:47:05 Todd Zullinger, vous avez ?crit?: > Your ssl cert has expired. I believe you just need to visit > https://admin.fedoraproject.org/accounts/gen-cert.cgi to generate a > new one. I generated a new one, but problem still here... Logout needed? -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From buytenh at wantstofly.org Thu Sep 27 16:15:10 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 27 Sep 2007 18:15:10 +0200 Subject: rpmdb and /var filesystem corruption in F7+ In-Reply-To: <46FBC5D2.60902@cora.nwra.com> References: <46FBC5D2.60902@cora.nwra.com> Message-ID: <20070927161510.GB20637@xi.wantstofly.org> On Thu, Sep 27, 2007 at 09:01:38AM -0600, Orion Poplawski wrote: > I have a lot of problems with rpmdb corruption occurring during > (network) installs since around February 2007, and with yum updates > afterwards. I've reported the problem here > . I've been seeing rpmdb environment corruption on ARM systems (all running >= 2.6.22) for a while now: https://www.redhat.com/archives/fedora-arm/2007-August/msg00007.html The theory was that there is still some problem with shared writable mmap()s, causing dirty pages to be dropped without being written out to disk. db4's data files are exclusively accessed via read()/write(), but the database environment is exclusively accessed via mmap(). One shred of evidence that seems to point in this direction is that I haven't seen this corruption occur on any of my ARM systems since we started mlock()ing the RPM database environment into memory: http://fedora-arm.wantstofly.org/diffs-f/rpm-4.4.2.1-10.fc8/rpm-4.4.2-always-mlock.patch One theory is that it might show up more on ARM systems because they typically have less RAM and thus more memory pressure. From mikeb at redhat.com Thu Sep 27 16:29:55 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 27 Sep 2007 12:29:55 -0400 Subject: koji error In-Reply-To: <200709271754.00643.aportal@univ-montp2.fr> References: <200709271718.43185.aportal@univ-montp2.fr> <20070927154705.GB363@psilocybe.teonanacatl.org> <200709271754.00643.aportal@univ-montp2.fr> Message-ID: <1190910595.5755.2.camel@localhost.localdomain> On Thu, 2007-09-27 at 17:54 +0200, Alain PORTAL wrote: > Le Thursday 27 September 2007 17:47:05 Todd Zullinger, vous avez ?crit : > > > Your ssl cert has expired. I believe you just need to visit > > https://admin.fedoraproject.org/accounts/gen-cert.cgi to generate a > > new one. > > I generated a new one, but problem still here... > Logout needed? You may need to rerun fedora-packager-setup.sh. From mjs at CLEMSON.EDU Thu Sep 27 16:31:51 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Thu, 27 Sep 2007 12:31:51 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190592214.4603.10.camel@localhost.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> <1190592214.4603.10.camel@localhost.localdomain> Message-ID: <1190910711.3079.16.camel@vincent52.localdomain> On Sun, 2007-09-23 at 20:03 -0400, Jeremy Katz wrote: > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > > system-config-display, there are two problems. > > > > (1) The Monitor section of xorg.conf is missing. > > This is correct -- there shouldn't need to be a monitor section as it > should be auto-detected When I use the vesa driver, it is auto-detected at 800x600, not 1280x800. I have to run system-config-display to select a capable monitor type (generic LCD or IBM TFT panel) before I can see 1280x800. > > > (2) The nv driver hangs with a black screen. The keyboard is still > > functional and I can reboot with -- --. > > This sounds like a driver bug, please file against xorg-x11-drv-nv and > include your X.log, lspci info and xorg.conf https://bugzilla.redhat.com/show_bug.cgi?id=249367 is already filed against F7. Should I do something (clone?) to get it in for F8T2? > > > - I used gparted to resize NTFS partitions and partition the drive. It > > hung at the end of the resize operation without confirming it is > > finished (although the operation appears to have completed). Also, > > gparted quits after the rescan step after each operation set. > > Haven't seen/heard this one. Probably worth filing against gparted (or > maybe ntfs-progs; hard to say) though Definitely gparted. The crash occurs on re-scanning even if no operation is performed. https://bugzilla.redhat.com/show_bug.cgi?id=309251. > > > - Have to install with "vesa" kernel option. The nv driver boots to a > > black screen. > > Same as above. > > > - On the Disk Druid screen, the screen is not repainted after opening > > and closing popups. > > This is filed already -- see bug 289281 > > > - The display is only configured for 800x600. > > This is going to be related to lack of proper monitor probing. Report against what component? > > > - Screen brightness is erratic. The screen brightness applet appears, > > but whatever controls I hit, brightness changes randomly up or down and > > does not get fully bright or dim. If I switch to a VC, I can control > > the brightness, but ^@ characters appear on the display. > > This has been reported a couple of times-- Warren was going to try to > track this down and get some better reporting of it I believe > > > - X server doesn't terminate on logout--I have to -- to > > kill it. > > Sounds like an X server bug > > > - Suspend doesn't work at all. Select Suspend from the power applet and > > the machine starts to suspend, the light comes on, then the light goes > > off and the machine is live, except that the display is black. I can > > reboot as above. > > Using which X driver? Vesa. It also happened under F7 with either vesa or the proprietary nvidia driver. I can't try nv, as it doesn't work at all. > > > - Hibernate appears to work, but on resume I get a message that > > hibernate failed. > > Sounds buggy Report against what component? > > > - Stopping the bluetooth service on reboot or shutdown fails, although > > starting on bootup succeeds. Have not tested bluetooth functionality > > otherwise. > > I believe I saw some discussion about this, but am not certain anymore Thanks. > > Jeremy > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From ajackson at redhat.com Thu Sep 27 17:00:34 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 27 Sep 2007 13:00:34 -0400 Subject: /etc/hosts and system entries In-Reply-To: <1190902242.3476.8.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> Message-ID: <1190912434.30715.1.camel@localhost.localdomain> On Thu, 2007-09-27 at 10:10 -0400, Simo Sorce wrote: > On Thu, 2007-09-27 at 10:02 -0400, David Cantrell wrote: > > On Thu, 27 Sep 2007 09:59:16 -0400 > > Harry Hoffman wrote: > > > > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > > > > > # Do not remove the following line, or various programs > > > # that require network functionality will fail. > > > 127.0.0.1 localhost.localdomain localhost > > > > > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > > > of the system was also added to the localhost entry: > > > > > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > > > > > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > > > mail from the system via a mail host then address would appear as: > > > root at my.host.com instead of root at localhost.com > > > > > > Am I remembering correctly, in terms of how I believe it used to be? If > > > so, anyone know why it changed? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=253979 > > > > Fixed in rawhide. > > > > Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. > > Please, PLEASE, reconsider. > I've long hated this thing of assigning the hostname to 127.0.0.1, it > always breaks when using kerberos/winbindd as the hostname needs to > reflect the public facing ip. Why is this not a bug in kerberos? If the application knows that the IP address it wants for the name needs to be globally routable, then the application should be responsible for walking the list of IPs for that name to find the routable ones. - ajax From lkundrak at redhat.com Thu Sep 27 17:21:06 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 27 Sep 2007 19:21:06 +0200 Subject: /etc/hosts and system entries In-Reply-To: <1190902242.3476.8.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> Message-ID: <1190913666.4815.3.camel@localhost.localdomain> On Thu, 2007-09-27 at 10:10 -0400, Simo Sorce wrote: > On Thu, 2007-09-27 at 10:02 -0400, David Cantrell wrote: > > On Thu, 27 Sep 2007 09:59:16 -0400 > > Harry Hoffman wrote: > > > > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > > > > > # Do not remove the following line, or various programs > > > # that require network functionality will fail. > > > 127.0.0.1 localhost.localdomain localhost > > > > > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > > > of the system was also added to the localhost entry: > > > > > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > > > > > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > > > mail from the system via a mail host then address would appear as: > > > root at my.host.com instead of root at localhost.com > > > > > > Am I remembering correctly, in terms of how I believe it used to be? If > > > so, anyone know why it changed? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=253979 > > > > Fixed in rawhide. > > > > Why it changed...don't know, but I'll take the blame since I'm responsible for a lot of the network gutting and rewriting in anaconda. Most likely a mistake on my part. > > > Please, PLEASE, reconsider. +1 Relying on the hostname resolving via hosts(5) to loopback address is plainly incorrect. Harry: hosts file is also meant to be exported via NIS. > > Simo. > > -- Lubomir Kundrak (Red Hat Security Response Team) From loganjerry at gmail.com Thu Sep 27 17:26:34 2007 From: loganjerry at gmail.com (Jerry James) Date: Thu, 27 Sep 2007 11:26:34 -0600 Subject: mediawiki dependencies In-Reply-To: <1190865859.3259.50.camel@ignacio.lan> References: <870180fe0709261344y6286e1b6l9bffeefa67c4dab7@mail.gmail.com> <1190865859.3259.50.camel@ignacio.lan> Message-ID: <870180fe0709271026t261bf73ctea58fa986019b1c@mail.gmail.com> On 9/26/07, Ignacio Vazquez-Abrams wrote: > You've updated php against a testing version that has been withdrawn. Ummmm.... how did I do that? I just set this machine up 10 days ago, so I'm pretty sure I'd remember enabling the testing repo. Also: [root at localhost ~]# yum repolist Loading "skip-broken" plugin repo id repo name status fedora Fedora 7 - i386 enabled updates Fedora 7 - i386 - Updates enabled Did the php RPMs escape to updates temporarily and I just got unlucky enough to yum update right then, or is yum fetching RPMs from testing without my permission? My yum log shows that the php packages were updated on Sep 19 at 16:19 MDT (== 22:19 UTC). In fact, package-cleanup --orphans shows that I also have pilot-link-0.12.2-4.fc7.i386, which is not in the fedora or updates repositories, so I presume that is from testing, too. The yum log shows that was installed on Sep 17 at 11:50 MDT (== 17:50 UTC). Has anybody noticed that --problems is listed twice on the package-cleanup man page? -- Jerry James http://loganjerry.googlepages.com/ From darrellpf at gmail.com Thu Sep 27 17:28:36 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Thu, 27 Sep 2007 10:28:36 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has gone away. I can use it to connect to wireless networks again without a lot of service restarting. For iwl3945, kernel-2.6.23-0.204.rc8.fc8 seems broken still. The 181 kernel works though. darrell From tmraz at redhat.com Thu Sep 27 18:22:41 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 27 Sep 2007 20:22:41 +0200 Subject: /etc/hosts and system entries In-Reply-To: <1190902042.3476.4.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <1190902042.3476.4.camel@hopeson> Message-ID: <1190917361.14778.38.camel@vespa.kabelta.loc> On Thu, 2007-09-27 at 10:07 -0400, Simo Sorce wrote: > On Thu, 2007-09-27 at 09:59 -0400, Harry Hoffman wrote: > > Hi, > > > > So, /etc/hosts comes setup by default (i.e. after kickstart install) > > > > # Do not remove the following line, or various programs > > # that require network functionality will fail. > > 127.0.0.1 localhost.localdomain localhost > > > > I'm fairly certain to not too long ago (redhat-9 perhaps) the hostname > > of the system was also added to the localhost entry: > > > > 127.0.0.1 my.host.com my localhost.localdomain localhost > > > > > > This had the distinct advantage that when apps (i.e. yum-updatesd) sent > > mail from the system via a mail host then address would appear as: > > root at my.host.com instead of root at localhost.com > > But breaks miserably in other situations when you wanto to resolve the > ip address of your machine. A typical example is kerberos and winbindd > (also using kerberos). > > > Am I remembering correctly, in terms of how I believe it used to be? If > > so, anyone know why it changed? > > Breaks stuff. Yes, it also causes this problem: https://bugzilla.redhat.com/show_bug.cgi?id=217925 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From lamont at gurulabs.com Thu Sep 27 18:23:49 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 27 Sep 2007 12:23:49 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <200709270855.17552.sgrubb@redhat.com> References: <46F33D05.4020701@ncsu.edu> <200709270636.14666.sgrubb@redhat.com> <46FB8DEC.1010201@warmcat.com> <200709270855.17552.sgrubb@redhat.com> Message-ID: <20070927122349.6630b9cc@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 27 Sep 2007 08:55:17 -0400 Steve Grubb wrote: > On Thursday 27 September 2007 07:03:08 Andy Green wrote: > > But when you create a file, by cp or whatever, it must use private > > knowledge about the specific path's "natural" context or it can't > > automagically label new files correctly based on where they were > > created. > > Correct. Cp has been coded to look at the originating context and > apply that to the destination context when the --preserve option is > supplied. It does not change the policy and the first time a relabel > occurs, the context may be reset. > > > Maybe it will be possible to adjust the policies to accept both > > /var/blah and /srv/blah, or via a bool. > > It looks like a couple daemons were done like this. However, its not > all daemons and you have to move the files exactly where selinux > policy says or you are fighting selinux. No, the "policy" doesn't say anything about file locations. The .fc files have something to say about file locations and are what is used for relabeling and thus need to have an entry added/edited if /srv/www/ and such were made to be default locations. The point is, SELinux policies should just work and .fc would need an extremely minor update in order to support additional paths like /srv/www/ for confined services. Additionally, there's no reason that both /var/www/ and /srv/www/ couldn't be listed for Apache in the .fc files. Thus, using "SELinux would have be changed" as an argument against using /srv/ as a default path for things that it makes sense to have in there is nonsense. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+/U1+YBsl9wN1AkRAr6UAJ9RzShmujbmAUjF21LcQM2uOvKF3ACfVoiE x7MtGJb4LrsTBuDSE/KC7QA= =3ySW -----END PGP SIGNATURE----- From rhally at mindspring.com Thu Sep 27 18:28:14 2007 From: rhally at mindspring.com (Richard Hally) Date: Thu, 27 Sep 2007 14:28:14 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070927074100.6a37fc03@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> <20070927074100.6a37fc03@redhat.com> Message-ID: <46FBF63E.5060909@mindspring.com> Jesse Keating wrote: > On Wed, 26 Sep 2007 20:52:45 -0600 > Richi Plana wrote: > >> Technically, those SELinux policies should come or be set by the >> installation package. Would you happen to know what Fedora's stand on >> that is? > > Not possible until SELinux upstream allows files to be written out with > an unknown context or unabled context and switch to the new policy when > it gets applied. > > Or something like that. Long long history and anger around this issue. > Huh? http://fedoraproject.org/wiki/PackagingDrafts/SELinux http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules From david at lovesunix.net Thu Sep 27 19:44:49 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 27 Sep 2007 21:44:49 +0200 Subject: yum pulling in 386 packages In-Reply-To: <1190801687.2905.308.camel@pmac.infradead.org> References: <1190504010.2166.22.camel@cutter> <3e4ec4600709221642q99592d8pf35d7a4ea58475b1@mail.gmail.com> <1190504659.2166.24.camel@cutter> <1190537312.7150.300.camel@pmac.infradead.org> <20070923071514.5d7b9f44@redhat.com> <1190565005.7150.308.camel@pmac.infradead.org> <20070924072407.6fa861a2@redhat.com> <46F92707.1050205@redhat.com> <1190733795.6478.46.camel@cutter> <20070925212926.GB31754@ryvius.pekin.waw.pl> <1190797396.27642.1.camel@dawkins> <1190801687.2905.308.camel@pmac.infradead.org> Message-ID: <1190922289.2885.9.camel@dawkins> ons, 26 09 2007 kl. 11:14 +0100, skrev David Woodhouse: > On Wed, 2007-09-26 at 11:03 +0200, David Nielsen wrote: > > tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann' Mierzejewski: > > > nspluginwrapper works quite well. > > > > I've never personally had any kind of success with it > > Really? At one point (with a bit of qemu hacking) I even had the i386 > flash plugin running with nspluginwrapper+qemu-i386 in my PowerPC > firefox. I wouldn't _recommend_ it, and there was a bit more > thread-related qemu hacking to be done before it worked _well_, but it > was definitely working. Ah it turns out that nspluginwrapper does not work when you are using Epiphany, even if they are using the same gecko backend. So I have the option of using gnash and my favorite browser or be forced to use Firefox (which I loath) and then have the option of using the official flash plugin. Gnash fortunately has been quite good to me, sure once in a while I have to reload a youtube page to get the videos playing and it doesn't really support anywhere near the full range of flash sites but it's shaping up very nicely. - David From kmacmill at redhat.com Thu Sep 27 19:53:38 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 27 Sep 2007 15:53:38 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46FBF63E.5060909@mindspring.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> <20070927074100.6a37fc03@redhat.com> <46FBF63E.5060909@mindspring.com> Message-ID: <1190922818.3197.19.camel@localhost.localdomain> On Thu, 2007-09-27 at 14:28 -0400, Richard Hally wrote: > Jesse Keating wrote: > > On Wed, 26 Sep 2007 20:52:45 -0600 > > Richi Plana wrote: > > > >> Technically, those SELinux policies should come or be set by the > >> installation package. Would you happen to know what Fedora's stand on > >> that is? > > > > Not possible until SELinux upstream allows files to be written out with > > an unknown context or unabled context and switch to the new policy when > > it gets applied. > > > > Or something like that. Long long history and anger around this issue. > > > > Huh? > > http://fedoraproject.org/wiki/PackagingDrafts/SELinux > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules > The basic problem is that packages that contain SELinux policy often contain new types and the package installs files that should get those new types. So you end up with a chicken and egg problem - the package has the policy which needs to be installed before the package. There are a few solutions: 1) Separate packages for policy and apps - the app depends on the policy package. The problem is that the order packages are installed during a transaction can't be guaranteed, so this doesn't always solve the problem. It also means more packages. 2) Have rpm treat the policy specially - the rpm maintainers don't want to do this (I can understand). 3) Have rpm set contexts that aren't yet valid. This option was explored and there was even a kernel patch that would allow this. The fear is that it would allow a malicious package to create files with _any_ context that is not yet valid. It makes it difficult or impossible to constrain rpm. You could go back after the policy is installed and check for contexts that are still invalid and fix those. No decision was reached about how to handle the hole and nothing happened. The SELinux upstream developers (well, at least me) are willing to reconsider this proposal. 4) Allow the files to be laid down with whatever types the current policy gives them and relabel based on the new policy in post. This means touching every file twice (worst case) and also has some security concerns. 4 is a reasonable option except for performance concerns and that is what those packaging guidelines suggest (last I checked). Karl From mattdm at mattdm.org Thu Sep 27 20:10:36 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 27 Sep 2007 16:10:36 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: References: <1190823905.15397.16.camel@vincent52.localdomain> Message-ID: <20070927201036.GA21031@jadzia.bu.edu> On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote: > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has > gone away. I can use it to connect to wireless networks again without > a lot of service restarting. Yeah, works for me too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Sep 27 20:18:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 27 Sep 2007 16:18:08 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190922818.3197.19.camel@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> <20070927074100.6a37fc03@redhat.com> <46FBF63E.5060909@mindspring.com> <1190922818.3197.19.camel@localhost.localdomain> Message-ID: <20070927161808.672f61f4@redhat.com> On Thu, 27 Sep 2007 15:53:38 -0400 Karl MacMillan wrote: > 3) Have rpm set contexts that aren't yet valid. This option was > explored and there was even a kernel patch that would allow this. The > fear is that it would allow a malicious package to create files with > _any_ context that is not yet valid. It makes it difficult or > impossible to constrain rpm. You could go back after the policy is > installed and check for contexts that are still invalid and fix > those. No decision was reached about how to handle the hole and > nothing happened. The SELinux upstream developers (well, at least me) > are willing to reconsider this proposal. Wouldn't it be reasonable to lay them down as 'undefined_t' and let the post-rpm transactions relabel them? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From triad at df.lth.se Thu Sep 27 20:19:00 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 27 Sep 2007 22:19:00 +0200 (CEST) Subject: lesswatts.org In-Reply-To: <20070923215708.GC8480@roque.1407.org> References: <1190437993.9010.5.camel@localhost6.localdomain6> <20070923215708.GC8480@roque.1407.org> Message-ID: On Sun, 23 Sep 2007, Rui Miguel Silva Seabra wrote: > It's an interesting initiative, but is it helping the AMD64 people? I > expect some measures help, regardless of architecture, but definitely > not all, and powertop seems overly dedicated to intel hardware! The move by Intel to launch lesswatts.org is not philantrophic, they want to gain a competitive advantage over AMD (and other competitors such as VIA chipsets) on Linux systems by doing this. AMD (and others) have to answer to it of course. Linus From cra at WPI.EDU Thu Sep 27 20:20:09 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 27 Sep 2007 16:20:09 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070927201036.GA21031@jadzia.bu.edu> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> Message-ID: <20070927202009.GR6066@angus.ind.WPI.EDU> On Thu, Sep 27, 2007 at 04:10:36PM -0400, Matthew Miller wrote: > On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote: > > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has > > gone away. I can use it to connect to wireless networks again without > > a lot of service restarting. > > Yeah, works for me too. Not working here. I use the ath5k driver and it scans and find wireless networks, but when I click on them (WPA/WPA2 Enterprise required) nothing happens--no pop up, no dialog asking for certificate files, nothing. From sandeen at redhat.com Thu Sep 27 20:23:31 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 27 Sep 2007 15:23:31 -0500 Subject: lesswatts.org In-Reply-To: References: <1190437993.9010.5.camel@localhost6.localdomain6> <20070923215708.GC8480@roque.1407.org> Message-ID: <46FC1143.2080803@redhat.com> Linus Walleij wrote: > On Sun, 23 Sep 2007, Rui Miguel Silva Seabra wrote: > >> It's an interesting initiative, but is it helping the AMD64 people? I >> expect some measures help, regardless of architecture, but definitely >> not all, and powertop seems overly dedicated to intel hardware! > > The move by Intel to launch lesswatts.org is not philantrophic, they want > to gain a competitive advantage over AMD (and other competitors such as > VIA chipsets) on Linux systems by doing this. > > AMD (and others) have to answer to it of course. I'd be willing to bet that patches submitted to powertop to better support AMD64 (if any are even needed), would be happily accepted by the project. -Eric From mattdm at mattdm.org Thu Sep 27 20:27:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 27 Sep 2007 16:27:33 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070927202009.GR6066@angus.ind.WPI.EDU> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> <20070927202009.GR6066@angus.ind.WPI.EDU> Message-ID: <20070927202733.GA22657@jadzia.bu.edu> On Thu, Sep 27, 2007 at 04:20:09PM -0400, Chuck Anderson wrote: > > Yeah, works for me too. > Not working here. I use the ath5k driver and it scans and find > wireless networks, but when I click on them (WPA/WPA2 Enterprise > required) nothing happens--no pop up, no dialog asking for certificate > files, nothing. I should add that I'm not using WPA. Previously, it was so broken that nothing at all worked. Now, non-autheneticated connections work fine. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From che666 at gmail.com Thu Sep 27 20:45:46 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 27 Sep 2007 22:45:46 +0200 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070927202733.GA22657@jadzia.bu.edu> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> <20070927202009.GR6066@angus.ind.WPI.EDU> <20070927202733.GA22657@jadzia.bu.edu> Message-ID: 2007/9/27, Matthew Miller : > On Thu, Sep 27, 2007 at 04:20:09PM -0400, Chuck Anderson wrote: > > > Yeah, works for me too. > > Not working here. I use the ath5k driver and it scans and find > > wireless networks, but when I click on them (WPA/WPA2 Enterprise > > required) nothing happens--no pop up, no dialog asking for certificate > > files, nothing. > > I should add that I'm not using WPA. Previously, it was so broken that > nothing at all worked. Now, non-autheneticated connections work fine. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > the vpn(c) plugin still doesent use previous settings properly for me and i actually just reverted to 0.6 for the while beeing to still have it working properly. regards, Rudolf Kastl From jkeating at redhat.com Thu Sep 27 20:49:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 27 Sep 2007 16:49:39 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> <20070927202009.GR6066@angus.ind.WPI.EDU> <20070927202733.GA22657@jadzia.bu.edu> Message-ID: <20070927164939.19091984@redhat.com> On Thu, 27 Sep 2007 22:45:46 +0200 "Rudolf Kastl" wrote: > the vpn(c) plugin still doesent use previous settings properly for me > and i actually just reverted to 0.6 for the while beeing to still have > it working properly. This is known, and hopefully we'll have a build tonight that may fix that. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Sep 27 20:52:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 27 Sep 2007 23:52:50 +0300 Subject: pm-utils ping-pong upgrade/downgrade problem in F7 Message-ID: <200709272352.51295.ville.skytta@iki.fi> Hello, pm-utils-0.99.3-6.fc7 and pm-utils-0.99.4-3.fc7 have a ping-pong upgrade/downgrade problem which bites smart: pm-utils-0.99.3-6.fc7 obsoletes (unversioned!) radeontool and vbetool, pm-utils-0.99.4-3.fc7 requires them (unversioned too), resulting in: # rpm -q pm-utils radeontool vbetool pm-utils-0.99.4-3.fc7.x86_64 radeontool-1.5-2.fc7.x86_64 vbetool-0.7-2.fc7.x86_64 # smart upgrade [...] Upgrading packages (1): pm-utils-0.99.3-6.fc7 at x86_64 Downgrading packages (1): pm-utils-0.99.3-6.fc7 at x86_64 Here smart decides to downgrade to pm-utils-0.99.3-6.fc7 because it sees it obsoletes the installed radeontool and vbetool versions. Once the downgrade is done, vbetool and radeontool are gone too. The "Upgrading packages" message looks like a smart bug, ditto the fact that it doesn't say beforehand that it's going to remove radeontool and vbetool. Anyway, after that transaction: # smart upgrade [...] Upgrading packages (1): pm-utils-0.99.4-3.fc7 at x86_64 Downgrading packages (2): radeontool-1.5-2.fc7 at x86_64 vbetool-0.7-2.fc7 at x86_64 Ok, back we go to 0.99.4-3.fc7, and get radeontool and vbetool back too. After that, again: # smart upgrade [...] Upgrading packages (1): pm-utils-0.99.3-6.fc7 at x86_64 Downgrading packages (1): pm-utils-0.99.3-6.fc7 at x86_64 Etc etc. Duh. yum does not appear to be affected by this. I suppose this could be argued to be a bug either in smart or yum (I don't have that strong opinions about which one it is although yum behaves in the desired way in this particular case), but it once again provides one example why unversioned Obsoletes and Provides are bad (which is why I'm posting here instead of reporting this to Bugzilla). I'm not sure about this and haven't tested, but I guess adding Obsoletes: pm-utils < %{version}-%{release} to the new pm-utils could help smart get over it. Thoughts? From camilo at mesias.co.uk Thu Sep 27 21:06:41 2007 From: camilo at mesias.co.uk (Camilo Mesias) Date: Thu, 27 Sep 2007 22:06:41 +0100 Subject: lesswatts.org In-Reply-To: <46FC1143.2080803@redhat.com> References: <1190437993.9010.5.camel@localhost6.localdomain6> <20070923215708.GC8480@roque.1407.org> <46FC1143.2080803@redhat.com> Message-ID: Shouldn't it be fewerwatts? There's room for AMD to launch a competing initiative. -Cam From kmacmill at redhat.com Thu Sep 27 21:11:25 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 27 Sep 2007 17:11:25 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <20070927161808.672f61f4@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> <20070927074100.6a37fc03@redhat.com> <46FBF63E.5060909@mindspring.com> <1190922818.3197.19.camel@localhost.localdomain> <20070927161808.672f61f4@redhat.com> Message-ID: <1190927485.3197.30.camel@localhost.localdomain> On Thu, 2007-09-27 at 16:18 -0400, Jesse Keating wrote: > On Thu, 27 Sep 2007 15:53:38 -0400 > Karl MacMillan wrote: > > > 3) Have rpm set contexts that aren't yet valid. This option was > > explored and there was even a kernel patch that would allow this. The > > fear is that it would allow a malicious package to create files with > > _any_ context that is not yet valid. It makes it difficult or > > impossible to constrain rpm. You could go back after the policy is > > installed and check for contexts that are still invalid and fix > > those. No decision was reached about how to handle the hole and > > nothing happened. The SELinux upstream developers (well, at least me) > > are willing to reconsider this proposal. > > Wouldn't it be reasonable to lay them down as 'undefined_t' and let the > post-rpm transactions relabel them? > That is possible - though obviously you have to handle things cleanly for upgrades to that you don't end up with, say, libc labeled as undefined_t. So you would have to: 1) check every context as you put a file down 2) if it is valid set it 3) otherwise, set to undefined_t (and ideally add file to list) 4) install policy in post 5) relabel (ideally with list kept from before) Part of the problem, though, is figuring out what the context for a file should be. I believe that you can record contexts from when the rpm was built, but how do you handle if the admin has a local labeling rule that should take effect? Karl From alan at redhat.com Thu Sep 27 21:12:24 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 27 Sep 2007 17:12:24 -0400 Subject: lesswatts.org In-Reply-To: References: <1190437993.9010.5.camel@localhost6.localdomain6> <20070923215708.GC8480@roque.1407.org> Message-ID: <20070927211224.GB27298@devserv.devel.redhat.com> On Thu, Sep 27, 2007 at 10:19:00PM +0200, Linus Walleij wrote: > to gain a competitive advantage over AMD (and other competitors such as > VIA chipsets) on Linux systems by doing this. > > AMD (and others) have to answer to it of course. Lets hope AMD know the difference between less and fewer From wtogami at redhat.com Thu Sep 27 21:27:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 27 Sep 2007 17:27:25 -0400 Subject: Category: Uncategorized in comps Message-ID: <46FC203D.9050003@redhat.com> Uncategorized > Window Managers ... shows up in Anaconda and Pirut. Is this an intentional name? Warren Togami wtogami at redhat.com From opensource at till.name Thu Sep 27 22:08:16 2007 From: opensource at till.name (Till Maas) Date: Fri, 28 Sep 2007 00:08:16 +0200 Subject: pm-utils ping-pong upgrade/downgrade problem in F7 In-Reply-To: <200709272352.51295.ville.skytta@iki.fi> References: <200709272352.51295.ville.skytta@iki.fi> Message-ID: <200709280008.35231.opensource@till.name> On Do September 27 2007, Ville Skytt? wrote: > I'm not sure about this and haven't tested, but I guess adding > Obsoletes: pm-utils < %{version}-%{release} > to the new pm-utils could help smart get over it. Thoughts? This seems not to work, I build a local pm-utils package, that obsoletes the older one: # rpm --obsoletes -q pm-utils pm-utils < 0.99.4-3.fc7 # LANG=C smart upgrade [...] Upgrading packages (1): pm-utils-0.99.3-6.fc7 at i386 Downgrading packages (1): pm-utils-0.99.3-6.fc7 at i386 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Thu Sep 27 22:36:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 27 Sep 2007 22:36:56 +0000 (UTC) Subject: pm-utils ping-pong upgrade/downgrade problem in F7 References: <200709272352.51295.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > Etc etc. Duh. yum does not appear to be affected by this. I suppose this > could be argued to be a bug either in smart or yum (I don't have that strong > opinions about which one it is although yum behaves in the desired way in > this particular case) Synaptic does the right thing too (upgrades pm-utils, installs radeontool and vbetool, no ping-pong). IMHO, this is smart trying to be too smart. This example shows how automatic downgrading is evil. Yum and apt won't even look at old versions of packages unless you force them to (in yum, you also need the yum-allowdowngrade plugin to even be able to force it). Kevin Kofler From buildsys at fedoraproject.org Thu Sep 27 22:44:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 27 Sep 2007 18:44:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-27 Message-ID: <20070927224417.4A0F615212D@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 8 NEW animorph-0.2-2.fc6 : 3D Animation and Morph Library (!) CCfits-1.7-1.fc6 : INVALID rebuild, not published! NEW python-fedora-0.2.90.19-1.fc6 : Python modules for talking to Fedora Infrastructure Services qgis-0.9.0-1.fc6 NEW solarwolf-1.5-2.fc6 : A Python port of SolarFox sysprof-kmod-1.0.8-1.2.6.22.7_57.fc6 t1lib-5.1.1-3.fc6 xmoto-0.3.3-2.fc6 Changes in Fedora Extras 6: animorph-0.2-2.fc6 ------------------ * Wed Sep 12 2007 kwizart < kwizart at gmail.com > - 0.2-2 - Change license to GPLv2+ as said in the source code - Remove BR glibc-headers - Change summary (taken from animorph.pc) CCfits-1.7-1.fc6 ---------------- * Sun Jul 22 2007 Sergio Pascual 1.7-1 - New upstream source 1.7 python-fedora-0.2.90.19-1.fc6 ----------------------------- * Tue Sep 25 2007 Toshio Kuratomi - 0.2.90.19-1 - New upstream release with a FAS2 unicode fix. * Mon Sep 24 2007 Toshio Kuratomi - 0.2.90.18-3 - Fix the Source URL. Should be fedorapeople rather than fedoraproject. * Fri Sep 21 2007 Toshio Kuratomi - 0.2.90.18-2 - BR: python-setuptools-devel as this has been split in the new versions. * Tue Sep 18 2007 Toshio Kuratomi - 0.2.90.18-1 - Update to version wih handling of control-center-maint bugzilla address. * Tue Sep 18 2007 Toshio Kuratomi - 0.2.90.17-2 - Minor touchups to description and URL. * Mon Sep 17 2007 Toshio Kuratomi - 0.2.90.17-1 - Update to 0.2.90.17. - Build separate packages for pieces useful on clients and only on the server. * Mon Sep 10 2007 Toshio Kuratomi - 0.2.90.16-1 - Bugfix to fasLDAP module. * Fri Sep 07 2007 Toshio Kuratomi - 0.2.90.15-1 - Make the fasLDAP module more OO. - Bugfixes. - Update the install line. qgis-0.9.0-1.fc6 ---------------- * Wed Sep 26 2007 Douglas E. Warner 0.9.0-1 - update to 0.9.0 - remove settings-include-workdir.patch - updated man-install-share.patch to man-install-share-0.9.0.patch - updated lib64-suffix.patch to lib64-suffix-0.9.0.patch - enabled python to support msexport tool - added Requires: grass to grass subpackage * Tue Aug 28 2007 Douglas E. Warner 0.8.1-13 - bump for expat 2.0 rebuild bug#195888 * Thu Aug 02 2007 Douglas E. Warner 0.8.1-12 - updated License from GPL to GPLv2+ solarwolf-1.5-2.fc6 ------------------- * Fri Sep 21 2007 Jon Ciesla - 1.5-2 - Fixed Source URL. - Switched from mv to cp for timestamps. - Moved permission correction to prep. * Fri Sep 14 2007 Jon Ciesla - 1.5-1 - create. sysprof-kmod-1.0.8-1.2.6.22.7_57.fc6 ------------------------------------ * Tue Aug 21 2007 Gianluca Sforna - Update License field t1lib-5.1.1-3.fc6 ----------------- * Thu Sep 27 2007 Jos? Matos - 5.1.1-3 - Apply patch to fix CVE-2007-4033 * Tue Aug 28 2007 Jos? Matos - 5.1.1-2 - License fix, rebuild for devel (F8). * Thu Jun 07 2007 Jos? Matos - 5.1.1-1 - Update to 5.1.1. - Remove t1lib-5.1.0-destdir.patch (applied upstream). xmoto-0.3.3-2.fc6 ----------------- * Mon Sep 24 2007 Jon Ciesla 0.3.3-2 - Patches from upstream to correct BZ 295981. From Matt_Domsch at dell.com Fri Sep 28 00:23:43 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 27 Sep 2007 19:23:43 -0500 Subject: i810switch -> xrandr for F8 Message-ID: <20070928002343.GA12138@auslistsprd01.us.dell.com> The i810switch program has been around for a while, and it forces the Intel i810 - i945 series video chips to enable or disable the external VGA or LCD panel video output devices on a laptop. i810switch has not had an update since June 2005. In Fedora 8, the xrandr application provides this same functionality, natively in the Xorg subsystem. In my limited testing, xrandr works on the i810 class hardware I have access to. I'd like to drop i810switch from the distribution for Fedora 8, and add a release note suggesting users of i810switch use xrandr instead. Thoughts? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From myfedora at richip.dhs.org Fri Sep 28 00:52:16 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 27 Sep 2007 18:52:16 -0600 Subject: i810switch -> xrandr for F8 In-Reply-To: <20070928002343.GA12138@auslistsprd01.us.dell.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> Message-ID: <1190940736.15886.10.camel@localhost6.localdomain6> On Thu, 2007-09-27 at 19:23 -0500, Matt Domsch wrote: > The i810switch program has been around for a while, and it forces the > Intel i810 - i945 series video chips to enable or disable the external > VGA or LCD panel video output devices on a laptop. i810switch has not > had an update since June 2005. > > In Fedora 8, the xrandr application provides this same functionality, > natively in the Xorg subsystem. > > In my limited testing, xrandr works on the i810 class hardware I have > access to. > > I'd like to drop i810switch from the distribution for Fedora 8, and > add a release note suggesting users of i810switch use xrandr instead. > > Thoughts? How does the xrandr method compare to i810switch's in terms of energy saving? Do they do the same thing to switch off the video output? If i810switch's method is better, can it's mechanism be rolled in to xrandr (via upstream, of course, 8-|). -- Richi Plana From lightsolphoenix at gmail.com Fri Sep 28 01:51:45 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 27 Sep 2007 21:51:45 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <46FADAE8.5020404@redhat.com> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> Message-ID: <200709272151.46167.lightsolphoenix@gmail.com> On Wednesday, September 26, 2007 6:19:20 pm John Dennis wrote: > Richi Plana wrote: > > If there's any interest, I could make spec files (based off of the > > latest SRPM) for one of these packages to move the data directory > > from /var to /srv. Just let me know which packages you find interesting > > and I'll submit the spec file to the package maintainer (or here if > > Fedora doesn't want to move it). > > Hold on there partner :-) In the case of mailman (and many other > packages) you can't just move things around without updating the selinux > policy in lock step. Then there's the issue of breaking all the scripts > out in the field which think they know where files are located, you're > going to ruffle a lot of feathers if you move things without a big prior > announcement Nah, just do what they did in openSUSE when the decision was made to move the Gnome stuff from the /opt folder to the /usr folder - have "compat" packages that create symlinks to the old locations, so that if the user has scripts that assume the stuff's still located in /var, they will still work properly. I'm not entirely sure how well this would work with SELinux, though. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From mike at miketc.com Fri Sep 28 02:29:27 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 27 Sep 2007 21:29:27 -0500 Subject: NO CD/DVD's detected Message-ID: <1190946567.32697.3.camel@scrappy.miketc.com> I don't know about after an initial f8t2 install, but at least since the updates, k3b nor xcdroast can detect a cdrom nor dvd drive. It wasn't detected on my last updated system before I did a reinstall yesterday. I can see the devices in the kernel messages. Would this have to do with cdrecord or something about that, as I thought there were license problems with that program and therefore is maybe screwing things up? -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From jkeating at redhat.com Fri Sep 28 04:28:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 00:28:59 -0400 Subject: Category: Uncategorized in comps In-Reply-To: <46FC203D.9050003@redhat.com> References: <46FC203D.9050003@redhat.com> Message-ID: <20070928002859.2454ba27@redhat.com> On Thu, 27 Sep 2007 17:27:25 -0400 Warren Togami wrote: > ... shows up in Anaconda and Pirut. Is this an intentional name? No, we just never got around to finding a good Category to stuff it in. The group itself is visible but not in any category. You pick one and make it happen. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Fri Sep 28 04:28:06 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 28 Sep 2007 00:28:06 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <46FABF0F.2010404@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> Message-ID: <1190953686.14740.0.camel@xo-3E-67-34.localdomain> On Wed, 2007-09-26 at 16:20 -0400, Zack Cerza wrote: > Tom London wrote: > > On 9/26/07, Jesse Keating wrote: > >> On Wed, 26 Sep 2007 15:06:03 -0400 > >> Matthew Miller wrote: > >> > >>> It seems pretty broken for me, and apparently others: > >>> > >>> > >>> > >>> Like, test3 showstopper level of broken. > >> Please retry with NetworkManager-0.7.0-0.3.svn2886.fc8 and the > >> wpa_supplicant that just missed rawhide: > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=19578 > >> > > I have these installed; NM seems to be scanning properly, but seems > > only to accept HEX keys in the 'prompt for key popups' for both WEP > > and WPA. > > > > That to be expected? > > > > tom > > That NM only accepts hex keys is going to be a big problem for me, too, > as my WPA2 AP only even lets me set a passphrase. /usr/sbin/wpa_passphrase > Of course, I've got bigger problems with my iwl3945 than NM: > https://bugzilla.redhat.com/show_bug.cgi?id=303871 > > Zack > From abo at kth.se Fri Sep 28 05:47:52 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 07:47:52 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <200709272151.46167.lightsolphoenix@gmail.com> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> Message-ID: <1190958472.5022.116.camel@home.alexander.bostrom.net> tor 2007-09-27 klockan 21:51 -0400 skrev Kelly: > Nah, just do what they did in openSUSE when the decision was made to move the > Gnome stuff from the /opt folder to the /usr folder - have "compat" packages > that create symlinks to the old locations, so that if the user has scripts > that assume the stuff's still located in /var, they will still work properly. > I'm not entirely sure how well this would work with SELinux, though. A httpd-compat-dir package with a %pre that moves /var/www to /srv/lib/www and makes /var/www a symlink? That might work, sometimes, but it will also break something in some systems and fail to install on others. (Different filesystems, one with, one without ACLs. One big, one small filesystem. Fill up the /srv filesystem so some other service breaks. /var/www is a network mount, /srv is local. I could go on...) This change can not be made transparent. You have to put the change in the release notes and let the admin sort out the mess after an upgrade. That's all you can do. Now can people _please_ discuss: * How to justify this change in the release notes. ("FHS told us to"?) * List of directories in /var that are "wrong". * Suggestions for what /srv structure to propose for the next FHS. I've already given my opinion about /srv, but I'll repeat it: If you necessarily need to impose a structure on it, put that structure only in /srv/lib. Make it /srv/lib/. You also need to make sure you follow the FHS or change the FHS regarding what goes in /var and what goes in /srv. To me, the FHS seems rather clear: /var is for files only the app should touch (and perhaps an admin too but preferably not), while /srv is for files which the users or admins need to find, look at and change. One problem is that something like that might change through the lifetime of an application, but you can't start moving things around because of that. /abo From opensource at till.name Fri Sep 28 06:07:42 2007 From: opensource at till.name (Till Maas) Date: Fri, 28 Sep 2007 08:07:42 +0200 Subject: i810switch -> xrandr for F8 In-Reply-To: <20070928002343.GA12138@auslistsprd01.us.dell.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> Message-ID: <200709280807.57725.opensource@till.name> On Fr September 28 2007, Matt Domsch wrote: > In Fedora 8, the xrandr application provides this same functionality, > natively in the Xorg subsystem. > > In my limited testing, xrandr works on the i810 class hardware I have > access to. How can one use xrandr to enable/disable vga output? I can test this with my X41 Thinkpad. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Fri Sep 28 06:10:11 2007 From: opensource at till.name (Till Maas) Date: Fri, 28 Sep 2007 08:10:11 +0200 Subject: NO CD/DVD's detected In-Reply-To: <1190946567.32697.3.camel@scrappy.miketc.com> References: <1190946567.32697.3.camel@scrappy.miketc.com> Message-ID: <200709280810.12211.opensource@till.name> On Fr September 28 2007, Mike Chambers wrote: > I can see the devices in the kernel messages. Would this have to do > with cdrecord or something about that, as I thought there were license > problems with that program and therefore is maybe screwing things up? Since Fedora 7, Fedora contains cdrkit instead of cdrecord, the application is now called wodim (cdrecord is a symlink to wodim) and does not have this license problems. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pmatilai at laiskiainen.org Fri Sep 28 06:11:07 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 28 Sep 2007 09:11:07 +0300 (EEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190927485.3197.30.camel@localhost.localdomain> References: <46F33D05.4020701@ncsu.edu> <1190839164.16820.53.camel@vincent52.localdomain> <1190843974.17132.10.camel@localhost6.localdomain6> <200709262117.40104.sgrubb@redhat.com> <1190861566.21836.0.camel@localhost6.localdomain6> <20070927074100.6a37fc03@redhat.com> <46FBF63E.5060909@mindspring.com> <1190922818.3197.19.camel@localhost.localdomain> <20070927161808.672f61f4@redhat.com> <1190927485.3197.30.camel@localhost.localdomain> Message-ID: On Thu, 27 Sep 2007, Karl MacMillan wrote: > On Thu, 2007-09-27 at 16:18 -0400, Jesse Keating wrote: >> On Thu, 27 Sep 2007 15:53:38 -0400 >> Karl MacMillan wrote: >> >>> 3) Have rpm set contexts that aren't yet valid. This option was >>> explored and there was even a kernel patch that would allow this. The >>> fear is that it would allow a malicious package to create files with >>> _any_ context that is not yet valid. It makes it difficult or >>> impossible to constrain rpm. You could go back after the policy is >>> installed and check for contexts that are still invalid and fix >>> those. No decision was reached about how to handle the hole and >>> nothing happened. The SELinux upstream developers (well, at least me) >>> are willing to reconsider this proposal. >> >> Wouldn't it be reasonable to lay them down as 'undefined_t' and let the >> post-rpm transactions relabel them? >> > > That is possible - though obviously you have to handle things cleanly > for upgrades to that you don't end up with, say, libc labeled as > undefined_t. So you would have to: > > 1) check every context as you put a file down > 2) if it is valid set it > 3) otherwise, set to undefined_t (and ideally add file to list) > 4) install policy in post > 5) relabel (ideally with list kept from before) > > Part of the problem, though, is figuring out what the context for a file > should be. I believe that you can record contexts from when the rpm was > built, but how do you handle if the admin has a local labeling rule that > should take effect? Rpm has been recording file contexts into headers from build time up to now, but nothing has been using it (except perhaps in early "selinux bootstrap" days, I don't know). I just killed that code a couple of weeks ago from rpm upstream, because it's just completely wrong: the selinux policy that happens to be loaded on the build host has *zero* relevance to that of the target host - could be local rules, or labeling differences between targeted/strict/whatever prepackaged policies or even just versions of the same policy. - Panu - From hughsient at gmail.com Fri Sep 28 06:38:13 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 28 Sep 2007 07:38:13 +0100 Subject: i810switch -> xrandr for F8 In-Reply-To: <20070928002343.GA12138@auslistsprd01.us.dell.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> Message-ID: <1190961493.2724.0.camel@hughsie-laptop> On Thu, 2007-09-27 at 19:23 -0500, Matt Domsch wrote: > In Fedora 8, the xrandr application provides this same functionality, > natively in the Xorg subsystem. Agreed. Richard. From fedora at camperquake.de Fri Sep 28 06:55:50 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 28 Sep 2007 08:55:50 +0200 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190953686.14740.0.camel@xo-3E-67-34.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> Message-ID: <20070928085550.2b74c397@banea.int.addix.net> Hi. On Fri, 28 Sep 2007 00:28:06 -0400, Dan Williams wrote: > > That NM only accepts hex keys is going to be a big problem for me, > > too, as my WPA2 AP only even lets me set a passphrase. > > /usr/sbin/wpa_passphrase That's nice, but no solutionn. From cjdahlin at ncsu.edu Fri Sep 28 07:07:21 2007 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Fri, 28 Sep 2007 03:07:21 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190958472.5022.116.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> Message-ID: <46FCA829.9040604@ncsu.edu> > Now can people _please_ discuss: > > * How to justify this change in the release notes. ("FHS told us > to"?) > There's been enough reasons in this thread, just a matter of aggregating them a bit. Immediately to mind are the divergent backup considerations. > * List of directories in /var that are "wrong". > /var/www, /var/ftp, /var/lib/mysql right off the top of my head. There's probably more. Let's keep going > * Suggestions for what /srv structure to propose for the next FHS. > > This is big enough that we might want to get the discussion going outside this mailing list before we spec this out > I've already given my opinion about /srv, but I'll repeat it: If you > necessarily need to impose a structure on it, put that structure only > in /srv/lib. Make it /srv/lib/. > > I agree. This is a fairly good compromise between all the issues brought up here. The FHS proposal might do something a little different, but this is the best solution for the present. > You also need to make sure you follow the FHS or change the FHS > regarding what goes in /var and what goes in /srv. To me, the FHS seems > rather clear: /var is for files only the app should touch (and perhaps > an admin too but preferably not), while /srv is for files which the > users or admins need to find, look at and change. One problem is that > something like that might change through the lifetime of an application, > but you can't start moving things around because of that. > > One (rather extreme) way to look at it is that /var contains information that should be stored in RAM except for 2 considerations: 1) it is too large, 2) its relevance may extend beyond the life of the process or across reboots. /var is a place for the application to write down what it is actively in the process of doing or where it left off when it last terminated. (This is how it SHOULD be IMHO. For now we should try not to break FHS beyond what we're doing now). > /abo > > > From aportal at univ-montp2.fr Fri Sep 28 07:17:14 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Fri, 28 Sep 2007 09:17:14 +0200 Subject: koji error In-Reply-To: <1190910595.5755.2.camel@localhost.localdomain> References: <200709271718.43185.aportal@univ-montp2.fr> <200709271754.00643.aportal@univ-montp2.fr> <1190910595.5755.2.camel@localhost.localdomain> Message-ID: <200709280917.14523.aportal@univ-montp2.fr> Le Thursday 27 September 2007 18:29:55 Mike Bonnet, vous avez ?crit?: > On Thu, 2007-09-27 at 17:54 +0200, Alain PORTAL wrote: > > Le Thursday 27 September 2007 17:47:05 Todd Zullinger, vous avez ?crit : > > > Your ssl cert has expired. I believe you just need to visit > > > https://admin.fedoraproject.org/accounts/gen-cert.cgi to generate a > > > new one. > > > > I generated a new one, but problem still here... > > Logout needed? > > You may need to rerun fedora-packager-setup.sh. Work fine, thanks! Alain -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From abo at kth.se Fri Sep 28 07:40:00 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 09:40:00 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <46FCA829.9040604@ncsu.edu> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> Message-ID: <1190965200.5022.126.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 03:07 -0400 skrev Casey Dahlin: > There's been enough reasons in this thread, just a matter of aggregating > them a bit. Immediately to mind are the divergent backup considerations. > > * List of directories in /var that are "wrong". > > > /var/www, /var/ftp, /var/lib/mysql right off the top of my head. There's > probably more. Let's keep going [...] > One (rather extreme) way to look at it is that /var contains information > that should be stored in RAM except for 2 considerations: 1) it is too > large, 2) its relevance may extend beyond the life of the process or > across reboots. /var is a place for the application to write down what > it is actively in the process of doing or where it left off when it last > terminated. (This is how it SHOULD be IMHO. For now we should try not to > break FHS beyond what we're doing now). Well, this seems to be spot on the current usage of /var/lib/mysql and also with the FHS's definition of /var/lib (*), so I don't really see why you think /var/lib/mysql is wrong. If you want to move /var/www to say /var/lib/www then that seems more in line with your idea of /var, though. *) http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION /abo From abo at kth.se Fri Sep 28 07:42:40 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 09:42:40 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1190965200.5022.126.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> Message-ID: <1190965360.5022.127.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 09:40 +0200 skrev Alexander Bostr?m: > move /var/www to say /var/lib/www /srv/lib/www, I mean /abo From mschwendt.tmp0701.nospam at arcor.de Fri Sep 28 07:47:22 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 28 Sep 2007 09:47:22 +0200 Subject: pm-utils ping-pong upgrade/downgrade problem in F7 In-Reply-To: References: <200709272352.51295.ville.skytta@iki.fi> Message-ID: <20070928094722.29d9539e.mschwendt.tmp0701.nospam@arcor.de> On Thu, 27 Sep 2007 22:36:56 +0000 (UTC), Kevin Kofler wrote: > Ville Skytt? writes: > > Etc etc. Duh. yum does not appear to be affected by this. I suppose this > > could be argued to be a bug either in smart or yum (I don't have that strong > > opinions about which one it is although yum behaves in the desired way in > > this particular case) > > Synaptic does the right thing too (upgrades pm-utils, installs radeontool and > vbetool, no ping-pong). IMHO, this is smart trying to be too smart. This > example shows how automatic downgrading is evil. +1 When the installed set of packages is not broken, i.e. the latest pm-utils requires the installed radeontool/vbetool pkgs without broken deps, why does Smart even look at the older pm-utils pkg? Does it always include old pkgs into its strategy? > > I'm not sure about this and haven't tested, but I guess adding > > Obsoletes: pm-utils < %{version}-%{release} > > to the new pm-utils could help smart get over it. Thoughts? Hmm... but it's already that a new version-release of a pkg implicitly replaces an old version-release, because that is how updates work. Effectively, you would try to add something only to get Smart not look at the old version-release anymore. From nicolas.mailhot at laposte.net Fri Sep 28 09:30:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Sep 2007 11:30:48 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190958472.5022.116.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> Message-ID: <29186.192.54.193.51.1190971848.squirrel@rousalka.dyndns.org> Le Ven 28 septembre 2007 07:47, Alexander Bostr?m a ?crit : > I've already given my opinion about /srv, but I'll repeat it: If you > necessarily need to impose a structure on it, put that structure only > in /srv/lib. Make it /srv/lib/. And this is broken by design. You're mirroring /var organisation when people have repeatedly told you this organisation was not adapted to their needs. Swapping /var and /srv does not make it magically sane. Also you contradict yourself by insisting both on packagename namespacing and taking a packagename-agnostic layout like /var/www as example. What's the point of lib in srv ? What's the point of forcing packagename in the namespace ? Admins do not move their http or ftp content just because they've switched http or ftp server implementation. The whole point of /srv is admins feel there is data that should be saved even if system libs are lost. The corollary is the coupling between this data and binary organisation is loose at best, and moving /srv to a system with a different set of binaries, different package repartition, is perfectly valid. Sure some stuff is package (and often package-version) specific, like database files. But a lot of it is completely package-agnostic. You should not force a stonger coupling than is technically required just because it makes packager life easier. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Sep 28 09:41:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Sep 2007 11:41:18 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190965200.5022.126.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> Message-ID: <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> Le Ven 28 septembre 2007 09:40, Alexander Bostr?m a ?crit : > Well, this seems to be spot on the current usage of /var/lib/mysql and > also with the FHS's definition of /var/lib (*), so I don't really see > why you think /var/lib/mysql is wrong. Because /var/ mixes long-term and transient data, generic and implementation-specific stuff, local and global data, and makes backup stategies a PITA for everything but SOHO contexts. People have little wish to comb /var and triage the different categories (no more than they had the wish to comb /home when it mixed human users and software users) Good backup is expensive backup so bulk-var-backup is not scaling In case of general system failure, or major release update, you're better of without a lot of /var contents, because some stuff is easier to set up again than take the risk of restoring a rotten state -- Nicolas Mailhot From jonathan.underwood at gmail.com Fri Sep 28 09:46:54 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 28 Sep 2007 10:46:54 +0100 Subject: i810switch -> xrandr for F8 In-Reply-To: <200709280807.57725.opensource@till.name> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> <200709280807.57725.opensource@till.name> Message-ID: <645d17210709280246j70d6c3f2t77c524c1195acfd3@mail.gmail.com> On 28/09/2007, Till Maas wrote: > On Fr September 28 2007, Matt Domsch wrote: > > > In Fedora 8, the xrandr application provides this same functionality, > > natively in the Xorg subsystem. > > > > In my limited testing, xrandr works on the i810 class hardware I have > > access to. > > How can one use xrandr to enable/disable vga output? I can test this with my > X41 Thinkpad. xrandr --output VGA --off From buildsys at redhat.com Fri Sep 28 10:09:31 2007 From: buildsys at redhat.com (Build System) Date: Fri, 28 Sep 2007 06:09:31 -0400 Subject: rawhide report: 20070928 changes Message-ID: <200709281009.l8SA9VOD013878@porkchop.devel.redhat.com> Updated Packages: NetworkManager-1:0.7.0-0.3.svn2907.fc8 -------------------------------------- * Thu Sep 27 2007 Dan Williams - 1:0.7.0-0.3.svn2907 - New snapshot - VPN support (only vpnc plugin ported at this time) anaconda-11.3.0.35-1 -------------------- * Thu Sep 27 2007 Jeremy Katz 11.3.0.35-1 - Support modname.option=value for passing options to kernel modules - Fix rescue CD + nfsiso (clumens) - Blacklist more wireless drivers that can't work - Make buildarch more predictable (#239897) java-1.7.0-icedtea-1.7.0.0-0.16.b19.snapshot.fc8 ------------------------------------------------ * Thu Sep 27 2007 Thomas Fitzsimmons - 1.7.0.0-0.16.b19.snapshot - Apply patch to use system tzdata. - Require tzdata-java. - Fix mauve shell fragment. * Thu Sep 27 2007 Lillian Angel - 1.7.0.0-0.15.b19.snapshot - Removed jtreg setup line. * Wed Sep 26 2007 Lillian Angel - 1.7.0.0-0.15.b19.snapshot - Removed jtreg. Does not adhere to Fedora guidelines. kernel-2.6.23-0.211.rc8.git2.fc8 -------------------------------- * Thu Sep 27 2007 Chuck Ebbert - Linux 2.6.23-rc8-git2 - Re-add AMD timer fix removed from upstream - Fix hotplug CPU (broken by AMD timer patch) * Thu Sep 27 2007 John W. Linville - Fix-up botched wireless patch restructuring... * Wed Sep 26 2007 John W. Linville - Update and restructure wireless patches kernel-xen-2.6-2.6.21-2944.fc8 ------------------------------ * Wed Sep 26 2007 Eduardo Habkost - Disable Firewire on i686. It is not supported by the current Xen swiotlb implementation (bug #307461) kvm-36-6.fc8 ------------ * Wed Sep 26 2007 Daniel P. Berrange - 36-6.fc8 - Fixed rtl8139 checksum calculation for Vista (rhbz #308201) mkinitrd-6.0.19-1.fc8 --------------------- * Thu Sep 27 2007 Peter Jones - 6.0.19-1 - Fix nosegneg library discovery in get_dso_deps() harder (#244730) qemu-0.9.0-5.fc8 ---------------- * Wed Sep 26 2007 Daniel P. Berrange - 0.9.0-5.fc8 - Fix rtl8139 checksum calculation for Vista (rhbz #308201) thinkfinger-0.3-5.fc8 --------------------- * Wed Sep 26 2007 Mike Bonnet - 0.3-5 - put fdi file in policy/ directory - use PolicyKit to manage fingerprint reader access tzdata-2007g-2.fc8 ------------------ * Tue Sep 25 2007 Keith Seitz - 2007g-2 - Add support for building java's zoneinfo files in new tzdata-java RPM. Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From benny+usenet at amorsen.dk Fri Sep 28 10:41:56 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 28 Sep 2007 12:41:56 +0200 Subject: [RFC] /var versus /srv References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <1190965360.5022.127.camel@home.alexander.bostrom.net> Message-ID: >>>>> "AB" == Alexander Bostr?m writes: AB> fre 2007-09-28 klockan 09:40 +0200 skrev Alexander Bostr?m: >> move /var/www to say /var/lib/www AB> /srv/lib/www, I mean There's no reason to have the spurious lib there. /Benny From johannbg at hi.is Fri Sep 28 10:57:08 2007 From: johannbg at hi.is (=?windows-1252?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 28 Sep 2007 10:57:08 +0000 Subject: Fedora spin from RpmFusion Message-ID: <46FCDE04.6040007@hi.is> We gonna start an Rpmfusion Fedora spin giving user the much wanted/needed media support in Fedora. With strictly the media support ( ugly-plugins etc. ) and the rpmfusion repo installed, and excluding AMD and Nvidia drivers will we need Rename the spin or could it be released under Fedora name and artwork? * Legal/others If needed to change the name/artwork would FedoriansFusion be A OK If naming/artwork is changed could we include the AMD and Nvidia drivers? Will this be available on fedoraprojects.org as in will Max Spevack put his money where is mouth is so I quote Max "So go forth and mix your own Fedora. And then come back and share it with us, and we?ll put it up on the _*Fedora website for others to use also.*_" ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) Or was this just a pr c... It would be interesting download stats Fedora VS Fedora with media support :) If everything is done outside US hosted outside US created outside US how much legal jibber jabber comes from that ? Not for US residents version of Fedora? Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mike at miketc.com Fri Sep 28 11:03:34 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 28 Sep 2007 06:03:34 -0500 Subject: NO CD/DVD's detected In-Reply-To: <200709280810.12211.opensource@till.name> References: <1190946567.32697.3.camel@scrappy.miketc.com> <200709280810.12211.opensource@till.name> Message-ID: <1190977414.3977.1.camel@scrappy.miketc.com> On Fri, 2007-09-28 at 08:10 +0200, Till Maas wrote: > On Fr September 28 2007, Mike Chambers wrote: > > > I can see the devices in the kernel messages. Would this have to do > > with cdrecord or something about that, as I thought there were license > > problems with that program and therefore is maybe screwing things up? > > Since Fedora 7, Fedora contains cdrkit instead of cdrecord, the application is > now called wodim (cdrecord is a symlink to wodim) and does not have this > license problems. Yes I can see that wodim is installed and the symlinks. But not sure if this is related to my problem or not though. If it's been this way a while, then guess it's something else. I don't know why k3b won't pick up neither of my drives. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From denis at poolshark.org Fri Sep 28 11:07:52 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 28 Sep 2007 13:07:52 +0200 Subject: NO CD/DVD's detected In-Reply-To: <1190977414.3977.1.camel@scrappy.miketc.com> References: <1190946567.32697.3.camel@scrappy.miketc.com> <200709280810.12211.opensource@till.name> <1190977414.3977.1.camel@scrappy.miketc.com> Message-ID: <46FCE088.4060607@poolshark.org> Mike Chambers wrote: > On Fri, 2007-09-28 at 08:10 +0200, Till Maas wrote: >> On Fr September 28 2007, Mike Chambers wrote: >> >>> I can see the devices in the kernel messages. Would this have to do >>> with cdrecord or something about that, as I thought there were license >>> problems with that program and therefore is maybe screwing things up? >> Since Fedora 7, Fedora contains cdrkit instead of cdrecord, the application is >> now called wodim (cdrecord is a symlink to wodim) and does not have this >> license problems. > > Yes I can see that wodim is installed and the symlinks. But not sure if > this is related to my problem or not though. If it's been this way a > while, then guess it's something else. I don't know why k3b won't pick > up neither of my drives. What if you run as root ? Do you see a difference between "wodim --scanbus" and "sudo wodim --scanbus" ? From j.w.r.degoede at hhs.nl Fri Sep 28 10:53:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 28 Sep 2007 12:53:56 +0200 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCDE04.6040007@hi.is> References: <46FCDE04.6040007@hi.is> Message-ID: <46FCDD44.1050707@hhs.nl> J?hann B. Gu?mundsson wrote: > We gonna start an Rpmfusion Fedora spin giving user > the much wanted/needed media support in Fedora. > > With strictly the media support ( ugly-plugins etc. ) and the rpmfusion > repo installed, > and excluding AMD and Nvidia drivers > will we need Rename the spin or could it be released under Fedora name > and artwork? * Legal/others > > If needed to change the name/artwork would FedoriansFusion be A OK > If naming/artwork is changed could we include the AMD and Nvidia drivers? > > Will this be available on fedoraprojects.org as in > will Max Spevack put his money where is mouth is so I quote Max > "So go forth and mix your own Fedora. And then come back and share it > with us, and we?ll put it up on the _*Fedora website for others to use > also.*_" > ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) > Or was this just a pr c... > > It would be interesting download stats Fedora VS Fedora with media > support :) > > If everything is done outside US hosted outside US created outside US > how much legal > jibber jabber comes from that ? Not for US residents version of Fedora? > > Best regards > Johann B. > Everyone, please take not that Johann is not speaking on behave of the rpmfusion project. Regards, Hans From fedora at camperquake.de Fri Sep 28 11:15:16 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 28 Sep 2007 13:15:16 +0200 Subject: NO CD/DVD's detected In-Reply-To: <46FCE088.4060607@poolshark.org> References: <1190946567.32697.3.camel@scrappy.miketc.com> <200709280810.12211.opensource@till.name> <1190977414.3977.1.camel@scrappy.miketc.com> <46FCE088.4060607@poolshark.org> Message-ID: <20070928131516.412f4a3b@banea.int.addix.net> Hi. On Fri, 28 Sep 2007 13:07:52 +0200, Denis Leroy wrote: > What if you run as root ? Do you see a difference between "wodim > --scanbus" and "sudo wodim --scanbus" ? As far as I know (which may well be wrong) k3b does not use wodim to scan for drives, but uses internal code for that. The actual burning is another story. From mike at miketc.com Fri Sep 28 11:15:19 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 28 Sep 2007 06:15:19 -0500 Subject: NO CD/DVD's detected In-Reply-To: <46FCE088.4060607@poolshark.org> References: <1190946567.32697.3.camel@scrappy.miketc.com> <200709280810.12211.opensource@till.name> <1190977414.3977.1.camel@scrappy.miketc.com> <46FCE088.4060607@poolshark.org> Message-ID: <1190978119.3977.3.camel@scrappy.miketc.com> On Fri, 2007-09-28 at 13:07 +0200, Denis Leroy wrote: > What if you run as root ? Do you see a difference between "wodim > --scanbus" and "sudo wodim --scanbus" ? [mike at scrappy ~]$ sudo wodim --scanbus Password: scsibus1: 1,0,0 100) 'LITE-ON ' 'LTR-52327S ' 'QS58' Removable CD-ROM 1,1,0 101) 'LITE-ON ' 'DVDRW SHW-160P6S' 'PS09' Removable CD-ROM 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * [mike at scrappy ~]$ su - Password: [root at scrappy ~]# wodim --scanbus scsibus1: 1,0,0 100) 'LITE-ON ' 'LTR-52327S ' 'QS58' Removable CD-ROM 1,1,0 101) 'LITE-ON ' 'DVDRW SHW-160P6S' 'PS09' Removable CD-ROM 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From jkeating at redhat.com Fri Sep 28 11:23:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 07:23:19 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCDE04.6040007@hi.is> References: <46FCDE04.6040007@hi.is> Message-ID: <20070928072319.35e126c3@redhat.com> On Fri, 28 Sep 2007 10:57:08 +0000 ""J?hann B. Gu?mundsson"" wrote: > With strictly the media support ( ugly-plugins etc. ) and the > rpmfusion repo installed, > and excluding AMD and Nvidia drivers > will we need Rename the spin or could it be released under Fedora name > and artwork? * Legal/others No. You are including content that is not in Fedora, therefor you cannot use the Fedora trademark and cannot use the trademarked logos. You would have some renaming work ahead of you. > > If needed to change the name/artwork would FedoriansFusion be A OK > If naming/artwork is changed could we include the AMD and Nvidia > drivers? Once you change the name, you can do whatever the heck you want with it, under the laws and restrictions of the particular country where it's being produced. I would suggest consulting a lawyer as to what laws apply (in particular with offering encryption technology). > > Will this be available on fedoraprojects.org as in > will Max Spevack put his money where is mouth is so I quote Max > "So go forth and mix your own Fedora. And then come back and share it > with us, and we?ll put it up on the _*Fedora website for others to > use also.*_" > ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) > Or was this just a pr c... Remix implies that you take the package set and do something interesting with it, not just add a bunch of stuff from outside Fedora. Furthermore, regardless of location, Fedora isn't interested in patent encumbered software, as it's not free for /everybody/. It's entirely uninteresting to promote such a thing. > It would be interesting download stats Fedora VS Fedora with media > support :) Not really. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johannbg at hi.is Fri Sep 28 11:38:40 2007 From: johannbg at hi.is (=?windows-1252?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 28 Sep 2007 11:38:40 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCDD44.1050707@hhs.nl> References: <46FCDE04.6040007@hi.is> <46FCDD44.1050707@hhs.nl> Message-ID: <46FCE7C0.7030704@hi.is> Hans de Goede wrote: > J?hann B. Gu?mundsson wrote: >> We gonna start an Rpmfusion Fedora spin giving user >> the much wanted/needed media support in Fedora. >> >> With strictly the media support ( ugly-plugins etc. ) and the >> rpmfusion repo installed, >> and excluding AMD and Nvidia drivers >> will we need Rename the spin or could it be released under Fedora name >> and artwork? * Legal/others >> >> If needed to change the name/artwork would FedoriansFusion be A OK >> If naming/artwork is changed could we include the AMD and Nvidia >> drivers? >> >> Will this be available on fedoraprojects.org as in >> will Max Spevack put his money where is mouth is so I quote Max >> "So go forth and mix your own Fedora. And then come back and share it >> with us, and we?ll put it up on the _*Fedora website for others to >> use also.*_" >> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >> Or was this just a pr c... >> >> It would be interesting download stats Fedora VS Fedora with media >> support :) >> >> If everything is done outside US hosted outside US created outside US >> how much legal >> jibber jabber comes from that ? Not for US residents version of Fedora? >> >> Best regards >> Johann B. >> > > Everyone, please take not that Johann is not speaking on behave of the > rpmfusion project. > > Regards, > > Hans > > I'm not speaking of behalf of the RpmFusion project so I make that clear ! If some one has taking it as such then I apologies It was never my intent to do so. My mistake what I meant to say Subject: Fedora spin from RpmFusion packages. I'm stricktly talking about an Fedora spin that will include RPMFusion repo to address an serious ( atleast I look at it as such ) problem an prevents Fedora to come even more widespreaded and add an working media support for the noob user so noob user does have to do anything to get an working media support. other then install and things work for him Best regards Johann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From katzj at redhat.com Fri Sep 28 11:43:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 07:43:56 -0400 Subject: Category: Uncategorized in comps In-Reply-To: <20070928002859.2454ba27@redhat.com> References: <46FC203D.9050003@redhat.com> <20070928002859.2454ba27@redhat.com> Message-ID: <1190979836.8193.2.camel@localhost.localdomain> On Fri, 2007-09-28 at 00:28 -0400, Jesse Keating wrote: > On Thu, 27 Sep 2007 17:27:25 -0400 > Warren Togami wrote: > > ... shows up in Anaconda and Pirut. Is this an intentional name? > > No, we just never got around to finding a good Category to stuff it > in. The group itself is visible but not in any category. You pick one > and make it happen. Jens actually committed something adding it to a group last night per the bug he had filed. So this should be fixed today. Jeremy From abo at kth.se Fri Sep 28 12:09:00 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 14:09:00 +0200 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <1190965360.5022.127.camel@home.alexander.bostrom.net> Message-ID: <1190981340.5022.135.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 12:41 +0200 skrev Benny Amorsen: > There's no reason to have the spurious lib there. The reasoning behind /srv/lib is that it's relatively unlikely to already be in use and it is similar in purpose and look to /usr/lib and /var/lib. Remember, you're adding structure to a directory that has previously been marked as open territory. Thread lightly. /abo From johannbg at hi.is Fri Sep 28 12:20:09 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 12:20:09 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928072319.35e126c3@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> Message-ID: <46FCF179.3070300@hi.is> Jesse Keating wrote: > On Fri, 28 Sep 2007 10:57:08 +0000 > ""J?hann B. Gu?mundsson"" wrote: > > >> With strictly the media support ( ugly-plugins etc. ) and the >> rpmfusion repo installed, >> and excluding AMD and Nvidia drivers >> will we need Rename the spin or could it be released under Fedora name >> and artwork? * Legal/others >> > > No. You are including content that is not in Fedora, therefor you > cannot use the Fedora trademark and cannot use the trademarked logos. > You would have some renaming work ahead of you. > > I guessed so.. and replacing the artwork as well right? >> If needed to change the name/artwork would FedoriansFusion be A OK >> If naming/artwork is changed could we include the AMD and Nvidia >> drivers? >> > > Once you change the name, you can do whatever the heck you want with > it, under the laws and restrictions of the particular country where > it's being produced. I would suggest consulting a lawyer as to what > laws apply (in particular with offering encryption technology). > Encryption added to the checklist.. But would I still be allowed to update and use Fedora repos right? As in how deep would I need to go in renaming things? Removing every image containing the Fedora logo and every instance of the word Fedora. Repackage? > >> Will this be available on fedoraprojects.org as in >> will Max Spevack put his money where is mouth is so I quote Max >> "So go forth and mix your own Fedora. And then come back and share it >> with us, and we?ll put it up on the _*Fedora website for others to >> use also.*_" >> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >> Or was this just a pr c... >> > > Remix implies that you take the package set and do something > interesting with it, not just add a bunch of stuff from outside > Fedora. Furthermore, regardless of location, Fedora isn't interested > in patent encumbered software, as it's not free for /everybody/. It's > entirely uninteresting to promote such a thing. > Mean what are the exact issue with for example libdvdcss ? licenced GPL In other words for me do get my spin hosted on fedora project I can only play with fedora packages in fedora repo and how *my* setup is aka spin correct? As in my spins do not include Emacs because Emacs sucks as an editor compared to Vi.. No offense Emacs users this was just an example... >> It would be interesting download stats Fedora VS Fedora with media >> support :) >> > > Not really. > For me it it would. Would it increase the usage of Fedora? Also would like to see what would be the next issue if the media problem would go away from user perspective. ( As in the user didn't have to bother to take some extra steps him self work out of the box kinda thing. ) Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From abo at kth.se Fri Sep 28 12:24:42 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 14:24:42 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> Message-ID: <1190982282.5022.156.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 11:41 +0200 skrev Nicolas Mailhot: > Because /var/ mixes long-term and transient data, generic and > implementation-specific stuff, local and global data, and makes backup > stategies a PITA for everything but SOHO contexts. Yeah, but to be useful you need to really make sure there's _nothing_ in /var that needs to be backed up. I'm not sure that's going to very easy. A bigger problem is the databases that you can't just back up like files. You need to ask the application for a consistent dump and pull that into the backup. Making sure all apps shipped with Fedora can be backed up by just copying a bunch of files would be a huge plus. This can achieved in a few different ways. They can dump their contents to consistent snapshot regularly or on demand. Or they can use several files for the database (base + copy-on-write). In some cases maybe filsystem snapshots are the best way to do it. Whatever is appropriate for the application, just so everyone doesn't have to roll their own. /abo From jwboyer at jdub.homelinux.org Fri Sep 28 12:25:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 28 Sep 2007 07:25:51 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCF179.3070300@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FCF179.3070300@hi.is> Message-ID: <20070928072551.464e949d@weaponx.rchland.ibm.com> On Fri, 28 Sep 2007 12:20:09 +0000 "J?hann B. Gu?mundsson" wrote: > Jesse Keating wrote: > > On Fri, 28 Sep 2007 10:57:08 +0000 > > ""J?hann B. Gu?mundsson"" wrote: > > > > > >> With strictly the media support ( ugly-plugins etc. ) and the > >> rpmfusion repo installed, > >> and excluding AMD and Nvidia drivers > >> will we need Rename the spin or could it be released under Fedora name > >> and artwork? * Legal/others > >> > > > > No. You are including content that is not in Fedora, therefor you > > cannot use the Fedora trademark and cannot use the trademarked logos. > > You would have some renaming work ahead of you. > > > > > I guessed so.. and replacing the artwork as well right? Yes. > But would I still be allowed to update and use Fedora repos right? You could have the spin pull from the Fedora repos for things, yes. > As in how deep would I need to go in renaming things? > Removing every image containing the Fedora logo and every instance of > the word Fedora. > Repackage? I'm not sure but it wouldn't be trivial. > >> Will this be available on fedoraprojects.org as in > >> will Max Spevack put his money where is mouth is so I quote Max > >> "So go forth and mix your own Fedora. And then come back and share it > >> with us, and we?ll put it up on the _*Fedora website for others to > >> use also.*_" > >> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) > >> Or was this just a pr c... > >> > > > > Remix implies that you take the package set and do something > > interesting with it, not just add a bunch of stuff from outside > > Fedora. Furthermore, regardless of location, Fedora isn't interested > > in patent encumbered software, as it's not free for /everybody/. It's > > entirely uninteresting to promote such a thing. > > > > Mean what are the exact issue with for example libdvdcss ? licenced GPL Doesn't matter what the license is if the techniques are patented. > > In other words for me do get my spin hosted on fedora project I can only > play > with fedora packages in fedora repo and how *my* setup is aka spin correct? > > As in my spins do not include Emacs because Emacs sucks as an editor > compared to Vi.. > > No offense Emacs users this was just an example... Right. To make it simple, you can't include any packages outside of the Fedora repos if you want to call it Fedora. > >> It would be interesting download stats Fedora VS Fedora with media > >> support :) > >> > > > > Not really. > > > For me it it would. > > Would it increase the usage of Fedora? No. It has the potential to increase the usage of whatever you call it, which won't be Fedora. > Also would like to see what would be the next issue if the media problem > would > go away from user perspective. > > ( As in the user didn't have to bother to take some extra steps him self > work out of the box kinda thing. ) That would be interesting, sure. But it's not really applicable to Fedora since the "media problem" isn't something Fedora can simply solve. josh From Matt_Domsch at dell.com Fri Sep 28 12:41:25 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Sep 2007 07:41:25 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928072551.464e949d@weaponx.rchland.ibm.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FCF179.3070300@hi.is> <20070928072551.464e949d@weaponx.rchland.ibm.com> Message-ID: <20070928124125.GA15163@auslistsprd01.us.dell.com> On Fri, Sep 28, 2007 at 07:25:51AM -0500, Josh Boyer wrote: > On Fri, 28 Sep 2007 12:20:09 +0000 > "J??hann B. Gu??mundsson" wrote: > > > Jesse Keating wrote: > > > On Fri, 28 Sep 2007 10:57:08 +0000 > > > ""J??hann B. Gu??mundsson"" wrote: > > > > > > > > >> With strictly the media support ( ugly-plugins etc. ) and the > > >> rpmfusion repo installed, > > >> and excluding AMD and Nvidia drivers > > >> will we need Rename the spin or could it be released under Fedora name > > >> and artwork? * Legal/others > > >> > > > > > > No. You are including content that is not in Fedora, therefor you > > > cannot use the Fedora trademark and cannot use the trademarked logos. > > > You would have some renaming work ahead of you. > > > > > > > > I guessed so.. and replacing the artwork as well right? > > Yes. With the exception of the trademarked logos, the rest of the artwork is licensed to be reused, so it need not all be replaced. > > > But would I still be allowed to update and use Fedora repos right? > > You could have the spin pull from the Fedora repos for things, yes. > > > As in how deep would I need to go in renaming things? > > Removing every image containing the Fedora logo and every instance of > > the word Fedora. > > Repackage? > > I'm not sure but it wouldn't be trivial. There's work underway to make the fedora-logos package replaceable exactly so this task becomes trivial. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dwalsh at redhat.com Fri Sep 28 12:53:46 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Sep 2007 08:53:46 -0400 Subject: Is there documentation on how to package foreign language man page translations in a spec file. Message-ID: <46FCF95A.7080005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have some Russian translations of manpages for one of the libraries I support, but I am not sure how to package them. Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG/PlarlYvE4MpobMRAi83AKCWRl9LF9vDH0QFqu93UQZ1hPLEsgCg3ue/ fsypr7iTTIuis+BIEUENhE8= =d0Ln -----END PGP SIGNATURE----- From abo at kth.se Fri Sep 28 12:55:14 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 14:55:14 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <29186.192.54.193.51.1190971848.squirrel@rousalka.dyndns.org> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <29186.192.54.193.51.1190971848.squirrel@rousalka.dyndns.org> Message-ID: <1190984114.5022.184.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 11:30 +0200 skrev Nicolas Mailhot: > And this is broken by design. You're mirroring /var organisation when > people have repeatedly told you this organisation was not adapted to > their needs. Swapping /var and /srv does not make it magically sane. No, they have not. The fact that /var is something you need to go through directory by directory to see what you need to backup and what you can lose is not an argument against /srv/lib. Is that what you mean? > Also you contradict yourself by insisting both on packagename > namespacing and taking a packagename-agnostic layout like /var/www as > example. No, I was suggesting bringing that dir into the fold with the others in /srv/lib if you move it to somewhere in /srv. Whether /srv/lib/www should be a shared dir for web-related packages or there should be one dir per package is a different question which I haven't really intended to comment on or even considered. > What's the point of lib in srv ? As I mentioned, it's to play nicely in /srv. > What's the point of forcing packagename in the namespace ? Symmetry. Unless there's a good argument against, symmetry is useful. Basically, if you're hoping to amend the FHS, you should concentrate on one or two subdirs in /srv and try to reserve those. That would be /srv/lib with /srv/lib/ when that is appropriate. You could also argue that sometimes package names are not relevant. Then you need to define a different structure and for that structure find another subdir name in /srv that is not likely to already be in widespread use. > Sure some stuff is package (and often package-version) specific, like > database files. But a lot of it is completely package-agnostic. You > should not force a stonger coupling than is technically required just > because it makes packager life easier. It's not about forcing, it's about finding something that can be agreed upon so that you can add it to the FHS. Everyone is free to use /srv as they like, which is what amending the FHS (or changing stuff in Fedora without going through FHS) is going to conflict with. /abo From nicu_fedora at nicubunu.ro Fri Sep 28 12:59:53 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 28 Sep 2007 15:59:53 +0300 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928124125.GA15163@auslistsprd01.us.dell.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FCF179.3070300@hi.is> <20070928072551.464e949d@weaponx.rchland.ibm.com> <20070928124125.GA15163@auslistsprd01.us.dell.com> Message-ID: <46FCFAC9.6030005@nicubunu.ro> Matt Domsch wrote: > On Fri, Sep 28, 2007 at 07:25:51AM -0500, Josh Boyer wrote: >> On Fri, 28 Sep 2007 12:20:09 +0000 >> "J??hann B. Gu??mundsson" wrote: >>> I guessed so.. and replacing the artwork as well right? >> Yes. > > With the exception of the trademarked logos, the rest of the artwork > is licensed to be reused, so it need not all be replaced. Indeed, and for the graphics containing logos, you can ask on the fedora-art-list for unbranded versions (graphics in F8 are already less branded compared with previous releases). Check also http://fedoraproject.org/wiki/Releases/FeatureGenericLogos -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From sundaram at fedoraproject.org Fri Sep 28 13:01:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 28 Sep 2007 18:31:04 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCF179.3070300@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FCF179.3070300@hi.is> Message-ID: <46FCFB10.8090104@fedoraproject.org> J?hann B. Gu?mundsson wrote: >> No. You are including content that is not in Fedora, therefor you >> cannot use the Fedora trademark and cannot use the trademarked logos. >> You would have some renaming work ahead of you. >> >> > I guessed so.. and replacing the artwork as well right? The branded images but a lot of work has gone into consolidating the branding and we already have generic-logos package in rawhide now which is created explicitly so that derivatives can do rebranding easily. Rahul From myfedora at richip.dhs.org Fri Sep 28 13:13:05 2007 From: myfedora at richip.dhs.org (Richi Plana) Date: Fri, 28 Sep 2007 07:13:05 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <1190981340.5022.135.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <1190965360.5022.127.camel@home.alexander.bostrom.net> <1190981340.5022.135.camel@home.alexander.bostrom.net> Message-ID: <1190985185.31942.6.camel@localhost6.localdomain6> On Fri, 2007-09-28 at 14:09 +0200, Alexander Bostr?m wrote: > fre 2007-09-28 klockan 12:41 +0200 skrev Benny Amorsen: > > > There's no reason to have the spurious lib there. > > The reasoning behind /srv/lib is that it's relatively unlikely to > already be in use and it is similar in purpose and look to /usr/lib > and /var/lib. Remember, you're adding structure to a directory that has > previously been marked as open territory. Thread lightly. "lib" does not make any sense. It didn't for /var/lib/(www| mysql|) and it certainly doesn't for /srv. If collision avoidance is what you're interested in, name it /srv/fedora[(-services)]/ or something. Personally, I'm fine with anything. The sanity that administering and maintaining systems that moving data to /srv brings is enough to satisfy me. As for ensuring that all the data that needs long-term storage be moved from /var: I don't see how that could be hard, but it will be a long, drawn-out process. Definitely worth the effort, though. -- Richi Plana From khc at pm.waw.pl Fri Sep 28 13:24:39 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Fri, 28 Sep 2007 15:24:39 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 28 Sep 2007 11:41:18 +0200 (CEST)") References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> Message-ID: "Nicolas Mailhot" writes: > Because /var/ mixes long-term and transient data, generic and > implementation-specific stuff, local and global data, and makes backup > stategies a PITA for everything but SOHO contexts. Non-SOHO, you back up everything you have on disk and you don't think about every file and directory. You have to be able to restore the system reliably and fast. You may consider excluding things like /tmp and /var/cache but any re-installations or rebuilding of RPMS databases etc. are not options. > Good backup is expensive backup so bulk-var-backup is not scaling > In case of general system failure, or major release update, you're > better of without a lot of /var contents, because some stuff is easier > to set up again than take the risk of restoring a rotten state Excuse me? Restoring from a good backup is the only option, if your last backup is rotten then you take the previous one. WRT /srv I personally rmdir /opt /*/opt /srv /media after a system upgrade because I don't usually use them. Should a need arise, mkdir and friends aren't that hard to type. I think there are no more real problems in Fedora as people start fixing "non-problems" instead. /var has been working fine for years and I don't see any reason to break it now. -- Krzysztof Halasa From billcrawford1970 at gmail.com Fri Sep 28 13:27:57 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 28 Sep 2007 14:27:57 +0100 Subject: /etc/hosts and system entries In-Reply-To: <1190912434.30715.1.camel@localhost.localdomain> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> Message-ID: <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com> On 27/09/2007, Adam Jackson wrote: > Why is this not a bug in kerberos? If the application knows that the IP > address it wants for the name needs to be globally routable, then the > application should be responsible for walking the list of IPs for that > name to find the routable ones. Another point being missed, is that if the hostname gets changed the moment an external IP interface is brought up, X becomes unusable because suddenly the magic cookie isn't found (the server and .Xauthority think it's "localhost" and the client thinks it's "some-dynamic-ip-xx-yy-zz.imaginative-dsl-provider.com"). So adding it to /etc/hosts as 127.0.0.1 (or, as I do, 127.0.0.x where x > 1) helps a lot(!) From johannbg at hi.is Fri Sep 28 13:34:32 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 13:34:32 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928072319.35e126c3@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> Message-ID: <46FD02E8.7040200@hi.is> Jesse Keating wrote: > On Fri, 28 Sep 2007 10:57:08 +0000 > ""J?hann B. Gu?mundsson"" wrote: > > >> Will this be available on fedoraprojects.org as in >> will Max Spevack put his money where is mouth is so I quote Max >> "So go forth and mix your own Fedora. And then come back and share it >> with us, and we?ll put it up on the _*Fedora website for others to >> use also.*_" >> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >> Or was this just a pr c... >> > > Remix implies that you take the package set and do something > interesting with it, not just add a bunch of stuff from outside > Fedora. Furthermore, regardless of location, Fedora isn't interested > in patent encumbered software, as it's not free for /everybody/. It's > entirely uninteresting to promote such a thing. > > The Fedora-unity re-spins could be posted on fedoraprojects.org along with the official img right? They just contain updates and nothing outside the fedora repo tree. ( And their FC6 respin release didn't contain the whole FC6 I586 issue that slipped through QA ) And I think that Max Spevack ( or any Red Hat/Fedora offical ) should contact them and offer them to post their images along with the official ones. That alone would be progress in the right direction ( and save users bandwith and long update time ) Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From abo at kth.se Fri Sep 28 13:36:18 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 15:36:18 +0200 Subject: /etc/hosts and system entries In-Reply-To: <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com> Message-ID: <1190986578.5022.189.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 14:27 +0100 skrev Bill Crawford: > Another point being missed, is that if the hostname gets changed the > moment an external IP interface is brought up, X becomes unusable > because suddenly the magic cookie isn't found (the server and > .Xauthority think it's "localhost" and the client thinks it's > "some-dynamic-ip-xx-yy-zz.imaginative-dsl-provider.com"). > > So adding it to /etc/hosts as 127.0.0.1 (or, as I do, 127.0.0.x where > x > 1) helps a lot(!) Nah, that's X or X usage that's broken then. DISPLAY should be ":X", nothing else. I mean, nowadays -nolisten tcp is the default anyway. /abo From abo at kth.se Fri Sep 28 13:43:42 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 15:43:42 +0200 Subject: /etc/hosts and system entries In-Reply-To: <1190912434.30715.1.camel@localhost.localdomain> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> Message-ID: <1190987022.5022.199.camel@home.alexander.bostrom.net> tor 2007-09-27 klockan 13:00 -0400 skrev Adam Jackson: > Why is this not a bug in kerberos? If the application knows that the > IP > address it wants for the name needs to be globally routable, then the > application should be responsible for walking the list of IPs for that > name to find the routable ones. While I do believe Kerberos protocols, libs or apps should be smarter about these things sometimes and I'm not sure what really happens here (though I've seen this happen a few times) I really do think Kerberos is in its right to complain when it's fed lies. If you put the hostname on the 127.0.0.1 line, doesn't that override everything DNS says? I always remove that entry from /etc/hosts after installation. /abo From ivazqueznet at gmail.com Fri Sep 28 13:44:32 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 28 Sep 2007 09:44:32 -0400 Subject: Is there documentation on how to package foreign language man page translations in a spec file. In-Reply-To: <46FCF95A.7080005@redhat.com> References: <46FCF95A.7080005@redhat.com> Message-ID: <1190987072.3259.73.camel@ignacio.lan> On Fri, 2007-09-28 at 08:53 -0400, Daniel J Walsh wrote: > I have some Russian translations of manpages for one of the libraries I > support, but I am not sure how to package them. The man and man-pages packages have examples of multilingual man page support. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Sep 28 09:47:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 05:47:58 -0400 Subject: /etc/hosts and system entries In-Reply-To: <1190987022.5022.199.camel@home.alexander.bostrom.net> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> Message-ID: <20070928054758.0abfde54@redhat.com> On Fri, 28 Sep 2007 15:43:42 +0200 "Alexander Bostr?m" wrote: > While I do believe Kerberos protocols, libs or apps should be smarter > about these things sometimes and I'm not sure what really happens here > (though I've seen this happen a few times) I really do think Kerberos > is in its right to complain when it's fed lies. If you put the > hostname on the 127.0.0.1 line, doesn't that override everything DNS > says? Almost every single location I take my laptop there is no dns entry for my hostname. Relying upon every hostname to be DNS resolvable is extremely dated thinking. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Sep 28 12:46:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 28 Sep 2007 08:46:37 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCF179.3070300@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FCF179.3070300@hi.is> Message-ID: <20070928124637.GA17375@nostromo.devel.redhat.com> "J?hann B. Gu?mundsson" (johannbg at hi.is) said: > I guessed so.. and replacing the artwork as well right? You may find the recently added generic-logos package useful. > In other words for me do get my spin hosted on fedora project I can only > play > with fedora packages in fedora repo and how *my* setup is aka spin correct? Correct - we can't host things that contain packages or content we can't ship. Bill From billcrawford1970 at gmail.com Fri Sep 28 13:56:22 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 28 Sep 2007 14:56:22 +0100 Subject: /etc/hosts and system entries In-Reply-To: <1190986578.5022.189.camel@home.alexander.bostrom.net> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com> <1190986578.5022.189.camel@home.alexander.bostrom.net> Message-ID: <544eb990709280656k42a7c8b1gcd159b49e1ad9348@mail.gmail.com> On 28/09/2007, Alexander Bostr?m wrote: > Nah, that's X or X usage that's broken then. DISPLAY should be ":X", > nothing else. I mean, nowadays -nolisten tcp is the default anyway. Running X from console login for a variety of reasons (e.g. can't run gui config tools in a xterm opened using sudo -i, when I log in from kdm). Changing the hostname can still crash the desktop. It may be a bug or design fault in X, KDE or something else, but it still happens :) However I don't know how plugging dsl in works with the latest F8 release because I have no internet connection at home and I'm not risking my work desktop on f8t[n] because if I can't work, I can't work ... From abo at kth.se Fri Sep 28 14:06:49 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 16:06:49 +0200 Subject: /etc/hosts and system entries In-Reply-To: <20070928054758.0abfde54@redhat.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> Message-ID: <1190988409.5022.215.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 05:47 -0400 skrev Jesse Keating: > Almost every single location I take my laptop there is no dns entry for > my hostname. Relying upon every hostname to be DNS resolvable is > extremely dated thinking. If you want to run a Kerberos service, say a telnetd or an sshd, on your laptop, then the laptop needs to agree with the rest of the world about some subset of DNS. A Kerberos service has a key stored on disk which is tied to its hostname, that's why the hostname is important. A typical client has a key tied to the username, so then DNS values for that client is less critical. Btw, PTR for your IP shouldn't really matter here, but it might, for some odd reason. Having your name point by A/AAAA to your current IP is useful though, if you want to be able to run a system service that accepts and authenticates incoming connections. That's why it's important for Windows AD laptop owners to be able to report their IP back to their home DC, so that they can be found and contacted by some central control thingy in the DC. I think. (That's also why the DC DNS will be cluttered with lots of 192.168.x.x A records...) But until someone explains what the problem really is, we shouldn't draw any conclusions. /abo From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Sep 28 14:07:53 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 28 Sep 2007 16:07:53 +0200 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCDE04.6040007@hi.is> References: <46FCDE04.6040007@hi.is> Message-ID: <20070928160753.5cac5abc@python3.es.egwn.lan> J?hann B. Gu?mundsson wrote : > We gonna start an Rpmfusion Fedora spin giving user > the much wanted/needed media support in Fedora. My take on this (initially posted to the rpmfusion list) : "We should not. I think it's just not worth it, especially since it would have to be called something completely different, and include non trademarked artwork. What we need to do is get the feature to use add-on media at installation time working again in Fedora. I had made a proof of concept CD with freshrpms packages which could be used with a Fedora installation a while back, but this has been "broken" ever since anaconda switched to using yum as a backend (AFAIR). Work will be better spent on fixing Fedora, that way we can just provide an add-on CD which could be used at install time and provide extra categories to pick from in order to install codecs, programs, and of course enable rpmfusion in yum. FWIW, here is my "announcement" of the CD (it was for FC4) : http://lists.freshrpms.net/pipermail/freshrpms-list/2006-January/013758.html ...notice the absolute zero feedback, though :-(" Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7 Load : 0.28 0.36 0.40 From abo at kth.se Fri Sep 28 14:11:17 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Fri, 28 Sep 2007 16:11:17 +0200 Subject: /etc/hosts and system entries In-Reply-To: <544eb990709280656k42a7c8b1gcd159b49e1ad9348@mail.gmail.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com> <1190986578.5022.189.camel@home.alexander.bostrom.net> <544eb990709280656k42a7c8b1gcd159b49e1ad9348@mail.gmail.com> Message-ID: <1190988677.5022.220.camel@home.alexander.bostrom.net> fre 2007-09-28 klockan 14:56 +0100 skrev Bill Crawford: > However I don't know how plugging dsl in works with the latest F8 > release because I have no internet connection at home and I'm not > risking my work desktop on f8t[n] because if I can't work, I can't > work ... My laptop changes IP often. I keep the hostname fixed though. I really couldn't care less about the PTR record of the WaveLAN I'm currently on. And, ugh, I just discovered it has a /etc/hosts with this and only this: ::1 hostname.domain hostname localhost.localdomain localhost I gotta change that and see what happens. And why isn't that localhost6? I thought that was the default... Now I'm confused. /abo From sundaram at fedoraproject.org Fri Sep 28 14:07:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 28 Sep 2007 19:37:50 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928160753.5cac5abc@python3.es.egwn.lan> References: <46FCDE04.6040007@hi.is> <20070928160753.5cac5abc@python3.es.egwn.lan> Message-ID: <46FD0AB6.6000009@fedoraproject.org> Matthias Saou wrote: > > What we need to do is get the feature to use add-on media at > installation time working again in Fedora. I had made a proof of > concept CD with freshrpms packages which could be used with a Fedora > installation a while back, but this has been "broken" ever since > anaconda switched to using yum as a backend (AFAIR). > > Work will be better spent on fixing Fedora, that way we can just > provide an add-on CD which could be used at install time and provide > extra categories to pick from in order to install codecs, programs, and > of course enable rpmfusion in yum. Completely agree on this front. A custom spin with different branding and name can be useful for other purposes. Somebody needs to serve as a test case for that. > FWIW, here is my "announcement" of the CD (it was for FC4) : > http://lists.freshrpms.net/pipermail/freshrpms-list/2006-January/013758.html > ...notice the absolute zero feedback, though :-(" fedora-list might have yielded more feedback. RPMFusion folks might want to try something similar and try it integrate it as well as you can with the releases from Fedora. Rahul From k.georgiou at imperial.ac.uk Fri Sep 28 14:25:29 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 28 Sep 2007 15:25:29 +0100 Subject: /etc/hosts and system entries In-Reply-To: <20070928054758.0abfde54@redhat.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> Message-ID: <20070928142529.GA23716@imperial.ac.uk> On Fri, Sep 28, 2007 at 05:47:58AM -0400, Jesse Keating wrote: > On Fri, 28 Sep 2007 15:43:42 +0200 > "Alexander Bostr?m" wrote: > > > While I do believe Kerberos protocols, libs or apps should be smarter > > about these things sometimes and I'm not sure what really happens here > > (though I've seen this happen a few times) I really do think Kerberos > > is in its right to complain when it's fed lies. If you put the > > hostname on the 127.0.0.1 line, doesn't that override everything DNS > > says? > > Almost every single location I take my laptop there is no dns entry for > my hostname. Relying upon every hostname to be DNS resolvable is > extremely dated thinking. You don't run any kerberos services at setups like this though (clients still work of course), not that different to ssl actually. In any case more or less everything in my systems uses kerberos and I haven't noticed any problems with the hostname on the 127.0.0.1 line that I can remember. Kostas Georgiou From selinux at gmail.com Fri Sep 28 14:28:43 2007 From: selinux at gmail.com (Tom London) Date: Fri, 28 Sep 2007 07:28:43 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070928085550.2b74c397@banea.int.addix.net> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> Message-ID: <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> On 9/27/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 28 Sep 2007 00:28:06 -0400, Dan Williams wrote: > > > > That NM only accepts hex keys is going to be a big problem for me, > > > too, as my WPA2 AP only even lets me set a passphrase. > > > > /usr/sbin/wpa_passphrase > > That's nice, but no solutionn. > I can verify that with latest NM and 'wpa_passphrase' I can connect once to my WPA AP. On second attempt, I get: Sep 28 07:13:41 localhost NetworkManager: (wlan0) Supplicant interface state change: 0 -> 2 Sep 28 07:13:41 localhost kernel: iwl3945: Microcode SW error detected. Restarting 0x82000008. Sep 28 07:13:41 localhost kernel: iwl3945: Error Reply type 0x00000000 cmd REPLY_SCAN_CMD (0x80) seq 0x44A7 ser 0x00000000 Sep 28 07:13:42 localhost kernel: iwl3945: Can't stop Rx DMA. Sep 28 07:13:43 localhost NetworkManager: (wlan0) Supplicant interface state change: 2 -> 0 Sep 28 07:13:43 localhost NetworkManager: (wlan0) Supplicant interface state change: 0 -> 2 Sep 28 07:13:51 localhost ntpd[3533]: sendto(193.224.70.42) (fd=21): Invalid argument Sep 28 07:14:03 localhost ntpd[3533]: sendto(194.88.2.88) (fd=21): Invalid argument Sep 28 07:14:06 localhost NetworkManager: Activation (wlan0/wireless): association took too long, asking for new key. Sep 28 07:14:06 localhost NetworkManager: (wlan0) Supplicant interface state change: 2 -> 0 Progress! This issue known? tom -- Tom London From johannbg at hi.is Fri Sep 28 14:29:04 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 14:29:04 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928160753.5cac5abc@python3.es.egwn.lan> References: <46FCDE04.6040007@hi.is> <20070928160753.5cac5abc@python3.es.egwn.lan> Message-ID: <46FD0FB0.7050806@hi.is> Matthias Saou wrote: > J?hann B. Gu?mundsson wrote : > > >> We gonna start an Rpmfusion Fedora spin giving user >> the much wanted/needed media support in Fedora. >> > > My take on this (initially posted to the rpmfusion list) : > > "We should not. I think it's just not worth it, especially since it > would have to be called something completely different, and include non > trademarked artwork. > > What we need to do is get the feature to use add-on media at > installation time working again in Fedora. I had made a proof of > concept CD with freshrpms packages which could be used with a Fedora > installation a while back, but this has been "broken" ever since > anaconda switched to using yum as a backend (AFAIR). > > Work will be better spent on fixing Fedora, that way we can just > provide an add-on CD which could be used at install time and provide > extra categories to pick from in order to install codecs, programs, and > of course enable rpmfusion in yum. > > You still need to create the cd. You still need to provide the cd which my guess is cant be done on fedoraproject.org That would be the ideal solution that if you have internet connection you could getting it from there or just choose it in Anaconda ( User provided with some disclaimer accepts it, his responsibility viola ), Guess legal has problem with that other wise I guess it would have been implemented already.. Regarding adding more cd's or *additional cd's* I think is step backwards. ( Any one remembering happy multi floppy diskette time debian/slackware what was it around 10 -15 diskettes But then again I could be the only one who expirienced Bad Sectors through out the years. ) Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From jkeating at redhat.com Fri Sep 28 10:34:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 06:34:28 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> Message-ID: <20070928063428.1a6cb2fe@redhat.com> On Fri, 28 Sep 2007 07:28:43 -0700 "Tom London" wrote: > Progress! > > This issue known? The second connection attempt issue looks more like kernel iwl3945 issues. Today's rawhide kernel may improve things. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Sep 28 14:37:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 09:37:43 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD02E8.7040200@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> Message-ID: <46FD11B7.3030200@redhat.com> J?hann B. Gu?mundsson wrote: > Jesse Keating wrote: >> On Fri, 28 Sep 2007 10:57:08 +0000 >> ""J?hann B. Gu?mundsson"" wrote: >> >> >>> Will this be available on fedoraprojects.org as in >>> will Max Spevack put his money where is mouth is so I quote Max >>> "So go forth and mix your own Fedora. And then come back and share >>> it with us, and we?ll put it up on the _*Fedora website for others to >>> use also.*_" >>> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >>> Or was this just a pr c... >>> >> >> Remix implies that you take the package set and do something >> interesting with it, not just add a bunch of stuff from outside >> Fedora. Furthermore, regardless of location, Fedora isn't interested >> in patent encumbered software, as it's not free for /everybody/. It's >> entirely uninteresting to promote such a thing. >> >> > The Fedora-unity re-spins could be posted on fedoraprojects.org > along with the official img right? Here's the current process. We're still working out the process but nothing has been approved yet (we just got this page up there yesterday afternoon) http://fedoraproject.org/wiki/Infrastructure/CustomSpins -Mike From johannbg at hi.is Fri Sep 28 14:44:44 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 14:44:44 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD0AB6.6000009@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928160753.5cac5abc@python3.es.egwn.lan> <46FD0AB6.6000009@fedoraproject.org> Message-ID: <46FD135C.8020809@hi.is> Rahul Sundaram wrote: > Matthias Saou wrote: > >> >> What we need to do is get the feature to use add-on media at >> installation time working again in Fedora. I had made a proof of >> concept CD with freshrpms packages which could be used with a Fedora >> installation a while back, but this has been "broken" ever since >> anaconda switched to using yum as a backend (AFAIR). >> >> Work will be better spent on fixing Fedora, that way we can just >> provide an add-on CD which could be used at install time and provide >> extra categories to pick from in order to install codecs, programs, and >> of course enable rpmfusion in yum. > > Completely agree on this front. A custom spin with different branding > and name can be useful for other purposes. Somebody needs to serve as > a test case for that. > How will it work with crediting the right peoples in such a spin and so on. mean this is not yet another linux distro it is Fedora with extra packages same thing diffrent themes logo name? Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mmcgrath at redhat.com Fri Sep 28 14:43:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 09:43:43 -0500 Subject: Compose tools common use of kickstart configs (Was Re: Fedora Games Spin) In-Reply-To: <1190990044.11341.19.camel@localhost.localdomain> References: <46FBCEE1.6000401@fedoraproject.org> <1190908771.17693.23.camel@localhost.localdomain> <46FBD768.90004@redhat.com> <1190911238.17693.39.camel@localhost.localdomain> <46FBE68B.5090305@redhat.com> <1190913897.17693.52.camel@localhost.localdomain> <46FBEB6F.9050109@fedoraproject.org> <46FBEEF3.2010002@redhat.com> <46FBF1F5.5060207@fedoraproject.org> <1190919588.17693.55.camel@localhost.localdomain> <46FBFE27.4010309@redhat.com> <1190920467.29395.6.camel@cutter> <46FCB15E.5090905@kanarip.com> <1190985600.11341.8.camel@localhost.localdomain> <46FD09E8.2060700@fedoraproject.org> <1190990044.11341.19.camel@localhost.localdomain> Message-ID: <46FD131F.8010702@redhat.com> Jeremy Katz wrote: > On Fri, 2007-09-28 at 19:34 +0530, Rahul Sundaram wrote: > >> If both live cd tools and pungi can take kickstart files as input then >> has any thought been given on the possibility of merging them. At this >> point they look too similar to be separate tools to me and maybe you can >> share more code that way too. >> > > The guts of what they do are really quite different. In a lot of ways, > livecd-creator is really more similar to anaconda than to pungi. > > But the fact that all three (pungi, livecd-creator and anaconda) use > kickstart configs is very very intentional. The idea is that there is > one common config that can be used to describe an image regardless of > whether you deploy it by having a traditional tree + installing from it, > a live image, etc. But that discussion is getting a bit off-topic for > here. Reply-to: set accordingly > This seems reasonable. So issues that come up from one to the other would be a bug with the tools and not so much with the spin if I understand the process correctly? -Mike From johannbg at hi.is Fri Sep 28 14:56:59 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 14:56:59 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD11B7.3030200@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> Message-ID: <46FD163B.9050400@hi.is> Mike McGrath wrote: > J?hann B. Gu?mundsson wrote: >> Jesse Keating wrote: >>> On Fri, 28 Sep 2007 10:57:08 +0000 >>> ""J?hann B. Gu?mundsson"" wrote: >>> >>> >>>> Will this be available on fedoraprojects.org as in >>>> will Max Spevack put his money where is mouth is so I quote Max >>>> "So go forth and mix your own Fedora. And then come back and share >>>> it with us, and we?ll put it up on the _*Fedora website for others to >>>> use also.*_" >>>> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >>>> Or was this just a pr c... >>>> >>> >>> Remix implies that you take the package set and do something >>> interesting with it, not just add a bunch of stuff from outside >>> Fedora. Furthermore, regardless of location, Fedora isn't interested >>> in patent encumbered software, as it's not free for /everybody/. It's >>> entirely uninteresting to promote such a thing. >>> >>> >> The Fedora-unity re-spins could be posted on fedoraprojects.org >> along with the official img right? > > Here's the current process. We're still working out the process but > nothing has been approved yet (we just got this page up there > yesterday afternoon) > > http://fedoraproject.org/wiki/Infrastructure/CustomSpins > > -Mike > I still think that Fedora-unity re-spins which are the official img with updates should be on the front with the official ones ( and I feel even more strongly about this issue should replace the official ones ). If users would have downloaded the FC6 respins instead of the "original cant be *touch* updated nor fixed after the release" ones would have saved alot of trouble ( I586 issue ). Custom spins like Daves spins or Mary's spins can be under spins.fedoraproject.org Best regards Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From jkeating at redhat.com Fri Sep 28 11:01:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 07:01:12 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD163B.9050400@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD163B.9050400@hi.is> Message-ID: <20070928070112.054c9b49@redhat.com> On Fri, 28 Sep 2007 14:56:59 +0000 ""J?hann B. Gu?mundsson"" wrote: > I still think that Fedora-unity re-spins which are the official img > with updates should be on the front > with the official ones ( and I feel even more strongly about this > issue should replace the official ones ). > If users would have downloaded the FC6 respins instead of the > "original cant be *touch* updated nor fixed after the release" > ones would have saved alot of trouble ( I586 issue ). The problem with this is the amount of work it would take before many of us would feel comfortable with them replacing the gold images. The code path used at install time is a bit fragile and replacing what was tested at GOLD time with a bunch of new packages (which at times won't work at all. It's quite literally yet another release to freeze for, spend a bunch of time QAing, fixing various bugs, etc... and when we're doing (currently) a full release every 6 months with 3 test releases between each, there really just isn't any bandwidth left to add respins with updates into the mix, especially if we want a chance at all of doing any tools development. Don't get me wrong, I think respins are great, but I really really don't feel comfortable offering them up as anything other than 'use at your own risk' and certainly not to replace the GOLD spins where yeah, there might be bugs, but at least they're known and usually have suitable workarounds. There are also legal concerns with doing more releases like this that I don't even want to get into right now. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Sep 28 15:11:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 28 Sep 2007 20:41:24 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD135C.8020809@hi.is> References: <46FCDE04.6040007@hi.is> <20070928160753.5cac5abc@python3.es.egwn.lan> <46FD0AB6.6000009@fedoraproject.org> <46FD135C.8020809@hi.is> Message-ID: <46FD199C.3050406@fedoraproject.org> J?hann B. Gu?mundsson wrote: > Rahul Sundaram wrote: >> Completely agree on this front. A custom spin with different branding >> and name can be useful for other purposes. Somebody needs to serve as >> a test case for that. >> > How will it work with crediting the right peoples in such a spin and so on. > mean this is not yet another linux distro it is Fedora with extra > packages same > thing diffrent themes logo name? Check out the guidelines at http://fedoraproject.org/wiki/Distribution#head-5a5cea96f0813a2767d5b4e7b215697a6042d8c3 Rahul From j.w.r.degoede at hhs.nl Fri Sep 28 15:04:15 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 28 Sep 2007 17:04:15 +0200 Subject: Can we please stop with the stupid add you Xorg.log canned response to X and OpenGL bugs? Message-ID: <46FD17EF.9090501@hhs.nl> Hi all, A couple of days ago I filed this (fairly detailed bug): https://bugzilla.redhat.com/show_bug.cgi?id=304551 About opengl rendering problems with a certain app on an other wise perfectly fine working opengl setup, and explaining that downgrading mesa-libGL and not making any other changes fixes this. Notice the and not making any other changes. Iow this is in no way a configuration problem. So I got his canned response: "Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance." Which is not the first time, and which just plain sucks! This looks as if it was added without even taken a look at the bug, as the requested info ranges from little relevant to compeltely unrelevant. This does not motivate me (at all) to take the time to fill proper detailed bug reports! So can we please stop with this kind of canned responses, I understand they can be usefull but before adding them atleast read the bug and consider if they are relevant. Thanks & Regards, Hans From kanarip at kanarip.com Fri Sep 28 15:34:38 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 28 Sep 2007 17:34:38 +0200 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928070112.054c9b49@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD163B.9050400@hi.is> <20070928070112.054c9b49@redhat.com> Message-ID: <46FD1F0E.6080106@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Fri, 28 Sep 2007 14:56:59 +0000 > ""J??hann B. Gu??mundsson"" wrote: > >> I still think that Fedora-unity re-spins which are the official img >> with updates should be on the front >> with the official ones ( and I feel even more strongly about this >> issue should replace the official ones ). In another thread on another mailing list I'm reading that Release Engineering will need to be able to build the spins that are to be blessed by the Fedora Project Board, and they have chosen to only do so with their own tools because they have "zero confidence" in the tool Fedora Unity uses. This would prevent the Unity Re-Spins from being blessed or included in a Fedora Project torrent site. >> If users would have downloaded the FC6 respins instead of the >> "original cant be *touch* updated nor fixed after the release" >> ones would have saved alot of trouble ( I586 issue ). > > The problem with this is the amount of work it would take before many > of us would feel comfortable with them replacing the gold images. The > code path used at install time is a bit fragile and replacing what was > tested at GOLD time with a bunch of new packages (which at times won't > work at all. It's quite literally yet another release to freeze for, > spend a bunch of time QAing, fixing various bugs, etc... Surely if a handful of volunteers can do it, as they do now, it shouldn't be the slightest problem for Red Hat, would it? and when we're > doing (currently) a full release every 6 months with 3 test releases > between each, there really just isn't any bandwidth left to add respins > with updates into the mix, especially if we want a chance at all of > doing any tools development. > > Don't get me wrong, I think respins are great, but I really really > don't feel comfortable offering them up as anything other than 'use at > your own risk' and certainly not to replace the GOLD spins where yeah, > there might be bugs, but at least they're known and usually have > suitable workarounds. > One of which is to compose a spin with the updates fixing the issues, don't you think? Kind regards, Jeroen van Meeuwen - -kanarip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG/R8OKN6f2pNCvwgRAg19AKCybiUhgDjM8EvmVvhA+vnc1z94BwCeLEX7 QWejU65s3e0RV3h6D2wAVfw= =a2z/ -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Fri Sep 28 16:15:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Sep 2007 18:15:40 +0200 (CEST) Subject: [RFC] /var versus /srv In-Reply-To: <1190984114.5022.184.camel@home.alexander.bostrom.net> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <29186.192.54.193.51.1190971848.squirrel@rousalka.dyndns.org> <1190984114.5022.184.camel@home.alexander.bostrom.net> Message-ID: <54965.192.54.193.51.1190996140.squirrel@rousalka.dyndns.org> Le Ven 28 septembre 2007 14:55, Alexander Bostr?m a ?crit : > fre 2007-09-28 klockan 11:30 +0200 skrev Nicolas Mailhot: > >> And this is broken by design. You're mirroring /var organisation >> when >> people have repeatedly told you this organisation was not adapted to >> their needs. Swapping /var and /srv does not make it magically sane. > > No, they have not. The fact that /var is something you need to go > through directory by directory to see what you need to backup and what > you can lose is not an argument against /srv/lib. Is that what you > mean? The fact that some stuff is nonsensically under /lib in var is no reason to inflict /lib on /srv > >> Also you contradict yourself by insisting both on packagename >> namespacing and taking a packagename-agnostic layout like /var/www >> as >> example. > > No, I was suggesting bringing that dir into the fold with the others > in /srv/lib if you move it to somewhere in /srv. Whether /srv/lib/www > should be a shared dir for web-related packages or there should be one > dir per package is a different question which I haven't really > intended to comment on or even considered. www is not the only directory with such a question and if you've not considered the problem please refrain from advocating generic packagename namespacing rules >> What's the point of forcing packagename in the namespace ? > > Symmetry. Unless there's a good argument against, symmetry is useful. Symmetry is what led to the wonderful LSB package naming no one uses. Also the package namespace is distro-specific, forcing it on /srv will result in distro-specific file layout. The nice thing about the FHS is it strives to be distro-agnostic. > It's not about forcing, it's about finding something that can be > agreed upon so that you can add it to the FHS. You have two ways to get new stuff in LSB/FHS. Define carefully though stuff that works and everyone is happy to use, and define ?sthetically pleasing stuff that has no relevance to reality but feels good in a spec. The first way is more work. Regards, -- Nicolas Mailhot From nphilipp at redhat.com Fri Sep 28 16:26:16 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 28 Sep 2007 18:26:16 +0200 Subject: Please modify your OpenGL using games to use opengl-games-utils In-Reply-To: <46F8FC8E.70906@hhs.nl> References: <46F8F5E8.3000801@hhs.nl> <1190722516.8399.1.camel@localhost.localdomain> <46F8FC8E.70906@hhs.nl> Message-ID: <1190996776.18404.4.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-09-25 at 14:18 +0200, Hans de Goede wrote: > G?rard Milmeister wrote: > > On Tue, 2007-09-25 at 13:50 +0200, Hans de Goede wrote: > >> This is esp. important for the Games Live DVD, as there people will > >> not have > >> those other drivers available. > > I wonder if it makes any sense to include OpenGL games in such a Games > > Live DVD, that does not provide drivers. > > Yes it does, as OpenGL games will work fine on all integrated intel graphics > (lots of systems) and on all pre r5xx radeons (quite a few systems). Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414 > And who knows, with Fedora 9 we might have radeon 3d support over the whole > line, and nouveau 3d support for nvidea cards, and yes then we still want to > have this check, as there will always be some unsupported cards. BTW: I've looked at the (F7) version of the script. Does it work with AIGLX desktops? AFAICS, accelerated 3d should work there, but this is indirect rendering and glxinfo should give "direct rendering: No". Then there's the issue of proprietary 3D drivers completely bypassing the DRI/DRM infrastructure. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mjs at CLEMSON.EDU Fri Sep 28 16:27:32 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 12:27:32 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070928063428.1a6cb2fe@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> Message-ID: <1190996852.10569.4.camel@vincent52.localdomain> On Fri, 2007-09-28 at 06:34 -0400, Jesse Keating wrote: > On Fri, 28 Sep 2007 07:28:43 -0700 > "Tom London" wrote: > > > Progress! > > > > This issue known? > > > The second connection attempt issue looks more like kernel iwl3945 > issues. Today's rawhide kernel may improve things. kernel-2.6.23-0.211.rc8.git2.fc8 does not solve my iwl3945 issue, which is that nm-applet pulldown menu shows all options related to wireless are grayed out. Also have NetworkManager*-0.7.0-0.3.svn2907.fc8 and wpa_supplicant-0.5.7-9.fc8. > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jkeating at redhat.com Fri Sep 28 16:44:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 12:44:27 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD1F0E.6080106@kanarip.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD163B.9050400@hi.is> <20070928070112.054c9b49@redhat.com> <46FD1F0E.6080106@kanarip.com> Message-ID: <20070928124427.574de18c@redhat.com> On Fri, 28 Sep 2007 17:34:38 +0200 Jeroen van Meeuwen wrote: > One of which is to compose a spin with the updates fixing the issues, > don't you think? Only if enough validation is done to ensure that the changes brought in don't introduce other issues. It's not like the time needed is just the time to click a button and watch a spin happens, there is a lot of validation work that needs to be done, and yes, some of it has to be done by myself before I'm willing to sign off on it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Fri Sep 28 16:56:33 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 10:56:33 -0600 Subject: Fedora spin from RpmFusion In-Reply-To: <46FCDE04.6040007@hi.is> References: <46FCDE04.6040007@hi.is> Message-ID: <20070928105633.3e1a7885@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 10:57:08 +0000 "J?hann B. Gu?mundsson" wrote: > We gonna start an Rpmfusion Fedora spin giving user > the much wanted/needed media support in Fedora. With yum based Anaconda, I can add any repos I want to at install time and then select a customized set of packages from all of them. This means that if you produce a CD/DVD that I can download and you put the proper repodata/ (and comps?) on the disc, then I can use it. But why would you want to produce such an image? It would be out of date before the first person finished downloading it. It might work, as long as people do not include any live over-the-network updated or updates repos in their installs. So, I guess it would be useful when someone has a need to install in an isolated environment/network without Internet access. So, I'm not sure if it would be that useful or not. [snip] > It would be interesting download stats Fedora VS Fedora with media > support :) That it would. > If everything is done outside US hosted outside US created outside US > how much legal > jibber jabber comes from that ? Not for US residents version of > Fedora? I am not a lawyer, I will refrain from sharing any comment in that regard. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/TJB+YBsl9wN1AkRAkGRAKCdJ4wScXdLnzjIhleuuXG39VzEBgCeP3md Z8dz6yNF1YCB6nFEUGPWRkc= =o2od -----END PGP SIGNATURE----- From katzj at redhat.com Fri Sep 28 17:01:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 13:01:32 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928105633.3e1a7885@reaver.lamontpeterson.net> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> Message-ID: <1190998892.4279.9.camel@localhost.localdomain> On Fri, 2007-09-28 at 10:56 -0600, Lamont Peterson wrote: > On Fri, 28 Sep 2007 10:57:08 +0000 > "J?hann B. Gu?mundsson" wrote: > > > We gonna start an Rpmfusion Fedora spin giving user > > the much wanted/needed media support in Fedora. > > With yum based Anaconda, I can add any repos I want to at install time > and then select a customized set of packages from all of them. This > means that if you produce a CD/DVD that I can download and you put the > proper repodata/ (and comps?) on the disc, then I can use it. Well, except that at that point during the install, we have the CD mounted and so you can't unmount to swap CDs. Changing that probably means committing to partitioning changes sooner (currently, we delay them until right before packages install unless you need early swap) so that we can move the install image to the hard disk. And then there may be a little bit of subtlety in ensuring that the ordering of package installation ends up right. But it's mostly a matter of someone sitting down, writing some code and doing some testing. > But why would you want to produce such an image? It would be out of > date before the first person finished downloading it. It might work, > as long as people do not include any live over-the-network updated or > updates repos in their installs. So, I guess it would be useful when > someone has a need to install in an isolated environment/network > without Internet access. > > So, I'm not sure if it would be that useful or not. There are a lot of cases like the above where it is useful. Also cases where people only have sporadic network access. Or slower network access and get media from a friend. Or connect via something more esoteric that anaconda doesn't support setting up. So there's definitely value in doing the work Jeremy From lamont at gurulabs.com Fri Sep 28 17:05:43 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 11:05:43 -0600 Subject: /etc/hosts and system entries In-Reply-To: <20070928054758.0abfde54@redhat.com> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> Message-ID: <20070928110543.3f045c28@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 05:47:58 -0400 Jesse Keating wrote: > On Fri, 28 Sep 2007 15:43:42 +0200 > "Alexander Bostr?m" wrote: > > > While I do believe Kerberos protocols, libs or apps should be > > smarter about these things sometimes and I'm not sure what really > > happens here (though I've seen this happen a few times) I really do > > think Kerberos is in its right to complain when it's fed lies. If > > you put the hostname on the 127.0.0.1 line, doesn't that override > > everything DNS says? > > Almost every single location I take my laptop there is no dns entry > for my hostname. Relying upon every hostname to be DNS resolvable is > extremely dated thinking. > We use Kerberos here. I have the notebooks hostname on the 127.0.0.1 line in my /etc/hosts file. Kerberos doesn't complain. IMNSHO, the /etc/hosts file is only for making sure that the box can resolve itself regardless of what's going on with whatever network(s) it's plugged into at the moment. Period. There are plenty of daemons that will grumble if you use names in the configuration and it can't resolve them (like MTAs, for example, in some parts of their configs). - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/TRn+YBsl9wN1AkRAvBUAKCitlYkA1fAMRXfPbBVVkTyWKvq8ACeOo+n oHDUA439wOjtm7bYVSHmb6w= =xPIa -----END PGP SIGNATURE----- From tcallawa at redhat.com Fri Sep 28 17:04:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 28 Sep 2007 13:04:27 -0400 Subject: Can we please stop with the stupid add you Xorg.log canned response to X and OpenGL bugs? In-Reply-To: <46FD17EF.9090501@hhs.nl> References: <46FD17EF.9090501@hhs.nl> Message-ID: <1190999067.3553.53.camel@localhost.localdomain> Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance. (sorry, couldn't resist) ~spot From trever.adams at gmail.com Fri Sep 28 17:07:56 2007 From: trever.adams at gmail.com (Trever Adams) Date: Fri, 28 Sep 2007 11:07:56 -0600 Subject: RTC/RTC0 issues Message-ID: <46FD34EC.2050004@gmail.com> I have the latest kernel I believe. This issue with rtc existing and /sbin/clock not being able to access it (because it should be a symlink to rtc0, or have the same device number as rt0) still exists. Am I the only one still seeing this? Trever Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From darrellpf at gmail.com Fri Sep 28 17:14:56 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 28 Sep 2007 10:14:56 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190996852.10569.4.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> Message-ID: On 9/28/07, Matthew Saltzman wrote: > (snip) > > kernel-2.6.23-0.211.rc8.git2.fc8 does not solve my iwl3945 issue, which > is that nm-applet pulldown menu shows all options related to wireless > are grayed out. > > Also have NetworkManager*-0.7.0-0.3.svn2907.fc8 and > wpa_supplicant-0.5.7-9.fc8. > On a positive note, the 211 kernel, iwl3945 with today's rawhide works for me. Not using wpa_supplicant since I'm connecting to an 'open' Cisco AP with web page login. darrell From selinux at gmail.com Fri Sep 28 17:24:26 2007 From: selinux at gmail.com (Tom London) Date: Fri, 28 Sep 2007 10:24:26 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1190996852.10569.4.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> Message-ID: <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> On 9/28/07, Matthew Saltzman wrote: > On Fri, 2007-09-28 at 06:34 -0400, Jesse Keating wrote: > > On Fri, 28 Sep 2007 07:28:43 -0700 > > "Tom London" wrote: > > > > > Progress! > > > > > > This issue known? > > > > > > The second connection attempt issue looks more like kernel iwl3945 > > issues. Today's rawhide kernel may improve things. > > kernel-2.6.23-0.211.rc8.git2.fc8 does not solve my iwl3945 issue, which > is that nm-applet pulldown menu shows all options related to wireless > are grayed out. > > Also have NetworkManager*-0.7.0-0.3.svn2907.fc8 and > wpa_supplicant-0.5.7-9.fc8. > Running kernel-2.6.23-0.213.rc8.git2.fc8 seems to work better for me: nm-applet seems to work (except it still is initially displayed with the red 'x'), I can select a WPA network and enter hex key generated by wpa_passphrase, the right 'stuff' gets stored in my keyring, etc. My Thinkpad X60 also has iwl3945, so I'm not sure what is different (do your networks broadcast their SSIDs?) I can alternate between wired and wireless without issue. Great progress! One issue: 'Connect to other wireless network' and 'Create new wireless network' menu items are grayed out. I'm guessing that will make it hard to connect to networks that don't broadcast SSIDs. tom -- Tom London From jkeating at redhat.com Fri Sep 28 17:40:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 13:40:46 -0400 Subject: /etc/hosts and system entries In-Reply-To: <20070928110543.3f045c28@reaver.lamontpeterson.net> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> <20070928110543.3f045c28@reaver.lamontpeterson.net> Message-ID: <20070928134046.01beb100@redhat.com> On Fri, 28 Sep 2007 11:05:43 -0600 Lamont Peterson wrote: > IMNSHO, the /etc/hosts file is only for making sure that the box can > resolve itself regardless of what's going on with whatever network(s) > it's plugged into at the moment. Period. There are plenty of > daemons that will grumble if you use names in the configuration and > it can't resolve them (like MTAs, for example, in some parts of their > configs). I agree. Locally resolvable is a must, DNS resolvable (or matching DNS) is silly. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Fri Sep 28 17:52:07 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Sep 2007 13:52:07 -0400 Subject: /etc/hosts and system entries In-Reply-To: <20070928110543.3f045c28@reaver.lamontpeterson.net> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> <20070928110543.3f045c28@reaver.lamontpeterson.net> Message-ID: <1191001927.3476.28.camel@hopeson> On Fri, 2007-09-28 at 11:05 -0600, Lamont Peterson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 28 Sep 2007 05:47:58 -0400 > Jesse Keating wrote: > > > On Fri, 28 Sep 2007 15:43:42 +0200 > > "Alexander Bostr?m" wrote: > > > > > While I do believe Kerberos protocols, libs or apps should be > > > smarter about these things sometimes and I'm not sure what really > > > happens here (though I've seen this happen a few times) I really do > > > think Kerberos is in its right to complain when it's fed lies. If > > > you put the hostname on the 127.0.0.1 line, doesn't that override > > > everything DNS says? > > > > Almost every single location I take my laptop there is no dns entry > > for my hostname. Relying upon every hostname to be DNS resolvable is > > extremely dated thinking. > > > > We use Kerberos here. I have the notebooks hostname on the 127.0.0.1 line in my /etc/hosts file. Kerberos doesn't complain Try to do that on the KDC, the KDC does not listen on 127.0.0.1 for some reason. > IMNSHO, the /etc/hosts file is only for making sure that the box can resolve itself regardless of what's going on with whatever network(s) it's plugged into at the moment. Period. There are plenty of daemons that will grumble if you use names in the configuration and it can't resolve them (like MTAs, for example, in some parts of their configs). Sure, if we can make dhclient or the network configuration tools put in the right name-ip pair in /etc/hosts I have no problems. Simo. From johannbg at hi.is Fri Sep 28 18:06:39 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 18:06:39 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD11B7.3030200@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> Message-ID: <46FD42AF.70204@hi.is> Mike McGrath wrote: > J?hann B. Gu?mundsson wrote: >> Jesse Keating wrote: >>> On Fri, 28 Sep 2007 10:57:08 +0000 >>> ""J?hann B. Gu?mundsson"" wrote: >>> >>> >>>> Will this be available on fedoraprojects.org as in >>>> will Max Spevack put his money where is mouth is so I quote Max >>>> "So go forth and mix your own Fedora. And then come back and share >>>> it with us, and we?ll put it up on the _*Fedora website for others to >>>> use also.*_" >>>> ref. ( http://www.redhatmagazine.com/2007/05/31/remixing-fedora-7/ ) >>>> Or was this just a pr c... >>>> >>> >>> Remix implies that you take the package set and do something >>> interesting with it, not just add a bunch of stuff from outside >>> Fedora. Furthermore, regardless of location, Fedora isn't interested >>> in patent encumbered software, as it's not free for /everybody/. It's >>> entirely uninteresting to promote such a thing. >>> >>> >> The Fedora-unity re-spins could be posted on fedoraprojects.org >> along with the official img right? > > Here's the current process. We're still working out the process but > nothing has been approved yet (we just got this page up there > yesterday afternoon) > > http://fedoraproject.org/wiki/Infrastructure/CustomSpins > > -Mike > Ok so let's take it step by step from the normal user... Even if he's familiar with other tools to created the images whatever they might be he knows that the image gets dropped since it he's not using the official Fedora remixing tools. ( Not looking at the quality of the final product/outcome but automatically dropping it since it was not build using official Fedora remixing tools ) So he study s he reads he learns, and finally masters Pungi,LiveCD Creator and Revisor. Don't know how much time it takes for an normal user do to that but let's say he stays focused through out the process. Happy as he is after all his work reading testing and all he now can start building his own favorite Fedora spin that he wants to share with the rest of the world or his fellow Fedorians. He starts his normal package selection he wants this and he doesn't want that and let's give him that he manages to go through that without his package constantly being pulled back in due to dependency. His package selection has now been successfully finished. For the finishing but vital touch for the him, his look, his feel, his view of the world, HIS theme and look in Gnome or KDE, because he wants to brag about how *COOL* his desktop looks but then he realizes that his icons, desktop image and window manager themes cant be used since he pulled it from gnome-look or kde-look or he created the theme/icons/background image himself and since his theme was not in the official repo he knows is spins gets rejected. Since he had put all that work in this already.. he's stubborn and decides to send his *final product his spin* to the release engineers. He was lucky he was the first of 1000 Fedorians that wanted to share their spins with each other so the release engineers actually could spare the little time they have from working on the official Fedora to review his spin and yes it is as technically Fedora as possible and he gets an pass, yea he thinks yes, it's not all for nothing, now for the board will they approve, Can he use Fedora trademarks? He can.... But But.. He had forgotten to learn how to create kickstart file, after all this work, so close yet so far... He study s, he reads, he learns, he MASTERS kickstart.. ant the beautiful kickstart script is born He gives the much needed kickstart script to the not so busy release engineers ( tho they are getting overloaded they seem to have less and less time to focus on Fedora itself.. ) It gets approved, It is there.. His work has now made it to the spins.fedoraproject.org he brags, points. spreads the word, look there it is there's my spin of Fedora.... It hits all the internet news websites, users from all over the world start downloading and installing, the first spin ever to be released on spins.fedoraproject.org. and whats the outcome it's is an web browser, an email client, and an office suite with no media support in theme that was so far from the user ideas as possible. A major flop, the reviews go in, user reads it, graps the next shot gun and kills himself. If this spins project is ever gonna work for both developers and users. the upload process of the spins have to be done without any reviews. Since the user is restricted to "Fedora ways" and the outcome can always be calculated you can take md5 some or some other thing of each package(s) + that with another package(s) store all the possible variation in a database, create a spins, Create a spin dump directory on the web server. let the user have an FC account which they have to authenticate against and after log in aka in their fedora account, there would be an option to upload an spin. When they are gonna upload a spin, they are asked to put an description of the spin(s) and the sum of the spin packages which is then match to the all possible sums in the database and voila. Release engingeers can focus on their work, users dont have go through "reviews" to be approved.. everybody is happy or as they can be ( except of no media support in their spins ).. Think more then 1 user people how where you gonna handle 10000 of spins, or this being develop of not being used and popular... ***sight*** Best regards. Johann B. -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From mjs at CLEMSON.EDU Fri Sep 28 18:18:35 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 14:18:35 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190631227.30606.10.camel@s1.crocom.com.pl> References: <1190410702.5762.26.camel@valkyrie.localdomain> <1190592214.4603.10.camel@localhost.localdomain> <1190631227.30606.10.camel@s1.crocom.com.pl> Message-ID: <1191003515.11875.9.camel@vincent52.localdomain> On Mon, 2007-09-24 at 12:53 +0200, Tomasz Torcz wrote: > Dnia 23-09-2007, N o godzinie 20:03 -0400, Jeremy Katz napisa?(a): > > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > > > - Screen brightness is erratic. The screen brightness applet appears, > > > but whatever controls I hit, brightness changes randomly up or down and > > > does not get fully bright or dim. If I switch to a VC, I can control > > > the brightness, but ^@ characters appear on the display. > > > > This has been reported a couple of times-- Warren was going to try to > > track this down and get some better reporting of it I believe > > This is because changing brightness generate brightness key event. User > turn brightness one step down, event is generated, event is seen by > gnome-power-manager which turns brightness down, event is generated... > all the way down to 0 up up to max. > > This issue is fixable at HAL (hal-info) level. Please > update /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi > with you model number and also send patch to HAL upstream list. > > Nb. this file in F7 still has a typo for other model ("Z31t" instead of > "Z61t") There's already an entry with vendor string="LENOVO" and version contains="ThinkPad". I assume the intention is to match all Lenovo ThinkPads, but it doesn't seem to fix the issue for my T61. What am I missing? Thanks. > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mmcgrath at redhat.com Fri Sep 28 18:14:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 13:14:53 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD42AF.70204@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> Message-ID: <46FD449D.7090503@redhat.com> J?hann B. Gu?mundsson wrote: > Mike McGrath wrote: >> >> Here's the current process. We're still working out the process but >> nothing has been approved yet (we just got this page up there >> yesterday afternoon) >> >> http://fedoraproject.org/wiki/Infrastructure/CustomSpins >> Snip > Ok so let's take it step by step from the normal user... What can I say dude, it takes commitment. If someone wants to spend 5 minutes to build an image and hand it off to us... we're not interested. > Since the user is restricted to "Fedora ways" and the outcome can > always be calculated you can take md5 some or some other thing of each > package(s) + that with another package(s) store all the > possible variation in a database, create a spins, Create a spin dump > directory on the web server. let the user have an FC account which > they have to authenticate against and > after log in aka in their fedora account, there would be an option to > upload an spin. > When they are gonna upload a spin, they are asked to put an > description of the spin(s) and the sum of the spin packages which is > then match to the all possible sums in the database and voila. > Release engingeers can focus on their work, users dont have go through > "reviews" to be approved.. everybody is happy or as they can be ( > except of no media support in their spins ).. > > Think more then 1 user people how where you gonna handle 10000 of > spins, > or this being develop of not being used and popular... > ***sight*** You've forgotten to take in to consideration brand dilution. I can't imagine a scenario where Fedora is officially hosting 10,000 spins for a single release. It's not the way I envision it (Not that what I say is the way it is, feel free to take a 10,000 spin proposal to the FAB but I think you'll find its not practical). Getting a spin hosted by Fedora should be a process that takes Fedora's image into account which is why there is a Trademark check by the board. If they decide that the spin is bad for Fedora's image or they have decided we've gotten spin crazy they'll put a stop to it. The re-spins are supposed to be quality, compelling spins. Not some silly crap that $RANDOM_STUDENT made for a class that he'll forget all about after the class is done. The way I see it is that SIG's in Fedora can create their own spin if they feel its needed. I doubt there will be too many "look what _I_ did" spins at spins.fedoraproject.org if any. I'd think it should be "look at what _we_ did". Being in the Infrastructure group we see a lot of "Wouldn't it be cool if? Here, now you host and maintain it." Which just doesn't scale / work and is very annoying. This is especially true since people, dedicated people, could create their own spin and host it themselves. -Mike From jkeating at redhat.com Fri Sep 28 18:19:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 14:19:43 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD42AF.70204@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> Message-ID: <20070928141943.47e6afcf@redhat.com> On Fri, 28 Sep 2007 18:06:39 +0000 ""J?hann B. Gu?mundsson"" wrote: > Think more then 1 user people how where you gonna handle 10000 of > spins, or this being develop of not being used and popular... > > ***sight*** Your entire tirade is flawed. There is no reason why using the graphical and easy to understand Revisor couldn't produce a working kickstart file that can be fed into which ever tool is necessary. One doesn't have to learn kickstart, one doesn't have to learn pungi/livecd, etc... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Sep 28 18:22:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Sep 2007 20:22:44 +0200 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD449D.7090503@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> Message-ID: <46FD4674.3010609@leemhuis.info> On 28.09.2007 20:14, Mike McGrath wrote: > >> Ok so let's take it step by step from the normal user... > What can I say dude, it takes commitment. If someone wants to spend 5 > minutes to build an image and hand it off to us... we're not interested. In addition: let's get rpmfusion running first before talking about rpmfusion spins. /me wanders off to continue installing plague for rpmfusion Cu knurd From curtis at GreenKey.net Fri Sep 28 17:40:52 2007 From: curtis at GreenKey.net (Curtis Doty) Date: Fri, 28 Sep 2007 10:40:52 -0700 (PDT) Subject: raid456 Message-ID: <20070928174053.4FBAF6F1C2@alopias.GreenKey.net> Am I the only one noticing that the raid456 module and all its deps are getting dragged in when only raid1 is desired? # lsmod |grep raid456 raid456 120937 0 async_xor 7233 1 raid456 async_memcpy 6209 1 raid456 async_tx 9793 3 raid456,async_xor,async_memcpy xor 17737 2 raid456,async_xor # cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md0 : active raid1 sda1[0] sdc1[2](S) sdb1[1] 64128 blocks [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 10490368 blocks [2/2] [UU] I see that it was added to mkinitrd for recovery scenarios. Which is fine. But does it *always* need to be loaded? ../C From fedora at camperquake.de Fri Sep 28 18:25:21 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 28 Sep 2007 20:25:21 +0200 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1191003515.11875.9.camel@vincent52.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> <1190592214.4603.10.camel@localhost.localdomain> <1190631227.30606.10.camel@s1.crocom.com.pl> <1191003515.11875.9.camel@vincent52.localdomain> Message-ID: <20070928202521.5f7be0c0@lain.camperquake.de> Hi. On Fri, 28 Sep 2007 14:18:35 -0400, Matthew Saltzman wrote > There's already an entry with vendor string="LENOVO" and version > contains="ThinkPad". I assume the intention is to match all Lenovo > ThinkPads, but it doesn't seem to fix the issue for my T61. What am I > missing? Same behaviour for my X60s, although the keys should match. Where do I poke to see if laptop_panel.brightness_in_hardware has really been set? From mjs at CLEMSON.EDU Fri Sep 28 18:33:50 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 14:33:50 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> Message-ID: <1191004430.12453.4.camel@vincent52.localdomain> On Fri, 2007-09-28 at 10:24 -0700, Tom London wrote: > On 9/28/07, Matthew Saltzman wrote: > > On Fri, 2007-09-28 at 06:34 -0400, Jesse Keating wrote: > > > On Fri, 28 Sep 2007 07:28:43 -0700 > > > "Tom London" wrote: > > > > > > > Progress! > > > > > > > > This issue known? > > > > > > > > > The second connection attempt issue looks more like kernel iwl3945 > > > issues. Today's rawhide kernel may improve things. > > > > kernel-2.6.23-0.211.rc8.git2.fc8 does not solve my iwl3945 issue, which > > is that nm-applet pulldown menu shows all options related to wireless > > are grayed out. > > > > Also have NetworkManager*-0.7.0-0.3.svn2907.fc8 and > > wpa_supplicant-0.5.7-9.fc8. > > > Running kernel-2.6.23-0.213.rc8.git2.fc8 seems to work better for me: > nm-applet seems to work (except it still is initially displayed with > the red 'x'), I can select a WPA network and enter hex key generated > by wpa_passphrase, the right 'stuff' gets stored in my keyring, etc. Got that one a few minutes ago, and it doesn't fix the issue for me. > > My Thinkpad X60 also has iwl3945, so I'm not sure what is different > (do your networks broadcast their SSIDs?) No, the one I'm at now does not broadcast. I'll take the machine home today and try with a broadcast SSID. > > I can alternate between wired and wireless without issue. > > Great progress! > > One issue: 'Connect to other wireless network' and 'Create new > wireless network' menu items are grayed out. I'm guessing that will > make it hard to connect to networks that don't broadcast SSIDs. Yes, this is exactly my issue. The machine is unusable for me at work if this isn't functional. > > tom -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From skvidal at fedoraproject.org Fri Sep 28 18:34:41 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 28 Sep 2007 14:34:41 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD449D.7090503@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> Message-ID: <1191004481.29395.27.camel@cutter> On Fri, 2007-09-28 at 13:14 -0500, Mike McGrath wrote: > You've forgotten to take in to consideration brand dilution. I can't > imagine a scenario where Fedora is officially hosting 10,000 spins for a > single release. It's not the way I envision it (Not that what I say is > the way it is, feel free to take a 10,000 spin proposal to the FAB but I > think you'll find its not practical). Getting a spin hosted by Fedora > should be a process that takes Fedora's image into account which is why > there is a Trademark check by the board. If they decide that the spin > is bad for Fedora's image or they have decided we've gotten spin crazy > they'll put a stop to it. /me plans the fedora-pr0n-server spin -sv From johannbg at hi.is Fri Sep 28 18:46:59 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 28 Sep 2007 18:46:59 +0000 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD449D.7090503@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> Message-ID: <46FD4C23.1070309@hi.is> Mike McGrath wrote: > J?hann B. Gu?mundsson wrote: >> Mike McGrath wrote: >>> >>> Here's the current process. We're still working out the process but >>> nothing has been approved yet (we just got this page up there >>> yesterday afternoon) >>> >>> http://fedoraproject.org/wiki/Infrastructure/CustomSpins >>> > Snip >> Ok so let's take it step by step from the normal user... > > What can I say dude, it takes commitment. If someone wants to spend 5 > minutes to build an image and hand it off to us... we're not interested. > So an image that is created in hour(s) day(s) weeks is an image that is better than an image that is created in 5 minutes.. So as long as I created the image in an time line the suits you guys that are interested. ( just hope that evolution will come to an halt and so I images that I would respin can meet their timeline ) >> Since the user is restricted to "Fedora ways" and the outcome can >> always be calculated you can take md5 some or some other thing of >> each package(s) + that with another package(s) store all the >> possible variation in a database, create a spins, Create a spin dump >> directory on the web server. let the user have an FC account which >> they have to authenticate against and >> after log in aka in their fedora account, there would be an option to >> upload an spin. >> When they are gonna upload a spin, they are asked to put an >> description of the spin(s) and the sum of the spin packages which is >> then match to the all possible sums in the database and voila. >> Release engingeers can focus on their work, users dont have go >> through "reviews" to be approved.. everybody is happy or as they can >> be ( except of no media support in their spins ).. >> >> Think more then 1 user people how where you gonna handle 10000 of >> spins, >> or this being develop of not being used and popular... >> ***sight*** > > You've forgotten to take in to consideration brand dilution. I can't > imagine a scenario where Fedora is officially hosting 10,000 spins for > a single release. It's not the way I envision it (Not that what I say > is the way it is, feel free to take a 10,000 spin proposal to the FAB > but I think you'll find its not practical). Getting a spin hosted by > Fedora should be a process that takes Fedora's image into account > which is why there is a Trademark check by the board. If they decide > that the spin is bad for Fedora's image or they have decided we've > gotten spin crazy they'll put a stop to it. The re-spins are supposed > to be quality, compelling spins. Not some silly crap that > $RANDOM_STUDENT made for a class that he'll forget all about after the > class is done. > The uploaded images would be deleted after user account as been inactive for a while or on 2 months after a new Fedora release > The way I see it is that SIG's in Fedora can create their own spin if > they feel its needed. I doubt there will be too many "look what _I_ > did" spins at spins.fedoraproject.org if any. I'd think it should be > "look at what _we_ did". Being in the Infrastructure group we see a > lot of "Wouldn't it be cool if? Here, now you host and maintain it." > Which just doesn't scale / work and is very annoying. > > This is especially true since people, dedicated people, could create > their own spin and host it themselves. > > -Mike > For the record if people haven't noticed it yet playing by those Fedora restricted/bounded rules will never become interesting... Know variable == Known result == Boring.. With this limited thinking this project is doomed to fail.... Best regards Johann B. "Put the clay in the hand of the individual and see what he creates without boundary's it's then when the outcome becomes interesting " -- Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From dmc.fedora at filteredperception.org Fri Sep 28 18:49:35 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 13:49:35 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928072319.35e126c3@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> Message-ID: <46FD4CBF.2080800@filteredperception.org> Jesse Keating wrote: > On Fri, 28 Sep 2007 10:57:08 +0000 > ""J?hann B. Gu?mundsson"" wrote: > >> With strictly the media support ( ugly-plugins etc. ) and the >> rpmfusion repo installed, >> and excluding AMD and Nvidia drivers >> will we need Rename the spin or could it be released under Fedora name >> and artwork? * Legal/others > > No. You are including content that is not in Fedora, therefor you > cannot use the Fedora trademark and cannot use the trademarked logos. > You would have some renaming work ahead of you. I don't believe this is strictly true. I can't seem to find the correct link with the info from legal, but I'm 99.9% certain that if you find a way to put together an iso which a) has a complete, identifiable-as-such, copy of 'the fedora software' (which I'll just take as a blessed fedora iso.) and b) custom non-blessed patches and c) the user can select on boot/install whether or not to boot the pure blessed fedora version, or the patched fedora version with obvious messages that the patches are not blessed, then this type of composition may in fact use the fedora artwork, etc... Please don't make an uninformed response to this mail before reading the legal trademark guidlines which specifically mention this 'supplying patches with the blessed fedora that the user may clearly choose, or choose not to use at boot/install time'. (not a verbatim quote, as all the links in this message which held the new policy are now broken- http://www.redhat.com/archives/fedora-devel-list/2007-August/msg02287.html (another broken link) http://fedoraproject.org/wiki/Legal/TrademarkGuidelines -dmc From jkeating at redhat.com Fri Sep 28 18:56:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 14:56:23 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD4C23.1070309@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> Message-ID: <20070928145623.47e08035@redhat.com> On Fri, 28 Sep 2007 18:46:59 +0000 ""J?hann B. Gu?mundsson"" wrote: > "Put the clay in the hand of the individual and see what he creates > without boundary's > it's then when the outcome becomes interesting " You have the clay, and the molding tools. All we ask is that if you color outside the lines you call your work of art something other than Fedora. If your art is interesting, and we can legally reproduce it, maybe we will. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Sep 28 18:54:25 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 13:54:25 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD4C23.1070309@hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> Message-ID: <46FD4DE1.8060904@redhat.com> J?hann B. Gu?mundsson wrote: > For the record if people haven't noticed it yet playing by those > Fedora restricted/bounded rules will never > become interesting... > > Know variable == Known result == Boring.. I agree, the most interesting spins will come from those people that either live in other countries or give no regard to the laws and regulations in which they live. People working outside of Fedora's rules will be able to do whatever they want, including forking a version of Fedora with full multimedia goodness. Mythdora anyone? I agree those spins will be awesome.... but they won't be called Fedora. Unfortunately what you are wanting to do can't be included into Fedora proper. Having said that I (and I assume many others) look forward to your spin, good luck. -Mike From tjb at unh.edu Fri Sep 28 18:59:40 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 28 Sep 2007 14:59:40 -0400 Subject: rawhide report: 20070928 changes In-Reply-To: <200709281009.l8SA9VOD013878@porkchop.devel.redhat.com> References: <200709281009.l8SA9VOD013878@porkchop.devel.redhat.com> Message-ID: <1191005980.4809.2.camel@raptor.sr.unh.edu> > > kernel-2.6.23-0.211.rc8.git2.fc8 > -------------------------------- > * Thu Sep 27 2007 Chuck Ebbert > - Linux 2.6.23-rc8-git2 > - Re-add AMD timer fix removed from upstream > - Fix hotplug CPU (broken by AMD timer patch) > > * Thu Sep 27 2007 John W. Linville > - Fix-up botched wireless patch restructuring... > > * Wed Sep 26 2007 John W. Linville > - Update and restructure wireless patches > This kernel or any newer doesn't boot on my Dell XPS1210 laptop, complaining about not finding a valid memory map. https://bugzilla.redhat.com/show_bug.cgi?id=311491 Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From mattdm at mattdm.org Fri Sep 28 19:05:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 28 Sep 2007 15:05:48 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191004430.12453.4.camel@vincent52.localdomain> References: <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> Message-ID: <20070928190548.GA8726@jadzia.bu.edu> On Fri, Sep 28, 2007 at 02:33:50PM -0400, Matthew Saltzman wrote: > > One issue: 'Connect to other wireless network' and 'Create new > > wireless network' menu items are grayed out. I'm guessing that will > > make it hard to connect to networks that don't broadcast SSIDs. > Yes, this is exactly my issue. The machine is unusable for me at work > if this isn't functional. Now (even with the 2.6.23-0.211 kernel), I'm getting "Interface doesn't support scanning" when I do iwlist scan. With 0.202 and 0.204, it seemed to do this some of the time but randomly work others. For example, it worked at home this morning initially but connected to my neighbor's network (which I use sometimes). When I tried to tell it to connect to (now slash-free) SSID, it sat there spinning and then after that (and across reboots) it wouldn't work again. Bizarreness. I'd go back and try to find one worked, but I don't have the installonly_limit set that high. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Sep 28 19:17:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 28 Sep 2007 15:17:30 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070928190548.GA8726@jadzia.bu.edu> References: <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <20070928190548.GA8726@jadzia.bu.edu> Message-ID: <20070928191730.GA10570@jadzia.bu.edu> On Fri, Sep 28, 2007 at 03:05:48PM -0400, Matthew Miller wrote: > Now (even with the 2.6.23-0.211 kernel), I'm getting "Interface doesn't > support scanning" when I do iwlist scan. With 0.202 and 0.204, it seemed to Hmm, or sometimes: "Failed to read scan data : Resource temporarily unavailable". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Matt_Domsch at dell.com Fri Sep 28 19:18:21 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Sep 2007 14:18:21 -0500 Subject: rawhide report: 20070928 changes In-Reply-To: <1191005980.4809.2.camel@raptor.sr.unh.edu> References: <200709281009.l8SA9VOD013878@porkchop.devel.redhat.com> <1191005980.4809.2.camel@raptor.sr.unh.edu> Message-ID: <20070928191821.GB25371@auslistsprd01.us.dell.com> On Fri, Sep 28, 2007 at 02:59:40PM -0400, Thomas J. Baker wrote: > > > > > > kernel-2.6.23-0.211.rc8.git2.fc8 > > > This kernel or any newer doesn't boot on my Dell XPS1210 laptop, > complaining about not finding a valid memory map. > > https://bugzilla.redhat.com/show_bug.cgi?id=311491 There'll be a new kernel in rawhide tomorrow to address this kernel bug. As of when that kernel was built, it was thought to be a BIOS bug, but has since been proven to be a kernel bug. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From orion at cora.nwra.com Fri Sep 28 19:26:11 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 28 Sep 2007 13:26:11 -0600 Subject: i810switch -> xrandr for F8 In-Reply-To: <645d17210709280246j70d6c3f2t77c524c1195acfd3@mail.gmail.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> <200709280807.57725.opensource@till.name> <645d17210709280246j70d6c3f2t77c524c1195acfd3@mail.gmail.com> Message-ID: <46FD5553.9010307@cora.nwra.com> Jonathan Underwood wrote: > On 28/09/2007, Till Maas wrote: >> On Fr September 28 2007, Matt Domsch wrote: >> >>> In Fedora 8, the xrandr application provides this same functionality, >>> natively in the Xorg subsystem. >>> >>> In my limited testing, xrandr works on the i810 class hardware I have >>> access to. >> How can one use xrandr to enable/disable vga output? I can test this with my >> X41 Thinkpad. > > xrandr --output VGA --off > Is there an xrandr (KDE) applet to provide a nice GUI way of doing this? -- 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 jonathan.underwood at gmail.com Fri Sep 28 19:34:15 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 28 Sep 2007 20:34:15 +0100 Subject: i810switch -> xrandr for F8 In-Reply-To: <46FD5553.9010307@cora.nwra.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> <200709280807.57725.opensource@till.name> <645d17210709280246j70d6c3f2t77c524c1195acfd3@mail.gmail.com> <46FD5553.9010307@cora.nwra.com> Message-ID: <645d17210709281234p6398e152x5fef5554ed9a5b2d@mail.gmail.com> On 28/09/2007, Orion Poplawski wrote: > > Is there an xrandr (KDE) applet to provide a nice GUI way of doing this? I don't know of one for KDE, but there is urandr for gnome: http://albertomilone.com/wordpress/?p=118 https://code.launchpad.net/urandr https://launchpad.net/urandr I have it running fine here on F7. From wtogami at redhat.com Fri Sep 28 19:36:55 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 28 Sep 2007 15:36:55 -0400 Subject: Thinkpad Fn-F5 Bluetooth Switch Message-ID: <46FD57D7.2020005@redhat.com> In F7 with apparently no configuration, my Thinkpad T60's Fn-F5 Bluetooth switching button worked. In F8, it stopped working. /proc/acpi/ibm can be toggled manually. Anyone know what might have disappeared from F7 -> F8? Warren Togami wtogami at redhat.com From jwboyer at jdub.homelinux.org Fri Sep 28 19:53:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 28 Sep 2007 14:53:56 -0500 Subject: Thinkpad Fn-F5 Bluetooth Switch In-Reply-To: <46FD57D7.2020005@redhat.com> References: <46FD57D7.2020005@redhat.com> Message-ID: <20070928145356.70a237b7@weaponx.rchland.ibm.com> On Fri, 28 Sep 2007 15:36:55 -0400 Warren Togami wrote: > In F7 with apparently no configuration, my Thinkpad T60's Fn-F5 > Bluetooth switching button worked. > > In F8, it stopped working. > > /proc/acpi/ibm can be toggled manually. > > Anyone know what might have disappeared from F7 -> F8? I recall seeing that on my z60m as well. josh From lamont at gurulabs.com Fri Sep 28 19:54:14 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 13:54:14 -0600 Subject: /etc/hosts and system entries In-Reply-To: <1191001927.3476.28.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> <20070928110543.3f045c28@reaver.lamontpeterson.net> <1191001927.3476.28.camel@hopeson> Message-ID: <20070928135414.1e0794d1@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 13:52:07 -0400 Simo Sorce wrote: > On Fri, 2007-09-28 at 11:05 -0600, Lamont Peterson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Fri, 28 Sep 2007 05:47:58 -0400 > > Jesse Keating wrote: > > > > > On Fri, 28 Sep 2007 15:43:42 +0200 > > > "Alexander Bostr?m" wrote: > > > > > > > While I do believe Kerberos protocols, libs or apps should be > > > > smarter about these things sometimes and I'm not sure what > > > > really happens here (though I've seen this happen a few times) > > > > I really do think Kerberos is in its right to complain when > > > > it's fed lies. If you put the hostname on the 127.0.0.1 line, > > > > doesn't that override everything DNS says? > > > > > > Almost every single location I take my laptop there is no dns > > > entry for my hostname. Relying upon every hostname to be DNS > > > resolvable is extremely dated thinking. > > > > > > > We use Kerberos here. I have the notebooks hostname on the > > 127.0.0.1 line in my /etc/hosts file. Kerberos doesn't complain > Try to do that on the KDC, the KDC does not listen on 127.0.0.1 for > some reason. Do I have "stupid" stamped on my forehead? I didn't think I did. :) Seriously, though, I wasn't talking about fixed servers or KDCs. Of course, using 127.0.0.1 on a KDC would be problematic, but that's a "fixed server". You're going to set it up and if you use DHCP, you're going to make sure that box always gets the same IP. It's going to be in your DNS and you're going to make sure the PTR record is correct, too (if possible, but not strictly required). You're also going to install the box and specify the hostname and not allow DHCP to try to determine it if you're using DHCP, in most cases. We were talking about a notebook. I don't know about you, but I don't run a KDC on mine. We were talking about the notebook as a Kerberos client. However, I have thought about running a slave KDC on my notebook, so that I don't have to wait for timeouts and failure due to not being able to contact the KDC while PAM is trying to authenticate. Still, I'm sure there would be a whole lot of other issues with that, not the least of which would be dealing with the KDC db keys. Oh well; I just don't have PAM doing Kerberos authentication and I simply run kinit when I need to. > > IMNSHO, the /etc/hosts file is only for making sure that the box > > can resolve itself regardless of what's going on with whatever > > network(s) it's plugged into at the moment. Period. There are > > plenty of daemons that will grumble if you use names in the > > configuration and it can't resolve them (like MTAs, for example, in > > some parts of their configs). > > Sure, if we can make dhclient or the network configuration tools put > in the right name-ip pair in /etc/hosts I have no problems. Agreed. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/Vvm+YBsl9wN1AkRAo8DAKDGtkpWbR6Ln9AJrUI/OfK6jCceRQCdEv2j Ncm7pj5RZk5Ukrx31AymDIw= =9Ydp -----END PGP SIGNATURE----- From Curtis at GreenKey.net Fri Sep 28 20:27:36 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Fri, 28 Sep 2007 13:27:36 -0700 (PDT) Subject: raid456 In-Reply-To: <20070928174053.4FBAF6F1C2@alopias.GreenKey.net> References: <20070928174053.4FBAF6F1C2@alopias.GreenKey.net> Message-ID: <20070928202737.236986F1C2@alopias.GreenKey.net> 10:40am Curtis Doty said: > Am I the only one noticing that the raid456 module and all its deps are > getting dragged in when only raid1 is desired? > Answering my own question with a teeny patch. Apolgies for the noise, I just can't see the wisdom in the prior code and what I might have b0rk. ../C --- mkinitrd.ORIG 2007-09-25 06:41:47.000000000 -0700 +++ mkinitrd 2007-09-28 13:24:05.000000000 -0700 @@ -683,8 +683,11 @@ handleraid() { findmodule multipath start=1 ;; - raid[01456] | raid10) + raid[01] | raid10) findmodule $level + start=1 + ;; + raid[456]) findmodule raid456 start=1 ;; From mr.ecik at gmail.com Fri Sep 28 21:19:38 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Fri, 28 Sep 2007 23:19:38 +0200 Subject: Fedora Live CD unwritable on CDs Message-ID: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> Hi! My friend noticed an oddity after trying to burn his Fedora-7-Live-x86_64.iso. Its size is 779M and it was impossible to write it on CD. He had to burn CD-image on DVD and this shouldn't be the thing we expect. Some people probably still don't own any DVD-reader and if they have x86_64 processor, they won't be able to install the distro. So my question is: why x86_64 and ppc live CDs are greater than CDs? How can users burn them? Are we doing anything to make these images smaller? Thanks. -- Micha? Bentkowski mr.ecik at gmail.com From mjs at CLEMSON.EDU Fri Sep 28 21:29:40 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 17:29:40 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191004430.12453.4.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> Message-ID: <1191014980.12995.14.camel@vincent52.localdomain> On Fri, 2007-09-28 at 14:33 -0400, Matthew Saltzman wrote: > On Fri, 2007-09-28 at 10:24 -0700, Tom London wrote: > > On 9/28/07, Matthew Saltzman wrote: > > > On Fri, 2007-09-28 at 06:34 -0400, Jesse Keating wrote: > > > > On Fri, 28 Sep 2007 07:28:43 -0700 > > > > "Tom London" wrote: > > > > > > > > > Progress! > > > > > > > > > > This issue known? > > > > > > > > > > > > The second connection attempt issue looks more like kernel iwl3945 > > > > issues. Today's rawhide kernel may improve things. > > > > > > kernel-2.6.23-0.211.rc8.git2.fc8 does not solve my iwl3945 issue, which > > > is that nm-applet pulldown menu shows all options related to wireless > > > are grayed out. > > > > > > Also have NetworkManager*-0.7.0-0.3.svn2907.fc8 and > > > wpa_supplicant-0.5.7-9.fc8. > > > > > Running kernel-2.6.23-0.213.rc8.git2.fc8 seems to work better for me: > > nm-applet seems to work (except it still is initially displayed with > > the red 'x'), I can select a WPA network and enter hex key generated > > by wpa_passphrase, the right 'stuff' gets stored in my keyring, etc. > > Got that one a few minutes ago, and it doesn't fix the issue for me. > > > > > My Thinkpad X60 also has iwl3945, so I'm not sure what is different > > (do your networks broadcast their SSIDs?) > > No, the one I'm at now does not broadcast. > > I'll take the machine home today and try with a broadcast SSID. At home, I see my WPA-encrypted, broadcast-SSID router in the pull-down menu. When I select it, I get prompted for a password/passphrase with no way to choose the encryption format. The Connect button is grayed out. Entering my passphrase (or indeed, any string of any length) never activates the connect button. As an aside, the second time I pop up the password dialog box, it is a tiny icon with no ability to see anything or change the size. The only way to restore the box to its full size is to restart nm-applet. "Connect to other..." and "Create new..." are still grayed out. > > > > > I can alternate between wired and wireless without issue. > > > > Great progress! > > > > One issue: 'Connect to other wireless network' and 'Create new > > wireless network' menu items are grayed out. I'm guessing that will > > make it hard to connect to networks that don't broadcast SSIDs. > > Yes, this is exactly my issue. The machine is unusable for me at work > if this isn't functional. I guess NetworkManager will work with unencrypted WAPs. It may work with WEP WAPs. system-config-network works fine with WEP, but doesn't support WPA. Have not tried wpa_supplicant. Does anyone know of a step-by-step, quick-start HOWTO for wpa_supplicant? > > > > > > tom -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jkeating at redhat.com Fri Sep 28 21:31:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 17:31:34 -0400 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> Message-ID: <20070928173134.784e3918@redhat.com> On Fri, 28 Sep 2007 23:19:38 +0200 "Micha? Bentkowski" wrote: > So my question is: why x86_64 and ppc live CDs are greater than CDs? > How can users burn them? Are we doing anything to make these images > smaller? Because they aren't Live "CDs" nor are they advertised as such. They're Live Images, to be used on whatever medium will hold them, such as USB Keys, virtualization, DVDs, etc.. Due to ppc and x86_64 being multilib, they have not only larger binaries but also compatible arch content and thus they are larger. Fitting onto a CD is a continuously losing game. You only ever decrease functionality when trying to fit. The i386 images (which will work on x86_64 hardware) will fit on a CD. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Sep 28 21:33:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 28 Sep 2007 17:33:04 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191014980.12995.14.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> Message-ID: <20070928173304.1de4fdeb@redhat.com> On Fri, 28 Sep 2007 17:29:40 -0400 Matthew Saltzman wrote: > At home, I see my WPA-encrypted, broadcast-SSID router in the > pull-down menu. When I select it, I get prompted for a > password/passphrase with no way to choose the encryption format. The > Connect button is grayed out. Entering my passphrase (or indeed, any > string of any length) never activates the connect button. Right now, all input must be in HEX form. wpa_passphrase should help here. Yes, this should be fixed in the next build. > > As an aside, the second time I pop up the password dialog box, it is a > tiny icon with no ability to see anything or change the size. The > only way to restore the box to its full size is to restart nm-applet. This is known, not sure if there is an imminent fix forthcoming. > > "Connect to other..." and "Create new..." are still grayed out. The UI for those is as of yet unwritten. We hope to have it done by F8 final, but they won't make the test3 cut. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Fri Sep 28 21:33:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 17:33:34 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070928173304.1de4fdeb@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <20070928173304.1de4fdeb@redhat.com> Message-ID: <1191015214.4413.3.camel@localhost.localdomain> On Fri, 2007-09-28 at 17:33 -0400, Jesse Keating wrote: > > As an aside, the second time I pop up the password dialog box, it is a > > tiny icon with no ability to see anything or change the size. The > > only way to restore the box to its full size is to restart nm-applet. > > This is known, not sure if there is an imminent fix forthcoming. Also will be fixed in the next build Jeremy From tcallawa at redhat.com Fri Sep 28 21:36:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 28 Sep 2007 17:36:23 -0400 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <20070928173134.784e3918@redhat.com> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> <20070928173134.784e3918@redhat.com> Message-ID: <1191015383.3553.59.camel@localhost.localdomain> On Fri, 2007-09-28 at 17:31 -0400, Jesse Keating wrote: > On Fri, 28 Sep 2007 23:19:38 +0200 > "Micha? Bentkowski" wrote: > > > So my question is: why x86_64 and ppc live CDs are greater than CDs? > > How can users burn them? Are we doing anything to make these images > > smaller? > > Because they aren't Live "CDs" nor are they advertised as such. > They're Live Images, to be used on whatever medium will hold them, such > as USB Keys, virtualization, DVDs, etc.. > > Due to ppc and x86_64 being multilib, they have not only larger > binaries but also compatible arch content and thus they are larger. > Fitting onto a CD is a continuously losing game. You only ever > decrease functionality when trying to fit. The i386 images (which will > work on x86_64 hardware) will fit on a CD. Have we considered not enabling multilib content on the LiveCD? (presumably, if someone really wanted it, they could get it in the post install process) ~spot From mjs at CLEMSON.EDU Fri Sep 28 21:39:23 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 17:39:23 -0400 Subject: Experiences with F8T2 on Thinkpad T61 In-Reply-To: <1190647285.3418.2.camel@localhost.localdomain> References: <1190410702.5762.26.camel@valkyrie.localdomain> <1190647285.3418.2.camel@localhost.localdomain> Message-ID: <1191015563.12995.21.camel@vincent52.localdomain> On Mon, 2007-09-24 at 11:21 -0400, Adam Jackson wrote: > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote: > > My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64 > > live dvd and installed the x86_64 DVD. This message covers > > platform-specific issues that I encountered. > > > > Live DVD: > > > > - The DVD won't boot into X. If I boot to runlevel 3 and attempt to > > system-config-display, there are two problems. > > > > (1) The Monitor section of xorg.conf is missing. > > (2) The nv driver hangs with a black screen. The keyboard is still > > functional and I can reboot with -- --. > > > > Hand-editing xorg.conf to create a Monitor section and using the vesa > > driver restores X functionality. > > An X log from the failed nv startup would be helpful here. https://bugzilla.redhat.com/show_bug.cgi?id=249367 > > > - X server doesn't terminate on logout--I have to -- to > > kill it. > > This was a bug I inflicted with a particular libICE/libSM combination. > It should be fixed now, I hope. Seems to be. > > > - Suspend doesn't work at all. Select Suspend from the power applet and > > the machine starts to suspend, the light comes on, then the light goes > > off and the machine is live, except that the display is black. I can > > reboot as above. > > As always, suspend on nv graphics chips is a disaster. Indeed. This is and wireless are the most important things for me to get working. What's the best way to help debug. What component should I bugzilla? Of course, WinXP has it working, so we know it can be done. It's just a question of how... (I don't mean for this to imply anything about relative quality of Linux and Windows or Linux and Windows developers. I just want this new machine to work. I know all about Linux's lag on new hardware--just trying to help as best I can to push it along.) > > - ajax > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From selinux at gmail.com Fri Sep 28 21:41:02 2007 From: selinux at gmail.com (Tom London) Date: Fri, 28 Sep 2007 14:41:02 -0700 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191014980.12995.14.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> Message-ID: <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> On 9/28/07, Matthew Saltzman wrote: > > I guess NetworkManager will work with unencrypted WAPs. It may work > with WEP WAPs. system-config-network works fine with WEP, but doesn't > support WPA. Have not tried wpa_supplicant. Does anyone know of a > step-by-step, quick-start HOWTO for wpa_supplicant? > I have it running with 'visible SSID' WPA. Requires 'converting' your passphrase into the derived hex key: 1. run '/usr/sbin/wpa_passphrase ', substituting your WPA ssid/passphrase. 2. select and copy the part of the output showing the hex key. 3. When you select the WPA network in NM, paste the hex key. The enter button should be enabled. 4. It should then ask about your keyring passphrase. If you enter it, you won't have to do the above again....;) Example: [root at localhost ~]# /usr/sbin/wpa_passphrase MY-SSID myPassPhrase network={ ssid="MY-SSID" #psk="myPassPhrase" psk=448ebab0a19b567dfe4089e5e92900932e4f1a7093f7a9fbf793ed43cbc95f57 } [root at localhost ~]# copy/paste text after 'psk=', etc. For 'wpa_supplicant', I found the man pages for wpa_supplicant.conf and wpa_supplicant useful. tom -- Tom London From sundaram at fedoraproject.org Fri Sep 28 21:39:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 03:09:06 +0530 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <1191015383.3553.59.camel@localhost.localdomain> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> <20070928173134.784e3918@redhat.com> <1191015383.3553.59.camel@localhost.localdomain> Message-ID: <46FD747A.5030602@fedoraproject.org> Tom "spot" Callaway wrote: > Have we considered not enabling multilib content on the LiveCD? > (presumably, if someone really wanted it, they could get it in the post > install process) It has been asked and refused before. I personally think a lot more people are wanting a Live CD even in their x86_64 boxes. I was told that everybody who has a x86_64 box would also have a DVD drive anyway but the number of people who have been asking for this seems to make that assumption ineffective. Rahul From johannbg at hi.is Fri Sep 28 21:49:00 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Fri, 28 Sep 2007 21:49:00 -0000 (GMT) Subject: Fedora spin from RpmFusion In-Reply-To: <46FD4DE1.8060904@redhat.com> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> Message-ID: <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> > J??hann B. Gu??mundsson wrote: >> For the record if people haven't noticed it yet playing by those >> Fedora restricted/bounded rules will never >> become interesting... >> >> Know variable == Known result == Boring.. > > > I agree, the most interesting spins will come from those people that > either live in other countries or give no regard to the laws and > regulations in which they live. People working outside of Fedora's > rules will be able to do whatever they want, including forking a version > of Fedora with full multimedia goodness. Mythdora anyone? I agree > those spins will be awesome.... but they won't be called Fedora. > Unfortunately what you are wanting to do can't be included into Fedora > proper. Having said that I (and I assume many others) look forward to > your spin, good luck. > > -Mike > Things settled once and for all.. With those word said. Is it an official statement from Red Hat/Fedora that proper media suppport and an option that could allow user to do so during install anaconda/firstboot ( disclaimer/user takes responsibility rpmfusion or other 3rd party repo setup for user and user can chose to install "questionable software" packages from there) inclusion or an chose for an user to setup, install or othewize an 3 party repository during installation that may contain questionable" software will never make it into Fedora/Red Hat unless changes in ( US )laws are made. ( And doesn't Red Hat/Fedora have to blacklist or prevent during installation that the name and paths of known 3 party repostory's from legal perspective otherwise they can be held countable? ) Users and developer can drop all discussion regarding this issue and ways to solve it. Leaving users and developers with these 3 options.. A. An addon cd that includes the prober media package. Users are left with the option to find and download an cd that contains the questionable software and can install from/off it B. User have to install/setup the 3 party respository after initial installation/setup. C. An respin with no affiliation with Red Hat/Fedora is made that include the "questionable packages and repos" and the user does not have to do any work from his half ( work out of the box solution ) Software that is/has been developed that can be misused to break "laws" tho it's initial creation and function of the software was never indented to do so will never be included in Red Hat/Fedora ( Even tho that package is gpl and source is made publicly available ) made available, in Red Hat/Fedora Just so things can be settled.. Best regards Johann B. From mmcgrath at redhat.com Fri Sep 28 21:46:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 16:46:07 -0500 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <46FD747A.5030602@fedoraproject.org> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> <20070928173134.784e3918@redhat.com> <1191015383.3553.59.camel@localhost.localdomain> <46FD747A.5030602@fedoraproject.org> Message-ID: <46FD761F.8080503@redhat.com> Rahul Sundaram wrote: > Tom "spot" Callaway wrote: > >> Have we considered not enabling multilib content on the LiveCD? >> (presumably, if someone really wanted it, they could get it in the post >> install process) > > It has been asked and refused before. I personally think a lot more > people are wanting a Live CD even in their x86_64 boxes. I was told > that everybody who has a x86_64 box would also have a DVD drive > anyway but the number of people who have been asking for this seems to > make that assumption ineffective. Do I detect a respin? Seriously though I don't see any reason why we don't carry a live CD. People just getting into Linux don't use new boxes anyway, they use some spare box (at least I did). -Mike From alan at redhat.com Fri Sep 28 21:58:17 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 28 Sep 2007 17:58:17 -0400 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <46FD747A.5030602@fedoraproject.org> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> <20070928173134.784e3918@redhat.com> <1191015383.3553.59.camel@localhost.localdomain> <46FD747A.5030602@fedoraproject.org> Message-ID: <20070928215817.GD2404@devserv.devel.redhat.com> On Sat, Sep 29, 2007 at 03:09:06AM +0530, Rahul Sundaram wrote: > everybody who has a x86_64 box would also have a DVD drive anyway but > the number of people who have been asking for this seems to make that > assumption ineffective. You still get laptops with 64bit and without DVD drives but with CD-RW. When the thinkpad exploded thats exactly what I got. So this isn't even an "old machine" issue - its true now, today and it is causing people to switch or pick other distributions in the confusion (they LiveCD CD install needs explaining too and I firmly believe we should go back to rolling a CD set) From mjs at CLEMSON.EDU Fri Sep 28 22:04:41 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 18:04:41 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070928173304.1de4fdeb@redhat.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070926190603.GA2999@jadzia.bu.edu> <20070926151941.6fb844df@redhat.com> <4c4ba1530709261231g760b6ce2k391ef689b1180052@mail.gmail.com> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <20070928173304.1de4fdeb@redhat.com> Message-ID: <1191017081.12995.25.camel@vincent52.localdomain> On Fri, 2007-09-28 at 17:33 -0400, Jesse Keating wrote: > On Fri, 28 Sep 2007 17:29:40 -0400 > Matthew Saltzman wrote: > > > At home, I see my WPA-encrypted, broadcast-SSID router in the > > pull-down menu. When I select it, I get prompted for a > > password/passphrase with no way to choose the encryption format. The > > Connect button is grayed out. Entering my passphrase (or indeed, any > > string of any length) never activates the connect button. > > Right now, all input must be in HEX form. wpa_passphrase > should help here. Yes, this should be fixed in the next > build. > > > > > As an aside, the second time I pop up the password dialog box, it is a > > tiny icon with no ability to see anything or change the size. The > > only way to restore the box to its full size is to restart nm-applet. > > This is known, not sure if there is an imminent fix forthcoming. > > > > > "Connect to other..." and "Create new..." are still grayed out. > > The UI for those is as of yet unwritten. We hope to have it done by F8 > final, but they won't make the test3 cut. This explains a lot, thanks. If this last feature is not ready for F8, will you ship with unfinished 0.7 or drop back to 0.6.5? -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sundaram at fedoraproject.org Fri Sep 28 22:00:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 03:30:11 +0530 Subject: Fedora Live CD unwritable on CDs In-Reply-To: <20070928215817.GD2404@devserv.devel.redhat.com> References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> <20070928173134.784e3918@redhat.com> <1191015383.3553.59.camel@localhost.localdomain> <46FD747A.5030602@fedoraproject.org> <20070928215817.GD2404@devserv.devel.redhat.com> Message-ID: <46FD796B.1040605@fedoraproject.org> Alan Cox wrote: > On Sat, Sep 29, 2007 at 03:09:06AM +0530, Rahul Sundaram wrote: >> everybody who has a x86_64 box would also have a DVD drive anyway but >> the number of people who have been asking for this seems to make that >> assumption ineffective. > > You still get laptops with 64bit and without DVD drives but with CD-RW. When > the thinkpad exploded thats exactly what I got. So this isn't even an > "old machine" issue - its true now, today and it is causing people to switch > or pick other distributions in the confusion (they LiveCD CD install needs > explaining too and I firmly believe we should go back to rolling a CD set) The confusion part is very true. You can just go back read the months of discussions in fedora-list after Fedora 7 release to realize that but I don't think anybody making the decision is even subscribed to the user list or watching the forums which helps in sticking to the flawed assumption. Either drop multilib by default or reduce the size of x86 image even further so that x86_64 even with multilib will fit into a CD (without overburn or anything fancy). Rahul From email.ahmedkamal at googlemail.com Fri Sep 28 22:09:33 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 29 Sep 2007 00:09:33 +0200 Subject: i810switch -> xrandr for F8 In-Reply-To: <645d17210709281234p6398e152x5fef5554ed9a5b2d@mail.gmail.com> References: <20070928002343.GA12138@auslistsprd01.us.dell.com> <200709280807.57725.opensource@till.name> <645d17210709280246j70d6c3f2t77c524c1195acfd3@mail.gmail.com> <46FD5553.9010307@cora.nwra.com> <645d17210709281234p6398e152x5fef5554ed9a5b2d@mail.gmail.com> Message-ID: <3da3b5b40709281509w52c448b8k5dce2a3b2acb9d82@mail.gmail.com> For KDE there's krandrtray, not sure if it handles the new features though On 9/28/07, Jonathan Underwood wrote: > > On 28/09/2007, Orion Poplawski wrote: > > > > Is there an xrandr (KDE) applet to provide a nice GUI way of doing this? > > I don't know of one for KDE, but there is urandr for gnome: > > http://albertomilone.com/wordpress/?p=118 > https://code.launchpad.net/urandr > https://launchpad.net/urandr > > I have it running fine here on F7. > > -- > 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 lamont at gurulabs.com Fri Sep 28 22:09:15 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 16:09:15 -0600 Subject: Fedora spin from RpmFusion In-Reply-To: <1190998892.4279.9.camel@localhost.localdomain> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> <1190998892.4279.9.camel@localhost.localdomain> Message-ID: <20070928160915.3e4b47b0@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 13:01:32 -0400 Jeremy Katz wrote: > On Fri, 2007-09-28 at 10:56 -0600, Lamont Peterson wrote: > > On Fri, 28 Sep 2007 10:57:08 +0000 > > "J?hann B. Gu?mundsson" wrote: > > > > > We gonna start an Rpmfusion Fedora spin giving user > > > the much wanted/needed media support in Fedora. > > > > With yum based Anaconda, I can add any repos I want to at install > > time and then select a customized set of packages from all of > > them. This means that if you produce a CD/DVD that I can download > > and you put the proper repodata/ (and comps?) on the disc, then I > > can use it. > > Well, except that at that point during the install, we have the CD > mounted and so you can't unmount to swap CDs. True, and I had thought about that while writing my message and I probably should have mentioned it. Of course, I can't remember the last time I did a CD/DVD install for any of my machines. Gotta love PXE. :) > Changing that probably > means committing to partitioning changes sooner I not sure that it would. After all, yum can deal with swapping CDs and it will ask you for whichever one it wants next, which should also work for multiple-DVD installs as long as there isn't an assumption of how many discs a DVD can install can be. It is nice that it always asks for them in order, as I don't have to think about what disc is going to come next. Even still, I'm sure there would have to be a couple of things to deal with. Someone getting it put together and out there for testing would certainly help nail that down. :) > (currently, we delay > them until right before packages install unless you need early swap) > so that we can move the install image to the hard disk. And then > there may be a little bit of subtlety in ensuring that the ordering > of package installation ends up right. But it's mostly a matter of > someone sitting down, writing some code and doing some testing. > > > But why would you want to produce such an image? It would be out of > > date before the first person finished downloading it. It might > > work, as long as people do not include any live over-the-network > > updated or updates repos in their installs. So, I guess it would > > be useful when someone has a need to install in an isolated > > environment/network without Internet access. > > > > So, I'm not sure if it would be that useful or not. > > There are a lot of cases like the above where it is useful. Also > cases where people only have sporadic network access. Or slower > network access and get media from a friend. Or connect via something > more esoteric that anaconda doesn't support setting up. So there's > definitely value in doing the work Even more good examples. Thanks. :) - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/XuM+YBsl9wN1AkRAi7tAKCeh3anLqpSvesNnDTAeUEOUGKinACZARp6 pbNujXU04R03tX5/LzdMryg= =3q1i -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Fri Sep 28 22:14:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 03:44:24 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> Message-ID: <46FD7CC0.7050109@fedoraproject.org> J?hann B. Gu?mundsson wrote: (The following really has been asked and answered in numerous times before...) > Things settled once and for all.. > > With those word said. Is it an official statement from Red Hat/Fedora > that proper media suppport and an option that could allow user to do so > during install anaconda/firstboot ( disclaimer/user takes responsibility > rpmfusion or other 3rd party repo setup for user and user can chose to > install "questionable software" packages from there) inclusion or an chose > for an user to setup, install or othewize an 3 party repository during > installation that may contain questionable" software will never make it > into Fedora/Red Hat unless changes in ( US )laws are made. https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01036.html > ( And doesn't Red Hat/Fedora have to blacklist or prevent during > installation that the name and paths of known 3 party repostory's > from legal perspective otherwise they can be held countable? ) They won't be. The whole point of contributory infringement is that you are contributing to it. Allowing something is different from aiding it. > Leaving users and developers with these 3 options.. > > A. An addon cd that includes the prober media package. > > Users are left with the option to find and download an > cd that contains the questionable software and can install from/off it > > B. User have to install/setup the 3 party respository after initial > installation/setup. Anaconda has the ability to install software off a repository during installation time from Fedora Core 6 onwards. > C. An respin with no affiliation with Red Hat/Fedora is made that include > the "questionable packages and repos" and the user does not have to > do any work from his half ( work out of the box solution ) If this is done, it should be rebranded and not called Fedora. > Software that is/has been developed that can be misused to break "laws" > tho it's initial creation and function of the software was never indented > to do so will never be included in Red Hat/Fedora > ( Even tho that package is gpl and source is made publicly available ) > made available, in Red Hat/Fedora > > Just so things can be settled.. If the software is infringing patents, it cannot be included regardless of it's copyright license. Rahul From lamont at gurulabs.com Fri Sep 28 22:20:19 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 16:20:19 -0600 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> Message-ID: <20070928162019.7c85a93b@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 15:24:39 +0200 Krzysztof Halasa wrote: > "Nicolas Mailhot" writes: > > > Because /var/ mixes long-term and transient data, generic and > > implementation-specific stuff, local and global data, and makes > > backup stategies a PITA for everything but SOHO contexts. > > Non-SOHO, you back up everything you have on disk and you don't > think about every file and directory. You have to be able to restore > the system reliably and fast. You may consider excluding things like > /tmp and /var/cache but any re-installations or rebuilding of RPMS > databases etc. are not options. I'm sorry, but I am having a lot of difficulty resolving your statements here. The only thing I can think of is that you have "SOHO" v. "Non-SOHO" backwards, but even then it doesn't make complete sense to me either. Let's just go to an example. Bob runs IT for a large organization. The systems that Bob deals with are firmly in the category of "Enterprise-Grade." Bob has 10,000 server to backup. Each of Bob's servers has an average of, say, 30GB of stuff (everything on the disk added up together). Of that average of 30GB/server, only 4GB is not data the server manipulate. Or in other words, 4GB is OS, libraries, application code, etc. (of course, this number would be significantly higher for Bob's Windows server, but let's keep this scenario simple for now, shall we?). So, 10,000 times 4GB of stuff that's either the same on all those servers or otherwise doesn't need to be backed up because Bob can reinstall it by other means. Let's see that 40TB of data he'd be backing up if he followed your advice. Oh, and it would take *longer* to restore those systems. Now, let's get back to a bit of the real world here. In medium to large Enterprise environments, I've never met anyone who just backs it all up and restores it. The data has to be separated from the OS and apps. In the real world, I can do a kickstart install (or other automated install, depending on the system) in under 10 minutes for any server. Then, I only have to go to the slow-speed stuff for the data the box needs. Tape, even very fast tape, isn't fast. > > Good backup is expensive backup so bulk-var-backup is not scaling > > In case of general system failure, or major release update, you're > > better of without a lot of /var contents, because some stuff is > > easier to set up again than take the risk of restoring a rotten > > state > > Excuse me? Restoring from a good backup is the only option, if your > last backup is rotten then you take the previous one. He wasn't advocating that the quality of the backup wasn't important. What I got from it was that he's merely saying that *state* information may no longer be valid by the time one needs to restore from backup. > WRT /srv I personally rmdir /opt /*/opt /srv /media after a system > upgrade because I don't usually use them. Should a need arise, mkdir > and friends aren't that hard to type. That's your choice. Personally, I hate having /media/ used for removable media instead of /mnt/, but that's where udev rules are going to do things for me. On a server (without X), removing /media/ is probably just fine (i.e. not going to break things so much), but on a desktop/notebook/whatever, you'd probably tick someone off if they are expecting the udev mounting magic to "just work." > I think there are no more real problems in Fedora as people start > fixing "non-problems" instead. /var has been working fine for years > and I don't see any reason to break it now. I'm sorry, I must have missed the part of this thread where people were wanting to change things in order to break the system. If you truly feel that there are no more real problems in Fedora, then why are you even on this list? After all, this list is for development discussion. The very nature of its existence implies that we're not done yet. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/X4k+YBsl9wN1AkRAho5AKDDYSMCZy0vOh2YnWehAU4ew87n5wCfZ1E1 OZETvrIHZ25hj+4bwo9l2sc= =QFBT -----END PGP SIGNATURE----- From lamont at gurulabs.com Fri Sep 28 22:23:46 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 16:23:46 -0600 Subject: [RFC] /var versus /srv In-Reply-To: <1190985185.31942.6.camel@localhost6.localdomain6> References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <1190965360.5022.127.camel@home.alexander.bostrom.net> <1190981340.5022.135.camel@home.alexander.bostrom.net> <1190985185.31942.6.camel@localhost6.localdomain6> Message-ID: <20070928162346.23c450b3@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 07:13:05 -0600 Richi Plana wrote: > On Fri, 2007-09-28 at 14:09 +0200, Alexander Bostr?m wrote: > > fre 2007-09-28 klockan 12:41 +0200 skrev Benny Amorsen: > > > > > There's no reason to have the spurious lib there. > > > > The reasoning behind /srv/lib is that it's relatively unlikely to > > already be in use and it is similar in purpose and look to /usr/lib > > and /var/lib. Remember, you're adding structure to a directory that > > has previously been marked as open territory. Thread lightly. > > "lib" does not make any sense. It didn't for /var/lib/(www| > mysql|) and it certainly doesn't for /srv. Agreed. After all "lib" is short for "library", is it not? What does "library" have to do with, well, anything that's currently found under the /var/lib/ directory? > If collision avoidance is what you're interested in, name > it /srv/fedora[(-services)]/ or something. Personally, > I'm fine with anything. The sanity that administering and maintaining > systems that moving data to /srv brings is enough to satisfy me. > > As for ensuring that all the data that needs long-term storage be > moved from /var: I don't see how that could be hard, but it will be a > long, drawn-out process. Definitely worth the effort, though. Right. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/X7y+YBsl9wN1AkRAjIpAKCZSkVkOJaOJvwpeC982V38ie5OrACffdsf wrC8RVPMcVd7crUJeSlhhvU= =Rj74 -----END PGP SIGNATURE----- From mjs at CLEMSON.EDU Fri Sep 28 22:28:35 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 28 Sep 2007 18:28:35 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> Message-ID: <1191018515.12995.30.camel@vincent52.localdomain> On Fri, 2007-09-28 at 14:41 -0700, Tom London wrote: > On 9/28/07, Matthew Saltzman wrote: > > > > I guess NetworkManager will work with unencrypted WAPs. It may work > > with WEP WAPs. system-config-network works fine with WEP, but doesn't > > support WPA. Have not tried wpa_supplicant. Does anyone know of a > > step-by-step, quick-start HOWTO for wpa_supplicant? > > > I have it running with 'visible SSID' WPA. Requires 'converting' your > passphrase into the derived hex key: > > 1. run '/usr/sbin/wpa_passphrase ', substituting > your WPA ssid/passphrase. > 2. select and copy the part of the output showing the hex key. > 3. When you select the WPA network in NM, paste the hex key. The > enter button should be enabled. > 4. It should then ask about your keyring passphrase. If you enter it, > you won't have to do the above again....;) > > Example: > > [root at localhost ~]# /usr/sbin/wpa_passphrase MY-SSID myPassPhrase > network={ > ssid="MY-SSID" > #psk="myPassPhrase" > psk=448ebab0a19b567dfe4089e5e92900932e4f1a7093f7a9fbf793ed43cbc95f57 > } > [root at localhost ~]# > > copy/paste text after 'psk=', etc. > > For 'wpa_supplicant', I found the man pages for wpa_supplicant.conf > and wpa_supplicant useful. Got connected! Yay... Tried to create a VPNC connection, but the wizard just exits after I select the vpnc connection type (which is the only type offered at this point). Is that supposed to work yet? Thanks. > > tom -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dmc.fedora at filteredperception.org Fri Sep 28 22:36:52 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 17:36:52 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD7CC0.7050109@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> Message-ID: <46FD8204.4060008@filteredperception.org> Rahul Sundaram wrote: > >(The following really has been asked and answered in numerous times >before...) But technology and published legal guidelines change... >> C. An respin with no affiliation with Red Hat/Fedora is made that include >> the "questionable packages and repos" and the user does not have to >> do any work from his half ( work out of the box solution ) > > If this is done, it should be rebranded and not called Fedora. 'should' is one of those words... By my reading of the current trademark guidelines (before they disappeared from http://rhold.fedoraproject.org/About/legal/trademarks/guidelines/ it is totally possible (with a little initrd guru-dom) to repackage the fedora-8-livecd iso (other isos too, but I'll use this as an example), such that mp3 and rpmfusion(or other arbitrary repos) work 'out of the box'. Just make a new iso, that contains the old iso as is, with a new initrd and bootloader, that present the user with two choices- a) "boot the official unmodified fedora-8-live image" or b) "boot the official fedora-8-live image, patched with mp3 support and software repository configuration that the fedora organization does not support or condone in any way" > >> Software that is/has been developed that can be misused to break "laws" >> tho it's initial creation and function of the software was never indented >> to do so will never be included in Red Hat/Fedora >> ( Even tho that package is gpl and source is made publicly available ) >> made available, in Red Hat/Fedora >> >> Just so things can be settled.. > > If the software is infringing patents, it cannot be included regardless > of it's copyright license. Given that the fedora trademark guidelines allow the above (seriously they do, I was very surprised when I read them myself), and given that some individuals and organizations may live in different countries, or have lawyers that come to different conclusions about what laws their country permits, I think the above should make everyone happy. No, such software compositions as described above would not be hosted by fedora, but hey, that's what bittorrent is for... -dmc (P.S.- please rel-eng-team, keep the official livecd iso as far under 700M as possible, wink wink, nudge nudge...) From sundaram at fedoraproject.org Fri Sep 28 22:57:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 04:27:12 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD8204.4060008@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> Message-ID: <46FD86C8.1070309@fedoraproject.org> Douglas McClendon wrote: > Rahul Sundaram wrote: > > >> (The following really has been asked and answered in numerous times >> before...) > > > But technology and published legal guidelines change... Not every other week in this context. >>> C. An respin with no affiliation with Red Hat/Fedora is made that >>> include >>> the "questionable packages and repos" and the user does not have to >>> do any work from his half ( work out of the box solution ) >> >> If this is done, it should be rebranded and not called Fedora. > > > 'should' is one of those words... > > By my reading of the current trademark guidelines (before they > disappeared from > > http://rhold.fedoraproject.org/About/legal/trademarks/guidelines/ > > it is totally possible (with a little initrd guru-dom) to repackage the > fedora-8-livecd iso (other isos too, but I'll use this as an example), > such that mp3 and rpmfusion(or other arbitrary repos) work 'out of the > box'. I believe you are incorrect in this reading given everything I heard on this topic so far. Rahul From johannbg at hi.is Fri Sep 28 23:16:52 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Fri, 28 Sep 2007 23:16:52 -0000 (GMT) Subject: Fedora spin from RpmFusion In-Reply-To: <46FD7CC0.7050109@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> Message-ID: <24494.88.149.97.225.1191021412.squirrel@webmail.hi.is> > J?hann B. Gu?mundsson wrote: > > > (The following really has been asked and answered in numerous times > before...) > >> Things settled once and for all.. >> >> With those word said. Is it an official statement from Red Hat/Fedora >> that proper media suppport and an option that could allow user to do so >> during install anaconda/firstboot ( disclaimer/user takes responsibility >> rpmfusion or other 3rd party repo setup for user and user can chose to >> install "questionable software" packages from there) inclusion or an >> chose >> for an user to setup, install or othewize an 3 party repository during >> installation that may contain questionable" software will never make it >> into Fedora/Red Hat unless changes in ( US )laws are made. > > https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01036.html Can I assume that the same thing applies for CD's that would contain *extra packages* and respins? > >> ( And doesn't Red Hat/Fedora have to blacklist or prevent during >> installation that the name and paths of known 3 party repostory's >> from legal perspective otherwise they can be held countable? ) > > They won't be. The whole point of contributory infringement is that you > are contributing to it. Allowing something is different from aiding it. > Ok. >> Leaving users and developers with these 3 options.. >> >> A. An addon cd that includes the prober media package. >> >> Users are left with the option to find and download an >> cd that contains the questionable software and can install from/off >> it >> >> B. User have to install/setup the 3 party respository after initial >> installation/setup. > > Anaconda has the ability to install software off a repository during > installation time from Fedora Core 6 onwards. Somehow I totally missed that, any docs about this I can be redirected to So I can see test and try on noob user to do so, so I see how viable solution it is. we are talking about the first installation scene not after you reboot and go to "first boot" where you can do some additional things? Had noticed you could install extra packages setup repos and that from there.. > >> C. An respin with no affiliation with Red Hat/Fedora is made that >> include >> the "questionable packages and repos" and the user does not have to >> do any work from his half ( work out of the box solution ) > > If this is done, it should be rebranded and not called Fedora. Yes that has already been established many times.. ( and work being developed respins tools that will easy the work in doing so) . And also how many letters from Fedora name have to be remove so the naming is neutralized ( fedorians, eudora etc... ) > >> Software that is/has been developed that can be misused to break "laws" >> tho it's initial creation and function of the software was never >> indented >> to do so will never be included in Red Hat/Fedora >> ( Even tho that package is gpl and source is made publicly available ) >> made available, in Red Hat/Fedora >> >> Just so things can be settled.. > > If the software is infringing patents, it cannot be included regardless > of it's copyright license. And in the scenario where software is created and a year later less/more something is patent hence the software now breaks the patent what then? who's in right here the software or the patent? And if the source of the code is made available could not the patent holders read the source and close "infringing" part in their code that is if we are talking about code and it can be patent ( Yes my knowledge in this are equals to 0 or less, ignorance shining through :) some how my internal logic had made the assumption the same thing as in the rules and regulations that protect writers and their written work would apply to coders and their coded work as well ? > > Rahul > Best regards. Johann B. From johannbg at hi.is Fri Sep 28 23:32:06 2007 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Fri, 28 Sep 2007 23:32:06 -0000 (GMT) Subject: Fedora spin from RpmFusion In-Reply-To: <46FD8204.4060008@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> Message-ID: <24497.88.149.97.225.1191022326.squirrel@webmail.hi.is> > Rahul Sundaram wrote: > > >>(The following really has been asked and answered in numerous times >>before...) > > > But technology and published legal guidelines change... > > >>> C. An respin with no affiliation with Red Hat/Fedora is made that >>> include >>> the "questionable packages and repos" and the user does not have to >>> do any work from his half ( work out of the box solution ) >> >> If this is done, it should be rebranded and not called Fedora. > > > 'should' is one of those words... > > By my reading of the current trademark guidelines (before they > disappeared from > > http://rhold.fedoraproject.org/About/legal/trademarks/guidelines/ > > it is totally possible (with a little initrd guru-dom) to repackage the > fedora-8-livecd iso (other isos too, but I'll use this as an example), > such that mp3 and rpmfusion(or other arbitrary repos) work 'out of the > box'. > > Just make a new iso, that contains the old iso as is, with a new initrd > and bootloader, that present the user with two choices- > > a) "boot the official unmodified fedora-8-live image" > > or > > b) "boot the official fedora-8-live image, patched with mp3 support and > software repository configuration that the fedora organization does not > support or condone in any way" > Now that is an viable userfriendly solution if allowed :) > >> >>> Software that is/has been developed that can be misused to break "laws" >>> tho it's initial creation and function of the software was never >>> indented >>> to do so will never be included in Red Hat/Fedora >>> ( Even tho that package is gpl and source is made publicly available ) >>> made available, in Red Hat/Fedora >>> >>> Just so things can be settled.. >> >> If the software is infringing patents, it cannot be included regardless >> of it's copyright license. > > Given that the fedora trademark guidelines allow the above (seriously > they do, I was very surprised when I read them myself), and given that > some individuals and organizations may live in different countries, or > have lawyers that come to different conclusions about what laws their > country permits, I think the above should make everyone happy. IF allowed +1 > > No, such software compositions as described above would not be hosted by > fedora, but hey, that's what bittorrent is for... Is int use and hence bittorent becoming illegal now days even tho it's creater never for saw or at least "publicly addmited" to have seen it be misused and used to distribute illegal content ( guess the same thing goes with car manufactures and transporting and distributing drugs ) :) > > -dmc > Best regards Johann B. From sundaram at fedoraproject.org Fri Sep 28 23:31:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 05:01:20 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <24494.88.149.97.225.1191021412.squirrel@webmail.hi.is> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <24494.88.149.97.225.1191021412.squirrel@webmail.hi.is> Message-ID: <46FD8EC8.1010404@fedoraproject.org> J?hann B. Gu?mundsson wrote: >> J?hann B. Gu?mundsson wrote: >> >> >> (The following really has been asked and answered in numerous times >> before...) >> >>> Things settled once and for all.. >>> >>> With those word said. Is it an official statement from Red Hat/Fedora >>> that proper media suppport and an option that could allow user to do so >>> during install anaconda/firstboot ( disclaimer/user takes responsibility >>> rpmfusion or other 3rd party repo setup for user and user can chose to >>> install "questionable software" packages from there) inclusion or an >>> chose >>> for an user to setup, install or othewize an 3 party repository during >>> installation that may contain questionable" software will never make it >>> into Fedora/Red Hat unless changes in ( US )laws are made. >> https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01036.html > Can I assume that the same thing applies for CD's that would contain > *extra packages* and respins? I guess so. >> Anaconda has the ability to install software off a repository during >> installation time from Fedora Core 6 onwards. > Somehow I totally missed that, any docs about this I can be redirected to > So I can see test and try on noob user to do so, > so I see how viable solution it is. we are talking about the first > installation scene not after you reboot and go to "first boot" where you > can do some additional things? Had noticed you could install extra > packages setup repos and that from there.. Yes. This worked fine for me in Fedora Core 6. See http://fedoraproject.org/wiki/Tours/FedoraCore6/005_Install_Add_Repository > And also how many letters from Fedora name have to be remove so the naming > is neutralized ( fedorians, eudora etc... ) I am not sure there is a specific limit of words. You should have a name that cannot be confused with the main product so you would have explicitly clarify that what you are creating is not Fedora. I would note there already is derivate called Mythdora however. If you want to play safe, find a different name entirely while specifying somewhere that it is derived from Fedora. > And in the scenario where software is created and a year later less/more > something is patent hence the software now breaks the patent what then? > > who's in right here the software or the patent? If you developed your software first and you can demonstrate that to the patent office that is called prior art and will invalidate the patent. > And if the source of the code is made available could not the patent holders > read the source and close "infringing" part in their code that is if we > are talking about code and it can be patent ( Yes my knowledge in this are > equals to 0 or less, ignorance shining through :) some how my internal > logic had made the assumption the same thing as in the rules and > regulations that protect writers and their written work would apply to > coders and their coded work as well ? If you want to learn about software patents, there are plenty of good references online. Start with http://www.redhat.com/magazine/007may05/features/ip/ http://en.wikipedia.org/wiki/Software_patent Rahul From kevin.kofler at chello.at Fri Sep 28 23:55:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Sep 2007 23:55:42 +0000 (UTC) Subject: Fedora Live CD unwritable on CDs References: <668bb39a0709281419t3e0a08c8g72abb5a7c15ea5d9@mail.gmail.com> Message-ID: Micha? Bentkowski gmail.com> writes: > My friend noticed an oddity after trying to burn his > Fedora-7-Live-x86_64.iso. Its size is 779M and it was impossible to > write it on CD. Try a CD-R90 next time. It should fit. Kevin Kofler From khc at pm.waw.pl Sat Sep 29 00:22:40 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sat, 29 Sep 2007 02:22:40 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <20070928162019.7c85a93b@reaver.lamontpeterson.net> (Lamont Peterson's message of "Fri, 28 Sep 2007 16:20:19 -0600") References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> Message-ID: Lamont Peterson writes: > Let's just go to an example. > > Bob runs IT for a large organization. The systems that Bob deals with > are firmly in the category of "Enterprise-Grade." > > Bob has 10,000 server to backup. So anything non-SOHO means 10,000 servers and perhaps hundreds of thousands people. Ok, let it be. > Each of Bob's servers has an average of, say, 30GB of stuff (everything > on the disk added up together). > > Of that average of 30GB/server, only 4GB is not data the server manipulate. > Or in other words, 4GB is OS, libraries, application code, etc. (of > course, this number would be significantly higher for Bob's Windows > server, but let's keep this scenario simple for now, shall we?). IOW, 13.3% of your data is the OS. How about a bit larger systems? Like the one I have here with ca. 440 GB of data? 1% = the OS. It's still a small machine. I don't know about MS Windows. > So, 10,000 times 4GB of stuff that's either the same on all those servers > or otherwise doesn't need to be backed up because Bob can reinstall it > by other means. Let's see that 40TB of data he'd be backing up if he > followed your advice. 40 TB per 10,000 servers, with the whole backup size of 360 TB? Seems fair, don't you think? Assuming, of course, that you store all copies of identical files. BTW: are those 10,000 servers identical (WRT to the set of RPMs)? Why don't you use a master server and replicate? > Oh, and it would take *longer* to restore those systems. Assuming you would reinstall your OS using kickstart in no time :-) it would take just 13% longer. Or just <1% longer in another case. Now I'm not exactly sure about this "no time kickstart". And, after the install finishes, you do a "yum update", don't you? What if the installation, for example, keeps crashing for some reason till morning? > He wasn't advocating that the quality of the backup wasn't important. > What I got from it was that he's merely saying that *state* > information may no longer be valid by the time one needs to restore > from backup. Sure, but the fresh backup is still way better than a fresh install. > I'm sorry, I must have missed the part of this thread where people > were wanting to change things in order to break the system. Do you think moving things out of /var won't break anything? -- Krzysztof Halasa From katzj at redhat.com Sat Sep 29 00:32:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 20:32:42 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928160915.3e4b47b0@reaver.lamontpeterson.net> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> <1190998892.4279.9.camel@localhost.localdomain> <20070928160915.3e4b47b0@reaver.lamontpeterson.net> Message-ID: <1191025962.6487.4.camel@localhost.localdomain> On Fri, 2007-09-28 at 16:09 -0600, Lamont Peterson wrote: > On Fri, 28 Sep 2007 13:01:32 -0400 > Jeremy Katz wrote: > > Changing that probably means committing to partitioning changes sooner > > I not sure that it would. After all, yum can deal with swapping CDs and > it will ask you for whichever one it wants next, which should also work > for multiple-DVD installs as long as there isn't an assumption of how many > discs a DVD can install can be. The problem is that we have to mount and look at the additional CDs to get their metadata and know what packages are available there. And to do that, we have to transfer stage2 elsewhere. To RAM kind of sucks because it increases the memory requirements by the size of stage2 (~100M) in a case where we're going to need more memory for package metadata and dep solving. Hence, the hard drive, hence partitioning being committed sooner. Jeremy From katzj at redhat.com Sat Sep 29 00:35:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 20:35:34 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191018515.12995.30.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> Message-ID: <1191026134.6487.8.camel@localhost.localdomain> On Fri, 2007-09-28 at 18:28 -0400, Matthew Saltzman wrote: > Tried to create a VPNC connection, but the wizard just exits after I > select the vpnc connection type (which is the only type offered at this > point). Is that supposed to work yet? You need NetworkManager-vpnc from koji (not tagged for rawhide atm) plus a manual tweak. That's fixed in upstream svn, so a new build will take care of that problem. The other outstanding vpn problem is that you have to restart nm-applet for it to notice the new VPN connection. Working on that... Jeremy From khc at pm.waw.pl Sat Sep 29 00:49:41 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sat, 29 Sep 2007 02:49:41 +0200 Subject: [RFC] /var versus /srv In-Reply-To: (Krzysztof Halasa's message of "Sat, 29 Sep 2007 02:22:40 +0200") References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> Message-ID: Krzysztof Halasa writes: > Assuming you would reinstall your OS using kickstart in no time :-) > it would take just 13% longer. Of course I meant 13/87*100% = ~ 15% longer. -- Krzysztof Halasa From lamont at gurulabs.com Sat Sep 29 01:19:33 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 19:19:33 -0600 Subject: Fedora spin from RpmFusion In-Reply-To: <1191025962.6487.4.camel@localhost.localdomain> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> <1190998892.4279.9.camel@localhost.localdomain> <20070928160915.3e4b47b0@reaver.lamontpeterson.net> <1191025962.6487.4.camel@localhost.localdomain> Message-ID: <20070928191933.2c0e9fad@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 20:32:42 -0400 Jeremy Katz wrote: > On Fri, 2007-09-28 at 16:09 -0600, Lamont Peterson wrote: > > On Fri, 28 Sep 2007 13:01:32 -0400 > > Jeremy Katz wrote: > > > Changing that probably means committing to partitioning changes > > > sooner > > > > I not sure that it would. After all, yum can deal with swapping > > CDs and it will ask you for whichever one it wants next, which > > should also work for multiple-DVD installs as long as there isn't > > an assumption of how many discs a DVD can install can be. > > The problem is that we have to mount and look at the additional CDs to > get their metadata and know what packages are available there. And to > do that, we have to transfer stage2 elsewhere. To RAM kind of sucks > because it increases the memory requirements by the size of stage2 > (~100M) in a case where we're going to need more memory for package > metadata and dep solving. Hence, the hard drive, hence partitioning > being committed sooner. So, even if it's another 200MB of RAM, is there anything wrong with saying, "If you want to include 'add-on' discs, you need to have X amount of RAM minimum to do the install." ?? After all, I only have 2 machines with less than a GB of RAM anymore (and I wouldn't do add-on discs with those, anyway). - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/agl+YBsl9wN1AkRAl4BAJ4qed1aTylaS89/LxO5PTMbPPLRSgCgn/ti iNeTTL5oziV3BduoaUKp1/4= =VeTK -----END PGP SIGNATURE----- From katzj at redhat.com Sat Sep 29 01:21:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 28 Sep 2007 21:21:10 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <20070928191933.2c0e9fad@reaver.lamontpeterson.net> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> <1190998892.4279.9.camel@localhost.localdomain> <20070928160915.3e4b47b0@reaver.lamontpeterson.net> <1191025962.6487.4.camel@localhost.localdomain> <20070928191933.2c0e9fad@reaver.lamontpeterson.net> Message-ID: <1191028870.6487.12.camel@localhost.localdomain> On Fri, 2007-09-28 at 19:19 -0600, Lamont Peterson wrote: > So, even if it's another 200MB of RAM, is there anything wrong with saying, > "If you want to include 'add-on' discs, you need to have X amount of RAM > minimum to do the install." ?? After all, I only have 2 machines with less > than a GB of RAM anymore (and I wouldn't do add-on discs with those, anyway). The people most likely to want to use add-on discs are the same ones that _don't_ have over a gig of RAM in every machine they use. Jeremy From dmc.fedora at filteredperception.org Sat Sep 29 01:19:15 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 20:19:15 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD86C8.1070309@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> Message-ID: <46FDA813.9010104@filteredperception.org> Rahul Sundaram wrote: > Douglas McClendon wrote: >> Rahul Sundaram wrote: >> > >>> (The following really has been asked and answered in numerous times >>> before...) >> >> >> But technology and published legal guidelines change... > > Not every other week in this context. > >>>> C. An respin with no affiliation with Red Hat/Fedora is made that >>>> include >>>> the "questionable packages and repos" and the user does not have to >>>> do any work from his half ( work out of the box solution ) >>> >>> If this is done, it should be rebranded and not called Fedora. >> >> >> 'should' is one of those words... >> >> By my reading of the current trademark guidelines (before they >> disappeared from >> >> http://rhold.fedoraproject.org/About/legal/trademarks/guidelines/ >> >> it is totally possible (with a little initrd guru-dom) to repackage >> the fedora-8-livecd iso (other isos too, but I'll use this as an >> example), such that mp3 and rpmfusion(or other arbitrary repos) work >> 'out of the box'. [unsnip] Just make a new iso, that contains the old iso as is, with a new initrd and bootloader, that present the user with two choices- a) "boot the official unmodified fedora-8-live image" or b) "boot the official fedora-8-live image, patched with mp3 support and software repository configuration that the fedora organization does not support or condone in any way" [/unsnip] > I believe you are incorrect in this reading given everything I heard on > this topic so far. > > Rahul Ok, thanks to MikeMC, I can defend my position from http://fedoraproject.org/legal/trademarks/guidelines/page5.html " Shipping Fedora? code unmodified from the original download with separate patches that may be applied by the end user at his/her discretion is not a modification of the original code, provided: 1. The original Fedora? code is intact and identifiable at the time of installation and on the media on which the code is delivered; 2. The patches are provided independent of the original Fedora? code and are identifiable on the media on which the code is delivered; 3. The end user is given the discretion as to whether to install the patches; and 4. Any marketing materials related to such a distribution make clear that the vendor is providing patches which, if installed by the user, will modify the Fedora? code from its original form. " Please tell me how my above thoeretical repackaging of fedora does not fall into this *very* explicitly permitted scenario. -dmc From mmcgrath at redhat.com Sat Sep 29 01:22:36 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 28 Sep 2007 20:22:36 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD8204.4060008@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> Message-ID: <46FDA8DC.6000408@redhat.com> Douglas McClendon wrote: > Rahul Sundaram wrote: > > >> (The following really has been asked and answered in numerous times >> before...) > > > But technology and published legal guidelines change... > > >>> C. An respin with no affiliation with Red Hat/Fedora is made that >>> include >>> the "questionable packages and repos" and the user does not have to >>> do any work from his half ( work out of the box solution ) >> >> If this is done, it should be rebranded and not called Fedora. > > > 'should' is one of those words... > > By my reading of the current trademark guidelines (before they > disappeared from > > http://rhold.fedoraproject.org/About/legal/trademarks/guidelines/ > This now exists here though I don't know who maintains it or if it is accurate. Can anyone clarify? http://fedoraproject.org/legal/trademarks/guidelines/ -Mike From lamont at gurulabs.com Sat Sep 29 01:41:33 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 28 Sep 2007 19:41:33 -0600 Subject: Fedora spin from RpmFusion In-Reply-To: <1191028870.6487.12.camel@localhost.localdomain> References: <46FCDE04.6040007@hi.is> <20070928105633.3e1a7885@reaver.lamontpeterson.net> <1190998892.4279.9.camel@localhost.localdomain> <20070928160915.3e4b47b0@reaver.lamontpeterson.net> <1191025962.6487.4.camel@localhost.localdomain> <20070928191933.2c0e9fad@reaver.lamontpeterson.net> <1191028870.6487.12.camel@localhost.localdomain> Message-ID: <20070928194133.1d14b5ec@reaver.lamontpeterson.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Sep 2007 21:21:10 -0400 Jeremy Katz wrote: > On Fri, 2007-09-28 at 19:19 -0600, Lamont Peterson wrote: > > So, even if it's another 200MB of RAM, is there anything wrong with > > saying, "If you want to include 'add-on' discs, you need to have X > > amount of RAM minimum to do the install." ?? After all, I only > > have 2 machines with less than a GB of RAM anymore (and I wouldn't > > do add-on discs with those, anyway). > > The people most likely to want to use add-on discs are the same ones > that _don't_ have over a gig of RAM in every machine they use. Touche'. - -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/a1N+YBsl9wN1AkRAtZmAJ9RyFgRnWOjcS9zQMdqzzOzcO/M8ACgmZpg yEmMC7GfaahgAbTXl/ZnrSA= =e3CL -----END PGP SIGNATURE----- From notting at redhat.com Sat Sep 29 01:50:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 28 Sep 2007 21:50:07 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FD4CBF.2080800@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD4CBF.2080800@filteredperception.org> Message-ID: <20070929015007.GC4903@nostromo.devel.redhat.com> Douglas McClendon (dmc.fedora at filteredperception.org) said: > http://fedoraproject.org/wiki/Legal/TrademarkGuidelines Links fixed. Bill From sundaram at fedoraproject.org Sat Sep 29 01:48:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 07:18:48 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDA813.9010104@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> Message-ID: <46FDAF00.3040303@fedoraproject.org> Douglas McClendon wrote: > " > > Please tell me how my above thoeretical repackaging of fedora does not > fall into this *very* explicitly permitted scenario. The permissions listed was done IIRC to OEM's to do post install modifications such as ship a optional repository of software. The guidelines are a living document and written to state the Fedora Project's position on various things. If they are exploited to do things, Fedora Project does not endorse, they can and will be modified to not permit those activities. IMO, modifying Fedora to offer Free software with patent restrictions or non-free software is one of those things, Fedora does not want to provide its brand towards for protecting the project goals as well as to avoid legal liability. Maybe spot (CC'ed) can look into why these permissions were provided in the first place. Rahul From cra at WPI.EDU Sat Sep 29 02:35:51 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 28 Sep 2007 22:35:51 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070927202009.GR6066@angus.ind.WPI.EDU> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> <20070927202009.GR6066@angus.ind.WPI.EDU> Message-ID: <20070929023551.GB20031@angus.ind.WPI.EDU> On Thu, Sep 27, 2007 at 04:20:09PM -0400, Chuck Anderson wrote: > On Thu, Sep 27, 2007 at 04:10:36PM -0400, Matthew Miller wrote: > > On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote: > > > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has > > > gone away. I can use it to connect to wireless networks again without > > > a lot of service restarting. > > > > Yeah, works for me too. > > Not working here. I use the ath5k driver and it scans and find > wireless networks, but when I click on them (WPA/WPA2 Enterprise > required) nothing happens--no pop up, no dialog asking for certificate > files, nothing. Ok, so I tried on an open wireless network. It seems to connect but then fails to DHCP (timeout). If I disable NM completely and run iwconfig/dhclient manually, everything works. From dmc.fedora at filteredperception.org Sat Sep 29 02:33:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 21:33:25 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDAF00.3040303@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> Message-ID: <46FDB975.6020209@filteredperception.org> Rahul Sundaram wrote: > Douglas McClendon wrote: > >> " >> >> Please tell me how my above thoeretical repackaging of fedora does not >> fall into this *very* explicitly permitted scenario. > > The permissions listed was done IIRC to OEM's to do post install > modifications such as ship a optional repository of software. The > guidelines are a living document and written to state the Fedora > Project's position on various things. If they are exploited to do > things, Fedora Project does not endorse, they can and will be modified > to not permit those activities. > > IMO, modifying Fedora to offer Free software with patent restrictions or ^^^^^^^^^^^^^^^^ I don't think you fully understood what I was describing, or the specific permissions involved. I was not talking about modifying one single bit of fedora, but rather packaging it with other software which fedora has no desire in auditing either the quality, or legality of. Likewise, the specific fedora legal guidelines I quoted, went to great lengths to create this exception and definition of what constitutes "non-modified fedora" and under what circumstances it is acceptable to redistribute it. Key Here- 'the fedora software', i.e. a 690M(fingers crossed) LiveOS iso image with a specific sha1sum, remains intact and unmodified. It is merely distributed in combination on media with additional software, fully adhering to the 4 conditions set forth in the legal guidelines. Remember, those guidelines were put in place presumably so that OEMs could ship software of any quality (i.e. maybe it eats half your hard drive every other install), in a way that integrates that software with fedora, but also in a way which keeps 'pure fedora' 'pure'. Whether the software addon is buggy crap that corrupts filesystems, or whether it is not legal in some countries, is really beside the point of diluting or poisoning the brand. (or rather, again, the guidelines are what puts up a firewall that is deemed acceptable for protecting the brand from _any_ arbitrarily 'bad' software/patches). Cheers, -dmc > non-free software is one of those things, Fedora does not want to > provide its brand towards for protecting the project goals as well as to > avoid legal liability. Maybe spot (CC'ed) can look into why these > permissions were provided in the first place. > > Rahul > From sundaram at fedoraproject.org Sat Sep 29 02:49:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 08:19:59 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDB975.6020209@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> Message-ID: <46FDBD57.6090409@fedoraproject.org> Douglas McClendon wrote: > Rahul Sundaram wrote: >> Douglas McClendon wrote: >> >>> " >>> >>> Please tell me how my above thoeretical repackaging of fedora does >>> not fall into this *very* explicitly permitted scenario. >> >> The permissions listed was done IIRC to OEM's to do post install >> modifications such as ship a optional repository of software. The >> guidelines are a living document and written to state the Fedora >> Project's position on various things. If they are exploited to do >> things, Fedora Project does not endorse, they can and will be modified >> to not permit those activities. >> >> IMO, modifying Fedora to offer Free software with patent restrictions or > ^^^^^^^^^^^^^^^^ > > I don't think you fully understood what I was describing, or the > specific permissions involved. I meant modification is a broader sense and not just patching some specific software. At any rate, the guidelines must reflect project goals and not vice versa. What you want to do IMO definitely falls outside the scope of the project and must not retain the Fedora name. Now it is upto to Fedora Project Board and Red Hat legal to determine what's acceptable. Let's leave it at that. Rahul From notting at redhat.com Sat Sep 29 02:56:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 28 Sep 2007 22:56:29 -0400 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDBD57.6090409@fedoraproject.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> Message-ID: <20070929025629.GA32005@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: >> I don't think you fully understood what I was describing, or the >> specific permissions involved. > > I meant modification is a broader sense and not just patching some specific > software. At any rate, the guidelines must reflect project goals and not > vice versa. What you want to do IMO definitely falls outside the scope of > the project and must not retain the Fedora name. Now it is upto to Fedora > Project Board and Red Hat legal to determine what's acceptable. Let's leave > it at that. The guidelines were specifically designed so that someone could ship stock Fedora and an additional repository of vendor packages, whether it be Dell addons, Creative Commons content or whatever. If those guidelines are followed, then, without actually changing the guidelines, it doesn't really matter what that content/packages are. Bill From sundaram at fedoraproject.org Sat Sep 29 03:00:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 08:30:14 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <20070929025629.GA32005@nostromo.devel.redhat.com> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> Message-ID: <46FDBFBE.9050708@fedoraproject.org> Bill Nottingham wrote: > The guidelines were specifically designed so that someone could ship > stock Fedora and an additional repository of vendor packages, whether > it be Dell addons, Creative Commons content or whatever. > > If those guidelines are followed, then, without actually changing the > guidelines, it doesn't really matter what that content/packages are. That is indeed my implicit question. Do you still want vendors to ship software not included in Fedora and still call it Fedora? Is it ok for anyone and everyone to do so with any set of software? Does the current trademark guidelines match the goals of the project? Rahul From dmc.fedora at filteredperception.org Sat Sep 29 02:59:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 28 Sep 2007 21:59:55 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDBD57.6090409@fedoraproject.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> Message-ID: <46FDBFAB.50109@filteredperception.org> Rahul Sundaram wrote: > Douglas McClendon wrote: >> Rahul Sundaram wrote: >>> Douglas McClendon wrote: >>> >>>> " >>>> >>>> Please tell me how my above thoeretical repackaging of fedora does >>>> not fall into this *very* explicitly permitted scenario. >>> >>> The permissions listed was done IIRC to OEM's to do post install >>> modifications such as ship a optional repository of software. The >>> guidelines are a living document and written to state the Fedora >>> Project's position on various things. If they are exploited to do >>> things, Fedora Project does not endorse, they can and will be >>> modified to not permit those activities. >>> >>> IMO, modifying Fedora to offer Free software with patent restrictions or >> ^^^^^^^^^^^^^^^^ >> >> I don't think you fully understood what I was describing, or the >> specific permissions involved. > > I meant modification is a broader sense and not just patching some > specific software. At any rate, the guidelines must reflect project > goals and not vice versa. What you want to do IMO definitely falls > outside the scope of the project and must not retain the Fedora name. > Now it is upto to Fedora Project Board and Red Hat legal to determine > what's acceptable. Let's leave it at that. I think you are trying to control things that are beyond the scope of the project. I was not advocating any action on the part of the fedora project, I was merely describing what I believed to be legally allowable for any individual to do, in a manner completely detached from the fedora project. Believe me, if this was something I wanted to personally do, I'd have done it, and not bothered discussing it here. Certainly it is up the Board and RHLegal to modify existing published documents as they see fit. But I am trying to persuade _you_ Rahul. I'm trying to persuade you that these permissions are a good thing, and you needn't and shouldn't lobby for them to change to 'protect fedora'. I think the guidelines as they stand were well thought out in the first place, with the intent of 'protecting fedora', and that changing them will serve no useful purpose, other than demonstrating that the fedora project has some control issues on par with GPLv3 (yes, I'm trying to be both serious and humorous as the same time ;) Please, just accept that what I described is a perfectly valid *use*(!=modification) of fedora, and that the fedora project gains nothing by changing its well laid foundations to prevent further similar *uses* of fedora in the future. Cheers, -dmc From sundaram at fedoraproject.org Sat Sep 29 03:08:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 29 Sep 2007 08:38:05 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDBFAB.50109@filteredperception.org> References: <46FCDE04.6040007@hi.is> <20070928072319.35e126c3@redhat.com> <46FD02E8.7040200@hi.is> <46FD11B7.3030200@redhat.com> <46FD42AF.70204@hi.is> <46FD449D.7090503@redhat.com> <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <46FDBFAB.50109@filteredperception.org> Message-ID: <46FDC195.7040004@fedoraproject.org> Douglas McClendon wrote: > > Please, just accept that what I described is a perfectly valid > *use*(!=modification) of fedora, and that the fedora project gains > nothing by changing its well laid foundations to prevent further similar > *uses* of fedora in the future. Personally, I am not sure what you are proposing is a perfectly valid use and what the legal implications of that are. It maybe that the technical possibility wasn't thought out when the guidelines were written or maybe the nature of the project has drifted off from when the guidelines were originally written. I think we might do well to make sure that those match. Rahul From tibbs at math.uh.edu Sat Sep 29 03:28:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Sep 2007 22:28:02 -0500 Subject: /etc/hosts and system entries In-Reply-To: <1191001927.3476.28.camel@hopeson> References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> <20070928110543.3f045c28@reaver.lamontpeterson.net> <1191001927.3476.28.camel@hopeson> Message-ID: >>>>> "SS" == Simo Sorce writes: SS> Try to do that on the KDC, the KDC does not listen on 127.0.0.1 SS> for some reason. Oddly, all of my KDCs have the hostname in /etc/hosts at 127.0.0.1 and I have had no issues. Really, I don't know what's supposed to break with kerberos in this case, because every single one of my hundreds of kerberos-using or -serving hosts have the hostname in /etc/hosts resolving to 127.0.0.1 and there are no issues with kerberos here. - J< From kevin.kofler at chello.at Sat Sep 29 04:19:14 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 29 Sep 2007 04:19:14 +0000 (UTC) Subject: Fedora spin from RpmFusion References: <46FCDE04.6040007@hi.is> Message-ID: J?hann B. Gu?mundsson hi.is> writes: > If naming/artwork is changed could we include the AMD and Nvidia drivers? Fedora naming is not your only worry if you want to do that. Non-GPL kernel modules are almost certainly a violation of the Linux kernel's GPL (version 2) license, especially when distributing them together with the kernel itself. I know some other distros get away with it, but that doesn't make it legal. If you want to know more about this issue, search the net, there have been numerous articles and flamewars written over that subject. Kevin Kofler From dcbw at redhat.com Sat Sep 29 04:46:29 2007 From: dcbw at redhat.com (Dan Williams) Date: Sat, 29 Sep 2007 00:46:29 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <20070927202009.GR6066@angus.ind.WPI.EDU> References: <1190823905.15397.16.camel@vincent52.localdomain> <20070927201036.GA21031@jadzia.bu.edu> <20070927202009.GR6066@angus.ind.WPI.EDU> Message-ID: <1191041189.9155.7.camel@xo-3E-67-34.localdomain> On Thu, 2007-09-27 at 16:20 -0400, Chuck Anderson wrote: > On Thu, Sep 27, 2007 at 04:10:36PM -0400, Matthew Miller wrote: > > On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote: > > > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has > > > gone away. I can use it to connect to wireless networks again without > > > a lot of service restarting. > > > > Yeah, works for me too. > > Not working here. I use the ath5k driver and it scans and find > wireless networks, but when I click on them (WPA/WPA2 Enterprise > required) nothing happens--no pop up, no dialog asking for certificate > files, nothing. ath5k is still pretty immature; it hasn't worked for me with wpa_supplicant/NM and only recently stopped hanging the machine on even a plain 'ifup' at boot time. I'll have a go at seeing whether or not this is an NM, wpa_supplicant, or driver problem. But just know that it may be rocky with ath5k for a while since it's still under really heavy development, about where mac80211 itself was this spring. dan From andy at smile.org.ua Sat Sep 29 05:22:12 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 29 Sep 2007 08:22:12 +0300 Subject: Is there documentation on how to package foreign language man page translations in a spec file. In-Reply-To: <46FCF95A.7080005@redhat.com> References: <46FCF95A.7080005@redhat.com> Message-ID: <20070929052212.GA6576@serv.smile.org.ua> Hi Daniel J Walsh! On Fri, Sep 28, 2007 at 08:53:46AM -0400, Daniel J Walsh wrote next: > I have some Russian translations of manpages for one of the libraries I > support, but I am not sure how to package them. Is it separate package? Or may be they are included in the corresponding packages (such as shadow-utils, f.e.). The russian man-pages-ru package already exists in the Fedora. If you have man pages that are addon to exists I think you could to send they to the upstream. P.S. Feel free to ask me for review content. I'm russian native speaker. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From fedora at leemhuis.info Sat Sep 29 06:32:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 29 Sep 2007 08:32:29 +0200 Subject: Fedora spin from RpmFusion In-Reply-To: References: <46FCDE04.6040007@hi.is> Message-ID: <46FDF17D.4040606@leemhuis.info> On 29.09.2007 06:19, Kevin Kofler wrote: > J?hann B. Gu?mundsson hi.is> writes: >> If naming/artwork is changed could we include the AMD and Nvidia drivers? > Fedora naming is not your only worry if you want to do that. Non-GPL kernel > modules are almost certainly a violation of the Linux kernel's GPL (version 2) > license, especially when distributing them together with the kernel itself. I > know some other distros get away with it, but that doesn't make it legal. If > you want to know more about this issue, search the net, there have been > numerous articles and flamewars written over that subject. +1 -- as I said on the rpmfusion list already some days ago, there is IMHO and AFAICS no way we can include the kernel part of the AMD or Nvidia drivers together with a potential rpmfusion spin. CU knurd From nicolas.mailhot at laposte.net Sat Sep 29 08:48:06 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 29 Sep 2007 10:48:06 +0200 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> Message-ID: <1191055686.7235.41.camel@rousalka.dyndns.org> Le samedi 29 septembre 2007 ? 02:22 +0200, Krzysztof Halasa a ?crit : > Lamont Peterson writes: > > > Let's just go to an example. > > > > Bob runs IT for a large organization. The systems that Bob deals with > > are firmly in the category of "Enterprise-Grade." > > > > Bob has 10,000 server to backup. > > So anything non-SOHO means 10,000 servers and perhaps hundreds > of thousands people. Ok, let it be. Anything non-SOHO is somewhere where you do automated regular backups via hardware you don't find in consumer PCs and is expensive enough you can't just backup everything. It starts at the cheap DLT auto-changer+amanda level > > Each of Bob's servers has an average of, say, 30GB of stuff (everything > > on the disk added up together). > > > > Of that average of 30GB/server, only 4GB is not data the server manipulate. > > Or in other words, 4GB is OS, libraries, application code, etc. (of > > course, this number would be significantly higher for Bob's Windows > > server, but let's keep this scenario simple for now, shall we?). > > IOW, 13.3% of your data is the OS. > How about a bit larger systems? Like the one I have here with > ca. 440 GB of data? 1% = the OS. It's still a small machine. Very often your critical data has not inflated like consumer OSes, so the trend goes the other way (increasing OS data weight). And you still have backup space constrains because many systems are connected to the same backup hardware. > [Several questions that show you've got absolutely no understanding of real-life enterprise contexts, and that I'll answer in one go] In real-life systems are not identical. They're supposed to be but perfection costs money, so they aren't. In case of system failure reinstalling from scratch is a way to heal a system which has bitrotten (or a system update that was planified in the next months is just done with the reinstall) An enterprise will have streamlined installation of its main OSes, using kickstart, mirroring or just plain paper procedure so "re-installation keeps crashing" is not a possibility. And anyway the problem is not you can save half an hour by restoring an OS backup but sysadmin availability - you don't pay a sysadmin per system, and you don't pay 24/24 7/7 care for every system. You're assuming every system connected to an enterprise backup system is critical and needs to be restored at once. It's not. Entreprises have big shared backup systems because big shared systems are more reliable and on the whole cheaper than lots of separate systems, and to achieve volume everything from critical to no-so-critical is plugged in the same system. Projects are then billed on data backup volume and frequency. A "critical" system will have a spare waiting to go live, will pay for full-system backup, and is on the night sysadmin list for immediate restoration. A "not-critical" system will only backup data, will be put back-on-line when sysadmins have the time, will be lagging on updates, etc. It will run on old obsolete hardware that can't be replaced identically when it fails. It's a lot more work to restore than the critical system, but recurrent costs are lower, and on the whole it's cheaper than the other one. If the hosting site is destroyed by fire or Al-Qaida plane it can wait months before restoration, while the other will have its hot spare on another hosting site go live in minutes This kind of setup where costs closely mirror system criticity requires careful planning and sorting of on-disk data (and current /var is such a mess it's not an option) -- 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 ville.skytta at iki.fi Sat Sep 29 08:56:36 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 29 Sep 2007 11:56:36 +0300 Subject: pm-utils ping-pong upgrade/downgrade problem in F7 In-Reply-To: <20070928094722.29d9539e.mschwendt.tmp0701.nospam@arcor.de> References: <200709272352.51295.ville.skytta@iki.fi> <20070928094722.29d9539e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200709291156.36434.ville.skytta@iki.fi> On Friday 28 September 2007, Michael Schwendt wrote: > On Thu, 27 Sep 2007 22:36:56 +0000 (UTC), Kevin Kofler wrote: > > Ville Skytt? writes: > > When the installed set of packages is not broken, i.e. the latest > pm-utils requires the installed radeontool/vbetool pkgs without broken > deps, why does Smart even look at the older pm-utils pkg? I can see Obsoletes making it hard to decide what's older. Sure, pm-utils in F7 is older than the one in F7 updates if you only look at the pm-utils EVRs, but the troublemaker unversioned Obsoletes on radeontool and vbetool in the F7 pm-utils also make it newer than radeontool and vbetool in F7 updates and the mess begins. I suppose if Smart wouldn't consider updating something for which it needs to downgrade something unless explicitly told to, we wouldn't see the problem in this particular case. Or something :) > > > I'm not sure about this and haven't tested, but I guess adding > > > Obsoletes: pm-utils < %{version}-%{release} > > > to the new pm-utils could help smart get over it. Thoughts? > > Hmm... but it's already that a new version-release of a pkg implicitly > replaces an old version-release, because that is how updates work. Adding some odd redundant-looking explicit Obsoletes to emphasize what we want has however been a cure for some similar looking corner case depsolving problems (nothing related to Smart in particular) before, so that's the first thing I thought trying in this case. > Effectively, you would try to add something only to get Smart not > look at the old version-release anymore. Sure, assigning a negative priority for the pm-utils package in the F7 release repo works around it. I have no problem doing that locally [0], but just wanted to use this case as yet another example why unversioned Obsoletes are practically always a bad idea. Ditto often but not always unversioned Provides. [0] Well, except that setting negative priorities on the command line is currently broken at least in Smart 0.51, workaround is to do it in smart --gui. http://tracker.labix.org/issue306 From mschwendt.tmp0701.nospam at arcor.de Sat Sep 29 09:42:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 29 Sep 2007 11:42:46 +0200 Subject: pm-utils ping-pong upgrade/downgrade problem in F7 In-Reply-To: <200709291156.36434.ville.skytta@iki.fi> References: <200709272352.51295.ville.skytta@iki.fi> <20070928094722.29d9539e.mschwendt.tmp0701.nospam@arcor.de> <200709291156.36434.ville.skytta@iki.fi> Message-ID: <20070929114246.70957a4b.mschwendt.tmp0701.nospam@arcor.de> On Sat, 29 Sep 2007 11:56:36 +0300, Ville Skytt? wrote: > On Friday 28 September 2007, Michael Schwendt wrote: > > On Thu, 27 Sep 2007 22:36:56 +0000 (UTC), Kevin Kofler wrote: > > > Ville Skytt? writes: > > > > When the installed set of packages is not broken, i.e. the latest > > pm-utils requires the installed radeontool/vbetool pkgs without broken > > deps, why does Smart even look at the older pm-utils pkg? > > I can see Obsoletes making it hard to decide what's older. Sure, pm-utils in > F7 is older than the one in F7 updates if you only look at the pm-utils EVRs, > but the troublemaker unversioned Obsoletes on radeontool and vbetool in the > F7 pm-utils also make it newer than radeontool and vbetool in F7 updates and > the mess begins. I suppose if Smart wouldn't consider updating something for > which it needs to downgrade something unless explicitly told to, we wouldn't > see the problem in this particular case. Or something :) We've been recommending _versioned_ Obsoletes for a very long time. We know that obsoleting packages _non-versioned_ and reintroducing them later can be trouble-some, in particular when the Obsoletes are still seen by the depsolver. I don't argue that pm-utils using non-versioned Obsoletes was a bad decision. But I believe Smart should not consider the old pm-utils at all unless there is a problem with the new pm-utils. It resurrects obsolete Obsoletes :) and becomes confused. From buildsys at redhat.com Sat Sep 29 10:41:07 2007 From: buildsys at redhat.com (Build System) Date: Sat, 29 Sep 2007 06:41:07 -0400 Subject: rawhide report: 20070929 changes Message-ID: <200709291041.l8TAf7VE028023@porkchop.devel.redhat.com> Removed package i810switch Updated Packages: NetworkManager-1:0.7.0-0.3.svn2914.fc8 -------------------------------------- * Fri Sep 28 2007 Dan Williams - 1:0.7.0-0.3.svn2914 - New snapshot - Add WPA passphrase support to password dialog - Applet now reflects actual VPN behavior of one active connection - Applet now notices VPN active connections on startup - Fix connections with some WPA and WEP keys * Thu Sep 27 2007 Dan Williams - 1:0.7.0-0.3.svn2907 - New snapshot - VPN support (only vpnc plugin ported at this time) * Tue Sep 25 2007 Dan Williams - 1:0.7.0-0.3.svn2886 - New snapshot - Make wired device carrier state work in the applet - Fix handling of errors with unencrypted APs - Fix "frozen" applet icon by reporting NM state better - Fix output of AP frequency in nm-tool anaconda-11.3.0.36-1 -------------------- * Fri Sep 28 2007 Chris Lumens 11.3.0.36-1 - Fix rescue CD + nfs tree as well. - More wireless driver blacklist fixing (katzj). coolkey-1.1.0-5.fc8 ------------------- * Thu Sep 27 2007 Jack Magne - 1.1.0-5 - Include patch for moving the cache directory to a safe location. - Bug #299481. fedora-release-7.92-1 --------------------- * Fri Sep 28 2007 Jesse Keating - 7.92-1 - Bump for F8 Test2. - Package up the compose kickstart files * Fri Sep 14 2007 Jesse Keating - 7.91-2 - Use failovermethod=priority in yum configs (243698) * Thu Aug 30 2007 Jesse Keating - 7.91-1 - Provide system-release, useful for spinoffs. - Also link system-release to fedora-release for file level checks - Bump for F8 Test2 - Fix license tag gdm-1:2.20.0-8.fc8 ------------------ * Fri Sep 28 2007 Ray Strode - 1:2.20.0-8 - Another crack at 240853 * Fri Sep 28 2007 Matthias Clasen - 1:2.20.0-7 - Fix the stupid bullets again * Thu Sep 27 2007 Ray Strode - 1:2.20.0-6 - The previously mentioned typo didn't matter before because the compiled in default matched what the config file was supposed to say. This commit restores matched default behavior (bug 301031) gimp-2:2.4.0-0.rc3.1.fc8 ------------------------ * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc3.1 - version 2.4.0-rc3 * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc2.2 - rebuild to pick up new version of poppler * Tue Sep 04 2007 Nils Philippsen - 2:2.4.0-0.rc2.1 - version 2.4.0-rc2 gnome-screensaver-2.20.0-6.fc8 ------------------------------ * Fri Sep 28 2007 Matthias Clasen - 2.20.0-6 - Use small bullets in the password entry * Mon Sep 24 2007 Matthias Clasen - 2.20.0-5 - Fix up GConf requires (#220547) * Fri Sep 21 2007 Matthias Clasen - 2.20.0-4 - Add %pre scriptlet kernel-2.6.23-0.214.rc8.git2.fc8 -------------------------------- * Fri Sep 28 2007 Chuck Ebbert - fix X86 memory detection (bz #311491) * Fri Sep 28 2007 Dave Airlie - Add i965 drm patch to fix vblank interrupts - should be upstream soon * Thu Sep 27 2007 John W. Linville - A few iwlwifi and ath5k fixes smolt-0.9.8.4-8.fc8 ------------------- * Fri Sep 28 2007 Mike McGrath 0.9.8.4-8 - Fixed Selinux * Thu Sep 27 2007 Mike McGrath 0.9.8.4-6 - Added translations yum-presto-0.4.2-1.fc8 ---------------------- * Fri Sep 28 2007 Jonathan Dieter - 0.4.2-1 - Fix a couple of typos that caused yum to hang if certain error paths were hit. * Sun Aug 05 2007 Jonathan Dieter - 0.4.1-1 - Applied small patch by Luke Macken to fix problems when not run directly from yum. - Fix for situation where repository may be removed and then added again * Wed Jul 11 2007 Jonathan Dieter - 0.4.0-1 - Complete rewrite (thanks, Jeremy) - Many features removed in preparation for inclusion in Fedora 8 Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From martin.sourada at seznam.cz Sat Sep 29 11:29:37 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 29 Sep 2007 13:29:37 +0200 Subject: A lot of selinux execstack denials in rawhide when starting audio apps Message-ID: <1191065377.30523.47.camel@localhost.localdomain> Hi, I enabled SELinux for the first time and I got a lot of execstack denials when starting applications providing audio output (so far I got it with listen, rhythmbox, totem and gxine). I have new clean install from latest rawhide live (plus some additional applications). Are these worth filling bugs or are they false positives? I attach an output from this denial for listen music player. I didn't do any actions to fix these denials and the applications seem to work OK. I have SELinux policy set to enforcing. If you need more info, ask. Not sure whether this is for test or devel list so CC-ing devel. Thanks, Martin -------------- next part -------------- Summary SELinux is preventing python from making the program stack executable. Detailed Description The python application attempted to make its stack executable. This is a potential security problem. This should never ever be necessary. Stack memory is not executable on most OSes these days and this will not change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code. Applications are sometimes coded incorrectly and request this permission. The http://people.redhat.com/drepper/selinux-mem.html web page explains how to remove this requirement. If python does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Allowing Access Sometimes a library is accidentally marked with the execstack flag, if you find a library with this flag you can clear it with the execstack -c LIBRARY_PATH. Then retry your application. If the app continues to not work, you can turn the flag back on with execstack -s LIBRARY_PATH. Otherwise, if you trust python to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t python" You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t python" The following command will allow this access: chcon -t unconfined_execmem_exec_t python Additional Information Source Context system_u:system_r:unconfined_t:s0 Target Context system_u:system_r:unconfined_t:s0 Target Objects None [ process ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-13.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.allow_execstack Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.23-0.202.rc8.fc8 #1 SMP Mon Sep 24 22:09:05 EDT 2007 i686 i686 Alert Count 49 First Seen Thu 27 Sep 2007 11:53:37 PM CEST Last Seen Sat 29 Sep 2007 01:18:14 PM CEST Local ID aeae736e-4900-4bc7-bea4-c67c7b4f5edf Line Numbers Raw Audit Messages avc: denied { execstack } for comm=python egid=500 euid=500 exe=/usr/bin/python exit=-13 fsgid=500 fsuid=500 gid=500 items=0 pid=6478 scontext=system_u:system_r:unconfined_t:s0 sgid=500 subj=system_u:system_r:unconfined_t:s0 suid=500 tclass=process tcontext=system_u:system_r:unconfined_t:s0 tty=(none) uid=500 -------------- 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 khc at pm.waw.pl Sat Sep 29 11:41:10 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sat, 29 Sep 2007 13:41:10 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1191055686.7235.41.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sat, 29 Sep 2007 10:48:06 +0200") References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> <1191055686.7235.41.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot writes: > Very often your critical data has not inflated like consumer OSes, so > the trend goes the other way (increasing OS data weight). So a home machine has more critical data than an enterprise network server? Hmm... > And you still > have backup space constrains because many systems are connected to the > same backup hardware. So what? Shared backup hardware is just cheaper. You always have space constrains, SOHO or large scale. > [Several questions that show you've got absolutely no understanding of > real-life enterprise contexts Nice argument :-) > You're assuming every system connected to an enterprise backup system is > critical No, I don't. I was under impression that we are talking about essential systems. Non-essential systems may not require any backup at all - why would you backup something if you'd never want to restore it? -- Krzysztof Halasa From nicolas.mailhot at laposte.net Sat Sep 29 11:59:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 29 Sep 2007 13:59:57 +0200 Subject: [RFC] /var versus /srv In-Reply-To: References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> <1191055686.7235.41.camel@rousalka.dyndns.org> Message-ID: <1191067197.7235.50.camel@rousalka.dyndns.org> Le samedi 29 septembre 2007 ? 13:41 +0200, Krzysztof Halasa a ?crit : > Nicolas Mailhot writes: > > > Very often your critical data has not inflated like consumer OSes, so > > the trend goes the other way (increasing OS data weight). > > So a home machine has more critical data than an enterprise network > server? Hmm... home systems have divx collectionx, enterprise rows of text in databasases > > [Several questions that show you've got absolutely no understanding of > > real-life enterprise contexts > > Nice argument :-) Plain truth sorry > > You're assuming every system connected to an enterprise backup system is > > critical > > No, I don't. I was under impression that we are talking about essential > systems. Non-essential systems may not require any backup at all - why > would you backup something if you'd never want to restore it? You obviously keep your home wide open with essential stuff in a titanium bunker. I could waste time detailing all the real-life shades of gray, but since I have better things to do, I'll stop there. You're smart enough to figure it out if you take the time to think about the problem. -- 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 choeger at cs.tu-berlin.de Sat Sep 29 12:21:43 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sat, 29 Sep 2007 14:21:43 +0200 Subject: Thinkpad Fn-F5 Bluetooth Switch In-Reply-To: <20070928145356.70a237b7@weaponx.rchland.ibm.com> References: <46FD57D7.2020005@redhat.com> <20070928145356.70a237b7@weaponx.rchland.ibm.com> Message-ID: <1191068503.3566.1.camel@choeger4> Am Freitag, den 28.09.2007, 14:53 -0500 schrieb Josh Boyer: > On Fri, 28 Sep 2007 15:36:55 -0400 > Warren Togami wrote: > > > In F7 with apparently no configuration, my Thinkpad T60's Fn-F5 > > Bluetooth switching button worked. > > > > In F8, it stopped working. > > > > /proc/acpi/ibm can be toggled manually. > > > > Anyone know what might have disappeared from F7 -> F8? > > I recall seeing that on my z60m as well. > > josh Hi, there is a /proc/acpi/ibm in F8? I miss this in F7 maybe we have a new driver which does not support bluetooth (yet)? -- Christoph H?ger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From khc at pm.waw.pl Sat Sep 29 17:25:09 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sat, 29 Sep 2007 19:25:09 +0200 Subject: [RFC] /var versus /srv In-Reply-To: <1191067197.7235.50.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sat, 29 Sep 2007 13:59:57 +0200") References: <46F33D05.4020701@ncsu.edu> <1190843974.17132.10.camel@localhost6.localdomain6> <46FADAE8.5020404@redhat.com> <200709272151.46167.lightsolphoenix@gmail.com> <1190958472.5022.116.camel@home.alexander.bostrom.net> <46FCA829.9040604@ncsu.edu> <1190965200.5022.126.camel@home.alexander.bostrom.net> <21968.192.54.193.51.1190972478.squirrel@rousalka.dyndns.org> <20070928162019.7c85a93b@reaver.lamontpeterson.net> <1191055686.7235.41.camel@rousalka.dyndns.org> <1191067197.7235.50.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot writes: > home systems have divx collectionx, enterprise rows of text in > databasases Ah, divx = critical and people have full backups. How nice. > I could waste time detailing all the real-life shades > of gray, but since I have better things to do, I'll stop there. You're welcome. -- Krzysztof Halasa From mjs at CLEMSON.EDU Sat Sep 29 17:32:38 2007 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 29 Sep 2007 13:32:38 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191026134.6487.8.camel@localhost.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> <1191026134.6487.8.camel@localhost.localdomain> Message-ID: <1191087158.12995.41.camel@vincent52.localdomain> On Fri, 2007-09-28 at 20:35 -0400, Jeremy Katz wrote: > On Fri, 2007-09-28 at 18:28 -0400, Matthew Saltzman wrote: > > Tried to create a VPNC connection, but the wizard just exits after I > > select the vpnc connection type (which is the only type offered at this > > point). Is that supposed to work yet? > > You need NetworkManager-vpnc from koji (not tagged for rawhide atm) plus > a manual tweak. That's fixed in upstream svn, so a new build will take > care of that problem. The other outstanding vpn problem is that you > have to restart nm-applet for it to notice the new VPN connection. > Working on that... OK I can wait a bit. Also noticed that (now that I have a connection defined) it doesn't connect automatically when NM/nm-applet starts (e.g., when I log in). I have to pull down the menu and select it. My F7 machine NM-0.6.5 connects to the most recently used WAP in range when it starts. Plus I ran into some quirks with keyrings, but that's another topic. > > Jeremy > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From wwoods at redhat.com Sat Sep 29 17:37:11 2007 From: wwoods at redhat.com (Will Woods) Date: Sat, 29 Sep 2007 13:37:11 -0400 Subject: RTC/RTC0 issues In-Reply-To: <46FD34EC.2050004@gmail.com> References: <46FD34EC.2050004@gmail.com> Message-ID: <1191087431.6544.1.camel@localhost.localdomain> On Fri, 2007-09-28 at 11:07 -0600, Trever Adams wrote: > I have the latest kernel I believe. This issue with rtc existing and > /sbin/clock not being able to access it (because it should be a symlink > to rtc0, or have the same device number as rt0) still exists. I assume you're using rawhide - this problem should be fixed in kernel 2.6.23-0.211 and later. See bug #290731. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From oisin.feeley at gmail.com Sat Sep 29 18:50:10 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Sat, 29 Sep 2007 14:50:10 -0400 Subject: [RFC] /var versus /srv In-Reply-To: <1190406746.23728.99.camel@localhost6.localdomain6> References: <20070921100859.GA6032@devserv.devel.redhat.com> <1190385168.2142.60.camel@cutter> <1190386145.31022.180.camel@mccallum.corsepiu.local> <2560.192.54.193.51.1190389112.squirrel@rousalka.dyndns.org> <1190394930.2567.173.camel@localhost.localdomain> <1190396573.23728.70.camel@localhost6.localdomain6> <20070921185842.GA27796@jadzia.bu.edu> <20070921134940.608dcaaa@reaver.lamontpeterson.net> <1190406746.23728.99.camel@localhost6.localdomain6> Message-ID: On 9/21/07, Richi Plana wrote: > Same thing I've been saying, but it's only now that I realized that I've > been assuming the wrong thing. When I read FHS, in my mind, I was > thinking LSB. So here I was thinking that Fedora was simply following > some guidelines set up by the FSB for its directory hierarchy. Now that > I know that FHS refers to the Fedora Hierarchy Structure, this changes a > few things. > > As I said, I thought it referred to an LSB guideline which made me think > Fedora could be flexible with its interpretation and implementation. > > Now that I've read up on the FHS, I have to say that it needs reworking > if only because some of the things it states contradict others. The FHS /is/ part of the LSB specification. It's the Filesystem Hierarchy Standard as promoted by the OpenGroup. See here: http://www.opengroup.org/testing/lsb-fhs/ The Fedora Project adopted it with the exception of libexecdir. Best wishes, Oisin Feeley From tjb at unh.edu Sat Sep 29 19:01:02 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Sat, 29 Sep 2007 15:01:02 -0400 Subject: bluetooth not working automatically Message-ID: <1191092462.4968.4.camel@continuity.bakerconsulting.com> Does bluetooth automatically work for anyone? I'm seeing the following problems: bluetooth service always fails to start at boot - address in use - can be started by hand after bluetooth-applet doesn't seem to get run at login - works fine if started by hand It seems like stuff is working, just not automatically. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tjb at unh.edu Sat Sep 29 19:03:07 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Sat, 29 Sep 2007 15:03:07 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191087158.12995.41.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> <1191026134.6487.8.camel@localhost.localdomain> <1191087158.12995.41.camel@vincent52.localdomain> Message-ID: <1191092592.4968.6.camel@continuity.bakerconsulting.com> On Sat, 2007-09-29 at 13:32 -0400, Matthew Saltzman wrote: > On Fri, 2007-09-28 at 20:35 -0400, Jeremy Katz wrote: > > On Fri, 2007-09-28 at 18:28 -0400, Matthew Saltzman wrote: > > > Tried to create a VPNC connection, but the wizard just exits after I > > > select the vpnc connection type (which is the only type offered at this > > > point). Is that supposed to work yet? > > > > You need NetworkManager-vpnc from koji (not tagged for rawhide atm) plus > > a manual tweak. That's fixed in upstream svn, so a new build will take > > care of that problem. The other outstanding vpn problem is that you > > have to restart nm-applet for it to notice the new VPN connection. > > Working on that... > > OK I can wait a bit. > > Also noticed that (now that I have a connection defined) it doesn't > connect automatically when NM/nm-applet starts (e.g., when I log in). I > have to pull down the menu and select it. My F7 machine NM-0.6.5 > connects to the most recently used WAP in range when it starts. > > Plus I ran into some quirks with keyrings, but that's another topic. > Auto connecting is not working for me either. Even at home where there is only one unencrypted choice. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tjb at unh.edu Sat Sep 29 19:06:30 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Sat, 29 Sep 2007 15:06:30 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191092592.4968.6.camel@continuity.bakerconsulting.com> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> <1191026134.6487.8.camel@localhost.localdomain> <1191087158.12995.41.camel@vincent52.localdomain> <1191092592.4968.6.camel@continuity.bakerconsulting.com> Message-ID: <1191092790.5870.0.camel@continuity.bakerconsulting.com> On Sat, 2007-09-29 at 15:03 -0400, Thomas J. Baker wrote: > On Sat, 2007-09-29 at 13:32 -0400, Matthew Saltzman wrote: > > On Fri, 2007-09-28 at 20:35 -0400, Jeremy Katz wrote: > > > On Fri, 2007-09-28 at 18:28 -0400, Matthew Saltzman wrote: > > > > Tried to create a VPNC connection, but the wizard just exits after I > > > > select the vpnc connection type (which is the only type offered at this > > > > point). Is that supposed to work yet? > > > > > > You need NetworkManager-vpnc from koji (not tagged for rawhide atm) plus > > > a manual tweak. That's fixed in upstream svn, so a new build will take > > > care of that problem. The other outstanding vpn problem is that you > > > have to restart nm-applet for it to notice the new VPN connection. > > > Working on that... > > > > OK I can wait a bit. > > > > Also noticed that (now that I have a connection defined) it doesn't > > connect automatically when NM/nm-applet starts (e.g., when I log in). I > > have to pull down the menu and select it. My F7 machine NM-0.6.5 > > connects to the most recently used WAP in range when it starts. > > > > Plus I ran into some quirks with keyrings, but that's another topic. > > > > Auto connecting is not working for me either. Even at home where there > is only one unencrypted choice. > I take it back. It works on login, just not resume from suspend. It used to in F7. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tjb at unh.edu Sat Sep 29 19:26:25 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Sat, 29 Sep 2007 15:26:25 -0400 Subject: gnome keyring problems Message-ID: <1191093985.5870.16.camel@continuity.bakerconsulting.com> The auto unlocking gnome keyring stuff is not working well for me. I get prompted every time I start evolution for the 'default' keyring password with the option of automatically unlocking it at login, which I always check. Half of my passwords are stored in the 'default' keyring and half are in the 'login' keyring. Assuming that a bold name in gnome-keyring-manager denotes what it thinks is the default keyring, then the login keyring is the default one. I get prompted for the password to the 'default' keyring which then means the one named default, and I also get prompted for the default keyring, which ends up being the login one. The only difference in the prompting dialogs is the quoting. The password to the login keyring is the same as my unix one. The password to my default keyring is different. Do all three need to be the same to work? Also, is this supposed to work for an NIS setup? My laptop is a local account but my work one is NIS. The auto unlocking keyring stuff doesn't work anywhere. I don't know if some of this is related to the fact that you still can't log out correctly so things may not get saved. https://bugzilla.redhat.com/show_bug.cgi?id=312531 tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From mastahnke at gmail.com Sat Sep 29 21:07:44 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 29 Sep 2007 16:07:44 -0500 Subject: /etc/hosts and system entries In-Reply-To: References: <46FBB734.90403@ip-solutions.net> <20070927100229.36836163.dcantrell@redhat.com> <1190902242.3476.8.camel@hopeson> <1190912434.30715.1.camel@localhost.localdomain> <1190987022.5022.199.camel@home.alexander.bostrom.net> <20070928054758.0abfde54@redhat.com> <20070928110543.3f045c28@reaver.lamontpeterson.net> <1191001927.3476.28.camel@hopeson> Message-ID: <7874d9dd0709291407t7b44d067q167d7e3580b24d5c@mail.gmail.com> I know we have several application (mostly third party apps on RHEL) at work that break horribly if 127.0.01 is the hostname IP address. The first thing I do when things are not working is to check /etc/hosts and make sure someone/thing didn't put the hostname back there. On client machines it's probably a different issue, but on servers, having it in /etc/hosts is unfun. stahnma From jonathan.underwood at gmail.com Sat Sep 29 22:48:25 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 29 Sep 2007 23:48:25 +0100 Subject: When should sysctl be run during boot? Message-ID: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com> Hi, Currently, values set in /etc/sysctl.conf are set on boot when sysctl -p -e is called. This happens in /etc/network. Of course, setting values for kernel modules not loaded at that point has no effect. This caught me out recently, as I tried to set a value for one of the conntrack modules. Because the relevant module wasn't loaded until shorewall started on my system, and because shorewall is started after the network, the setting didn't do anything. The way I fixed it is by adding sysctl -e -p to rc.local, so that it is ran after all the other init scripts. However, I could see that this approach might be unwise since the nfs script uses sysctl to change some values, and potentially that could be undone by bad settings in sysctl.conf. My question then is: should there not be a service that runs sysctl on boot, as the last thing before rc.local? I have seen this on other distributions. This would make the following statement true: If you want to make a change to /proc/sys persistent across reboots, then add it to /etc/sysctl.conf. It currently isn't always true due to the timing of systl being run, but that statement is, for many, expected behaviour. Thoughts? Jonathan. From jonathan.underwood at gmail.com Sat Sep 29 22:50:32 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 29 Sep 2007 23:50:32 +0100 Subject: When should sysctl be run during boot? In-Reply-To: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com> References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com> Message-ID: <645d17210709291550s3513f0b6t8cb8934466a0b179@mail.gmail.com> On 29/09/2007, Jonathan Underwood wrote: > Hi, > > Currently, values set in /etc/sysctl.conf are set on boot when sysctl > -p -e is called. This happens in /etc/network. Of course, setting er, that should be /etc/init.d/network. From jos at xos.nl Sat Sep 29 23:05:12 2007 From: jos at xos.nl (Jos Vos) Date: Sun, 30 Sep 2007 01:05:12 +0200 Subject: When should sysctl be run during boot? In-Reply-To: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com> References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com> Message-ID: <20070929230512.GA12304@jasmine.xos.nl> On Sat, Sep 29, 2007 at 11:48:25PM +0100, Jonathan Underwood wrote: > Currently, values set in /etc/sysctl.conf are set on boot when sysctl > -p -e is called. This happens in /etc/network. Of course, setting > values for kernel modules not loaded at that point has no effect. FWIW: It is also called in an earlier stage, in rc.sysinit. Of course, this doesn't solve your complaint... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From s.adam at diffingo.com Sun Sep 30 00:10:32 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sat, 29 Sep 2007 20:10:32 -0400 Subject: gnome keyring problems In-Reply-To: <1191093985.5870.16.camel@continuity.bakerconsulting.com> References: <1191093985.5870.16.camel@continuity.bakerconsulting.com> Message-ID: <1191111032.24321.1.camel@Diffingo.localdomain> On Sat, 2007-09-29 at 15:26 -0400, Thomas J. Baker wrote: > The auto unlocking gnome keyring stuff is not working well for me. I get > prompted every time I start evolution for the 'default' keyring password > with the option of automatically unlocking it at login, which I always > check. Half of my passwords are stored in the 'default' keyring and half > are in the 'login' keyring. Assuming that a bold name in > gnome-keyring-manager denotes what it thinks is the default keyring, > then the login keyring is the default one. I get prompted for the > password to the 'default' keyring which then means the one named > default, and I also get prompted for the default keyring, which ends up > being the login one. The only difference in the prompting dialogs is the > quoting. > > The password to the login keyring is the same as my unix one. The > password to my default keyring is different. Do all three need to be the > same to work? Also, is this supposed to work for an NIS setup? My laptop > is a local account but my work one is NIS. The auto unlocking keyring > stuff doesn't work anywhere. > > I don't know if some of this is related to the fact that you still can't > log out correctly so things may not get saved. > > https://bugzilla.redhat.com/show_bug.cgi?id=312531 > I see this too, and I'm not sure if it's the program or the keyring itself, but sometimes programs refuse to connect and I have to remove the keyring named "default" and re-create to get things working. Stewart From mattdm at mattdm.org Sun Sep 30 00:25:52 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 29 Sep 2007 20:25:52 -0400 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191087158.12995.41.camel@vincent52.localdomain> References: <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> <1191026134.6487.8.camel@localhost.localdomain> <1191087158.12995.41.camel@vincent52.localdomain> Message-ID: <20070930002552.GA8910@jadzia.bu.edu> On Sat, Sep 29, 2007 at 01:32:38PM -0400, Matthew Saltzman wrote: > Also noticed that (now that I have a connection defined) it doesn't > connect automatically when NM/nm-applet starts (e.g., when I log in). I > have to pull down the menu and select it. My F7 machine NM-0.6.5 > connects to the most recently used WAP in range when it starts. You can use gconf-editor to toggle the autoconnect flag for the connections, once you've connected once. This seems to work. (With the caveat that the whole thing is acting really flaky for me. Once I connect to one network -- or even *try* to connect -- the network card then loses the ability to scan for any networks or connect to other ones until I reboot.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From snecklifter at gmail.com Sun Sep 30 00:49:17 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 30 Sep 2007 01:49:17 +0100 Subject: Thinkpad Fn-F5 Bluetooth Switch In-Reply-To: <1191068503.3566.1.camel@choeger4> References: <46FD57D7.2020005@redhat.com> <20070928145356.70a237b7@weaponx.rchland.ibm.com> <1191068503.3566.1.camel@choeger4> Message-ID: <364d303b0709291749u4c5f737fn1709f8e635b57481@mail.gmail.com> On 29/09/2007, Christoph H?ger wrote: > > Am Freitag, den 28.09.2007, 14:53 -0500 schrieb Josh Boyer: > > On Fri, 28 Sep 2007 15:36:55 -0400 > > Warren Togami wrote: > > > > > In F7 with apparently no configuration, my Thinkpad T60's Fn-F5 > > > Bluetooth switching button worked. > > > > > > In F8, it stopped working. > > > > > > /proc/acpi/ibm can be toggled manually. > > > > > > Anyone know what might have disappeared from F7 -> F8? > > > > I recall seeing that on my z60m as well. > > > > josh > > Hi, > > there is a /proc/acpi/ibm in F8? I miss this in F7 maybe we have a new > driver which does not support bluetooth (yet)? I take it: # modprobe thinkpad-acpi doesn't do anything for you? Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Sun Sep 30 00:52:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 29 Sep 2007 19:52:14 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FDBFBE.9050708@fedoraproject.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> Message-ID: <46FEF33E.3000506@filteredperception.org> Rahul Sundaram wrote: > Bill Nottingham wrote: > >> The guidelines were specifically designed so that someone could ship >> stock Fedora and an additional repository of vendor packages, whether >> it be Dell addons, Creative Commons content or whatever. >> If those guidelines are followed, then, without actually changing the >> guidelines, it doesn't really matter what that content/packages are. > > That is indeed my implicit question. Do you still want vendors to ship > software not included in Fedora and still call it Fedora? Nobody currently gets to call anything "Fedora" that isn't a very specific set of bits that are originally and solely shipped by the fedora project. What they get to do, is take those bits as a whole, not modify them in any way whatsoever, and bundle them with other software, with the explicit restriction that- " 4. Any marketing materials related to such a distribution make clear that the vendor is providing patches which, if installed by the user, will modify the Fedora? code from its original form. " Is it ok for > anyone and everyone to do so with any set of software? Does the current > trademark guidelines match the goals of the project? Honestly, what business is it of yours, how people distribute *unmodified* copies of fedora? Sure I'd love to have a legal license which states that any free software I write, cannot be used by governments to support in any way whatsoever an institution which engages in 'baiting' tactics that use entrapment as justification for murder, but I'm a realist. Hopefully our software will save more babies than it kills (or 'eats' is I suppose the parlance of choice...) -dmc From trever.adams at gmail.com Sun Sep 30 01:36:27 2007 From: trever.adams at gmail.com (Trever L. Adams) Date: Sat, 29 Sep 2007 19:36:27 -0600 Subject: RTC/RTC0 issues In-Reply-To: <1191087431.6544.1.camel@localhost.localdomain> References: <46FD34EC.2050004@gmail.com> <1191087431.6544.1.camel@localhost.localdomain> Message-ID: <46FEFD9B.60906@gmail.com> Will Woods wrote: > I assume you're using rawhide - this problem should be fixed in kernel > 2.6.23-0.211 and later. See bug #290731. > > -w > The original one that said it was fixed didn't do it. The 211 indeed did. Thank you, Trever Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Sep 30 03:29:49 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 30 Sep 2007 12:29:49 +0900 Subject: rpms/glibc/devel .cvsignore, 1.217, 1.218 glibc-fedora.patch, 1.239, 1.240 glibc.spec, 1.328, 1.329 sources, 1.241, 1.242 In-Reply-To: <200709291948.l8TJm27G003812@cvs-int.fedora.redhat.com> References: <200709291948.l8TJm27G003812@cvs-int.fedora.redhat.com> Message-ID: <46FF182D.4020201@ioa.s.u-tokyo.ac.jp> Jakub Jelinek (jakub) wrote, at 09/30/2007 04:48 AM +9:00: > Author: jakub > > Update of /cvs/pkgs/rpms/glibc/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3759/devel > > Modified Files: > .cvsignore glibc-fedora.patch glibc.spec sources > Log Message: > 2.6.90-16 With this glibc, gdm seems to hang. Once a cursor appears, it never proceeds. Reverting to -15 seems okay. Regards, Mamoru From denis at poolshark.org Sun Sep 30 06:35:33 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 30 Sep 2007 08:35:33 +0200 Subject: NetworkManager-0.7 can't make new wireless connection In-Reply-To: <1191087158.12995.41.camel@vincent52.localdomain> References: <1190823905.15397.16.camel@vincent52.localdomain> <46FABF0F.2010404@redhat.com> <1190953686.14740.0.camel@xo-3E-67-34.localdomain> <20070928085550.2b74c397@banea.int.addix.net> <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com> <20070928063428.1a6cb2fe@redhat.com> <1190996852.10569.4.camel@vincent52.localdomain> <4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com> <1191004430.12453.4.camel@vincent52.localdomain> <1191014980.12995.14.camel@vincent52.localdomain> <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com> <1191018515.12995.30.camel@vincent52.localdomain> <1191026134.6487.8.camel@localhost.localdomain> <1191087158.12995.41.camel@vincent52.localdomain> Message-ID: <46FF43B5.8050602@poolshark.org> Matthew Saltzman wrote: > On Fri, 2007-09-28 at 20:35 -0400, Jeremy Katz wrote: >> On Fri, 2007-09-28 at 18:28 -0400, Matthew Saltzman wrote: >>> Tried to create a VPNC connection, but the wizard just exits after I >>> select the vpnc connection type (which is the only type offered at this >>> point). Is that supposed to work yet? >> You need NetworkManager-vpnc from koji (not tagged for rawhide atm) plus >> a manual tweak. That's fixed in upstream svn, so a new build will take >> care of that problem. The other outstanding vpn problem is that you >> have to restart nm-applet for it to notice the new VPN connection. >> Working on that... > > OK I can wait a bit. > > Also noticed that (now that I have a connection defined) it doesn't > connect automatically when NM/nm-applet starts (e.g., when I log in). I > have to pull down the menu and select it. Same here also, even with only a single unencrypted choice in the list. From choeger at cs.tu-berlin.de Sun Sep 30 08:56:16 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 30 Sep 2007 10:56:16 +0200 Subject: Thinkpad Fn-F5 Bluetooth Switch In-Reply-To: <364d303b0709291749u4c5f737fn1709f8e635b57481@mail.gmail.com> References: <46FD57D7.2020005@redhat.com> <20070928145356.70a237b7@weaponx.rchland.ibm.com> <1191068503.3566.1.camel@choeger4> <364d303b0709291749u4c5f737fn1709f8e635b57481@mail.gmail.com> Message-ID: <1191142576.3630.2.camel@choeger4> Am Sonntag, den 30.09.2007, 01:49 +0100 schrieb Christopher Brown: > On 29/09/2007, Christoph H?ger wrote: > Am Freitag, den 28.09.2007, 14:53 -0500 schrieb Josh Boyer: > > On Fri, 28 Sep 2007 15:36:55 -0400 > > Warren Togami wrote: > > > > > In F7 with apparently no configuration, my Thinkpad T60's > Fn-F5 > > > Bluetooth switching button worked. > > > > > > In F8, it stopped working. > > > > > > /proc/acpi/ibm can be toggled manually. > > > > > > Anyone know what might have disappeared from F7 -> F8? > > > > I recall seeing that on my z60m as well. > > > > josh > > Hi, > > there is a /proc/acpi/ibm in F8? I miss this in F7 maybe we > have a new > driver which does not support bluetooth (yet)? > > I take it: > > # modprobe thinkpad-acpi > > doesn't do anything for you? Hi, I did not know that module until this morning. Thank you for the hint :) And to topic: I can use FN-F5 with this module in F7 with 2.6.22.9-91.fc7 -- Christoph H?ger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From buildsys at redhat.com Sun Sep 30 09:46:05 2007 From: buildsys at redhat.com (Build System) Date: Sun, 30 Sep 2007 05:46:05 -0400 Subject: rawhide report: 20070930 changes Message-ID: <200709300946.l8U9k5Rp008975@porkchop.devel.redhat.com> Updated Packages: NetworkManager-vpnc-1:0.7.0-0.2.svn2914.fc8 ------------------------------------------- * Fri Sep 28 2007 Dan Williams - 1:0.7.0-0.1.svn2914 - Fix .name file on 64-bit systems * Fri Sep 28 2007 Jesse Keating - 1:0.7.0-0.2.svn2910 - BuildRequire NetworkManager-glib-devel * Thu Sep 27 2007 Dan Williams - 1:0.7.0-0.1.svn2910 - New snapshot; ported to NM 0.7 API pulseaudio-0.9.7-0.14.svn20070929.fc8 ------------------------------------- * Sat Sep 29 2007 Lennart Poettering 0.9.7-0.14.svn20070929 - Another SVN snapshot, fixing a couple of subtle bugs quilt-0.46-4.fc8 ---------------- * Fri Sep 28 2007 - jwboyer at jdub.homelinux.org 0.46-4 - BR util-linux-ng for getopt repoview-0.6.1-1.fc8 -------------------- * Thu Sep 27 2007 Konstantin Ryabitsev - 0.6.1-1 - Upstream 0.6.1 - Adjust license to GPLv2+ Broken deps for i386 ---------------------------------------------------------- csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 Broken deps for x86_64 ---------------------------------------------------------- csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone Broken deps for ppc64 ---------------------------------------------------------- kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics From buildsys at fedoraproject.org Sun Sep 30 12:41:20 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 30 Sep 2007 08:41:20 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-09-30 Message-ID: <20070930124120.8331B15212F@buildsys.fedoraproject.org> Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6, FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8 a badger AT gmail com: python-docutils F7-updates-testing > F8 (0:0.4-7.fc7 > 0:0.4-6.fc8) clumens AT redhat com: pykickstart F7-updates-testing > F8 (0:1.13-2.fc7 > 0:1.13-1.fc8) devrim AT commandprompt com: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) enrico scholz AT informatik tu-chemnitz de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libextractor FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7) esandeen AT redhat com: xfsprogs FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7) foolish AT guezz net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) gauret AT free fr: amarok F7-updates-testing > F8 (0:1.4.7-5.fc7 > 0:1.4.7-4.fc8) jamatos AT fc up pt: t1lib FE6 > F8 (0:5.1.1-3.fc6 > 0:5.1.1-2.fc8) F7-updates > F8 (0:5.1.1-3.fc7 > 0:5.1.1-2.fc8) tellico F7-updates > F8 (0:1.2.14-2.fc7 > 0:1.2.13-2.fc8) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) lxtnow AT gmail com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mdehaan AT redhat com: cobbler FE6 > F7-updates (0:0.6.2-2.fc6 > 0:0.6.1-2.fc7) FE6 > F8 (0:0.6.2-2.fc6 > 0:0.6.1-2.fc8) koan FE6 > F7-updates (0:0.6.2-2.fc6 > 0:0.6.1-2.fc7) FE6 > F8 (0:0.6.2-2.fc6 > 0:0.6.1-2.fc8) michel sylvan AT gmail com: python-nltk FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) mmcgrath AT redhat com: cacti FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7) mtasaka AT ioa s u-tokyo ac jp: jd FE6 > F7-updates (0:1.9.6-0.6.rc070930.fc6 > 0:1.9.6-0.5.beta070918.fc7) FE6 > F8 (0:1.9.6-0.6.rc070930.fc6 > 0:1.9.6-0.5.beta070918.fc8) kazehakase FE6 > F7-updates (0:0.4.9-1.fc6 > 0:0.4.8-1.fc7) FE6 > F8 (0:0.4.9-1.fc6 > 0:0.4.8-1.fc8) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) paul AT city-fan org: lat F7-updates-testing > F8 (0:1.2.3-1.fc7 > 0:1.2.2-3.fc8) robert AT marcanoonline com: eclipse-subclipse FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8) F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8) roland AT redhat com: monotone FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) shahms AT shahms com: bzr F7-updates-testing > F8 (0:0.91-1.fc7 > 0:0.90-1.fc8) bzr-gtk F7-updates-testing > F8 (0:0.91.0-2.fc7 > 0:0.18.0-1.fc8) bzrtools F7-updates-testing > F8 (0:0.91.0-1.fc7 > 0:0.90.0-2.fc8) silfreed AT silfreed net: qgis FE6 > F8 (0:0.9.0-1.fc6 > 0:0.8.1-13.fc8) F7-updates-testing > F8 (0:0.9.0-1.fc7 > 0:0.8.1-13.fc8) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) tjanouse AT redhat com: cyrus-imapd FE6 > F7 (0:2.3.9-6.fc6 > 0:2.3.8-3.fc7) tla AT rasmil dk: yumex F7-updates-testing > F8 (0:2.0.2-1.fc7 > 0:2.0.1-1.fc8) twaugh AT redhat com: cupsddk FE6 > F7-updates (0:1.2.1-1.fc6 > 0:1.2.0-3.fc7) FE6 > F8 (0:1.2.1-1.fc6 > 0:1.2.0-4.fc8) ---------------------------------------------------------------------- amarok: gauret AT free fr F7-updates-testing > F8 (0:1.4.7-5.fc7 > 0:1.4.7-4.fc8) bzr: shahms AT shahms com F7-updates-testing > F8 (0:0.91-1.fc7 > 0:0.90-1.fc8) bzr-gtk: shahms AT shahms com F7-updates-testing > F8 (0:0.91.0-2.fc7 > 0:0.18.0-1.fc8) bzrtools: shahms AT shahms com F7-updates-testing > F8 (0:0.91.0-1.fc7 > 0:0.90.0-2.fc8) cacti: mmcgrath AT redhat com FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7) cobbler: mdehaan AT redhat com FE6 > F7-updates (0:0.6.2-2.fc6 > 0:0.6.1-2.fc7) FE6 > F8 (0:0.6.2-2.fc6 > 0:0.6.1-2.fc8) cupsddk: twaugh AT redhat com FE6 > F7-updates (0:1.2.1-1.fc6 > 0:1.2.0-3.fc7) FE6 > F8 (0:1.2.1-1.fc6 > 0:1.2.0-4.fc8) cyrus-imapd: tjanouse AT redhat com FE6 > F7 (0:2.3.9-6.fc6 > 0:2.3.8-3.fc7) eclipse-subclipse: robert AT marcanoonline com FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8) F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8) fedora-usermgmt: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gtranslator: foolish AT guezz net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jd: mtasaka AT ioa s u-tokyo ac jp FE6 > F7-updates (0:1.9.6-0.6.rc070930.fc6 > 0:1.9.6-0.5.beta070918.fc7) FE6 > F8 (0:1.9.6-0.6.rc070930.fc6 > 0:1.9.6-0.5.beta070918.fc8) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kazehakase: mtasaka AT ioa s u-tokyo ac jp FE6 > F7-updates (0:0.4.9-1.fc6 > 0:0.4.8-1.fc7) FE6 > F8 (0:0.4.9-1.fc6 > 0:0.4.8-1.fc8) koan: mdehaan AT redhat com FE6 > F7-updates (0:0.6.2-2.fc6 > 0:0.6.1-2.fc7) FE6 > F8 (0:0.6.2-2.fc6 > 0:0.6.1-2.fc8) lat: paul AT city-fan org F7-updates-testing > F8 (0:1.2.3-1.fc7 > 0:1.2.2-3.fc8) libextractor: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) monotone: roland AT redhat com FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) postgresql-pgpool-II: devrim AT commandprompt com FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) pykickstart: clumens AT redhat com F7-updates-testing > F8 (0:1.13-2.fc7 > 0:1.13-1.fc8) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-docutils: a badger AT gmail com F7-updates-testing > F8 (0:0.4-7.fc7 > 0:0.4-6.fc8) python-gammu: lxtnow AT gmail com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) python-nltk: michel sylvan AT gmail com FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) qgis: silfreed AT silfreed net FE6 > F8 (0:0.9.0-1.fc6 > 0:0.8.1-13.fc8) F7-updates-testing > F8 (0:0.9.0-1.fc7 > 0:0.8.1-13.fc8) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) t1lib: jamatos AT fc up pt FE6 > F8 (0:5.1.1-3.fc6 > 0:5.1.1-2.fc8) F7-updates > F8 (0:5.1.1-3.fc7 > 0:5.1.1-2.fc8) tcptraceroute: foolish AT guezz net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) tellico: jamatos AT fc up pt F7-updates > F8 (0:1.2.14-2.fc7 > 0:1.2.13-2.fc8) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7) xfsprogs: esandeen AT redhat com FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7) xmlrpc-c: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7) yumex: tla AT rasmil dk F7-updates-testing > F8 (0:2.0.2-1.fc7 > 0:2.0.1-1.fc8) From buildsys at fedoraproject.org Sun Sep 30 12:49:19 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 30 Sep 2007 08:49:19 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-09-30 Message-ID: <20070930124919.0EF5515212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 10 cobbler-0.6.2-2.fc6 cupsddk-1.2.1-1.fc6 i810switch-0.6.5-6.fc6 jd-1.9.6-0.6.rc070930.fc6 kazehakase-0.4.9-1.fc6 koan-0.6.2-2.fc6 NEW lybniz-1.3-5.fc6.1 : A function graph plotter NEW mhgui-0.1-2.fc6 : A simple GUI library for MakeHuman NEW qwt-5.0.2-5.fc6 : Qt Widgets for Technical Applications NEW SteGUI-0.0.1-12.fc6 : Graphical front-end to Steghide Changes in Fedora Extras 6: cobbler-0.6.2-2.fc6 ------------------- * Fri Sep 28 2007 Michael DeHaan - 0.6.2-2 - Upstream changes (see CHANGELOG) - removed syslinux as a requirement (cobbler check will detect absense) - packaged /var/lib/cobbler/settings as a config file - added BuildRequires of redhat-rpm-config to help src RPM rebuilds on other platforms - permissions cleanup - make license field conform to rpmlint - relocate cgi-bin files to cobbler subdirectory - include the WUI! cupsddk-1.2.1-1.fc6 ------------------- * Sat Sep 29 2007 Tim Waugh 1.2.1-1 - 1.2.1. * Wed Aug 29 2007 Tim Waugh 1.2.0-4 - More specific license tag. i810switch-0.6.5-6.fc6 ---------------------- * Fri Sep 28 2007 Matt Domsch - 0.6.5-6 - add i945 detection, fixes BZ297371 jd-1.9.6-0.6.rc070930.fc6 ------------------------- * Sun Sep 30 2007 Mamoru Tasaka - 1.9.6-0.6.rc070930 - 1.9.6 rc 070930 kazehakase-0.4.9-1.fc6 ---------------------- * Sat Sep 29 2007 Mamoru Tasaka - 0.4.9-1 - 0.4.9 koan-0.6.2-2.fc6 ---------------- * Fri Sep 28 2007 Michael DeHaan - 0.6.2-2 - Upstream changes (see CHANGELOG) lybniz-1.3-5.fc6.1 ------------------ * Fri Sep 28 2007 Stewart Adam 1.3-5.1 - Bump * Fri Sep 28 2007 Stewart Adam 1.3-5 - Fix changelog version * Fri Sep 28 2007 Stewart Adam 1.3-4 - Directory ownership... * Thu Sep 27 2007 Stewart Adam 1.3-3 - Add patch to fix Exec field in desktop file * Thu Sep 27 2007 Stewart Adam 1.3-2 - Change Source0 to proper URL - Fix perms on lybniz-startup.sh - Why CFLAGS? Gone. - Use --delete-original and drop rm for the .desktop file * Tue Sep 25 2007 Stewart Adam 1.3-1 - Initial Release mhgui-0.1-2.fc6 --------------- * Thu Sep 13 2007 kwizart < kwizart at gmail.com > - 0.1-2 - Fix URL - Change summary qwt-5.0.2-5.fc6 --------------- * Sat Sep 29 2007 Frank B?ttner - 5.0.2-5 - add EPEL support * Sat Sep 29 2007 Frank B?ttner - 5.0.2-4 - remove parallel build, because it will fail sometimes * Fri Sep 28 2007 Frank B?ttner - 5.0.2-3 - fix some errors in the spec file SteGUI-0.0.1-12.fc6 ------------------- * Fri Sep 28 2007 Pingou 0.0.1-12 - Change in the desktop file * Sun Sep 23 2007 Pingou 0.0.1-11 - Change in the desktop file * Sun Sep 23 2007 Pingou 0.0.1-10 - Change in the change log (add lines) - Change in the license tag to fit the packaging guidelines From sundaram at fedoraproject.org Sun Sep 30 12:51:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 30 Sep 2007 18:21:06 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FEF33E.3000506@filteredperception.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> Message-ID: <46FF9BBA.4030002@fedoraproject.org> Douglas McClendon wrote: > Is it ok for >> anyone and everyone to do so with any set of software? Does the >> current trademark guidelines match the goals of the project? > > Honestly, what business is it of yours, how people distribute > *unmodified* copies of fedora? Some modifications are explicitly allowed by the trademark guidelines. My question to the Fedora Project Board was whether it should be. Sure I'd love to have a legal license > which states that any free software I write, cannot be used by > governments to support in any way whatsoever an institution which > engages in 'baiting' tactics that use entrapment as justification for > murder, but I'm a realist. Such a restriction wouldn't qualify as Free software at all. Rahul From dmc.fedora at filteredperception.org Sun Sep 30 13:21:38 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 30 Sep 2007 08:21:38 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FF9BBA.4030002@fedoraproject.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> Message-ID: <46FFA2E2.6030504@filteredperception.org> Rahul Sundaram wrote: > Douglas McClendon wrote: > >> Is it ok for >>> anyone and everyone to do so with any set of software? Does the >>> current trademark guidelines match the goals of the project? >> >> Honestly, what business is it of yours, how people distribute >> *unmodified* copies of fedora? > > Some modifications are explicitly allowed by the trademark guidelines. > My question to the Fedora Project Board was whether it should be. But you do see, that our point of disagreement is over whether or not what I described was a 'modification'. I.e. your question is irrelevant to the conversation, since no modification is taking place. > > Sure I'd love to have a legal license >> which states that any free software I write, cannot be used by >> governments to support in any way whatsoever an institution which >> engages in 'baiting' tactics that use entrapment as justification for >> murder, but I'm a realist. > > Such a restriction wouldn't qualify as Free software at all. That was my point. -dmc From mail at robertoragusa.it Sun Sep 30 13:29:08 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 30 Sep 2007 15:29:08 +0200 Subject: ibm-acpi, thinkpad_acpi (was: Thinkpad Fn-F5 Bluetooth Switch) In-Reply-To: <1191142576.3630.2.camel@choeger4> References: <46FD57D7.2020005@redhat.com> <20070928145356.70a237b7@weaponx.rchland.ibm.com> <1191068503.3566.1.camel@choeger4> <364d303b0709291749u4c5f737fn1709f8e635b57481@mail.gmail.com> <1191142576.3630.2.camel@choeger4> Message-ID: <46FFA4A4.1010404@robertoragusa.it> Christoph H?ger wrote: > Am Sonntag, den 30.09.2007, 01:49 +0100 schrieb Christopher Brown: >> >> I take it: >> >> # modprobe thinkpad-acpi >> >> doesn't do anything for you? > > Hi, > > I did not know that module until this morning. Thank you for the hint :) > And to topic: I can use FN-F5 with this module in F7 with > 2.6.22.9-91.fc7 It was called ibm-acpi until a few weeks ago, then it changed for F7 too. The path also changed and that causes a problem because /etc/rc.d/rc.sysinit doesn't load the module. The new path is: /lib/modules/$unamer/kernel/drivers/misc/thinkpad_acpi.ko But the loading script does this: # Initialize ACPI bits if [ -d /proc/acpi ]; then for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do module=${module##*/} module=${module%.ko} modprobe $module >/dev/null 2>&1 done fi I noticed because some gkrellm temperature readings (gkibm-acpi) are unavailable without the module. Best regards. -- Roberto Ragusa mail at robertoragusa.it From sundaram at fedoraproject.org Sun Sep 30 13:31:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 30 Sep 2007 19:01:55 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FFA2E2.6030504@filteredperception.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> Message-ID: <46FFA54B.9020005@fedoraproject.org> Douglas McClendon wrote: > But you do see, that our point of disagreement is over whether or not > what I described was a 'modification'. I.e. your question is irrelevant > to the conversation, since no modification is taking place. I wasn't merely concerned about what you are doing. I was talking about the trademark guideline clauses which allow certain kind of modifications while retaining the name and whether they fit with the current project goals. >> Sure I'd love to have a legal license >>> which states that any free software I write, cannot be used by >>> governments to support in any way whatsoever an institution which >>> engages in 'baiting' tactics that use entrapment as justification for >>> murder, but I'm a realist. >> >> Such a restriction wouldn't qualify as Free software at all. > > That was my point. Copyright licenses and trademark guidelines are two different things. I could for example have Free software with trademark guidelines that didn't allow certain kind of things. If you want to do those things, you merely have to fork like Firefox and IceWeasel. The trademark requirements on Firefox the name does not make Firefox the software non-free. Rahul From snecklifter at gmail.com Sun Sep 30 14:31:15 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 30 Sep 2007 15:31:15 +0100 Subject: ibm-acpi, thinkpad_acpi (was: Thinkpad Fn-F5 Bluetooth Switch) In-Reply-To: <46FFA4A4.1010404@robertoragusa.it> References: <46FD57D7.2020005@redhat.com> <20070928145356.70a237b7@weaponx.rchland.ibm.com> <1191068503.3566.1.camel@choeger4> <364d303b0709291749u4c5f737fn1709f8e635b57481@mail.gmail.com> <1191142576.3630.2.camel@choeger4> <46FFA4A4.1010404@robertoragusa.it> Message-ID: <364d303b0709300731m3a89fbffsead8605ed07063a3@mail.gmail.com> On 30/09/2007, Roberto Ragusa wrote: > > Christoph H?ger wrote: > > Am Sonntag, den 30.09.2007, 01:49 +0100 schrieb Christopher Brown: > >> > >> I take it: > >> > >> # modprobe thinkpad-acpi > >> > >> doesn't do anything for you? > > > > Hi, > > > > I did not know that module until this morning. Thank you for the hint :) > > And to topic: I can use FN-F5 with this module in F7 with > > 2.6.22.9-91.fc7 > > It was called ibm-acpi until a few weeks ago, then it > changed for F7 too. > The path also changed and that causes a problem because > /etc/rc.d/rc.sysinit doesn't load the module. > > The new path is: > > /lib/modules/$unamer/kernel/drivers/misc/thinkpad_acpi.ko > > But the loading script does this: > > # Initialize ACPI bits > if [ -d /proc/acpi ]; then > for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do > module=${module##*/} > module=${module%.ko} > modprobe $module >/dev/null 2>&1 > done > fi > > I noticed because some gkrellm temperature readings (gkibm-acpi) are > unavailable without the module. It was moved to drivers/misc for 2.6.22 (and renamed from ibm-acpi to thinkpad-acpi) as it doesn't just cover acpi functions. As this is intentional it looks like sysinit will need tweaking. Maybe. I've filed a bug with patch for this. https://bugzilla.redhat.com/show_bug.cgi?id=313091 We'll see what happens. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Sun Sep 30 16:29:03 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 30 Sep 2007 17:29:03 +0100 Subject: PackageKit and pirut playing nicely Message-ID: <1191169743.2710.22.camel@hughsie-laptop> As I've mentioned in previous emails to this list, system-config-printers depends on pirut for installing other packages. Specifically, s-c-p calls /usr/bin/system-install-packages to install new print drivers. PackageKit has two helpers like this, pk-install-package and pk-install-file. The former allows a script or program to install "openoffice.org" using the PackageKit daemon (asking PolicyKit auth and resolving the package_id etc.) and the latter allows installing local files such as /tmp/moo-1.23.rpm How do I go about making s-c-p call into PackageKit instead? I'm guessing I have to "provide" /usr/bin/system-install-packages in the PackageKit spec file, and then install a symlink to pk-install-package - this would then leave two packages owning the same file. What's the Fedora way of solving this - maybe alternatives (which might be overkill) or maybe some cleverness in s-c-p? Thanks, Richard. From dmc.fedora at filteredperception.org Sun Sep 30 16:55:34 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 30 Sep 2007 11:55:34 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FFA54B.9020005@fedoraproject.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> <46FFA54B.9020005@fedoraproject.org> Message-ID: <46FFD506.6080708@filteredperception.org> Rahul Sundaram wrote: > Douglas McClendon wrote: > >> But you do see, that our point of disagreement is over whether or not >> what I described was a 'modification'. I.e. your question is >> irrelevant to the conversation, since no modification is taking place. > > I wasn't merely concerned about what you are doing. I was talking about > the trademark guideline clauses which allow certain kind of > modifications while retaining the name and whether they fit with the > current project goals. Can you give me an example of a permitted modification that is currently allowed that you think should not be? > >>> Sure I'd love to have a legal license >>>> which states that any free software I write, cannot be used by >>>> governments to support in any way whatsoever an institution which >>>> engages in 'baiting' tactics that use entrapment as justification >>>> for murder, but I'm a realist. >>> >>> Such a restriction wouldn't qualify as Free software at all. >> >> That was my point. > > Copyright licenses and trademark guidelines are two different things. I > could for example have Free software with trademark guidelines that > didn't allow certain kind of things. If you want to do those things, > you merely have to fork like Firefox and IceWeasel. The trademark > requirements on Firefox the name does not make Firefox the software > non-free. Can trademark guidelines on free software restrict the ability to redistribuite bit-for-bit copies of the software, that don't use the trademarks in any other way than the fact that they are included in those bits? -dmc From sundaram at fedoraproject.org Sun Sep 30 17:14:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 30 Sep 2007 22:44:48 +0530 Subject: Fedora spin from RpmFusion In-Reply-To: <46FFD506.6080708@filteredperception.org> References: <46FD4C23.1070309@hi.is> <46FD4DE1.8060904@redhat.com> <24306.88.149.97.225.1191016140.squirrel@webmail.hi.is> <46FD7CC0.7050109@fedoraproject.org> <46FD8204.4060008@filteredperception.org> <46FD86C8.1070309@fedoraproject.org> <46FDA813.9010104@filteredperception.org> <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> <46FFA54B.9020005@fedoraproject.org> <46FFD506.6080708@filteredperception.org> Message-ID: <46FFD988.6010206@fedoraproject.org> Douglas McClendon wrote: > Rahul Sundaram wrote: >> Douglas McClendon wrote: >> >>> But you do see, that our point of disagreement is over whether or not >>> what I described was a 'modification'. I.e. your question is >>> irrelevant to the conversation, since no modification is taking place. >> >> I wasn't merely concerned about what you are doing. I was talking >> about the trademark guideline clauses which allow certain kind of >> modifications while retaining the name and whether they fit with the >> current project goals. > > Can you give me an example of a permitted modification that is currently > allowed that you think should not be? I make no such claims. I just want Fedora Project Board to verify if the trademark guidelines match the project goals and see if any modifications are required in light of the interest in spins and derivatives. It might even be adding more permissions. > Can trademark guidelines on free software restrict the ability to > redistribuite bit-for-bit copies of the software, that don't use the > trademarks in any other way than the fact that they are included in > those bits? Unlike copyright licenses which are broadly consistent across various regions, trademark and patent laws seem to be quite different in scope. Someone more familiar with US trademark laws would have to answer your question. I know RHEL has some sort of requirements on plain redistribution based on a couple of non-software packages which contain the Red Hat branded images which appear to based on trademark. So it does seem to be possible but I haven't looked into it in depth. Rahul From Matt_Domsch at dell.com Sun Sep 30 18:11:15 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 30 Sep 2007 13:11:15 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <46FFD506.6080708@filteredperception.org> References: <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> <46FFA54B.9020005@fedoraproject.org> <46FFD506.6080708@filteredperception.org> Message-ID: <20070930181115.GA14773@auslistsprd01.us.dell.com> On Sun, Sep 30, 2007 at 11:55:34AM -0500, Douglas McClendon wrote: > Can trademark guidelines on free software restrict the ability to > redistribuite bit-for-bit copies of the software, that don't use the > trademarks in any other way than the fact that they are included in > those bits? yes, they can, which is why one of the feature of Fedora 8 is to clean up the fedora-logos and redhat-artwork packages, and the addition of the generic-logos package, exactly so one can create a derivative of Fedora using and containing only Free Software, easily, without including the Fedora trademarks. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Curtis at GreenKey.net Sun Sep 30 19:18:35 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Sun, 30 Sep 2007 12:18:35 -0700 (PDT) Subject: crystal-project crashes repoquery Message-ID: <20070930191835.D90536F1C2@alopias.GreenKey.net> Any idea who's bug this is anyways? $ repoquery -ql crystal-project Traceback (most recent call last): File "/usr/bin/repoquery", line 806, in main(sys.argv) File "/usr/bin/repoquery", line 803, in main repoq.runQuery(regexs) File "/usr/bin/repoquery", line 473, in runQuery print pkg.doQuery(oper) UnicodeEncodeError: 'latin-1' codec can't encode character u'\uf003' in position 25663: ordinal not in range(256) It's been most annoying due to its wholesale breakage of my favorite "repoquery -qal |grep foo" without providing any helpful info. It appears the problem stems from some corrupt filenames in crystal_project.tar.gz: crystal_project/*/apps/softwareD???.png Where those three oddball 8-bit chars are 0xEF, 0x80 and 0x83. But how on earth did the buildsys let that crap into fillists.xml.gz anyways? And are spaces and other 8-bit grunge really valid in the packaging guidelines? And why does yum-utils/python choke on it so badly, imagining that their is 16-bit Unicode involved? ../C From nicolas.mailhot at laposte.net Sun Sep 30 19:30:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 30 Sep 2007 21:30:24 +0200 Subject: crystal-project crashes repoquery In-Reply-To: <20070930191835.D90536F1C2@alopias.GreenKey.net> References: <20070930191835.D90536F1C2@alopias.GreenKey.net> Message-ID: <1191180624.10605.4.camel@rousalka.dyndns.org> Le dimanche 30 septembre 2007 ? 12:18 -0700, Curtis Doty a ?crit : > It's been most annoying due to its wholesale breakage of my favorite > "repoquery -qal |grep foo" without providing any helpful info. > > It appears the problem stems from some corrupt filenames in > crystal_project.tar.gz: crystal_project/*/apps/softwareD???.png Where > those three oddball 8-bit chars are 0xEF, 0x80 and 0x83. It's probably a repoquery bug ? our python tools are supposed to handle UTF-8 but this has not been impressed strongly enough on their writers at the right time. And current python is a mess on the unicode front, so software writers have to care about it for stuff to work. > But how on earth did the buildsys let that crap into fillists.xml.gz > anyways? Because that's what in the package? > And are spaces and other 8-bit grunge really valid in the > packaging guidelines? Our policy is UTF-8 filenames are valid package content -- 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 tmus at tmus.dk Sun Sep 30 20:57:17 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 30 Sep 2007 18:57:17 -0200 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? Message-ID: Hi there... It seems (noted in releasenotes) that F7 should have a VMI (Virtual Machine Interface) enabled kernel by default, but from what I can find in the .config files it doesn't... Do I need a special kernel (i.e. only the XEN kernel has VMI or something) or was it lost in a kernel update or...? /Thomas From dmc.fedora at filteredperception.org Sun Sep 30 21:23:33 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 30 Sep 2007 16:23:33 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <20070930181115.GA14773@auslistsprd01.us.dell.com> References: <46FDAF00.3040303@fedoraproject.org> <46FDB975.6020209@filteredperception.org> <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> <46FFA54B.9020005@fedoraproject.org> <46FFD506.6080708@filteredperception.org> <20070930181115.GA14773@auslistsprd01.us.dell.com> Message-ID: <470013D5.8010905@filteredperception.org> Matt Domsch wrote: > On Sun, Sep 30, 2007 at 11:55:34AM -0500, Douglas McClendon wrote: >> Can trademark guidelines on free software restrict the ability to >> redistribuite bit-for-bit copies of the software, that don't use the >> trademarks in any other way than the fact that they are included in >> those bits? > > yes, they can, which is why one of the feature of Fedora 8 is to clean > up the fedora-logos and redhat-artwork packages, and the addition of > the generic-logos package, exactly so one can create a derivative of > Fedora using and containing only Free Software, easily, without including > the Fedora trademarks. Certainly for derivatives and any other modification, it seems obvious that trademarks are protected. My question rather involved bundling an unmodified copy of free software with other (free and/or non-free) software. My not-a-lawyer hunch is that the nature of free software suggests that it may be redistributed unmodified in any and all manner. But a hunch is hardly anything to go by. My scenario involved supplying the end-user with software that makes it dirt-simple (i.e. a bootloader choice) for the end-user to apply patches. This is somewhat similar to the ideas I have heard kicked around regarding supplying kernel modules as source along with scripts that make it as simple for the end-user to turn the source into the binary, which for obscure legal reasons could not be distributed as a binary. -dmc From Matt_Domsch at dell.com Sun Sep 30 21:44:38 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 30 Sep 2007 16:44:38 -0500 Subject: Fedora spin from RpmFusion In-Reply-To: <470013D5.8010905@filteredperception.org> References: <46FDBD57.6090409@fedoraproject.org> <20070929025629.GA32005@nostromo.devel.redhat.com> <46FDBFBE.9050708@fedoraproject.org> <46FEF33E.3000506@filteredperception.org> <46FF9BBA.4030002@fedoraproject.org> <46FFA2E2.6030504@filteredperception.org> <46FFA54B.9020005@fedoraproject.org> <46FFD506.6080708@filteredperception.org> <20070930181115.GA14773@auslistsprd01.us.dell.com> <470013D5.8010905@filteredperception.org> Message-ID: <20070930214438.GA26047@auslistsprd01.us.dell.com> On Sun, Sep 30, 2007 at 04:23:33PM -0500, Douglas McClendon wrote: > Matt Domsch wrote: > >On Sun, Sep 30, 2007 at 11:55:34AM -0500, Douglas McClendon wrote: > >>Can trademark guidelines on free software restrict the ability to > >>redistribuite bit-for-bit copies of the software, that don't use the > >>trademarks in any other way than the fact that they are included in > >>those bits? > > > >yes, they can, which is why one of the feature of Fedora 8 is to clean > >up the fedora-logos and redhat-artwork packages, and the addition of > >the generic-logos package, exactly so one can create a derivative of > >Fedora using and containing only Free Software, easily, without including > >the Fedora trademarks. > > Certainly for derivatives and any other modification, it seems obvious > that trademarks are protected. My question rather involved bundling an > unmodified copy of free software with other (free and/or non-free) software. > > My not-a-lawyer hunch is that the nature of free software suggests that > it may be redistributed unmodified in any and all manner. But a hunch > is hardly anything to go by. > > My scenario involved supplying the end-user with software that makes it > dirt-simple (i.e. a bootloader choice) for the end-user to apply > patches. This is somewhat similar to the ideas I have heard kicked > around regarding supplying kernel modules as source along with scripts > that make it as simple for the end-user to turn the source into the > binary, which for obscure legal reasons could not be distributed as a > binary. AIUI, the obscure legal reasoning seems to be that if the distribution delivers pre-linked kernel modules, such infringes the kernel's copyright; but if the linking is done by end users, that it somehow doesn't infringe that copyright. I've never been comfortable with this line of thinking myself. If true, it feels like passing the buck, and I grew up in Independence, MO[1]. One challenge to Free Software is that it's based upon copyright law. The other two pillars of "intellectual property law" are patents and trademarks, neither of which are often adequately addressed in copyright licenses, insofar as they're not even mentioned. GNU GPL v2 does include some text regarding patents; v3 even more so. So unless you adequately license patents and trademarks too, copyright licenses don't convey "all" the rights one might need to do "anything you want". GPL doesn't speak to modifications - it's obligations are incurred at point of distribution of the work, modified or not. [1] Home of Harry S. Truman, 33rd President of the United States. Famous for the saying "the buck stops here". -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From snecklifter at gmail.com Sun Sep 30 21:47:06 2007 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 30 Sep 2007 22:47:06 +0100 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: References: Message-ID: <364d303b0709301447x267ed64bi13dd366cf5dbeb8@mail.gmail.com> On 30/09/2007, Thomas M Steenholdt wrote: > > Hi there... > > It seems (noted in releasenotes) that F7 should have a VMI (Virtual > Machine Interface) enabled kernel by default, but from what I can find > in the .config files it doesn't... Do I need a special kernel (i.e. only > the XEN kernel has VMI or something) or was it lost in a kernel update > or...? Could you point me to where it says this in the release notes - I cant see it. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at dell.com Sun Sep 30 21:52:55 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 30 Sep 2007 16:52:55 -0500 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: References: Message-ID: <20070930215255.GB26047@auslistsprd01.us.dell.com> On Sun, Sep 30, 2007 at 06:57:17PM -0200, Thomas M Steenholdt wrote: > Hi there... > > It seems (noted in releasenotes) that F7 should have a VMI (Virtual > Machine Interface) enabled kernel by default, but from what I can find > in the .config files it doesn't... Do I need a special kernel (i.e. only > the XEN kernel has VMI or something) or was it lost in a kernel update > or...? in config-x86-generic: CONFIG_VIRTUALIZATION=y CONFIG_VMI=y CONFIG_LGUEST=m but it doesn't appear that CONFIG_VMI is enabled on the x86_64 kernel in config-2.6.23-0.214.rc8.git2.fc8. Unless there's a better answer shortly, please file this as a bug against the kernel. It may just be an oversight. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From tmus at tmus.dk Sun Sep 30 22:24:07 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 30 Sep 2007 20:24:07 -0200 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: <364d303b0709301447x267ed64bi13dd366cf5dbeb8@mail.gmail.com> References: <364d303b0709301447x267ed64bi13dd366cf5dbeb8@mail.gmail.com> Message-ID: Christopher Brown wrote: > Could you point me to where it says this in the release notes - I cant > see it. > http://fedoraproject.org/wiki/F7ReleaseSummary /Thomas From tmus at tmus.dk Sun Sep 30 22:25:48 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 30 Sep 2007 20:25:48 -0200 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: <20070930215255.GB26047@auslistsprd01.us.dell.com> References: <20070930215255.GB26047@auslistsprd01.us.dell.com> Message-ID: Matt Domsch wrote: > > in config-x86-generic: > > CONFIG_VIRTUALIZATION=y > CONFIG_VMI=y > CONFIG_LGUEST=m > > but it doesn't appear that CONFIG_VMI is enabled on the x86_64 kernel > in config-2.6.23-0.214.rc8.git2.fc8. Unless there's a better answer > shortly, please file this as a bug against the kernel. It may just be > an oversight. > That's very much like what I'm seeing on i686... Perhaps the configs are not applied correctly for some reason?!? /Thomas From sundaram at fedoraproject.org Sun Sep 30 22:33:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 01 Oct 2007 04:03:49 +0530 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: References: <364d303b0709301447x267ed64bi13dd366cf5dbeb8@mail.gmail.com> Message-ID: <4700244D.30900@fedoraproject.org> Thomas M Steenholdt wrote: > Christopher Brown wrote: >> Could you point me to where it says this in the release notes - I cant >> see it. >> > http://fedoraproject.org/wiki/F7ReleaseSummary I wrote up the release summary and release notes overview based on what I saw in the kernel configuration. Looks like a bug that needs to be fixed. Rahul From docs-list at fedoralinks.org Sun Sep 30 21:53:42 2007 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Sun, 30 Sep 2007 16:53:42 -0500 Subject: Kernel VMI (Virtual Machine Interface) in F7/F8? In-Reply-To: References: Message-ID: <47001AE6.8040400@fedoralinks.org> Thomas M Steenholdt wrote: > Hi there... > > It seems (noted in releasenotes) that F7 should have a VMI (Virtual > Machine Interface) enabled kernel by default, but from what I can find > in the .config files it doesn't... Do I need a special kernel (i.e. only > the XEN kernel has VMI or something) or was it lost in a kernel update > or...? > > /Thomas > The page http://fedoraproject.org/wiki/F7ReleaseSummary mentions VMware's VMI. "This release includes the 2.6.21 based kernel which integrates Kernel-based Virtual Machine (KVM) technology with Fedora's graphical virt-manager and command-line virsh tools. KVM provides a hardware accelerated virtualization solution, and users have a choice between KVM and Xen, along with Qemu, in this release. The kernel included in this release also has support for VMWare's VMI interface." I do not find any other mention of VMI on the Wiki or in the release notes. Robert 'Bob' Jensen Fedora Unity Project http://fedoraunity.org/ bob at fedoraunity.org From michel.sylvan at gmail.com Thu Sep 6 21:02:35 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 06 Sep 2007 21:02:35 -0000 Subject: Killing maintainers In-Reply-To: <20070905173132.655bc3ae@mentok.boston.redhat.com> References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com> <20070905173132.655bc3ae@mentok.boston.redhat.com> Message-ID: On 05/09/07, Jesse Keating wrote: > On Wed, 5 Sep 2007 22:26:24 +0100 > "Jonathan Underwood" wrote: > > > What is the quickest way of getting this done? Which of the myriad > > committees does this need to go through? > > I will be pushing this through FESCo tomorrow. > If the mailing list software allows the use of +FOO suffix, an alternative to mailing list proliferation is to have a main -devel-list (like now), with major subcategories suffixed at the end? People can then filter and prioritize their list messages accordingly. Cheers, -- Michel From buildsys at redhat.com Sat Sep 8 13:53:57 2007 From: buildsys at redhat.com (Build System) Date: Sat, 08 Sep 2007 13:53:57 -0000 Subject: rawhide report: 20070908 changes Message-ID: <200709081353.l88DruvV003688@porkchop.devel.redhat.com> New package HippoDraw Interactive and Python scriptable data analysis application New package Pixie 3D renderer Renderman compliant New package alpine UW Alpine mail user agent New package armacycles-ad A lightcycle game in 3D New package aspell-sk Slovak dictionaries for Aspell New package audio-convert-mod A simple audio file converter supporting many formats New package blktrace Utilities for performing block layer IO tracing in the linux kernel New package cheese A webcam application for snapshots and movies New package eclipse-rpm-editor RPM Specfile editor for Eclipse New package flashrom Simple program for reading/writing BIOS chips content New package g-wrap A tool for creating Scheme interfaces to C libraries New package gimmage A Simple GNOME Image Viewer New package klear DVB TV application and harddisk-recorder for linux New package libflaim Embeddable cross-platform database engine New package maniadrive 3D stunt driving game New package maniadrive-data Data files for maniadrive, a 3D stunt driving game New package maniadrive-music Replacement soundtrack for the non free ManiaDrive soundtrack New package obexfs FUSE based filesystem using ObexFTP New package perl-IPC-Run3 Run a subprocess in batch mode (a la system) on Unix, Win32, etc New package pharosc VLSI and ASIC Technology Standard Cell Libraries New package php-pecl-memcache Extension to work with the Memcached caching daemon New package python-boto A simple lightweight interface to Amazon Web Services New package rubygem-rake Ruby based make-like utility New package scim-array SCIM Array 30 Input Method Engine New package sepostgresql Security Enhanced PostgreSQL New package setroubleshoot-plugins Analysis plugins for use with setroubleshoot New package system-config-vsftpd A graphical interface for administering vsftpd server New package tomcat-native Tomcat native library New package xorg-x11-drv-vermilion Xorg driver for Intel Vermilion Range chipset Updated Packages: CGAL-3.3.1-2.fc8 ---------------- * Mon Sep 03 2007 Laurent Rineau - 3.3.1-2.fc8 - Fix soversion. * Mon Sep 03 2007 Laurent Rineau - 3.3.1-1.fc8 - New upstream bug-fixes release. GeoIP-1.4.3-1.fc8 ----------------- * Wed Sep 05 2007 Michael Fleming 1.4.3-1 - New upstream release. - Fix GeoIPCity fetcher script - Update License tag PolicyKit-0.5-3.fc8 ------------------- * Fri Aug 31 2007 David Zeuthen - 0.5-3.fc8 - Rebuild * Fri Aug 31 2007 David Zeuthen - 0.5-2.fc8 - Upstream release 0.5 * Fri Aug 10 2007 Matthias Clasen - 0.5-1.git20070731.fc8 - Add missing Requires (#251268) - Own /etc/PolicyKit (#251274) PolicyKit-gnome-0.5-4.fc8 ------------------------- * Mon Sep 03 2007 Matthias Clasen - 0.5-4 - Add gettext BR * Fri Aug 31 2007 David Zeuthen - 0.5-3.fc8 - Rebuild * Fri Aug 31 2007 David Zeuthen - 0.5-2.fc8 - Require newer PolicyKit release PyOpenGL-3.0.0-0.4.a6.fc8 ------------------------- * Thu Aug 30 2007 Hans de Goede 3.0.0-0.4.a6 - Change BuildRequiresL python-setuptools to python-setuptools-devel for the python-setuptools package split TurboGears-1.0.2.2-3.fc8 ------------------------ * Sun Sep 02 2007 Luke Macken 1.0.2.2-3 - Update for python-setuptools changes in rawhide abiword-1:2.4.6-6.fc8 --------------------- * Tue Sep 04 2007 Lubomir Kundrak - 1:2.4.6-6.fc7 - Fix 248103 adns-1.2-6.fc8 -------------- * Fri Aug 31 2007 Radek Vok??l 1.2-6 - rebuilt alfont-2.0.6-3.fc8 ------------------ amarok-1.4.7-4.fc8 ------------------ * Sun Sep 02 2007 Aurelien Bompard 1.4.7-4 - add patch for kde bug 147126 : amarok freezes when trying to play mp3 files without mp3 support * Fri Aug 24 2007 Todd Zullinger 1.4.7-3 - rebuild with libgpod-0.5.2 * Sat Aug 18 2007 Aurelien Bompard 1.4.7-2 - version 1.4.7 amtterm-1.0-1.fc8 ----------------- * Fri Aug 31 2007 Gerd Hoffmann - 1.0-1 - update to version 1.0 * more amttool improvements (network config). - don't strip binaries (bug #269241). anacron-2.3-55.fc8 ------------------ * Fri Aug 31 2007 Marcela Maslanova 2.3-55 - change chkconfig --add, because it wasn't running after fresh install #267801 * Thu Aug 30 2007 Marcela Maslanova 2.3-54 - change chkconfig levels in post part asciidoc-8.2.2-1.fc8 -------------------- * Sat Sep 01 2007 Florian La Roche - 8.2.2-1 - new upstream version 8.2.2 aspell-en-50:6.0-8.fc8 ---------------------- * Thu Aug 30 2007 Ivana Varekova - 50:6.0-8 - fix #62225 - add practice to gb world lists audit-1.6.1-2.fc8 ----------------- * Thu Sep 06 2007 Steve Grubb 1.6.1-2 - Fix uninitialized variable in auparse (John Dennis) autofs-1:5.0.2-15 ----------------- * Wed Sep 05 2007 Ian Kent - 5.0.2-15 - fix LDAP schema discovery. avahi-0.6.21-5.fc8 ------------------ * Thu Sep 06 2007 Lennart Poettering - 0.6.21-5 - resolves #249044: Update init script to use runlevel 96 - resolves #251700: Fix assertion in libdns_sd-compat * Thu Sep 06 2007 Lennart Poettering - 0.6.21-4 - Ship ssh static service file by default, don't ship ssh-sftp by default - resolves: #269741: split off avahi-ui-tools package - resolves: #253734: add missing dependency on avahi-glib-devel to avahi-ui-devel bacula-2.0.3-11.fc8 ------------------- * Wed Sep 05 2007 Andreas Thienemann - 2.0.3-11 - Remove spooldir in client, fixing #251879 - Remove dependency on libtermcap, fixing #251158 balsa-2.3.20-1.fc8 ------------------ * Fri Sep 07 2007 Pawel Salek - 2.3.20-1 - update to upstream 2.3.20. banshee-0.13.1-1.fc8 -------------------- * Fri Aug 31 2007 Christopher Aillon - 0.13.1-1 - Update to 0.13.1 bash-3.2-18.fc8 --------------- * Fri Aug 31 2007 Pete Graner - 3.2-18 - Added bash32-021 upstream official patch - Added bash32-025 upstream official patch - Added bash32-024 upstream official patch - Added bash32-023 upstream official patch - Added bash32-022 upstream official patch beagle-0.2.18-1.fc8 ------------------- * Tue Sep 04 2007 Matthias Clasen - 0.2.18-1 - Update to 0.2.18 - Update the license field beneath-a-steel-sky-0.0348-4.fc8 -------------------------------- * Fri Aug 31 2007 Hans de Goede 0.0348-4 - Fix Source0 URL bigboard-0.5.12-2.fc8 --------------------- * Fri Sep 07 2007 Colin Walters - 0.5.12-2 - some brs * Thu Sep 06 2007 Colin Walters - 0.5.12-1 - new upstream bind-32:9.5.0-12.a6.fc8 ----------------------- * Thu Sep 06 2007 Adam Tkac 32:9.5.0-12.a6 - bind-9.5-2119_revert.patch and bind-9.5-fix_h_errno.patch are obsoleted by upstream bind-9.5-_res_errno.patch * Wed Sep 05 2007 Adam Tkac 32:9.5.0-11.9.a6 - fixed wrong resolver's dispatch pool cleanup (#275011, patch from tmraz redhat com) * Wed Sep 05 2007 Adam Tkac 32:9.5.0-11.3.a6 - initscript failure message is now printed correctly (#277981, Quentin Armitage (quentin armitage org uk) ) bitbake-1.8.8-1.fc8 ------------------- * Fri Aug 31 2007 Andreas Thienemann - 1.8.8-1 - Updated to 1.8.8 bluez-gnome-0.14-2.fc8 ---------------------- * Fri Aug 31 2007 - Bastien Nocera - 0.14-2 - Remove the obex BR, we're not using it yet - Build with HAL support bluez-libs-3.17-1.fc8 --------------------- * Thu Aug 30 2007 David Woodhouse - 3.17-1 - Update to bluez-libs 3.17 bluez-utils-3.17-1.fc8 ---------------------- * Thu Aug 30 2007 David Woodhouse 3.17-1 - Update to bluez-utils 3.17 bouml-2.31.1-1.fc8 ------------------ * Thu Sep 06 2007 Debarshi Ray - 2.31.1-1 - Version bump to 2.31.1. * Wed Aug 22 2007 Debarshi Ray - 2.30.2-1 - Version bump to 2.30.2. - Cleaned up SPEC. * Sat Aug 04 2007 Debarshi Ray - 2.30.1-1 - Version bump to 2.30.1. - Changed value of License according to Fedora licensing guidelines. - Executable bits turned off for C++ sources by upstream. - Application removed from Categories by upstream. bug-buddy-1:2.19.91-1.fc8.svn20070904 ------------------------------------- * Mon Sep 03 2007 Matthias Clasen - 1:2.19.91.fc8.svn20070904-1 - Update to a post-2.19.91 snapshot busybox-1:1.6.1-2.fc8 --------------------- * Tue Sep 04 2007 Ivana Varekova - 1:1.6.1-2 - spec file cleanup bzflag-2.0.8-5.fc8 ------------------ * Wed Sep 05 2007 Nils Philippsen 2.0.8-5 - change license tag from LGPL to LGPLv2, the licensing is a bit ambigious about if it's "V2.1 only" or "V2.1 or later". I've requested upstream to clarify this: http://sf.net/tracker/?func=detail&aid=1788424&group_id=3248&atid=103248 * Fri Jun 22 2007 Nils Philippsen - change license tag from GPL to LGPL bzr-0.90-1.fc8 -------------- * Tue Aug 28 2007 Toshio Kuratomi - 0.90-1 - Update to 0.90 * Mon Aug 27 2007 Toshio Kuratomi - 0.90-0.1.rc1 - Update to 0.90rc1. - 0.90 contains some pyrex code to speed things up. bzr is now arch specific. - Update license tag. * Wed Jul 25 2007 Warren Togami - 0.18-1 - Update to 0.18. bzrtools-0.90.0-2.fc8 --------------------- * Thu Aug 30 2007 Toshio Kuratomi 0.90.0-2 - Move plugin manually since setuptools has no way of knowing that bzr is arch specific. - Disable debuginfo packages. * Tue Aug 28 2007 Toshio Kuratomi 0.90.0-1 - Update to 0.90.0. - Fix License tag to conform to the new Licensing Guidelines. - Bzr is now arch specific so all its plugins have to be as well. cdlabelgen-4.0.0-1.fc8 ---------------------- * Thu Sep 06 2007 Dominik 'Rathann' Mierzejewski 4.0.0-1 - updated to 4.0.0 - preserve timestamps upon install claws-mail-3.0.0-1.fc8 ---------------------- * Mon Sep 03 2007 Andreas Bierfert - 3.0.0-1 - version upgrade - new license tag (upstream switch to GPLv3+) - fix #254121 (CVE-2007-2958) clutter-0.4.1-1.fc8 ------------------- * Mon Sep 03 2007 Allisson Azevedo 0.4.1-1 - Update to 0.4.1 clutter-gst-0.4.0-1.fc8 ----------------------- clutter-gtk-0.4.0-1.fc8 ----------------------- * Mon Sep 03 2007 Allisson Azevedo 0.4.0-1 - Update to 0.4.0 cobbler-0.6.1-2.fc8 ------------------- * Thu Aug 30 2007 Michael DeHaan - 0.6.1-2 - Upstream changes (see CHANGELOG) codeblocks-1.0-0.27.20070828svn4413.fc8 --------------------------------------- * Wed Aug 29 2007 Dan Horak 1.0-0.27.20070828svn4413 - update to revision 4413 - update the License tag control-center-1:2.19.92-1.fc8 ------------------------------ * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 * Thu Aug 30 2007 - Bastien Nocera - 2.19.91.-1 - Update to 2.19.91 - Update the background and the default-apps patches cpio-2.9-4.fc8 -------------- * Tue Sep 04 2007 Radek Brich 2.9-4 - Updated license tag crash-4.0-4.6.2 --------------- * Wed Aug 29 2007 Dave Anderson - 4.0-4.6.2 - Updated crash.patch to match upstream version 4.0-4.6. crontabs-1.10-17.fc8 -------------------- * Thu Aug 30 2007 Marcela Maslanova 1.10-17 - better solution of configuration script curl-7.16.4-5.fc8 ----------------- * Thu Sep 06 2007 Jindrich Novy 7.16.4-5 - add support for the NSS PKCS#11 pem reader so the command-line is the same for both OpenSSL and NSS by Rob Crittenden (rcritten at redhat.com) - switch to NSS again db4-4.6.19-1.fc8 ---------------- * Mon Sep 03 2007 Jindrich Novy 4.6.19-1 - update to 4.6.19 (#273461) * Wed Aug 29 2007 Jindrich Novy 4.6.18-2 - rebuild for BuildID - BR util-linux-ng * Mon Jul 30 2007 Jindrich Novy 4.6.18-1 - update to 4.6.18 - drop upstream patches for 4.5.20 and gcj patch - remove nptl-abi-note.S, useless as we are definitely running kernel >= 2.4.20 (#245416) - move C++ stuff to subpackages to reduce dependency bloat (#220484) - package db_codegen - correct open() calls so that new db4 compiles with the new glibc deluge-0.5.4.1.95-1.fc8 ----------------------- * Mon Sep 03 2007 Peter Gordon - 0.5.4.1.95-1 - Update to new upstream release candidate (0.5.5 RC1) * Mon Aug 13 2007 Peter Gordon - 0.5.4.1-1 - Update to new upstream release (0.5.4.1) - Build with new binutils to gain BuildID debugging goodness. * Mon Aug 06 2007 Peter Gordon - 0.5.4-1 - Update to new upstream release (0.5.4) desktop-backgrounds-7.92-4 -------------------------- * Thu Sep 06 2007 Bill Nottingham - 7.92-4 - fix symlinks dhcp-12:3.0.6-4.fc8 ------------------- * Tue Sep 04 2007 David Cantrell - 12:3.0.6-4 - Do not override manually configured NTP servers in /etc/ntp.conf (#274761) dhcpv6-0.10-47.fc8 ------------------ * Tue Sep 04 2007 David Cantrell - 0.10-47 - Do not parse an empty /var/lib/dhcpv6/server6.leases file (#253968) dietlibc-0.31-1.fc8 ------------------- * Sat Sep 01 2007 Enrico Scholz - 0.31-1 - updated to 0.31 - removed the no-stack-protector bits for i386 and x86_64 archs - improved stack-smash code a little bit - disabled dynamic lib for all arches - made objects non-executable to avoid "No build ID note" errors docbook-style-xsl-1.73.2-2.fc8 ------------------------------ * Fri Sep 07 2007 Ondrej Vasik 1.73.2-2 - Added PreReq of libxml2(#253962) dstat-0.6.6-2.fc8 ----------------- * Tue Sep 04 2007 Radek Brich - 0.6.6-2 - Updated license tag. - Spec clean up. dvd+rw-tools-7.0-7.fc8 ---------------------- * Fri Aug 31 2007 Matthias Saou 7.0-7 - Minor spec file cleanups (tabs vs. spaces, etc.). - Use install instead of cp for the html file to avoid umask differences. e2fsprogs-1.40.2-5.fc8 ---------------------- * Fri Sep 07 2007 Eric Sandeen 1.40.2-5 - wrap a couple headers to fix multilib issues (#270441) eclipse-1:3.3.0-18.fc8 ---------------------- * Fri Sep 07 2007 Ben Konrath 3.3.0-18 - Build 1.6 plugins when building with IcedTea. * Fri Sep 07 2007 Ben Konrath 3.3.0-17 - Update Fedora Eclipse product plugin to fix Welcome page. * Thu Sep 06 2007 Ben Konrath 3.3.0-16 - Compile SDK to 1.5 bytecode and disable 1.6 plugins. ejabberd-1.1.4-1.fc8 -------------------- * Wed Sep 05 2007 Jeffrey C. Ollie - 1.1.4-1 - Drop LDAP patch - Update mod_ctlextra - Update to 1.1.4 * Tue Sep 04 2007 Jeffrey C. Ollie - 1.1.3-11 - Fix ejabberdctl wrapper script - #276071 emacs-vm-8.0.3.495-3.fc8 ------------------------ * Thu Aug 30 2007 Jonathan G. Underwood - 8.0.3.495-3 - Fix problem with vm-autoloads.el RH BZ #262361 empathy-0.12-2.fc8 ------------------ * Fri Aug 31 2007 Peter Gordon - 0.12-2 - Add ldconfig invocations to %post and %postun scriptlets. * Fri Aug 31 2007 Peter Gordon - 0.12-1 - Update to new upstream release (0.12). - Build against new mission-control stack. - Update License tag (GPLv2+). - Alphabetize BuildRequires list (aesthetic-only change). eog-2.19.92-1.fc8 ----------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 epiphany-2.19.91-1.fc8 ---------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 * Fri Aug 24 2007 Adam Jackson - 2.19.90-2 - Rebuild for build ID * Mon Aug 13 2007 Matthias Clasen - 2.19.90-1 - Update to 2.19.90 epiphany-extensions-2.19.90-1.fc8 --------------------------------- * Tue Sep 04 2007 Peter Gordon - 2.19.90-1 - Update to new upstream release (2.19.90), which contains reworked installation rules for the icons and a fix for the Greasemonkey extension so that it does not break when the directory is not created (GNOME bug 437648). esc-1.0.1-7.fc8 --------------- * Thu Aug 30 2007 Jack Magne License field change- 1.0.1-7 evince-2.19.92-1.fc8 -------------------- * Tue Sep 04 2007 Kristian H??gsberg - 2.19.92-1 - Update to 2.19.92. Evince now follows GNOME version numbers. evolution-2.11.92-1.fc8 ----------------------- * Mon Sep 03 2007 Matthew Barnes - 2.11.92-1.fc8 - Update to 2.11.92 * Wed Aug 29 2007 Matthew Barnes - 2.11.91-3.fc8 - Revise patch for GNOME bug #362638 to fix GNOME bug #357175 (Evolution fails to close after IMAP alert has been displayed). * Tue Aug 28 2007 Matthew Barnes - 2.11.91-2.fc8 - Fix compilation breakage caused by our strict build settings. evolution-data-server-1.11.92-1.fc8 ----------------------------------- * Mon Sep 03 2007 Matthew Barnes - 1.11.92-1.fc8 - Update to 1.11.92 evolution-exchange-2.11.92-1.fc8 -------------------------------- * Mon Sep 03 2007 Matthew Barnes - 2.11.92-1.fc8 - Update to 2.11.92 exempi-1.99.4-2.fc8 ------------------- exim-4.68-1.fc8 --------------- * Fri Aug 31 2007 David Woodhouse 4.68-1 - Update to 4.68 exim-doc-4.68-1.fc8 ------------------- * Fri Aug 31 2007 David Woodhouse 4.68-1 - Update to 4.68 fetchmail-6.3.8-3.fc8 --------------------- * Tue Sep 04 2007 Vitezslav Crhonek - 6.3.8-3 - Fix CVE-2007-4565 file-roller-2.19.92-1.fc8 ------------------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 * Fri Aug 24 2007 Adam Jackson - 2.19.90-2 - Rebuild for build ID freenx-0.7.0-1.fc8 ------------------ * Thu Sep 06 2007 Jon Ciesla - 0.7.0-1 - CM = Christian Mandery mail at chrismandery.de, BZ 252976 - Version bump to 0.7.0 upstream release (CM) - Fixed download URL (didn't work, Berlios changed layout). (CM) - Changed license field from GPL to GPLv2 in RPM. (CM) - Fixed release. freetype1-1.4-0.4.pre.fc8 ------------------------- * Wed Sep 05 2007 Hans de Goede 1.4-0.4.pre - Update license tag fwfstab-0.01.1-6.fc8 -------------------- * Sat Sep 01 2007 Stewart Adam 0.01.1-6 - /still/ not working, perhaps I do need python as a BR fwrestart-1.05-1.fc8 -------------------- * Tue Sep 04 2007 Kevin Fenzi - 1.05-1 - Update to 1.0.5 - Clarify License gallery2-2.2-0.7.svn20070831.fc8 -------------------------------- * Fri Aug 31 2007 John Berninger - 2.2-0.7.svn20070831 - update to 2.2.3 SVN snapshot to fix security vuln's - bz 267421 gcalctool-5.19.92-1.fc8 ----------------------- * Tue Sep 04 2007 Matthias Clasen - 5.19.92-1 - Update to 5.19.92 gcc-4.1.2-23 ------------ * Fri Sep 07 2007 Jakub Jelinek 4.1.2-23 - fix __builtin_va_arg_pack () support for C++ * Thu Sep 06 2007 Jakub Jelinek 4.1.2-22 - backport __builtin_va_arg_pack () support - make sure __builtin_{,v}{,f}{print,scan}f, __builtin_{,f}printf_unlocked and __builtin___{,v}{,f}printf_chk can throw - handle __*_chk builtins without __builtin_ in the name as anticipated in C++ * Sat Sep 01 2007 Jakub Jelinek 4.1.2-21 - fix libmudflap-devel multilib conflict on ppc/ppc64 and sparc/sparc64 (#270281) gconf-editor-2.18.2-1.fc8 ------------------------- * Mon Sep 03 2007 Matthias Clasen - 2.18.2-1 - Update to 2.18.2 gd-2.0.34-3.fc8 --------------- * Tue Sep 04 2007 Ivana Varekova 2.0.34-3 - fix font paths (#225786#5) - fix pkgconfig Libs flag (#225786#4) * Thu Feb 22 2007 Ivana Varekova 2.0.34-2 - incorporate package review feedback * Thu Feb 08 2007 Ivana Varekova 2.0.34-1 - update to 2.0.34 gdm-1:2.19.8-3.fc8 ------------------ * Fri Sep 07 2007 Ray Strode - 1:2.19.8-3 - rebuild --with-selinux * Fri Sep 07 2007 Ray Strode - 1:2.19.8-2 - make things work better for xguest users (bug 254164) * Fri Sep 07 2007 Matthias Clasen - 1:2.19.8-1 - Update to 2.19.8 gedit-1:2.19.91-1.fc8 --------------------- * Tue Sep 04 2007 Matthias Clasen - 1:2.19.91-1 - Update to 2.19.91 ghex-2.19.91-1 -------------- * Fri Aug 31 2007 Thorsten Leemhuis - 2.19.91-1 - Update to 2.19.91 gimp-2:2.4.0-0.rc2.2.fc8 ------------------------ * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc2.2 - rebuild to pick up new version of poppler * Tue Sep 04 2007 Nils Philippsen - 2:2.4.0-0.rc2.1 - version 2.4.0-rc2 * Thu Aug 16 2007 Nils Philippsen - 2:2.4.0-0.rc1.1 - version 2.4.0-rc1 - change license tags to GPLv2+ (main app), LGPLv2+ (libs and devel) - drop libXt-devel build requirement - build-require pygobject2-devel directly - don't let %postun fail - remove obsolete buildroot, gimphelpmissing, icontheme, gifload, gimptool patches - update htmlview patch - use more distinct build root - use %buildroot consistently - explicitely enable configure options - more versionized build requirements - don't rebuild autofoo files - reformat spec file a bit git-1.5.3.1-2.fc8 ----------------- * Thu Sep 06 2007 Josh Boyer 1.5.3.1-2 - Include git-gui and git-citool docs * Thu Sep 06 2007 Josh Boyer 1.5.3.1-1 - git-1.5.3.1-1 gkrellm-2.3.0-4.fc8 ------------------- * Wed Sep 05 2007 Ville Skytt?? - 2.3.0-4 - Rewrite gkrellmd init script: better LSB compliance, hddtemp interoperability, avoidance of X error messages, general cleanup. * Tue Sep 04 2007 Ville Skytt?? - 2.3.0-3 - Fix gnutls detection/build and use it instead of openssl. - Sync user and group creation with current Fedora guidelines. * Tue Aug 07 2007 Hans de Goede 2.3.0-2 - Update License tag for new Licensing Guidelines compliance gkrellm-volume-2.1.13-6.fc8 --------------------------- * Tue Sep 04 2007 Ville Skytt?? - 2.1.13-6 - Convert docs to UTF-8. glest-2.0.1-1.fc8 ----------------- * Sun Sep 02 2007 Aurelien Bompard 2.0.1-1 - version 2.0.1 - patch1 merged upstream * Sun Aug 26 2007 Aurelien Bompard 2.0.0-7 - fix ExcludArch tag (no comma allowed) * Sat Aug 25 2007 Aurelien Bompard 2.0.0-6 - rebuild for BuildID - fix license tag glibmm24-2.13.9-3.fc8 --------------------- * Thu Sep 06 2007 Denis Leroy - 2.13.9-3 - Removed Perl code autogeneration tools (#278191) gnash-0.8.1-3.fc8 ----------------- * Fri Sep 07 2007 Patrice Dumas 0.8.1-3 - better documentation generation * Wed Sep 05 2007 Patrice Dumas 0.8.1-2 - update to 0.8.1 - agg is now the default renderer gnome-applets-1:2.19.91-1.fc8 ----------------------------- * Tue Sep 04 2007 Matthias Clasen - 1:2.19.91-1 - Update to 2.19.91 gnome-desktop-2.19.92-1.fc8 --------------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 (translation updates) * Fri Aug 31 2007 Soren Sandmann - 2.19.90-7 - Plug a leak in the slideshow parser gnome-doc-utils-0.11.2-1.fc8 ---------------------------- * Mon Sep 03 2007 Matthias Clasen - 0.11.2-1 - Update to 0.11.2 * Thu Aug 02 2007 Matthias Clasen - 0.11.1-2 - Update the license field gnome-games-1:2.19.92-1.fc8 --------------------------- * Tue Sep 04 2007 Matthias Clasen - 1:2.19.92-1 - 2.19.92 * Tue Aug 28 2007 Hans de Goede - 1:2.19.90.1-2 - Rebuild for new expat 2.0 * Tue Aug 14 2007 Matthias Clasen - 1:2.19.90.1-1 - 2.19.90.1 gnome-icon-theme-2.19.91-1.fc8 ------------------------------ * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 gnome-keyring-2.19.91-1.fc8 --------------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 gnome-mag-0.14.8-1.fc8 ---------------------- * Tue Sep 04 2007 Matthias Clasen - 0.14.8-1 - Update to 0.14.8 gnome-media-2.19.92-1.fc8 ------------------------- * Fri Sep 07 2007 - Bastien Nocera - 2.19.92-1 - Update to 2.19.92 - Remove upstreamed/obsolete patches gnome-menus-2.19.92-1.fc8 ------------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gnome-panel-2.19.92-2.fc8 ------------------------- * Thu Sep 06 2007 Matthias Clasen - 2.19.92-2 - Improve the handling of preferred apps in launchers * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gnome-power-manager-2.19.92-1.fc8 --------------------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gnome-screensaver-2.19.7-1.fc8 ------------------------------ * Tue Sep 04 2007 Matthias Clasen - 2.19.7-1 - Update to 2.19.7 gnome-session-2.19.92-2.fc8 --------------------------- * Wed Sep 05 2007 Kristian H??gsberg - 2.19.92-2 - Update gnome-session-2.17.5-window-manager.patch to apply (remove chunks that are now upstream). * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gnome-system-monitor-2.19.91.1-1.fc8 ------------------------------------ * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 gnome-themes-2.19.92-1.fc8 -------------------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 gnome-utils-1:2.19.92-1.fc8 --------------------------- * Thu Sep 06 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 * Tue Sep 04 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 gnome-vfs2-2.19.91-1.fc8 ------------------------ * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Re-add gnome-mount dependency - Update to 2.19.91 - Drop upstreamed posix patch * Sun Sep 02 2007 Matthias Clasen - 2.19.3-3 - Temporarily drop gnome-mount requires to break PolicyKit-gnome dependency cycle gnomebaker-0.6.1-4.fc8 ---------------------- * Fri Aug 31 2007 Tomas Smetana - 0.6.1-4 - fix blanking CDRWs * Thu Aug 30 2007 Tomas Smetana - 0.6.1-3 - fix problems with wodim and old scsi b,t,l syntax - fix uninitialised g_threads warning on startup - cdrecord -> wodim, cdda2wav -> icedax, mkisofs -> genisoimage gnomeradio-1.7-3.fc8 -------------------- * Wed Aug 29 2007 Dominik Mierzejewski - 1.7-3 - one more missing BR - fix building of help * Wed Aug 29 2007 Karol Trzcionka - 1.7-2 - Rebuild for BuildID * Tue Mar 27 2007 Dominik Mierzejewski - 1.7-1 - updated to 1.7 - added new missing BRs - fix make install gnotime-2.2.2-10.fc8 -------------------- * Wed Aug 29 2007 Toshio Kuratomi - 2.2.2-10 - Update qof patch for differences in how headers are included from each other in qof-0.7.2. * Wed Aug 29 2007 Toshio Kuratomi - 2.2.2-9 - Update qof patch for renamed headers in qof-0.7.2. * Sat Aug 18 2007 Toshio Kuratomi - 2.2.2-8 - Update license tag. - Rebuild for changes in Fedora's build tools. - Patch to deal with new gtkhtml. gnumeric-1:1.6.3-11.fc8 ----------------------- * Fri Aug 31 2007 Hans de Goede 1:1.6.3-11 - Fix Source0 URL gnuplot-4.2.0-5.fc8 ------------------- * Fri Sep 07 2007 Ivana Varekova - 4.2.0-5 - move emacs files to */site-lisp/gnuplot subdirectory * Thu Sep 06 2007 Ivana Varekova - 4.2.0-4 - change font paths, change documenatation gok-1.3.2-1.fc8 --------------- * Tue Sep 04 2007 Matthias Clasen - 1.3.2-1 - Update to 1.3.2 graphviz-2.14.1-3.fc8 --------------------- * Tue Sep 04 2007 Patrick "Jima" Laughton 2.14.1-3 - Patch to resurrect arith.h grip-1:3.2.0-17.fc8 ------------------- * Mon Sep 03 2007 Adrian Reber - 1:3.2.0-17 - search for ripper and encoder executables in path (#249150) - updated License: gstreamer-plugins-good-0.10.6-5.fc8 ----------------------------------- * Sun Sep 02 2007 - Bastien Nocera - 0.10.6-5 - Add a patch to fix id3demux, so that MP3s can be played back (#273561) gthumb-2.10.6-1.fc8 ------------------- * Tue Sep 04 2007 Matthias Clasen - 2.10.6-1 - Update to 2.10.6 * Tue Aug 28 2007 Fedora Release Engineering - 2.10.5-5 - Rebuild for selinux ppc32 issue. * Wed Aug 22 2007 Adam Jackson - 2.10.5-4 - Rebuild for PPC toolchain bug gtk2-2.11.6-9.fc8 ----------------- * Fri Sep 07 2007 Matthias Clasen - 2.11.6-9 - Add a workaround for the flash plugin * Fri Sep 07 2007 Ray Strode - 2.11.6-8 - install dummy binary in libdir/gtk-2.0/immodules directory to aid rpm when doing ia64 multilib (bug 253726) * Mon Aug 27 2007 Jens Petersen - 2.11.6-7 - own libdir/gtk-2.0/immodules directory (#255621) gtk2-engines-2.11.7-1.fc8 ------------------------- * Mon Sep 03 2007 Matthias Clasen - 2.11.7-1 - Update to 2.11.7 gtkhtml3-3.15.92-1.fc8 ---------------------- * Mon Sep 03 2007 Matthew Barnes - 3.15.92-1.fc8 - Update to 3.15.92 gtklp-1.2.5-1.fc8 ----------------- * Fri Aug 31 2007 Gerard Milmeister - 1.2.5-1 - new release 1.2.5 gtksourceview2-1.90.4-1.fc8 --------------------------- * Tue Sep 04 2007 Matthias Clasen - 1.90.4-1 - Update to 1.90.4 * Tue Aug 07 2007 Matthias Clasen - 1.90.3-2 - Update license field gtkwave-3.1.0-1.fc8 ------------------- * Tue Sep 04 2007 Paul Howarth 3.1.0-1 - update to 3.1.0 hal-0.5.10-0.git20070831.fc8 ---------------------------- * Fri Aug 31 2007 - David Zeuthen - 0.5.10-0.git20070831.fc8 - Update to upstream 0.5.10rc2 release - Drop patches that are upstream already hamlib-1.2.5-6.fc8 ------------------ * Mon Sep 03 2007 Denis Leroy - 1.2.5-6 - Rebuild, License tag update - Added net-tools BR * Wed May 09 2007 Ignacio Vazquez-Abrams 1.2.5-5 - Move HTML devel documentation to the proper subpackage (#228364) hardinfo-0.4.2.2-19.fc8 ----------------------- * Wed Sep 05 2007 Adel Gadllah 0.4.2.2-19 - Fix libz location (/lib(64) vs /usr/lib(64)) * Sun Sep 02 2007 Adel Gadllah 0.4.2.2-18 - Fix libz detection RH #274381 hddtemp-0.3-0.14.beta15.fc8 --------------------------- * Wed Sep 05 2007 Ville Skytt?? - 0.3-0.14.beta15 - Adjust server chkconfig start/stop priorities to start before gkrellmd, other cosmetic init script tweaks. - Mark hddtemp.db as %config(noreplace). hplip-2.7.7-4.fc8 ----------------- * Thu Sep 06 2007 Tim Waugh 2.7.7-4 - Reverted udev rules change. - Ship a HAL FDI file to get correct access control on the USB device nodes (bug #251470). - Make libsane-hpaio requires the main hplip package, needed for libhpip.so (bug #280281). * Thu Aug 30 2007 Tim Waugh 2.7.7-3 - Updated udev rules to allow scanning by console user. hsqldb-1:1.8.0.8-1jpp.1 ----------------------- * Fri Aug 31 2007 Fernando Nasser 1:1.8.0.8-1jpp.1 - Merge with upstream * Fri Aug 31 2007 Fernando Nasser 1:1.8.0.8-1jpp - Upgrade to 1.8.0.8 * Mon Jan 22 2007 Deepak Bhole 1:1.8.0.7-2jpp - Update copyright date httpd-2.2.6-2 ------------- * Fri Sep 07 2007 Joe Orton 2.2.6-2 - update to 2.2.6 (#250757, #282761) hunspell-1.1.12.2-1.fc8 ----------------------- * Wed Sep 05 2007 Caolan McNamara - 1.1.12.2-1 - next version hunspell-da-1.7.15-1.fc8 ------------------------ * Thu Aug 30 2007 Caolan McNamara - 1.7.15-1 - latest version * Fri Aug 03 2007 Caolan McNamara - 1.7.14-2 - clarify license version hunspell-de-0.20070829-1.fc8 ---------------------------- hunspell-it-2.4-0.1.20070901.fc8 -------------------------------- hunspell-pl-0.20070903-1.fc8 ---------------------------- * Mon Sep 03 2007 Caolan McNamara - 0.20070903-1 - new version * Thu Aug 09 2007 Caolan McNamara - 0.20070803-1 - clarify that is tri-licensed * Sun Jul 01 2007 Caolan McNamara - 0.20070701-1 - latest version - near daily updates => move to a pick it up the 1st of the month cycle hwdata-0.207-1.fc8 ------------------ * Thu Sep 06 2007 Adam Jackson 0.207-1 - MonitorsDB: Fix the sync ranges for the generic monitors to not be quite so dumb. 90kHz hsync is way out of range for any common single-link DVI panel, for example. (#247271) ice-3.2.1-11.fc8 ---------------- * Fri Sep 07 2007 Mary Ellen Foster 3.2.1-11 - Also add Obsoletes: for the old zeroc names - Fix bad date in changelog * Wed Aug 29 2007 Mary Ellen Foster 3.2.1-9 - Add "with exceptions" to license tag - Minor typo corrections in README.Fedora - Move ruby sitearch files out of an "Ice/" subdirectory so that they're actually useful * Tue Aug 28 2007 Mary Ellen Foster 3.2.1-8 - Remove parallel make to see if that fixes build errors icu-3.8-0.2.d02.fc8 ------------------- * Mon Sep 03 2007 Caolan McNamara - 3.8-0.2.d02 - next release candidate * Wed Aug 29 2007 Caolan McNamara - 3.8-0.2.d01 - rebuild * Tue Aug 07 2007 Caolan McNamara - 3.8-0.1.d01 - 3.8 release candidate - drop integrated icu.icu5433.oriya.patch - drop integrated icu.icu5488.assamese.patch - drop integrated icu.icu5500.devicetablecrash.patch - drop integrated icu.icu5501.sinhala.biggerexpand.patch - drop integrated icu.icu5594.gujarati.patch - drop integrated icu.icu5465.telegu.patch im-chooser-0.5.0-1.fc8 ---------------------- * Thu Sep 06 2007 Akira TAGOH - 0.5.0-1 - New upstream release. * Wed Aug 08 2007 Akira TAGOH - Update License tag. imlib2-1.4.0-3.fc8 ------------------ * Thu Sep 06 2007 Hans de Goede 1.4.0-3 - Update license tag inadyn-1.96.2-1.fc8 ------------------- * Sun Sep 02 2007 Jochen Schmitt 1.96.2-1 - New upstream release (#270801) iso-codes-1.4-1.fc8 ------------------- * Wed Sep 05 2007 Christopher Aillon 1.4-1 - Update to 1.4 jabberd-2.0-0.s11.14.fc8 ------------------------ * Mon Aug 27 2007 Adrian Reber - 2.0-0.s11.14 - applied patch to fix bz #175219 - removed config flag for startup script - updated License - added patch for new glibc open macro jack-audio-connection-kit-0.103.0-4.fc8 --------------------------------------- * Tue Sep 04 2007 Andy Shevchenko 0.103.0-4 - fix Source Forge's URL scheme jakarta-commons-codec-0:1.3-8jpp.2.fc8 -------------------------------------- * Thu Sep 06 2007 Andrew Overholt 1.3-8jpp.2 - Add OSGi manifest. * Wed Mar 21 2007 Matt Wringe 0:1.3-8jpp.1 - Update to latest jpp version - Fix rpmlint issues * Wed Mar 21 2007 Matt Wringe 0:1.3-8jpp - Fix some rpmlint warnings - Update copyright year jakarta-commons-digester-0:1.7-6jpp.2 ------------------------------------- * Fri Sep 07 2007 Matt Wringe - 0:1.7-6jpp.2 - Fix unowned dir (/usr/lib/gcj/jakarta-commons-digester) jakarta-commons-httpclient-1:3.0.1-1jpp.2.fc8 --------------------------------------------- * Thu Sep 06 2007 Andrew Overholt 1:3.0.1-1jpp.2 - Add OSGi MANIFEST.MF information. jakarta-commons-launcher-0:1.1-1jpp.3.fc8 ----------------------------------------- * Fri Sep 07 2007 Matt Wringe - 0:1.1-1jpp.3 - Fix unowned directory jakarta-commons-modeler-0:2.0-3jpp.2.fc8 ---------------------------------------- * Fri Sep 07 2007 Matt Wringe - 0:2.0-3jpp.2 - Fix unowned directory java-1.7.0-icedtea-1.7.0.0-0.15.b19.snapshot.fc8 ------------------------------------------------ * Fri Sep 07 2007 Thomas Fitzsimmons - 1.7.0.0-0.15.b18.snapshot - Do not require openssl for build. - Require openssl. - Set gcjbootstrap to 0. - Remove generate-cacerts.pl. - Update icedtearelease. - Update icedteasnapshot. - Update openjdkver. - Update openjdkdate. * Wed Sep 05 2007 Thomas Fitzsimmons - 1.7.0.0-0.15.b18.snapshot - Rename javadoc master alternative javadocdir. - Resolves: rhbz#269901 * Wed Sep 05 2007 Thomas Fitzsimmons - 1.7.0.0-0.15.b18.snapshot - Remove epoch in plugin provides. - Bump release number. - Resolves: rhbz#274001 jd-1.9.6-0.4.svn1314.fc8 ------------------------ * Fri Sep 07 2007 Mamoru Tasaka - 1.9.6-0.4.svn1314 - svn 1314 * Sun Aug 05 2007 Mamoru Tasaka - 1.9.6-0.2.beta070804 - 1.9.6 beta 070804 release 2 * Sat Aug 04 2007 Mamoru Tasaka - 1.9.6-0.1.beta070804 - 1.9.6 beta 070804 jetty-5.1.12-1jpp.7.fc8 ----------------------- * Fri Aug 31 2007 Jeff Johnston 5.1.12-1jpp.7 - Resolves #262221 - Use /bin/sh instead of /sbin/nologin so init will work * Thu Aug 30 2007 Jeff Johnston 5.1.12-1jpp.6 - Rename all source files from jetty5 to jetty - Replace jetty5 references with jetty in source files jokosher-1.0-0.1.20070904svn.fc8 -------------------------------- * Tue Sep 04 2007 Christopher Brown - 1.0-0.1.20070904svn - change to python-setuptools-devel - update to latest svn * Fri Aug 24 2007 Christopher Brown - 1.0-0.1.20070824svn - update to latest svn * Mon Aug 20 2007 Christopher Brown - 0.9-5 - update license tag jomolhari-fonts-0.003-4.fc8 --------------------------- * Fri Aug 31 2007 Marcin Garski 0.003-4 - Fix license tag kbackup-0.5.2-1.fc8 ------------------- * Thu Sep 06 2007 Alain Portal 0.5.2-1 - New upstream version - Update patch 1 - Remove patch 2 that is no more needed kdebase-6:3.5.7-14.fc8 ---------------------- * Thu Aug 30 2007 Than Ngo - 6:3.5.7-14 - fix bz#265801, fuser command not found by kio_media_mounthelper kdegraphics-7:3.5.7-4.fc8 ------------------------- * Wed Sep 05 2007 Rex Dieter - 7:3.5.7-4 - respin (for poppler) kdelibs-6:3.5.7-22.fc8 ---------------------- * Sun Sep 09 2007 Kevin Kofler 6:3.5.7-22 - Remove Conflicts: kdelibs4-devel, let kdelibs4 decide whether we conflict (allows using the old /opt/kde4 versions for now) kdepim-6:3.5.7-7.fc8 -------------------- * Wed Aug 29 2007 Rex Dieter - 6:3.5.7-7 - templates for forwarding do not work with inline mails (kde#140549) kdevelop-9:3.4.1-5.fc8 ---------------------- * Mon Sep 03 2007 Than Ngo - 9:3.4.1-5 - rebuilt against apr kernel-2.6.23-0.169.rc5.git1.fc8 -------------------------------- * Thu Sep 06 2007 Chuck Ebbert - x86: debug early boot * Thu Sep 06 2007 Chuck Ebbert - fix imbalance in scheduler on multicore systems * Thu Sep 06 2007 Chuck Ebbert - fix Xen boot problem - fix boot hang on Via C7 CPU - Fix oops in networking code kexec-tools-1.102pre-1.fc8 -------------------------- * Thu Aug 30 2007 Neil Horman - 1.102pre-1 - Bumping kexec version to latest horms tree (bz 257201) - Adding trigger to remove initrds when a kernel is removed kftpgrabber-0.8.1-3.fc8 ----------------------- * Mon Sep 03 2007 Johan Cwiklinski 0.8.1-3 - Fix licence tag kinput2-v3.1-34.fc8 ------------------- * Wed Sep 05 2007 Akira TAGOH - v3.1-34 - Add QT_IM_MODULE=xim to the xinput script. koffice-1.6.3-11.fc8 -------------------- * Wed Sep 05 2007 Rex Dieter 1.6.3-11 - rebuild (for poppler) - re-enable (kross)ruby support (f8+) krb5-1.6.2-6.fc8 ---------------- * Thu Sep 06 2007 Nalin Dahyabhai 1.6.2-6 - incorporate updated fix for CVE-2007-3999 - fix incorrect call to "test" in the kadmin init script * Tue Sep 04 2007 Nalin Dahyabhai 1.6.2-5 - incorporate fixes for MITKRB5-SA-2007-006 (CVE-2007-3999, CVE-2007-4000) * Sat Aug 25 2007 Nalin Dahyabhai 1.6.2-4 - cover more cases in labeling files on creation - add missing gawk build dependency krusader-1.80.0-2.fc8 --------------------- * Fri Aug 31 2007 Marcin Garski 1.80.0-2 - Fix license tag kvm-36-2.fc8 ------------ * Tue Sep 04 2007 Jeremy Katz - 36-2 - rebase vnc auth patch * Tue Sep 04 2007 Jeremy Katz - 36-1 - update to kvm-36 latexmk-3.20-1.fc8 ------------------ * Fri Aug 31 2007 Jerry James - 3.20-1 - New version 3.20. - Texlive isn't as near as I thought; require the tetex packages for now. lesstif-0.95.0-19.fc8 --------------------- * Sat Sep 01 2007 Hans de Goede 0.95.0-19 - Fix more 64 bit XChange/GetWindowProperty issues (inspired by the cut and paste 64 bit fix which was an XChange/GetWindowProperty issue too) - Fix z88: http://www.z88.uni-bayreuth.de/ not working with lesstif - Stop lessstif from spewing messages about XtUngrab... (bz 210384) * Thu Aug 30 2007 Hans de Goede 0.95.0-18 - Fix cut and paste from / to lesstif apps on 64 bits machines (bz 243508) - Fix accelkeys which use more then one modifier (bz 214018) * Thu Aug 30 2007 Hans de Goede 0.95.0-17 - Update included Debian 0.94.4-2 patch to the Debian 0.95.0-2 patch - Not only include but also actually apply Debian's patches (bz 261821) - Add 2 patches with small fixes from lesstif CVS (bz 261821) - Do not apply lesstif-64.patch it causes more issues then it fixes (bz 253456) lftp-3.5.10-4.fc8 ----------------- * Thu Sep 06 2007 Maros Barabas - 3.5.10-4 - rebuild libXaw-1.0.2-10.fc8 ------------------- * Thu Sep 06 2007 Adam Jackson 1.0.2-10 - Move Xaw6 to a compat package, nothing in the distro needs it. libapreq2-2.09-0.rc2.7.fc8 -------------------------- * Sat Sep 01 2007 Bojan Smojver - 2.09-0.rc2.7 - rebuild against apr-1.2.9-3 (bug #254241) libedit-2.10-1.20070831cvs.fc8 ------------------------------ libgnomekbd-2.19.91-1.fc8 ------------------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 libgsf-1.14.6-1.fc8 ------------------- * Wed Sep 05 2007 Caolan McNamara 1.14.6-1 - next version libgtop2-2.19.92-1.fc8 ---------------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 libkdcraw-0.1.1-3.fc8 --------------------- * Fri Aug 31 2007 Marcin Garski 0.1.1-3 - Fix license tag libnetfilter_conntrack-0.0.81-1.fc8 ----------------------------------- * Thu Aug 30 2007 Paul P. Komkoff Jr - 0.0.81-1 - new upstream version libnfnetlink-0.0.30-1.fc8 ------------------------- * Thu Aug 30 2007 Paul P. Komkoff Jr - 0.0.30-1 - new upstream version libnjb-2.2.6-1.fc8 ------------------ * Wed Sep 05 2007 Linus Walleij 2.2.6-1 - Long overdue upstream release. - Shape up udev rules so they look like the libsane stuff. - Add HAL FDI file. liboil-0.3.12-11.fc8 -------------------- * Fri Sep 07 2007 - Bastien Nocera - 0.3.12-11 - Revert the previous commit, it's still broken, see: http://koji.fedoraproject.org/koji/taskinfo?taskID=151172 * Thu Aug 30 2007 - David Woodhouse - 0.3.12-10 - Re-enable explicit Altivec but don't let the compiler use it automatically - Start applying the ppc64-configure patch again librsvg2-2.18.2-1.fc8 --------------------- * Mon Sep 03 2007 Matthias Clasen - 2.18.2-1 - Update to 2.18.2 * Mon Sep 03 2007 Matthias Clasen - 2.18.1-1 - Update to 2.18.1 libselinux-2.0.31-4.fc8 ----------------------- * Thu Sep 06 2007 Dan Walsh - 2.0.31-4 - Apply James Athway patch to fix rpm_execcon python binding libsemanage-2.0.5-1.fc8 ----------------------- * Thu Aug 23 2007 Dan Walsh - 2.0.5-1 - Upgrade to latest from NSA libsepol-2.0.9-1.fc8 -------------------- * Fri Aug 31 2007 Dan Walsh 2.0.9-1 - Upgrade to latest from NSA * Moved next_entry and put_entry out-of-line to reduce code size from Ulrich Drepper. * Fixed module_package_read_offsets bug introduced by the prior patch. libsexymm-0.1.9-4.fc8 --------------------- * Wed Aug 29 2007 Ha??kel Gu??mar - 0.1.9-4 - fixed devel dependencies issues libsvm-2.84-4.fc8 ----------------- * Thu Aug 30 2007 Ding-Yi Chen - 2.84-4 - Refined description. - Fix the /tmp/python.ver problem libtasn1-1.1-1.fc8 ------------------ * Mon Sep 03 2007 Enrico Scholz - 1.1-1 - updated to 1.1 - workaround 'make check' errors on ppc64 * Thu Jun 14 2007 Enrico Scholz - 0.3.10-1 - updated to 0.3.10 libtelepathy-0.0.57-1.fc8 ------------------------- * Fri Sep 07 2007 Matej Cepl - 0.0.57-1 - New upstream version. * Thu Jun 14 2007 John (J5) Palmieri - 0.0.55-1 - Update to 0.0.55 * Fri Apr 13 2007 Brian Pepple - 0.0.53-1 - Update to 0.0.53. libupnp-1.6.0-3.fc8 ------------------- * Fri Sep 07 2007 Eric Tanguy - 1.6.0-3 - Patch to build with new glibc * Wed Aug 29 2007 Fedora Release Engineering - 1.6.0-2 - Rebuild for selinux ppc32 issue. libusb-0.1.12-10.fc8 -------------------- * Thu Aug 23 2007 Jindrich Novy 0.1.12-10 - optimize usb_find_devices() and use openat() instead of open() (#273901), thanks to Ulrich Drepper - BR gawk libuser-0.56.4-3 ---------------- * Wed Sep 05 2007 Miloslav Trma?? - 0.56.4-3 - s/popt/popt-devel/ in BuildRequires Resolves: #277541 libwnck-2.19.92-1.fc8 --------------------- * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 (translations) libxklavier-3.3-1.fc8 --------------------- * Wed Sep 05 2007 Matthias Clasen - 3.3-1 - Update to 3.3 libxml-1:1.8.17-17.fc8 ---------------------- * Thu Aug 30 2007 Paul Howarth 1:1.8.17-17 - rebuild for BuildID inclusion (http://fedoraproject.org/wiki/Releases/FeatureBuildId) * Fri Aug 17 2007 Paul Howarth 1:1.8.17-16 - add mode to fix call to open() with O_CREAT and only 2 args - unexpand tabs in spec - update license tag lighttpd-1.4.17-1.fc8 --------------------- * Wed Sep 05 2007 Matthias Saou 1.4.17-1 - Update to 1.4.17. - Update defaultconf patch to match new example configuration. - Include patch to fix log file rotation with max-workers set (trac #902). - Add /var/run/lighttpd/ directory where to put fastcgi sockets. m17n-db-1.4.0-6.fc8 ------------------- * Fri Sep 07 2007 Parag Nemade - 1.4.0-6.fc8 - Removed incorrect version of hi-typewriter.mim mapserver-4.10.3-2.fc8 ---------------------- * Thu Aug 30 2007 Oliver Falk 4.10.3-2 - Add fix to include libmapserver (in some places), instead of libmap, that doesn't exist (anymore) * Thu Aug 30 2007 Oliver Falk 4.10.3-1 - Update to fix bz#256561, CVE-2007-4542 maven-doxia-0:1.0-0.1.a7.3jpp.4.fc8 ----------------------------------- * Sat Sep 01 2007 Deepak Bhole 0:1.0-0.1.a7.3jpp.4 - Rebuild without maven (fpr initial ppc build) maven-jxr-0:1.0-2jpp.3.fc8 -------------------------- * Fri Aug 31 2007 Deepak Bhole 0:1.0-2jpp.3 - Build without maven (for initial ppc build) maven-surefire-0:1.5.3-2jpp.3.fc8 --------------------------------- * Fri Aug 31 2007 Deepak Bhole 0:1.5.3-2jpp.3 - Build without maven (for initial ppc build) maxima-5.13.0-4.fc8 ------------------- * Thu Aug 30 2007 Rex Dieter 5.13.0-4 - (re)--enable-gcl (#256281) mesa-7.0.1-5.fc8 ---------------- * Thu Sep 06 2007 Adam Jackson 7.0.1-5 - mesa-7.0.1-965-sampler-crash.patch: Fix a crash with 965 in Torcs. (#262941) metapixel-1.0.2-2.fc8 --------------------- * Fri Aug 31 2007 Andreas Thienemann - 1.0.2-2 - Added BR on giflib-devel to enable gif-support * Fri Aug 31 2007 Andreas Thienemann - 1.0.2-1 - New upstream release 1.0.2 mgetty-1.1.33-11.fc8 -------------------- * Thu Sep 06 2007 Maros Barabas - 1.1.33-11 - rebuild mkinitrd-6.0.15-1.fc8 --------------------- * Fri Sep 07 2007 Peter Jones - 6.0.15-1 - Fix dmraid on x86_64. mksh-31-1.fc8 ------------- * Sat Sep 08 2007 Robert Scheck 31-1 - Upgrade to 31 mod_auth_pam-1.1.1-5.fc8 ------------------------ * Wed Sep 05 2007 Brandon Holbrook 1.1.1-5 - Rebuild for new APR libs mod_dnssd-0.5-5.fc8 ------------------- * Mon Sep 03 2007 Ignacio Vazquez-Abrams 0.5-5 - Rebuild for new 32-bit APR ABI mod_evasive-1.10.1-4.1.fc8 -------------------------- * Wed Sep 05 2007 Konstantin Ryabitsev - 1.10.1-4.1 - Rebuild for APR changes mod_geoip-1.2.0-1.fc8 --------------------- * Wed Sep 05 2007 Michael Fleming 1.2.0-1 - New upstream release - Employ some macro sanity.. mod_perl-2.0.3-14 ----------------- * Wed Sep 05 2007 Joe Orton 2.0.3-14 - filter perl(HTTP::Request::Common) Provide from -devel (#247250) mod_security-2.1.1-3.fc8 ------------------------ * Mon Sep 03 2007 Joe Orton 2.1.1-3 - rebuild for fixed 32-bit APR (#254241) mugshot-1.1.51-1.fc8 -------------------- * Thu Sep 06 2007 Colin Walters - 1.1.51-1 - 1.1.51 * Tue Sep 04 2007 Owen Taylor - 1.1.50-2 - Don't put two autostart files in the autostart directory (https://bugzilla.redhat.com/show_bug.cgi?id=274921) (Nils Philippsen) * Tue Aug 21 2007 Colin Walters - 1.1.50-1 - 1.1.50 nautilus-2.19.91-1.fc8 ---------------------- * Mon Sep 03 2007 Matthias Clasen - 2.19.91-1 - Update to 2.19.91 neon-0.27.0-2 ------------- * Thu Aug 30 2007 Joe Orton 0.27.0-2 - enable OpenSSL thread-safety hooks netpanzer-0.8.2-1.fc8 --------------------- * Wed Aug 29 2007 Jon Ciesla 0.8.2-1 - Bumped to 0.8.2. - Merged in and obsoleted/provided netpanzer-data to follow upstream. - Patch to correct upstream .desktop file. * Thu Aug 16 2007 Jon Ciesla 0.8.1-2 - License tag correction. * Thu Mar 01 2007 Jon Ciesla 0.8.1-1 - Bumped to upstream - Pulled gcc 4.1 patch, fixed upstream - Pulled CVE 2006-2575, 2005-2295 patches, fixed upstream - Updated netpanzer-data RQ to allow update of app without update of data. nss-3.11.7-9.fc8 ---------------- * Thu Sep 06 2007 Rob Crittenden - 3.11.7-9 - Fix off-by-one error in the PEM module * Thu Sep 06 2007 Kai Engert - 3.11.7-8 - fix a C++ mode compilation error * Wed Sep 05 2007 Bob Relyea - 3.11.7-7 - Add 3.12 ckfw and libnsspem obexftp-0.22-0.5.rc7.fc8 ------------------------ * Thu Sep 06 2007 Dominik Mierzejewski - 0.22-0.5.rc7 - updated to 0.22-rc7 - added pkgconfig file - make perl BR more specific ocaml-3.10.0-7.fc8 ------------------ * Thu Sep 06 2007 Richard W.M. Jones - 3.10.0-7 - Run chrpath to delete rpaths used on some of the stublibs. - Ignore Parsetree module in dependency calculation. - Fixed ocaml-find-{requires,provides}.sh regexp calculation so it doesn't over-match module names. * Mon Sep 03 2007 Richard W.M. Jones - 3.10.0-6 - ocaml-runtime provides ocaml(runtime) = 3.10.0, and ocaml-find-requires.sh modified so that it adds this requires to other packages. Now can upgrade base ocaml packages without needing to rebuild everything else. * Mon Sep 03 2007 Richard W.M. Jones - 3.10.0-5 - Don't include the release number in fedora-ocaml-release file, so that packages built against this won't depend on the Fedora release. ocaml-calendar-1.10-9.fc8 ------------------------- * Thu Sep 06 2007 Richard W.M. Jones - 1.10-9 - Force rebuild because of updated requires/provides scripts in OCaml. * Mon Sep 03 2007 Richard W.M. Jones - 1.10-8 - Force rebuild because of base OCaml. * Thu Aug 30 2007 Richard W.M. Jones - 1.10-7 - Force rebuild because of changed BRs in base OCaml. ocaml-csv-1.1.6-5.fc8 --------------------- * Thu Sep 06 2007 Richard W.M. Jones - 1.1.6-5 - Force rebuild because of base OCaml. ocaml-curl-0.2.1-5.fc8 ---------------------- * Thu Sep 06 2007 Richard W.M. Jones - 0.2.1-5 - Force rebuild because of changed build-requires/provides scripts in OCaml. ocaml-curses-0.1-5.20020319.fc8 ------------------------------- * Thu Sep 06 2007 Richard W.M. Jones - 0.1-5.20020319 - Force rebuild because of updated requires/provides scripts in OCaml. ocaml-expat-0.9.1-8.fc8 ----------------------- * Thu Sep 06 2007 Richard W.M. Jones - 0.9.1-8 - Force rebuild because of updated requires/provides scripts in OCaml. * Thu Aug 30 2007 Richard W.M. Jones - 0.9.1-7 - Force rebuild because of changed BRs in base OCaml. ocaml-extlib-1.5-8.fc8 ---------------------- * Thu Sep 06 2007 Richard W.M. Jones - 1.5-8 - Force rebuild because of updated requires/provides scripts in OCaml. * Mon Sep 03 2007 Richard W.M. Jones - 1.5-7 - Force rebuild because of base OCaml. * Thu Aug 30 2007 Richard W.M. Jones - 1.5-6 - Force rebuild because of changed BRs in base OCaml. ocaml-findlib-1.1.2pl1-14.fc8 ----------------------------- * Thu Sep 06 2007 Richard W.M. Jones - 1.1.2pl1-14 - Ignore Parsetree module, it's a part of the toplevel. * Mon Sep 03 2007 Richard W.M. Jones - 1.1.2pl1-13 - Bump version to force rebuild against ocaml -6 release. * Thu Aug 30 2007 Richard W.M. Jones - 1.1.2pl1-12 - Added BR: gawk. ocaml-lablgl-1.02-15.fc8 ------------------------ * Fri Sep 07 2007 Gerard Milmeister - 1.02-15 - Rebuild * Thu Aug 30 2007 Gerard Milmeister - 1.02-13 - Rebuild ocaml-lablgtk-2.6.0-10.20060908cvs.fc8 -------------------------------------- * Fri Sep 07 2007 Gerard Milmeister - 2.6.0-10.20060908cvs - rebuild * Thu Aug 30 2007 Gerard Milmeister - 2.6.0-9.20060908cvs - rebuild ocaml-libvirt-0.3.2.6-2.fc8 --------------------------- * Thu Sep 06 2007 Richard W.M. Jones - 0.3.2.6-2 - Force dependency on ocaml >= 3.10.0-7 which has fixed requires/provides scripts. * Thu Sep 06 2007 Richard W.M. Jones - 0.3.2.6-1 - New upstream version 0.3.2.6. * Wed Aug 29 2007 Richard W.M. Jones - 0.3.2.5-1 - New upstream version 0.3.2.5. - Keep TODO out of the main package, but add (renamed) TODO.libvirt and TODO.virt-top to the devel and virt-top packages respectively. - Add BR gawk. ocaml-pcre-5.11.4-9.fc8 ----------------------- * Thu Sep 06 2007 Richard W.M. Jones - 5.11.4-9 - Force rebuild because of updated requires/provides scripts in OCaml. * Mon Sep 03 2007 Richard W.M. Jones - 5.11.4-8 - Force rebuild because of base OCaml. * Thu Aug 30 2007 Richard W.M. Jones - 5.11.4-7 - Force rebuild because of changed BRs in base OCaml. ocaml-ssl-0.4.2-5.fc8 --------------------- * Thu Sep 06 2007 Richard W.M. Jones - 0.4.2-5 - Force rebuild because of updated requires/provides scripts in OCaml. ocaml-ulex-1.0-6.fc8 -------------------- * Thu Sep 06 2007 Richard W.M. Jones - 1.0-6 - Ignore Parsetree module. * Thu Sep 06 2007 Richard W.M. Jones - 1.0-5 - Force rebuild because of updated requires/provides scripts in OCaml. * Thu Aug 30 2007 Richard W.M. Jones - 1.0-4 - Force rebuild because of changed BRs in base OCaml. ocaml-xml-light-2.2.cvs20070817-5.fc8 ------------------------------------- * Thu Sep 06 2007 Richard W.M. Jones - 2.2.cvs20070817-5 - Don't package test.cmi file (it's a test program). oddjob-0.29-1.fc8 ----------------- * Wed Sep 05 2007 Nalin Dahyabhai 0.29-1 - split off mkhomedir bits into a subpackage (#236820) - take a pass at new-init-ifying the init script (#247005) * Thu Aug 16 2007 Nalin Dahyabhai - move helpers to libexecdir, keeping pkglibdir around in the package (#237207) * Mon Apr 09 2007 Nalin Dahyabhai 0.28-1 - split off python subpackage, make -devel depend on -libs, let autodeps provide the main package's dependency on -libs (#228377) offlineimap-5.99.2-1.fc8 ------------------------ * Tue Sep 04 2007 Till Maas - 5.99.2-1 - update to new version - update license Tag - add unclosed listitem in offlineimap.sgml - add missing BR: docbook-utils - build manpage - remove todo and manual files from %doc online-desktop-0.2.10-1.fc8 --------------------------- * Thu Sep 06 2007 Colin Walters - 0.2.10-1 - new upstream opencdk-0.6.4-1.fc8 ------------------- * Wed Sep 05 2007 Enrico Scholz - 0.6.4-1 - updated to 0.6.4 openct-0.6.14-1.fc8 ------------------- * Thu Aug 30 2007 Ville Skytt?? - 0.6.14-1 - 0.6.14. openldap-2.3.38-1.fc8 --------------------- * Thu Sep 06 2007 Jan Safranek 2.3.38-1.fc8 - new upstream version - added images to the guide.html (#273581) openoffice.org-1:2.3.0-3.2.fc8 ------------------------------ * Tue Sep 04 2007 Caolan McNamara - 1:2.3.0-3.2 - rebuild against icu - rebuild against icedtea - add openoffice.org-2.3.0.ooo74751.bean.mawt.patch to allow build against icedtea - don't prefer gcj over icedtea when both installed - add ooo#81253 connectivity uninit fix - add ooo#81258 sw uninit fix - package sandbox.jar where available * Sat Sep 01 2007 Caolan McNamara - 1:2.3.0-3.1 - release candidate - drop integrated openoffice.org-1.9.130.ooo67740.doublefree.xmlhelp.patch - drop integrated openoffice.org-2.2.0.ooo75790.sc.pa-IN.translate.patch - drop integrated openoffice.org-2.3.0.ooo80944.sd.sixtyfour.patch - drop integrated workspace.dba23e.patch - drop integrated openoffice.org-2.3.0.ooo80931.sysui.genericname.patch * Wed Aug 29 2007 Caolan McNamara - 1:2.3.0-2.4 - add openoffice.org-2.3.0.ooo81112.reportdesign.parallel.patch openssh-4.7p1-1.fc8 ------------------- * Thu Sep 06 2007 Tomas Mraz - 4.7p1-1 - upgrade to latest upstream - use libedit in sftp (#203009) - fixed audit log injection problem (CVE-2007-3102) orca-2.19.92-1.fc8 ------------------ * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 oxine-0.7.0-1.fc8 ----------------- * Thu Aug 30 2007 Matthias Saou 0.7.0-1 - Update to 0.7.0. - Add new build requirements. pango-1.18.1-1.fc8 ------------------ * Tue Sep 04 2007 Matthias Clasen - 1.18.1-1 - Update to 1.18.1 pcmciautils-014-11.fc8 ---------------------- * Fri Sep 07 2007 Harald Hoyer - 014-11 - fixed udev rule perl-Ace-1.91-3.fc8 ------------------- perl-AutoClass-1_01-4.fc8 ------------------------- * Tue Sep 04 2007 Alex Lancaster 1_01-4 - Add missing BuildRequires: perl(Test::More) perl-Bio-ASN1-EntrezGene-1.091-4.fc8 ------------------------------------ * Tue Sep 04 2007 Alex Lancaster 1.091-4 - Clarified license terms: GPL+ or Artistic perl-Cache-Simple-TimedExpiry-0.27-3.fc8 ---------------------------------------- * Tue Sep 04 2007 Ralf Cors??pius - 0.27-3 - BR: perl(Test::More). * Tue Sep 04 2007 Ralf Cors??pius - 0.27-2 - Update license tag. - BR: perl(ExtUtils::MakeMaker). perl-Class-Autouse-1.28-1.fc8 ----------------------------- * Wed Sep 05 2007 Ralf Cors??pius - 1.28-1 - Upstream update. - Update license. perl-Class-ReturnValue-0.55-1.fc8 --------------------------------- perl-DBIx-DBSchema-0.34-1.fc8 ----------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 0.34-1 - Upstream update. - Update license tag. perl-DBIx-SearchBuilder-1.49-1.fc8 ---------------------------------- * Tue Sep 04 2007 Ralf Cors??pius - 1.49-1 - Upstream update. - Update license tag. perl-Data-Stag-0.10-3.fc8 ------------------------- perl-ExtUtils-AutoInstall-0.63-6.fc8 ------------------------------------ * Wed Sep 05 2007 Ralf Cors??pius - 0.63-6 - Update license tag. - BR: perl(ExtUtils::MakeMaker). - BR: perl(CPAN). perl-File-Find-Rule-0.30-3.fc7 ------------------------------ * Mon Sep 03 2007 Ralf Cors??pius - 0.30-3 - Update license tag. - Add BR: perl(ExtUtils::MakeMaker). perl-File-Flat-1.00-2.fc8 ------------------------- * Sun Sep 02 2007 Ralf Cors??pius - 1.00-2 - License update. perl-File-NCopy-0.34-6.fc8 -------------------------- * Sun Sep 02 2007 Ralf Cors??pius - 0.34-6 - Update license tag. - BR: perl(ExtUtils::MakeMaker). perl-File-Slurp-9999.12-3.fc8 ----------------------------- * Sun Sep 02 2007 Ralf Cors??pius - 9999.12-3 - Update license tag. - BR: perl(ExtUtils::MakeMaker). perl-Font-AFM-1.19-5.fc8 ------------------------ * Fri Aug 31 2007 Ralf Cors??pius - 1.19-5 - BR: perl(ExtUtils::MakeMaker). - Update license tag. perl-GD-SVG-0.28-3.fc8 ---------------------- * Tue Sep 04 2007 Alex Lancaster 0.28-3 - Add missing BuildRequires: perl(Test::More) perl-Graph-0.84-1.fc8 --------------------- * Wed Sep 05 2007 Alex Lancaster 0.84-1 - Update to latest upstream. * Thu Aug 23 2007 Alex Lancaster 0.83-3 - License tag to GPL+ or Artistic as per new guidelines. * Sat Aug 18 2007 Alex Lancaster 0.83-2 - Add missing BR: perl(Test::More) perl-HTML-Format-2.04-6.fc8 --------------------------- * Mon Sep 03 2007 Ralf Cors??pius - 2.04-6 - Update license tag. - BR: perl(ExtUtils::MakeMaker). * Tue Sep 05 2006 Ralf Cors??pius - 2.04-5 - Mass rebuild. * Wed Mar 01 2006 Ralf Cors??pius - 2.04-4 - Rebuild for perl-5.8.8. perl-HTTP-Server-Simple-Mason-0.09-6.fc8 ---------------------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 0.09-6 - Update license tag. perl-Locale-Maketext-Lexicon-0.64-2.fc8 --------------------------------------- * Tue Sep 04 2007 Ralf Cors??pius - 0.64-2 - Update license tag. - BR: perl(ExtUtils::MakeMaker). perl-Mail-GnuPG-0.10-1.fc8 -------------------------- * Tue Sep 04 2007 Ralf Cors??pius - 0.10-1 - Upstream update. - Reflect source url having changed. - Update license tag. perl-Math-Derivative-0.01-3.fc8 ------------------------------- perl-Math-Spline-0.01-2.fc8 --------------------------- perl-Module-Refresh-0.13-2.fc8 ------------------------------ * Thu Sep 06 2007 Ralf Cors??pius < - 0.13-2 - Update license tag. perl-Newt-1.08-17 ----------------- * Thu Aug 30 2007 Joe Orton 1.08-17 - clarify License tag perl-Params-Util-0.29-1.fc8 --------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 0.29-1 - Upstream update. - Update licence tag. - Conditionally disable AUTOMATED_TESTING. * Sat Jul 28 2007 Ralf Cors??pius - 0.26-1 - Upstream update. perl-Params-Validate-0.88-3.fc8 ------------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 0.88-3 - Update license tag. perl-Pod-Tests-0.18-5.fc8 ------------------------- * Tue Sep 04 2007 Ralf Cors??pius - 0.18-5 - Update license tag. - BR: perl(ExtUtils::MakeMaker). perl-PostScript-0.06-2.fc8 -------------------------- perl-Test-ClassAPI-1.04-2.fc8 ----------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 1.04-2 - Update license tag. perl-Test-LongString-0.11-2.fc8 ------------------------------- * Thu Sep 06 2007 Ralf Cors??pius - 0.11-2 - BR: perl(ExtUtils::MakeMaker). - Update license tag. perl-Text-Iconv-1.5-1.fc8 ------------------------- * Fri Aug 31 2007 Andreas Thienemann - 1.5-1 - Updated to new upstream release perl-Text-Quoted-2.02-3.fc8 --------------------------- * Fri Aug 31 2007 Ralf Cors??pius - 2.02-3 - BR: perl(Test::More). - Update license tag. perl-Text-Shellwords-1.08-2.fc8 ------------------------------- * Tue Sep 04 2007 Alex Lancaster 1.08-2 - Clarified license terms: GPL+ or Artistic perl-Text-Wrapper-1.01-2.fc8 ---------------------------- * Thu Aug 30 2007 Ralf Cors??pius - 1.01-2 - BR: perl(Test::More). - Update License tag. perl-XML-DOM-XPath-0.13-2.fc8 ----------------------------- perl-XML-XPathEngine-0.08-2.fc8 ------------------------------- php-pear-Mail-Mime-1.5.2-2.fc8 ------------------------------ * Wed May 16 2007 Brandon Holbrook 1.5.2-2 - Add Requirement for pear-1.6.0 * Wed May 16 2007 Brandon Holbrook 1.5.2-1 - Upgraded to 1.5.2 php-pecl-phar-1.2.1-1.fc8 ------------------------- phpMyAdmin-2.11.0-1.fc8 ----------------------- * Thu Sep 06 2007 Mike McGrath 2.11.0-1 - Upstream released new version - Altered sources file as required - Added proper license piklab-0.14.5-2.fc8 ------------------- * Sun Sep 02 2007 Chitlesh Goorah - 0.14.5-2 - fixing desktop file pikloops-0.2.3-3.fc8 -------------------- * Sun Sep 02 2007 Chitlesh Goorah - 0.2.3-3 - Fix desktop file pinot-0.76-2.fc8 ---------------- * Wed Sep 05 2007 Adel Gadllah 0.76-2 - Add upstream patch to fix preferences segfault pirut-1.3.17-1.fc8 ------------------ * Fri Sep 07 2007 Jeremy Katz - 1.3.17-1 - Catch another downloading error (#270201) - Handle errors a little better in puplet - Fix repo refreshing after adding/removing repos pixman-0.9.5-1.fc8 ------------------ * Wed Sep 05 2007 Adam Jackson 0.9.5-1 - Update to 0.9.5 release. * Mon Aug 27 2007 Adam Jackson 0.9.0-7.20070827 - New snapshot plexus-ant-factory-0:1.0-0.1.a1.2jpp.3.fc8 ------------------------------------------ * Fri Aug 31 2007 Deepak Bhole 1.0-0.1.a1.2jpp.3 - Build without maven (to build on ppc) plexus-bsh-factory-0:1.0-0.1.a7s.2jpp.3.fc8 ------------------------------------------- * Fri Aug 31 2007 Deepak Bhole 1.0-0.1.a7s.2jpp.3 - Build without maven (to build on ppc) policycoreutils-2.0.25-9.fc8 ---------------------------- * Tue Sep 04 2007 Dan Walsh 2.0.25-9 - Bump libsemanage version for disable dontaudit - New gui features for creating admin users * Fri Aug 31 2007 Dan Walsh 2.0.25-8 - Fix generated code for admin policy * Fri Aug 31 2007 Dan Walsh 2.0.25-7 - Lots of fixes for role templates poppler-0.6-1.fc8 ----------------- * Tue Sep 04 2007 Kristian H??gsberg - 0.6-1 - Update to 0.6 postgresql-8.2.4-6.fc8 ---------------------- * Tue Sep 04 2007 Tom Lane 8.2.4-6 - Fix multilib problem for /usr/include/ecpg_config.h (which is new in 8.2.x) * Sat Aug 25 2007 Tom Lane 8.2.4-5 - Use nicer solution for tzdata file substitution: upstream discussion concluded that hardwiring the path was better than a symlink after all. * Wed Aug 22 2007 Tom Lane 8.2.4-4 - Use tzdata package's data files instead of private copy, so that postgresql-server need not be turned for routine timezone updates - Don't remove postgres user/group during RPM uninstall, per Fedora packaging guidelines - Seems we need an explicit BuildRequires on gawk now - Rebuild to fix Fedora toolchain issues powermanga-0.90-1 ----------------- * Mon Sep 03 2007 Matthias Saou 0.90-1 - Update to 0.90. - Update License field (changed to GPLv3+). - Update install patch, include fix for "fonts" directory. - No longer manually install texts, but install the config.ini. - Add gawk and libpng-devel build requirements. ppracer-0.3.1-11.fc8 -------------------- * Wed Sep 05 2007 Nils Philippsen 0.3.1-11 - change license to GPLv2+ pyclutter-0.4.1-1.fc8 --------------------- * Mon Sep 03 2007 Allisson Azevedo 0.4.1-1 - Update to 0.4.1 pygtksourceview-1.90.4-1.fc8 ---------------------------- * Tue Sep 04 2007 Matthias Clasen - 1.90.4-1 - Update to 1.90.4 python-TestGears-0.2-6.fc8 -------------------------- * Sat Sep 01 2007 Toshio Kuratomi 0.2-6 - python-setuptools change for rawhide. * Sat Sep 01 2007 Toshio Kuratomi 0.2-5 - Remove the .pth file (setuptools will generate its own otherwise it's unneeded.) - Fix directory ownership. python-clientform-0.2.7-2.fc8 ----------------------------- * Sun Sep 02 2007 Luke Macken 0.2.7-2 - Update for python-setuptools changes in rawhide python-configobj-4.4.0-2.fc8 ---------------------------- * Sun Sep 02 2007 Luke Macken - 4.4.0-2 - Update for python-setuptools changes in rawhide python-decoratortools-1.5-2.fc8 ------------------------------- * Sat Sep 01 2007 Toshio Kuratomi - 1.5-2 - Verify that .pth files are correct. - Update license tag for new guidelines. - Update setuptools BR for changes in rawhide. python-formencode-0.7.1-2.fc8 ----------------------------- * Sun Sep 02 2007 Luke Macken 0.7.1-2 - Update for python-setuptools changes in rawhide python-mechanize-0.1.6-0.2.b.fc8 -------------------------------- * Sun Sep 02 2007 Luke Macken - 0.1.6-0.2.b - Update for python-setuptools changes in rawhide python-myghty-1.1-4.fc8 ----------------------- * Sun Sep 02 2007 Luke Macken 1.1-4 - Update for python-setuptools changes in rawhide python-nose-0.10.0-0.3.b1.fc8 ----------------------------- * Sun Sep 02 2007 Luke Macken 0.10.0-0.3.b1 - Update for python-setuptools changes in rawhide python-paste-1.4-2.fc8 ---------------------- * Sun Sep 02 2007 Luke Macken - 1.4-2 - Update for python-setuptools changes in rawhide * Sun Jul 08 2007 Luke Macken - 1.4-1 - 1.4 * Sat Mar 03 2007 Luke Macken - 1.2.1-1 - 1.2.1 python-paste-deploy-1.3.1-2.fc8 ------------------------------- * Sun Sep 02 2007 Luke Macken - 1.3.1-2 - Update for python-setuptools changes in rawhide python-paste-script-1.3.5-2.fc8 ------------------------------- * Sun Sep 02 2007 Luke Macken - 1.3.5-2 - Update for python-setuptools changes in rawhide python-ruledispatch-0.5a0-0.7.svnr2306.fc8 ------------------------------------------ * Sun Sep 02 2007 Luke Macken 0.5a0-0.7.svn2305 - Update for python-setuptools changes in rawhide python-simplejson-1.7.1-3.fc8 ----------------------------- * Sun Sep 02 2007 Luke Macken - 1.7.1-3 - Update for python-setuptools changes in rawhide python-sqlalchemy-0.4.0-0.3.beta4.fc8 ------------------------------------- * Fri Aug 31 2007 Toshio Kuratomi - 0.4.0-0.3.beta4 - setuptools seems to be broken WRT having an active and inactive version of an egg. Have to make both versions inactive and manually setup a copy that can be started via import. (Necessary for the sqlalchemy0.3 compat package.) * Tue Aug 28 2007 Toshio Kuratomi - 0.4.0-0.2.beta4 - Modify setuptools to handle the -devel subpackage split in F-8. python-turbocheetah-0.9.5-8.fc8 ------------------------------- * Sun Sep 02 2007 Luke Macken - 0.9.5-8 - Update for python-setuptools changes in rawhide python-turbokid-1.0.2-2.fc8 --------------------------- * Sun Sep 02 2007 Luke Macken - 1.0.2-2 - Update for python-setuptools changes in rawhide python-twisted-conch-0.8.0-1.fc8 -------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 0.8.0-1 - new version python-twisted-core-2.5.0-2.fc8 ------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 2.5.0-2 - add sed and awk as buildrequires * Thu Aug 23 2007 Thomas Vander Stichele - 2.5.0-1 - updated to newest version - remove twisted/spread/*.so - added epoll.so python-twisted-mail-0.4.0-1.fc8 ------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 0.4.0-1 - new version python-twisted-names-0.4.0-1.fc8 -------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 0.4.0-1 - updated to latest version python-twisted-news-0.3.0-1.fc8 ------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 0.3.0-1 - update to latest release python-twisted-web-0.7.0-1.fc8 ------------------------------ * Fri Aug 31 2007 Thomas Vander Stichele - 0.7.0-1 - updated to new version - updated core requires - removed websetroot python-twisted-words-0.5.0-1.fc8 -------------------------------- * Fri Aug 31 2007 Thomas Vander Stichele - 0.5.0-1 - updated to latest version qtparted-0.4.5-15.fc8 --------------------- * Thu Sep 06 2007 Steven Pritchard 0.4.5-15 - Fix qtparted.pam (#237075). rarian-0.5.8-3.fc8 ------------------ * Thu Aug 30 2007 Matthew Barnes - 0.5.8-3 - Add patch for RH bug #254301 (rarian-sk-config --omfdir). ratpoison-1.4.1-0.fc8 --------------------- * Fri Aug 31 2007 John Berninger - 1.4.1-0 - update to 1.4.1 - bz 269821 redhat-menus-8.9.10-10.fc8 -------------------------- * Fri Sep 07 2007 Matthias Clasen - 8.9.10-10 - More category finetuning; remove remaining overrides * Thu Sep 06 2007 Ray Strode - 8.9.10-9 - create /etx/xdg/menus/settings-merged by default * Mon Jul 02 2007 Matthias Clasen - 8.9.10-8 - More category finetuning resapplet-0.1.1-6.fc8 --------------------- * Thu Sep 06 2007 Stepan Kasal 0.1.1-6 - resapplet.desktop.in; s/SystemTools/System/, to conform with http://standards.freedesktop.org/menu-spec/latest/apa.html - Fix License: tag, add Url: * Fri Dec 22 2006 Radek Vok??l 0.1.1-5 - Call automake with "--add-missing". - Call aclocal before intltoolize. revisor-2.0.4.3-7.fc8 --------------------- * Fri Sep 07 2007 Jeroen van Meeuwen 2.0.4.3-7 - Bugfixes - Removed pungi dependency - Added kickstart interfacing for pykickstart API differences - Enable Revisor to run in CLI mode on Enterprise Linux 5 - Split comps in their own package - Add rebrand module - Fixed pkgorder, copy_dir - Development release * Thu Aug 09 2007 Jeroen van Meeuwen 2.0.4.2-1 - Added Source RPM Tree for Installation Media - Rebased livecd-tools and created/submitted the necessary patches - Added pre-alpha jigdo sub-package - Disable jigdo, virt and dual media compose for release - Lots of bug fixes - Fixed up some features * Thu Jul 26 2007 Jeroen van Meeuwen 2.0.4.2-1rc1 - Adding a workaround fix for yum issues rhgb-0.17.6-7.fc8 ----------------- * Tue Sep 04 2007 Ray Strode - 0.17.6-7 - don't show strings like "Starting random number generator" and "Starting console mouse services" anymore, since the subset we support aren't that good anyway, and it causes a lot of stutter when booting rhpl-0.209-3.fc8 ---------------- * Fri Aug 31 2007 Lubomir Kundrak - 0.209-3 - Compile in build, not in prep. rogue-5.4.4-1.fc8 ----------------- * Sun Sep 02 2007 Wart 5.4.4-1 - Update to 5.4.4 rpm-4.4.2.2-0.4.rc1 ------------------- * Wed Sep 05 2007 Panu Matilainen 4.4.2.2-0.4.rc1 - remove duplicated libraries from rpm-devel (#278151) * Tue Sep 04 2007 Panu Matilainen 4.4.2.2-0.3.rc1 - require gawk, not awk, doh * Tue Sep 04 2007 Panu Matilainen 4.4.2.2-0.2.rc1 - add back accidentally dropped debugedit patch until upstreamed - add a bunch of previously implicit dependencies for rpm-build rpmlint-0.81-1.fc8 ------------------ * Mon Sep 03 2007 Ville Skytt?? - 0.81-1 - 0.81, fixes #239611, #240840, #241471, #244835. - Improve Fedora license check (Todd Zullinger). - Sync Fedora license list with Wiki rev 87. * Wed Aug 29 2007 Ville Skytt?? - Sync Fedora license list with Wiki rev 84 (Todd Zullinger). rsync-2.6.9-3.1.fc8 ------------------- * Wed Sep 05 2007 Simo Sorce 2.6.9-3.fc8 - Add patch to fix crash bug with hardlinks and ACLs patches rt3-3.6.4-1.fc8 --------------- * Tue Sep 04 2007 Ralf Cors??pius - 3.6.4-1 - Upstream update. * Tue Sep 04 2007 Ralf Cors??pius - 3.6.3-2 - Update license tag. rubygem-mongrel-1.0.1-5.fc8 --------------------------- * Sat Sep 01 2007 Scott Seago - 1.0.1-5 - Include cgi multipart fix * Fri Aug 24 2007 Scott Seago - 1.0.1-4 - rpmlint fixes - added Ruby >= 1.8.6 Requires * Thu Aug 23 2007 Scott Seago - 1.0.1-3 - Removed requirement for rubygem(cgi_multipart_eof_fix) - Patched source to work without cgi_multipart_eof_fix scorchwentbonkers-1.1-4.fc8 --------------------------- * Fri Aug 31 2007 Hans de Goede 1.1-4 - Fix Source0 URL selinux-policy-3.0.7-7.fc8 -------------------------- * Fri Sep 07 2007 Dan Walsh 3.0.7-7 - Turn off direct transition * Fri Sep 07 2007 Dan Walsh 3.0.7-6 - Allow wine to run in system role sip-4.6-2.fc8 ------------- * Thu Aug 30 2007 Than Ngo - 4.6-2.fc7 - typo in description sipp-2.0.1-4.fc8 ---------------- * Fri Sep 07 2007 Peter Lemenkov 2.0.1-4 - Removed .svn entries (close BZ #282431) - Added macro for builds for EL-4 * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.2 - finally added correct BR for EL-4 * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.1 - rebuild slim-1.3.0-1.fc8 ---------------- * Mon Aug 06 2007 Anders F Bjorklund 1.3.0-1 - version upgrade smartmontools-1:5.37-6.fc8 -------------------------- * Tue Sep 04 2007 Tomas Smetana - 1:5.37-6 - fix #271741 - smartd-conf.py should allow customization of parameters - fix #253753 - service starting by default, perhaps shouldn't - update initscript (related #247058 - initscript review) smb4k-0.8.4-2.fc8 ----------------- * Fri Aug 31 2007 Marcin Garski 0.8.4-2 - Fix license tag snort-2.7.0.1-3.fc8 ------------------- * Fri Aug 31 2007 Dennis Gilmore - 2.7.0.1-3 - fix for glibc open * Fri Aug 31 2007 Dennis Gilmore - 2.7.0.1-2 - fix detection of mysql and libnet10 * Mon Aug 27 2007 Dennis Gilmore - 2.7.0.1-1 - update to 2.7.0.1 spandsp-0.0.4-0.4.pre8.fc8 -------------------------- * Fri Sep 07 2007 Jeffrey C. Ollie - 0.0.4-0.4.pre8 - Update to 0.0.4pre8 squashfs-tools-3.2-2 -------------------- * Wed Sep 05 2007 Jeremy Katz - 3.2-2 - fixes from package review (#226430) star-1.5a84-3.fc8 ----------------- * Fri Aug 31 2007 Dan Kopecek 1.5a84-3 - added -O0 to COPTX (CFLAGS) (see #255261) * Mon Aug 27 2007 Peter Vrabec 1.5a84-2 - fix segfault of data-change-warn option (#255261), patch from dkopecek at redhat.com * Fri Aug 24 2007 Peter Vrabec 1.5a84-1 - new upstream release with CVE-2007-4134 fix stardict-3.0.0-4.fc8 -------------------- * Mon Sep 03 2007 Hu Zheng - 3.0.0-4 - Small fix on spec file. subcommander-1.2.2-7.fc8 ------------------------ * Sun Sep 02 2007 Jochen Schmitt 1.2.2-7 - Rebuild agains updated neon lib (#243638) sudo-1.6.9p4-2.fc8 ------------------ * Thu Aug 30 2007 Peter Vrabec 1.6.9p4-2 - fix autotools stuff and add audit support sunifdef-3.1-4.fc8 ------------------ * Fri Aug 31 2007 RPM building - 3.1-4 - Fix source URL - Fix email addresses in changelog entries sylpheed-2.4.5-1 ---------------- * Fri Aug 31 2007 Michael Schwendt - 2.4.5-1 - Update to 2.4.5 (accumulated bug-fixes). system-config-kickstart-2.7.12-1.fc8 ------------------------------------ * Tue Sep 04 2007 Chris Lumens 2.7.12-1 - Rework network device dialog to not use four input boxes for each address. - Don't require a gateway or nameserver address (#215191). system-config-printer-0.7.74.1-1.fc8 ------------------------------------ * Fri Sep 07 2007 Tim Waugh 0.7.74.1-1 - 0.7.74.1: - Updated Polish translation (bug #263001). - Don't select the default printer after changes to another printer have been made. - Always construct URI from input fields when changing device (bug #281551). - Avoid busy-cursor traceback when window is not yet displayed. * Thu Aug 30 2007 Tim Waugh 0.7.74-1 - Updated pycups to 1.9.25. - 0.7.74: - Fixed New Class dialog. - UI fixes. * Sat Aug 25 2007 Tim Waugh - More specific license tag. system-config-samba-1.2.50-1.fc8 -------------------------------- * Fri Aug 31 2007 Nils Philippsen - 1.2.50 - bundle the GPL * Thu Aug 30 2007 Nils Philippsen - 1.2.49 - pull in updated translations tcsh-6.15-1.fc8 --------------- * Mon Aug 27 2007 Vitezslav Crhonek - 6.15-1 - Update to tcsh-6.15.00 - Fix license - Add gettext-devel to BuildRequires (AM_ICONV) * Wed Apr 25 2007 Vitezslav Crhonek - 6.14-16 - Fix floating exception in print_by_column() with unprintable characters (#233525) telepathy-gabble-0.5.14-1.fc8 ----------------------------- * Fri Sep 07 2007 Matej Cepl - 0.5.14-1 - New upstream version * Thu Aug 30 2007 Brian Pepple - 0.5.13-1 - Update to 0.5.13. - Bump minimum version of telepathy-glib. tesseract-2.01-1.fc8 -------------------- * Fri Sep 07 2007 Karol Trzcionka - 2.01-1 - Upgrade to v2.01 tftp-0.42-5 ----------- * Fri Aug 31 2007 Maros Barabas - 0.42-5 - rebuild tibetan-machine-uni-fonts-1.0-2.fc8 ----------------------------------- tog-pegasus-2:2.6.1-1.fc8 ------------------------- * Thu Aug 30 2007 Vitezslav Crhonek - 2.6.1-1 - Update to 2.6.1 - Fix wrong init script (#245339) * Wed Mar 28 2007 Vitezslav Crhonek - 2.6.0-2 - Update changelog - Build with Open Pegasus' Makefiles, istall with RedHats (Mark Hamzy) tomboy-0.7.6-1.fc8 ------------------ * Tue Sep 04 2007 Matthias Clasen - 0.7.6-1 - Update to 0.7.6 * Sat Aug 25 2007 Ray Strode - 0.7.4-3 - Not sure why ppc64 is excluded and it's causing a broken conduit dep, try adding it back to the build. - Mono isn't available on ppc64, get rid of it again from the build tor-0.1.2.17-1.fc8 ------------------ * Fri Aug 31 2007 Enrico Scholz - 0.1.2.17-1 - updated to 0.1.2.17 * Sat Aug 25 2007 Enrico Scholz - 0.1.2.16-2 - fixed open(2) issue * Fri Aug 03 2007 Enrico Scholz - 0.1.2.16-1 - updated to 0.1.2.16 (SECURITY) torque-2.1.8-3.fc8 ------------------ * Fri Aug 31 2007 Garrick Staples 2.1.8-3 - correct License tag tracker-0.6.2-1.fc8 ------------------- * Wed Sep 05 2007 Deji Akingunola - 0.6.2-1 - Version 0.6.2 udev-115-2.fc8 -------------- * Fri Sep 07 2007 Harald Hoyer - 115-2 - some upstream fixes from git - last_rule for loop rules (speedup for live-cds/qemu with 128 loop devices) * Fri Aug 24 2007 Harald Hoyer - 115-1 - version 115 unzip-5.52-5.fc8 ---------------- * Tue Sep 04 2007 Ivana Varekova - 5.52-5 - fix open call usbsink-0.3.2-1.fc8 ------------------- * Mon Sep 03 2007 Jef Spaleta 0.3.2-1 New upstream version usermode-1.93-1.fc8 ------------------- * Wed Sep 05 2007 Miloslav Trma?? - 1.93-1 - Fix handling of PAM conversations with no questions Resolves: #267361 - Update License: util-vserver-0.30.214-1.fc8 --------------------------- * Mon Sep 03 2007 Enrico Scholz - 0.30.214-1 - updated to 0.30.214 vala-0.1.3-2.fc8 ---------------- * Tue Sep 04 2007 Michel Salim - 0.1.3-2 - Enable binding generation tools * Sun Sep 02 2007 Michel Salim - 0.1.3-1 - Update to 0.1.3 valgrind-1:3.2.3-6 ------------------ * Fri Aug 31 2007 Jakub Jelinek 3.2.3-6 - handle new x86_64 nops (#256801, KDE#148447) - add support for private futexes (KDE#146781) - update License tag varnish-1.1.1-3.fc8 ------------------- * Sat Sep 08 2007 Ingvar Hagelund - 1.1.1-3 - Added a patch, changeset 1913 from svn trunk. This makes varnish more stable under specific loads. * Thu Sep 06 2007 Ingvar Hagelund - 1.1.1-2 - Removed autogen call (only diff from relase tarball) * Mon Aug 20 2007 Ingvar Hagelund - 1.1.1-1 - Bumped the version number to 1.1.1. vavoom-1.24-3.fc8 ----------------- * Fri Aug 31 2007 Hans de Goede 1.24-3 - Fix some security issues in the server: CVE-2007-4533, CVE-2007-4534, CVE-2007-4535 (bz 256621) vim-2:7.1.100-1.fc8 ------------------- * Fri Sep 07 2007 Karsten Hopp 7.1.100-1 - patchlevel 100 vino-2.19.92-1.fc8 ------------------ * Tue Sep 04 2007 Matthias Clasen - 2.19.92-1 - Update to 2.19.92 vpnc-0.4.0-4.fc8 ---------------- * Mon Sep 03 2007 Tomas Mraz - 0.4.0-4 - fix long standing bug causing problems on x86_64 (#232565) now for real w3c-libwww-5.4.1-0.6.20060206cvs.fc8 ------------------------------------ * Fri Sep 07 2007 Andreas Bierfert 5.4.1-0.6.20060206cvs - enable reentrant wcstools-3.7.0-1.fc8 -------------------- * Wed Sep 05 2007 Sergio Pascual 3.7.0-1 - New upstream source 3.7.0 webalizer-2.01_10-34 -------------------- * Thu Aug 30 2007 Joe Orton 2.01_10-34 - clarify License tag wordpress-2.2.2-0.fc7 --------------------- * Wed Aug 29 2007 John Berninger - 2.2.2-0 - update to upstream 2.2.2 - license tag update x11-ssh-askpass-1.2.4.1-3.fc8 ----------------------------- * Sun Feb 04 2007 Enrico Scholz - 1.2.4.1-3 - rebuilt with -Wl,--as-needed xarchon-0.50-5.fc8 ------------------ * Fri Aug 31 2007 Hans de Goede 0.50-5 - Update Debian patch set to 0.50-10.1 xgalaxy-2.0.34-7.fc8 -------------------- * Fri Aug 31 2007 Hans de Goede 2.0.34-7 - Update Debian patch to the 2.0.34-44 version xine-lib-1.1.8-1.fc8 -------------------- * Thu Aug 30 2007 Ville Skytt?? - 1.1.8-1 - 1.1.8, "open" patch applied upstream. - Build XCB plugins by default for Fedora 8+ only. xkeyboard-config-1.0-1.fc8 -------------------------- * Wed Sep 05 2007 Matthias Clasen - 1.0-1 - Update to 1.0 - Drop upstreamed patches - Update remaining patches xmlrpc-c-1.06.18-1.fc8 ---------------------- * Tue Sep 04 2007 Enrico Scholz - 1.06.18-1 - updated to 1.06.18 xmlrpc3-3.0-1jpp.4.fc8 ---------------------- * Fri Sep 07 2007 Andrew Overholt 3.0-1jpp.4 - Disable ppc64 (rh#239123). * Fri Sep 07 2007 Andrew Overholt 3.0-1jpp.3 - Add OSGi manifests. * Fri Aug 24 2007 Andrew Overholt 3.0-1jpp.2 - Rebuild. xorg-x11-drivers-7.2-7.fc8 -------------------------- * Fri Sep 07 2007 Adam Jackson 7.2-7 - Add linuxwacom and synaptics to the default set. xorg-x11-drv-cyrix-1.1.0-5.fc8 ------------------------------ * Thu Sep 06 2007 Adam Jackson 1.1.0-5 - Fix license. Disown the module and driver directories. (#226585) xorg-x11-drv-neomagic-1.1.1-4.fc8 --------------------------------- * Thu Sep 06 2007 Adam Jackson 1.1.1-4 - Fix license. Disown the module and driver dirs. (#226610) xorg-x11-drv-nsc-2.8.1-4.fc8 ---------------------------- * Thu Sep 06 2007 Adam Jackson 2.8.1-4 - Fix license. Disown the module and driver dirs. (#226611) xorg-x11-drv-sisusb-0.8.1-9.fc8 ------------------------------- * Thu Sep 06 2007 Adam Jackson 0.8.1-9 - Disown the manual directory. (#226622) xorg-x11-drv-vga-4.1.0-5.fc8 ---------------------------- * Thu Sep 06 2007 Adam Jackson 4.1.0-5 - Fix license. Disown the module and driver dirs. (#226632) xorg-x11-drv-via-0.2.2-4.fc8 ---------------------------- * Thu Sep 06 2007 Adam Jackson 0.2.2-4 - Explain why there's no ldconfig for the xvmc drivers. (#226633) xorg-x11-server-1.3.0.0-23.fc8 ------------------------------ * Thu Sep 06 2007 Adam Jackson 1.3.0.0-23 - xserver-1.3.0-xrandr-timestamp-buglet.patch: Make sure xrandr doesn't stop working after several hours. (Marius Gedminas, #273801) * Fri Aug 24 2007 Adam Jackson 1.3.0.0-22 - Bump BuildRequires: xorg-x11-xtrans-devel to pull in abstract socket support. * Thu Aug 23 2007 Adam Jackson 1.3.0.0-21 - xserver-1.3.0-document-fontpath-correctly.patch: Fix man page to point to directories that exist. (#251203, Mat??j Cepl) xsane-0.994-3.fc8 ----------------- * Wed Sep 05 2007 Nils Philippsen - 0.994-4 - change license to GPLv2+ xscorch-0.2.0-12.fc8 -------------------- * Fri Aug 31 2007 Marcin Garski 0.2.0-12 - Fix license tag xscreensaver-1:5.03-3.fc8 ------------------------- * Mon Sep 03 2007 Mamoru Tasaka - 1:5.03-3 - Don't split hack part of XScreenSaver.ad into each hack piece and make update script allow multiple hacks in one config file (along with rss-glx, bug 200881) - move hack update scripts to %_sbindir * Sun Sep 02 2007 Mamoru Tasaka - 1:5.03-2 - Try to make XScreenSaver.ad modular (bug 200881) xtide-2.9.4-1.fc8 ----------------- * Wed Sep 05 2007 Mamoru Tasaka - 2.9.4-1 - 2.9.4 (Relicensed: GPLv2+ -> GPLv3+) - Update user creation script yum-3.2.4-4.fc8 --------------- * Wed Sep 05 2007 Jeremy Katz - 3.2.4-4 - test patch for only packages which are not being otherwise updated to not be shown as being updated for deps yum-updatesd-1:0.5-1.fc8 ------------------------ * Wed Sep 05 2007 Jeremy Katz - 1:0.5-1 - add option for configurable SMTP server - fix email sending (Rich Fearn, #251196) - make updates checking in the presence of NetworkManager smarter (#213732) - ensure group info gets updated - work with yum 3.0.x (jantill) - don't poll gamin zeroinstall-injector-0.30-1.fc8 ------------------------------- * Wed Sep 05 2007 Michel Salim 0.30-1 - Update to 0.30 - License is now versioned - Incorporate changes from Thomas Leonard: * create zeroinst user * create shared cache Broken deps for i386 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.i386 requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.i386 requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.i386 requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.i386 requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.i386 requires libsqlite.so.0 glest - 2.0.1-1.fc8.i386 requires glest-data = 0:2.0.1 glest-data - 2.0.0-5.fc8.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-PAE - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.124.rc3.git2.fc8PAE kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8 kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE moodss - 21.5-1.fc7.i386 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.i386 requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.i386 requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10 referencer - 1.0.4-3.fc8.i386 requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.i386 requires libpoppler-glib.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.x86_64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.x86_64 requires firefox = 0:2.0.0.5 anjuta - 1:2.2.0-2.fc8.i386 requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.i386 requires libgraph.so.3 anjuta - 1:2.2.0-2.fc8.x86_64 requires libgvc.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libgraph.so.3()(64bit) anjuta - 1:2.2.0-2.fc8.x86_64 requires libcdt.so.3()(64bit) claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) csync2 - 1.33-5.fc7.x86_64 requires libsqlite.so.0()(64bit) glest - 2.0.1-1.fc8.x86_64 requires glest-data = 0:2.0.1 glest-data - 2.0.0-5.fc8.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8 moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.x86_64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.x86_64 requires libsqlite.so.0()(64bit) polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit) referencer - 1.0.4-3.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) ruby-poppler - 0.16.0-10.fc8.x86_64 requires libpoppler-glib.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc requires firefox = 0:2.0.0.5 Miro - 0.9.8.1-2.fc7.ppc requires libboost_python.so.2 anjuta - 1:2.2.0-2.fc8.ppc requires libgvc.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libcdt.so.3 anjuta - 1:2.2.0-2.fc8.ppc requires libgraph.so.3 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc requires libpoppler-glib.so.1 csync2 - 1.33-5.fc7.ppc requires libsqlite.so.0 gambas-gb-db - 1.0.19-1.fc8.2.ppc requires libsqlite.so.0 kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-smp - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.124.rc3.git2.fc8smp moodss - 21.5-1.fc7.ppc requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler.so.1 pdfcube - 0.0.2-4.fc8.ppc requires libpoppler-glib.so.1 perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc requires libsqlite.so.0 polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10 python-vcpx - 0.9.28-4.fc8.noarch requires monotone referencer - 1.0.4-3.fc8.ppc requires libpoppler-glib.so.1 ruby-poppler - 0.16.0-10.fc8.ppc requires libpoppler-glib.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro - 0.9.8.1-2.fc7.ppc64 requires libboost_python.so.2()(64bit) Miro - 0.9.8.1-2.fc7.ppc64 requires firefox = 0:2.0.0.5 claws-mail-plugins-pdfviewer - 2.10.0-2.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-changelog eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-subclipse eclipse-platform - 1:3.3.0-18.fc8.ppc64 requires eclipse-rpm-editor kmod-em8300 - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8 kmod-em8300-kdump - 0.16.3-5.2.6.23_0.124.rc3.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.124.rc3.git2.fc8kdump moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22 pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) pdfcube - 0.0.2-4.fc8.ppc64 requires libpoppler.so.1()(64bit) perl-DBD-SQLite2 - 0.33-7.fc8.1.ppc64 requires libsqlite.so.0()(64bit) referencer - 1.0.4-3.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display ruby-poppler - 0.16.0-10.fc8.ppc64 requires libpoppler-glib.so.1()(64bit) xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics xorg-x11-drivers - 7.2-7.fc8.ppc64 requires linuxwacom From nicolas.mailhot at laposte.net Fri Sep 14 11:52:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Sep 2007 11:52:15 -0000 Subject: [Long] Do we need a font SIG ? Message-ID: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org> Hi all [I wanted to prepare a bit more before writing this, but it seems everyone is asking about the same things at once, so this will have to do] I'd like know what people think of setting up a font SIG, and if there are enough would-be contributors for such a SIG to be viable. Fonts are a very transversal subject in Fedora, and the initial To: list reflects this. Please take care to reply on fedora-devel only however. The situation right now is: 1. we have several font packages in Fedora, but are only scratching what could be packaged. http://mihmo.livejournal.com/45152.html 2. In particular the art team wants a lot more fonts in for its Art spin http://fedoraproject.org/wiki/Artwork/ArtTeamProjects/FedoraArtStudio 3. I don't believe our font selection is optimal for every locale. It took a near-revolt by our Greek users to get their situation fixed in Fedora Core 6, and there are probably many other problem locales, where users just pass on Fedora or bear their pain silently instead of telling us about problems. 4. The i18n team is nominally in charge of selecting the best fonts for each locale, but does not always have the right local contacts to do so. So far i18n has focused on technical problems : if your locale needs complex IM methods you have i18n visibility, if your locale poses no technical challenge but your default fonts are suboptimal the i18n team may not notice you. 4. The l10n team has local contacts and could provide useful feedback on font choices, currently packaged font problems, local foundries/font designers that could be contacted to contribute to the FLOSS font pool, etc but has mostly focused on translation so far. 5. The desktop team handles our font infrastructure and takes the heat when a font is badly rendered (since we can not use the patented freetype autohinter many fonts that work fine under windows do not under Fedora) 6. We already have some font-related material disseminated on our wiki: - packaging rules, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 - licensing rules http://fedoraproject.org/wiki/Licensing#head-63f9d798a33b23a752e5a3b22a0888046d4cb8d8 - other http://fedoraproject.org/wiki/Fonts/DejaVu 7. The font situation is bad enough we have a font exception to our FLOSS rules http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac [for example we ship Luxi even though its licensing forbids modification, making it non-free http://www.xfree86.org/current/LICENSE11.html] 8. There are efforts to drain the font licensing swamp and promote FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with Fedora general objectives yet Fedora has totally ignored them so far (cf Liberation licensing choices) This is a stark contrast with the very active debian font team : http://wiki.debian.org/DebianInstaller/GUIFonts The main part of the OLPC font page is the Debian font list! http://wiki.laptop.org/go/Fonts I believe there is enough interest in the various Fedora groups to improve the current situation through a font SIG. This SIG would be tasked with: A. providing a single point of entry for Fedora people interested in fonts, centralizing all our packaging rules or at least indexing them in a single place B. completing the existing font packaging documentation C. helping the i18n team maintain the font install list for each locale D. identifying fonts worthy of packaging for l10n or art reasons E. identifying problems in existing font packages and helping relay the info upstream F. identifying problems in our font infrastructure, packaging necessary font tools G. coordinating and effectively packaging new fonts As the current maintainer of dejavu, and a co-maintainer of charis and dejavu-lgc, I am ready to write a commented font spec example (B) (without legacy core font bits, which IMHO should be optional nowadays ; however I'm sure there are people ready and willing to write this part as an extension), and package a few fonts (G). The l10n and i18n groups are naturals for (C). We just have to steal the Debian receipe of having a font-by-locale table in our wiki. I think it's pretty obvious the art team is motivated by (E). IMHO the l10n team should have a role there too. Note that doing the legal analysis of a potential font is far from easy as font licensing practices are far less clean than software licensing practices. Also we should try to build font from sources whenever possible, but font building is often a mess. G will demand packagers and reviewers. By nature most of them will be active in other Fedora forums, so we're not talking of a few full-time SIG members but a lot of part-time contributors. I created a mockup wiki page to try to make all this clear http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix It's far from complete, but I hope it's complete enough to give everyone an idea of the potential SIG scope. So, who wants to play? Is Fedora ready for a font SIG or should I ask again next year? Kind regards, -- Nicolas Mailhot